Anda di halaman 1dari 176

U     

U

FACULTAD DE INGENIERIA
CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS
MODALIDAD PRO-TESIS

Estudio comparativo de sistemas de planificacin de recursos empresariales basados


en software libre para satisfacer las necesidades de informacin en el proceso de
negocio de las mypes en el sector manufacturero de la ciudad de cusco

Presentado por: Br. Wilson Ademir Aragn lvarez


PARA OPTAR EL TTULO PROFESIONAL DE INGENIERO DE SISTEMAS
Asesor: Mgt. Cristhian Eduardo Ganvini Valcarcel

CUSCO, NOVIEMBRE DE 2014

DEDICATORIA

La concepcin de esta tesis est dedicada a mi familia ya que gracias a ellos soy lo que
soy.
Para mis padres por su apoyo, consejos, comprensin, amor, ayuda en los momentos
difciles, y por ayudarme con los recursos necesarios para estudiar. Me han dado todo lo
que soy como persona, mis valores, mis principios, mi carcter, mi empeo, mi
perseverancia, as como mi coraje para conseguir mis objetivos.

La dicha de la vida consiste en tener siempre que hacer, alguien a quien amar y alguna cosa que
esperar. Thomas Chalmers.

AGRADECIMIENTOS

En primer lugar a Dios por haberme guiado por el camino de la felicidad hasta ahora: en
Segundo lugar a cada uno de los que son parte de mi familia, a mis padres Wilfredo y
Carmen.

Por ltimo a mi asesor de tesis quin me ayud en todo momento: Mgt. Christian Ganvini.

RESUMEN

El presente trabajo de tesis se realiz con el fin de mostrar la validez de los sistemas
integrados de planificacin de recursos empresariales basados en software libre para las
MYPES del sector manufacturero en la ciudad del Cusco.

Inicialmente se estudi las empresas Cermicas y Arte Ruiz Caro y Cermicas


Kantu de las cuales se sac el proceso de fabricacin, as como el listado las reas de casa
empresas y sus necesidades bsicas de informacin.

Posteriormente se estudi los sistemas OpenERP y OpenBravo de los cuales se vio


cada uno de sus mdulos principales, as como sus caractersticas funcionales y tcnicas.

Finalmente se evalu ambos sistemas tomando en cuenta criterios de la


metodologa de seleccin de sistemas integrados de planificacin de recursos empresariales:
Metodologa para seleccin de sistemas erp (MSSE), para dar con la solucin ms
adecuada a las empresas estudiadas.

ABSTRACT

This thesis work was carried out in order to show the validity of the integrated
systems of ERP based on free software for the manufacturing sector MSEs of Cusco.

Initially Ceramics and Art Ruiz Caro and Pottery Kantu companies of which the
manufacturing process is cleared, and the list of home business areas and their basic
information needs are studied.

Subsequently OpenBravo OpenERP and systems which saw each of its core modules and
their functional and technical characteristics was studied.

Finally taking into account both criteria selection methodology of integrated ERP systems:
Methodology for selection of erp systems (MSSE) was evaluated to give the best solution
to the companies studied.

INTRODUCCIN

La tesis se comienza a realizar con un anlisis acerca de la situacin actual de las


pequeas y medianas empresas (Mypes) con respecto al uso de tecnologas de informacin,
ms especficamente en este caso, sistemas integrados de planificacin de recursos
empresariales.

En el segundo captulo se estudian los conceptos bsicos referidos a los sistemas


integrados de planificacin de recursos empresas y acerca de las pequeas y medianas
empresas MYPES, as como metodologas para la seleccin de sistemas ERP.

En el tercer captulo se define la muestra a estudiarse en este caso las empresas de


cermicos Ruiz Caro y Kantu, de las cuales se estudian sus caractersticas en relacin a las
reas que las componen y las necesidades de informacin de estas.

Luego se estudian las caractersticas y mdulos de los sistemas OpenERP,


OpenBravo y SAP ERP.

En el cuarto captulo se comparan las soluciones OpenBravo y OpenERP tomando


en cuenta criterios a nivel de arquitectura y funciones tcnicas.

El quinto captulo se analiza los resultados de las comparaciones y se da una


alternativa para las empresas estudiadas.

Finalmente se dan las conclusiones y recomendaciones dadas como resultado del


trabajo de investigacin.

INDICE

Dedicatoria
Agradecimientos
Resumen
Abstract
Introduccin

i
ii
iii
iv
v
CAPITULO I ASPECTOS GENERALES

Descripcin de la situacin actual


Formulacin del problema
Objetivos
Objetivo general
Objetivos especficos
Justificacin
Metodologa

1
1
2
2
2
3
3

CAPITULO II MARCO TERICO


2.1. Aspectos tericos pertinentes
2.1.1. Sistema de planificacin de recursos empresariales
2.1.2. Pequea y mediana empresa
2.1.3. Gestin empresarial
2.1.4. Manufactura
2.1.5. Actividades que abarca la manufactura
2.1.6. Tendencias y demandas en manufactura
2.1.7. Importancia de los sistemas ERP
2.1.8. Caractersticas de los sistemas ERP
2.1.9. Beneficios de los sistemas ERP
2.1.9.1. Beneficios tangibles
2.1.9.2. Beneficios intangibles
2.1.10. Riesgos de los sistemas ERP
2.1.10.1. Riesgos relacionados a las personas
2.1.10.2. Riesgos relacionados al proceso
2.1.10.3. Riesgos relacionados a la tecnologa
2.1.10.4. Riesgos relacionados a la implantacin
2.1.11. Tecnologas relacionadas a los sistemas ERP
2.1.12. Sistemas ERP Libres VS Sistemas ERP Propietarios
2.1.13. Objetivo de los sistemas ERP
2.1.14. Metodologa MSSE
2.1.14.1. Estructura de MSSE
2.1.14.2. Fases de MSSE
2.1.14.2.1. Fase 1 Seleccin
2.1.14.2.1.1. Actividad 1 Documentar la necesidad

4
4
4
5
5
6
6
8
8
10
10
10
11
12
12
13
13
14
15
17
18
19
20
20
20

2.1.14.2.1.2. Actividad 2 - Primera seleccin


2.1.14.2.1.3. Actividad 3 Seleccin final
2.1.14.2.2. Fase 2 Seleccin del equipo de consultora
2.1.14.2.2.1. Actividad 1 Documentar fases de la bsqueda
2.1.14.2.2.2. Actividad 2 Seleccin de candidatos
2.1.13.2.3. Fase 3 Presentacin y planificacin general del proyecto
2.1.15. ERP System Selection Key Factors
2.1.15.1. Estructura de ERP System Selection Key Factors
2.1.16. Software libre
2.1.17. GNU / Linux
2.1.18. Caractersticas de las Mypes
2.1.19. Criterios para determinar si una Mype es formal
2.1.20. Situacin actual de las empresas manufactureras en la provincia de
Cusco
2.1.21. Distribucin total de las empresas manufactureras en la regin de
Cusco
CAPITULO III METODOLOGA

22
27
29
29
30
33
34
34
35
36
36
37
37

3.1. Tipo de investigacin


3.2. Poblacin y muestra
3.2.1. Poblacin de estudio
3.2.2. Muestra
3.3. Instrumentos
3.4. Recoleccin y anlisis de datos
3.4.1. Recoleccin y anlisis de datos de la empresa Cermica y Arte Ruiz
Caro SAC.
3.4.1.1. Breve descripcin de la empresa
3.4.1.2. Organigrama de la empresa
3.4.1.3. Proceso bsico de fabricacin de la empresa
3.4.2. Recoleccin y anlisis de datos de la empresa Cermicas Kantu
3.4.2.1. Breve descripcin de la empresa
3.4.2.2. Organigrama de la empresa
3.4.2.3. Proceso bsico de fabricacin de la empresa
3.4.3. Necesidades por reas de las empresas
3.4.3.1. Gerencia
3.4.3.2. Contabilidad
3.4.3.3. Almacn
3.4.3.4. Ventas
3.4.3.5. Recursos Humanos
3.4.3.6. Logstica
3.4.4. Anlisis del ERP OpenERP.
3.4.4.1. Aspectos funcionales
3.4.4.1.1. Propsito principal
3.4.4.1.2. reas soportadas
3.4.4.1.3. Adaptabilidad y flexibilidad
3.4.4.1.4. Facilidad de parametrizacin
3.4.4.1.5. Facilidad para hacer desarrollos propios

39
39
39
39
40
40
40

38

40
41
42
43
43
44
45
46
46
46
46
47
48
48
49
49
49
49
59
59
59

3.4.4.1.6. Interaccin con otros sistemas


3.4.4.1.7. Soporte especfico de algunos temas
3.4.4.1.8. Multilenguaje
3.4.4.1.9. Localizaciones y presentaciones legales
3.4.4.1.10. Comunicacin con bancos
3.4.4.1.11. Operaciones multimoneda
3.4.4.1.12. Herramientas amigables de reporting
3.4.4.2. Aspectos tcnicos
3.4.4.2.1. Adaptabilidad a la estructura del cliente
3.4.4.2.2. Distintos ambientes
3.4.4.2.3. Multiplataforma
3.4.4.2.4. Instalacin remota
3.4.4.2.5. Cliente / Servidor
3.4.4.2.6. Base de Datos
3.4.4.2.7. Herramientas de lenguaje de programacin
3.4.4.2.8. Seguridad
3.4.4.2.8.1. Descripcin de cada rol
3.4.4.2.9. Backup
3.4.4.2.10. Auditoria
3.4.4.2.11. Gestor de configuraciones
3.4.4.2.12. Documentacin
3.4.4.2.13. Documentacin tcnica
3.4.4.2.14. Conectividad externa
3.4.4.2.15. Compatibilidad con correo electrnico
3.4.5. Anlisis del ERP OpenBravo
3.4.5.1. Aspectos funcionales
3.4.5.1.1. Propsito principal
3.4.5.1.2. reas soportadas
3.4.5.1.3. Adaptabilidad y flexibilidad
3.4.5.1.4. Facilidad de parametrizacin
3.4.5.1.5. Facilidad para hacer desarrollos propios
3.4.5.1.6. Interaccin con otros sistemas
3.4.5.1.7. Soporte especifico de algunas temas
3.4.5.1.8. Multilenguaje
3.4.5.1.9. Localizaciones y presentaciones legales
3.4.5.1.10. Comunicacin con bancos
3.4.5.1.11. Operaciones multimoneda
3.4.5.1.12. Herramientas amigables de reporting para el usuario
3.4.5.2. Aspectos tcnicos
3.4.5.2.1. Adaptabilidad a la estructura del cliente
3.4.5.2.2. Distintos ambientes
3.4.5.2.3. Multiplataforma
3.4.5.2.4. Instalacin remota
3.4.5.2.5. Cliente / Servidor
3.4.5.2.6. Base de datos
3.4.5.2.7. Herramientas de lenguaje de programacin
3.4.5.2.8. Seguridad

60
60
60
61
61
61
62
63
63
63
63
64
64
66
68
69
71
72
73
74
74
74
74
74
75
75
75
75
80
80
80
81
81
81
82
82
82
82
84
84
84
84
84
84
88
89
92

3.4.5.2.9. Backup
3.4.5.2.10. Auditoria
3.4.5.2.11. Gestor de configuraciones
3.4.5.2.12. Documentacin
3.4.5.2.13. Documentacin tcnica
3.4.5.2.14. Conectividad externa
3.4.5.2.15. Compatibilidad con correo electrnico

93
94
94
95
95
95
95

CAPITULO IV RESULTADOS

96

CAPITULO V DISCUSION

99

CONCLUSIONES
RECOMENDACIONES
REFERENCIAS

105
106
107

INDICE DE TABLAS

Tabla 1 Estructura de MSSE


Tabla 2 Estructura de SKSF
Tabla 3 Listado de criterios ponderados MSSE
Tabla 4 Listado de criterios ponderados para la Tesis
Tabla 5 Sistema de calificacin puntual
Tabla 6 Evaluacin de aspectos funcionales
Tabla 7 Evaluacin de aspectos tcnicos
Tabla 8 Resultados de aspectos funcionales
Tabla 9 Resultados de aspectos funcionales

19
34
Anexo 1
Anexo 2
92
93
94
96
97

INDICE DE GRAFICOS

Grafico 1 Organigrama Ruiz Caro


Grafico 2 Proceso Produccin Ruiz Caro
Grafico 3 Organigrama Kantu
Grafico 4 Proceso Produccin Kantu
Grafico 5 Modulo CRM OpenERP
Grafico 6 Modulo Proyectos OpenERP
Grafico 7 Modulo Almacn OpenERP
Grafico 8 Modulo Contabilidad OpenERP
Grafico 9 Modulo Compras OpenERP
Grafico 10 Modulo Ventas OpenERP
Grafico 11 Modulo RR.HH OpenERP
Grafico 12 Modulo Marketing OpenERP
Grafico 13 Modulo Fabricacin OpenERP
Grafico 14 Proceso Interno Reportes OpenERP
Grafico 15 Arquitectura de OpenERP
Grafico 16 MVC de OpenERP
Grafico 17 Modulo Gestin Datos Maestros OpenBravo
Grafico 18 Modulo Compras OpenBravo
Grafico 19 Modulo Ventas OpenBravo
Grafico 20 Modulo Contabilidad y Finanzas OpenBravo
Grafico 21 Modulo Almacn OpenBravo
Grafico 22 Diseo de informes en OpenBravo
Grafico 23 Arquitectura de OpenBravo
Grafico 24 MVC de OpenBravo
Grafico 25 Entorno de desarrollo de OpenBravo
Grafico 26 Procesos de desarrollo de OpenBravo
Grafico 27 Resultados Aspectos Funcionales
Grafico 28 - Resultados Aspectos Tcnicos
Grafico 29 Resultado General a nivel de aspectos
Grafico 30 Resultado Final ERP

41
42
44
45
50
51
52
53
54
55
56
57
58
62
64
64
72
73
74
75
76
80
82
83
87
88
97
98
99
100

CAPITULO I

ASPECTOS GENERALES

1.1. Descripcin de la situacin actual

Segn los resultados de la encuesta de micro y pequea empresa


2013 realizados por el INEI (1); actualmente en nuestra ciudad, son pocas
las medianas y pequeas empresas del sector manufacturero que
cuentan con sistemas de planificacin de recursos empresariales como
herramienta para una mejor gestin organizacional, esto se pudo
comprobar luego de la visita a dos mypes del sector manufacturero en la
ciudad el Cusco.

Esto es debido principalmente al desconocimiento de estas


herramientas, as como a los costos que implica su implementacin y
puesta en funcionamiento.

1.2. Formulacin del problema

Problema general:
Cul es el sistema de planificacin de recursos empresariales que
satisface todas las necesidades de informacin en el proceso de
negocio de las medianas y pequeas empresas en la ciudad del
Cusco?

Problemas especficos.
P1: Cules son las principales necesidades de informacin de
negocio de las medianas y pequeas empresas en la ciudad del
Cusco?
P2: Qu sistemas de planificacin de recursos empresariales
basados en software libre tenemos disponibles?

1.3. Objetivos

1.3.1. Objetivo General

Analizar las alternativas de sistemas de planificacin de recursos


empresariales basados en software libre que cubran las necesidades de
informacin en medianas y pequeas empresas del sector manufacturero
para mejorar sus procesos de gestin de negocio.

1.3.2. Objetivos especficos

a) Determinar las necesidades de informacin en el proceso de


negocio de las medianas y pequeas empresas del sector
manufacturero.

b) Evaluar las alternativas de sistemas de planificacin de recursos


empresariales basadas en software libre.

c) Determinar criterios de seleccin funcionales de los sistemas de


planificacin de recursos empresariales.

d) Seleccionar la mejor alternativa de sistemas de planificacin de


recursos empresariales.

1.4. Justificacin
La presente tesis se realiz principalmente para fomentar el inters
en el uso de tecnologas de informacin como herramientas de ayuda y
mejora en los procesos de las medianas y pequeas empresas del sector
manufacturero de la ciudad del Cusco, as como tambin para mostrar la
validez del software libre frente a las alternativas de pago en este sector.

1.5 Metodologa
El tipo de investigacin utilizada fue una investigacin aplicada en
la cual se estudiaron las caractersticas y necesidades de informacin de
las MYPES del sector manufacturero de la ciudad y en base a ese estudio
se evaluaron los requisitos funcionales de cada sistema ERP propuesto.

CAPITULO II

MARCO TERICO

2.1. Aspectos tericos pertinentes

2.1.1. Sistema de planificacin de recursos empresariales

Un sistema de planificacin de recursos empresariales (ERP) es un


conjunto de herramientas y procesos que integra departamentos y
funciones a travs de una empresa en un sistema automtico. Un ERP
funciona con una sola base de datos, permitiendo a varios departamentos
compartir informacin y comunicarse con los dems. Los sistemas ERP
comprenden

mdulos

con

funciones

especficas

diseados

para

interactuar con los otros mdulos, por ejemplo, cuentas por cobrar,
cuentas por pagar, ventas, entre otros. (1)

2.1.2. Pequea y mediana empresa

La Micro y Pequea empresa es la unidad econmica constituida


por una persona natural o jurdica, bajo cualquier forma de organizacin o
gestin empresarial contemplada en la legislacin vigente, que tiene como
objeto desarrollar actividades de extraccin, transformacin, produccin,
comercializacin de bienes o prestacin de servicios.

Segn la Ley de promocin y formalizacin de la pequea y


mediana empresa; cuando se hace mencin a la sigla MYPE se est
refiriendo a las Micro y Pequeas Empresas, las cuales no obstante de
tener tamaos y caractersticas propias, tienen igual tratamiento en la
presente Ley, con excepcin al rgimen laboral que es de aplicacin para
las Microempresas. (2)

2.1.3. Gestin empresarial

Es la actividad empresarial que busca a travs de personas (como


directores institucionales, gerentes, productores, consultores y expertos)
mejorar la productividad y por ende la competitividad de las empresas o
negocios. Una ptima gestin no busca slo hacer las cosas mejor, lo
ms importante es hacer mejor las cosas correctas y en ese sentido es
necesario identificar los factores que influyen en el xito o mejor resultado
de la gestin. (3)

2.1.4. Manufactura

Es el proceso de convertir materias primas en productos. Tambin


comprende las actividades en que el propio producto se utiliza para
elaborar otros productos. Los ejemplos podran incluir a las grandes
prensas que formar las hojas metlicas usadas en accesorios y
carroceras para automviles, la maquinaria para fabricar sujetadores,
como tornillos y tuercas, y las mquinas de coser ropa. (4)

2.1.5. Actividades que abarca la manufactura

La manufactura es una actividad compleja que comprende una


amplia variedad de recursos y actividades, como las siguientes:

-Diseo del producto


-Maquinaria y herramienta
-Planeacin del proceso
-Materiales
-Compra
-Manufactura
-Control de produccin
-Servicios de soporte
-Mercadeo
-Ventas
-Embarque
-Servicios al cliente (4)

2.1.6. Tendencias y demandas en manufactura

a. Un producto debe satisfacer totalmente los requisitos de diseo,


especificaciones y normas.

b. Un producto debe manufacturarse mediante los mtodos ms


econmicos y amigables con el medio ambiente.

c. La calidad debe integrarse al producto en cada etapa, desde el


diseo hasta el ensamblado, en vez de confiar slo en las pruebas
de calidad despus de haberlo manufacturado.

d. En el muy competitivo ambiente actual, los mtodos de

produccin deben ser lo suficientemente flexibles para responder a


las cambiantes demandas del mercado, a los tipos de productos y
a las capacidades de produccin, a fin de asegurar una entrega
oportuna al cliente.

e. Los continuos desarrollos en materiales, mtodos de produccin


e integracin a las computadoras, tanto de las actividades
tecnolgicas como de las administrativas en una organizacin
manufacturera, deben evaluarse constantemente con miras a su
implantacin apropiada, oportuna y econmica.

f. Las actividades de manufactura deben verse como un gran


sistema, cuyas partes se relacionan entre s en grados variables.
Estos sistemas se pueden modelar para estudiar el efecto de
factores como los cambios en las demandas del mercado, el diseo
del producto, los materiales y los mtodos de produccin tanto en
la calidad como en el costo de los productos.

g. El fabricante debe trabajar con el cliente para obtener una


retroalimentacin oportuna y conseguir as una mejora continua del
producto. (4)

2.1.7. Importancia de los sistemas ERP

Los sistemas ERP son importantes para las empresas debido a su


mejora en la forma en que la empresa toma un pedido de un cliente y lo
procesa en una factura e ingresos (proceso de cumplimiento de la orden).
Los sistemas ERP hacen que el proceso de negocio sea automatizado y
ms racional y hace que la organizacin sea ms gil y competitiva para
que pueda responder a las necesidades cambiantes de los clientes y de la
competencia de forma rpida y eficiente. (4)

2.1.8. Caractersticas de los sistemas ERP

-Flexibilidad: Un sistema ERP es flexible de tal manera que


responde a las constantes transformaciones de las empresas. La
tecnologa cliente/servidor permite al sistema ERP operar sobre diferentes
bases de datos por las conexiones de bases de datos abiertas, pues es
muy probable que el mismo producto migre de un rea de produccin
para otra durante el ciclo total de produccin.

-Modularidad: El sistema ERP es un sistema de arquitectura abierta,


es decir, puede usar un mdulo libremente sin que este afecte los
restantes. El sistema soporta plataformas mltiples de hardware pues
muchas empresas poseen sistemas heterogneos. Debe tambin facilitar
la expansin y o/adaptabilidad de otros mdulos posteriormente.

-Comprensivo: El sistema debe estar apto a soportar las diferentes


estructuras organizacionales de las empresas, as como una vasta rea
negocios.

-Conectividad: El sistema no se debe confinar al espacio fsico de


la empresa y permitir la conexin con otras entidades pertenecientes al
mismo grupo empresarial.

-Seleccin de diferentes formas de negocio: Debe contener una


seleccin de las mejores prcticas de negocios en todo el planeta.

-Simulacin de la realidad: Debe permitir la simulacin de la


realidad de la empresa en el ordenador. De forma alguna el control del
sistema debe estar fuera del proceso de negocio y debe ser posible la
elaboracin de informes para los usuarios que controlan el sistema. (8)

2.1.9. Beneficios de los sistemas ERP (1)

2.1.9.1. Beneficios tangibles:

a) Reduccin de inventarios.
b) Reduccin de costos de mantenimiento de inventario.
c) Reduccin de plazos de entrega.
d) Reduccin de personal.
e) Reduccin del tiempo de ciclo.
f) Mejoras en la productividad.
g) Mejoras en la gestin.
h) Reduccin del ciclo de cierre financiero.
i) Reduccin de costos de TI.
j) Reduccin de costos de obtencin.
k) Mejoras en la gestin de caja.
l) Mejoras ingres/beneficio.
m) Reduccin de costos de calidad.
n) Mejora en la utilizacin de recursos.
o) Reduccin de costos de transporte / logstica.
p) Reduccin de mantenimientos.
q) Mejoras en los tiempos de entrega.

2.1.9.2. Beneficios intangibles

a) Visibilidad de la informacin.
b) Nuevos y mejorados procesos del negocio.
c) Capacidad de respuesta al cliente.
d) Mejora en el desempeo de los proveedores.
e) Mayor satisfaccin del consumidor.
f) Reduccin de costos.
g) Integracin de funciones del negocio.

10

h) Integracin de la informacin.
i) Mejores capacidades de anlisis y capacitacin.
j) Mejora de la precisin de la informacin.
k) Capacidad de toma de decisiones mejorada.
l) Estandarizacin de procesos del negocio.
m) Flexibilidad y agilidad empresarial.
n) Globalizacin de la organizacin.
o) Mejor rendimiento empresarial.
p) Integracin de la cadena de suministro.
q) Uso de tecnologa de punta.

2.1.10. Riesgos de los sistemas ERP (1)

Las implementaciones de ERP son de uso intensivo de recursos,


altamente complejas, lentas e impredecibles en trminos de costos y por
lo tanto muy arriesgadas.

Hay tres reas bsicas donde los problemas pueden ocurrir:


Personas, procesos y tecnologa.

11

2.1.10.1. Riesgos relacionados a las personas

Empleados, gestin, equipo de implementacin, consultores y


proveedores son el factor ms importante que determina el xito o el
fracaso de un sistema ERP.

Los principales problemas son:


a. Gestin del cambio
b. Adecuacin del personal interno
c. Equipo del proyecto
d. Formacin
e. Empleado re-localizacin y re-entrenamiento
f. Dotacin de personal (incluye la facturacin)
g. El apoyo de la alta direccin
h. Consultores
i. disciplina
j. La resistencia al cambio

2.1.10.2. Riesgos relacionados al proceso

El sistema ERP introducir cientos de nuevos procesos de negocio


y eliminar muchos de los actuales procesos. La gestin de la aplicacin
de la los procesos de negocio es un factor que decidir el xito de la
implementacin de ERP.

Las principales reas de inters son:


a. Gestin de Programas
b. Reingeniera de Procesos de Negocios
c. Etapa de Transicin
d. Realizacin de Beneficios

12

2.1.10.3. Riesgos relacionados a la tecnologa

Mantener el ritmo de los avances tecnolgicos es uno de los temas


muy importantes que determinarn el xito de la Sistemas ERP.

Algunas de las cuestiones tecnolgicas son:


a. Funciones del software
b. Obsolescencia Tecnolgica
c. Gestin de la cartera de aplicaciones
d. Mejora y Actualizaciones

2.1.10.4. Riesgos relacionados a la implementacin

Muchas implementaciones de ERP fracasan porque no tienen en


cuenta los diversos problemas de ejecucin asociados a un proyecto
complejo y arriesgado.

Algunas de estas cuestiones son:


a. Tamao del proyecto
b. Duracin del tiempo de Implementacin
c. Inversin inicial alta
d. Los plazos no razonables
e. Financiacin insuficiente
f. Interfaz
g. Polticas de la organizacin
h. Cambio de alcance.
i. Brechas inesperadas
j. Dificultades de configuracin

2.1.11. Tecnologas relacionadas a los sistemas ERP

13

Los sistemas ERP tienen una funcin importante en la integracin


de la gestin separada de las funciones del negocio, materiales,
planificacin de productos, ventas, distribucin, finanzas y otros en una
sola aplicacin.

Sin embargo, los sistemas ERP tienen tres limitaciones importantes:


a. Los administradores no pueden generar informes o consultas
personalizadas sin la ayuda de un programador y esto impide a los
gerentes la obtencin de informacin de forma rpida, lo cual no les
permite actuar con eficiencia ni eficacia frente a los problemas as
como mejorar la ventaja competitiva.

b. Los sistemas ERP proporcionan slo el estado actual, como


rdenes abiertas.
Los administradores a menudo tienen que mirar ms all de la
situacin actual para encontrar tendencias y patrones que ayudan a
una mejor toma de decisiones.

c. Los datos de la aplicacin ERP no est integrado con otras


empresas o sistemas de divisin y no incluye externo inteligencia.
Hay muchas tecnologas que ayudan a los sistemas ERP a superar
las limitaciones, lo cual que reduce sus utilidades.
Estas tecnologas, cuando se usan en combinacin con el paquete
ERP ayudarn a superar las limitaciones de un sistema de ERP
independiente y por lo tanto ayudar a los empleados en la toma de
mejores decisiones.

Algunas de estas tecnologas, las cuales se integran con el sistema


ERP, permitirn a las empresas hacer negocios a la velocidad de Internet.

14

Estas tecnologas se utilizan son:


a. Reingeniera de Procesos de Negocios (BPR)
b. Data warehousing & data marts
c. La minera de datos
d. Procesamiento analtico en lnea (OLAP)
e. Gestin del ciclo de vida del producto (PLM)
f. Gestin de la cadena de suministro (SCM)
g. Gestin de relaciones con clientes (CRM)
h. Sistemas de informacin geogrfica (GIS)
i. Intranets y extranets
j. Intercambio electrnico de datos (EDI)
k. Transferencia electrnica de fondos (EFT)
l. Criptografa (1)

2.1.12. Sistemas ERP Libres vs Sistemas ERP Propietarios


En el momento de elegir un sistema ERP para controlar los
procesos de la gestin empresarial, surgen las dudas relacionadas a las
prestaciones que ofrecen el distinto software existente para dicha tarea, y
la encrucijada de decidir la utilizacin de un software propietario o libre.

Cabe destacar que la diferencia ms grande que existe entre los ERP de
software propietario y los de software libre reside precisamente en sus
parmetros legales, ya que mientras que para utilizar un software
propietario se debe abonar ciertas licencias y adquirir por la va legal la
herramienta informtica, en el caso del software libre se evitan los
impuestos de licencias para uso.

Adems de lo anteriormente mencionado podemos tomar en cuenta:

Actualizaciones:
En general, en los ltimos aos los ERP de software propietario se han

15

estancado en relacin a la tecnologa implementada, incluso hasta


convertirse en una herramienta antigua y obsoleta para las necesidades
del mercado actual.

Por el contrario, los ERP de software libre son permanentemente


actualizados en base a dar respuesta a las necesidades cambiantes del
mercado y de las empresas, y utilizan las tecnologas de ltima
generacin, gracias a haber sido diseados de manera moderna,
permitiendo as su evolucin constante.

Orientaciones:
La mayora del software propietario, de compaas tales como Microsoft,
SAP y otras, ofrecen un producto apto para grandes empresas, sin brindar
la posibilidad de incorporar herramientas informticas en las Pymes,
debido a que el software propietario suele ser complejo sin posibilidades
de reducir sus capacidades de acuerdo a las necesidades de cada
organizacin.

Por el contrario, en el mercado del software ERP para pequeas y medias


empresas, desde hace aos se encuentran liderando los sistemas ERP
de software libre, gracias a las infinitas posibilidades de personalizacin
que ofrecen, cualquiera sea el tamao y las necesidades de cada
organizacin.

16

Soporte:
Otra de las grandes ventajas que poseen los ERP de software libre en
comparacin a los de software propietario es, sin lugar a dudas, el gran
nivel de soporte que posee, ya que son desarrollados por comunidades
de

programadores

que

mejoran

los

productos

constantemente.

Independientemente de si finalmente seleccionaremos un ERP de


software libre o propietario para la gestin empresarial de nuestra
compaa, cabe destacar que ante la eleccin de un ERP se deben
evaluar una serie de objetivos a cumplir con la implementacin de este
tipo de sistema.

2.1.13. Objetivos del sistema ERP


Los aspectos fundamentales que se deben tener en cuenta al
implementar un sistema ERP es que permita a la compaa alcanzar los
siguientes objetivos: optimizar los procesos, reducir los costos operativos,
mejorar

la

eficiencia,

tomar

mejores

decisiones

empresariales,

incrementar la satisfaccin de sus clientes, minimizar los errores humanos


y reducir el inventario y los faltantes. (10)

17

2.1.14. Metodologa MSSE

Metodologa creada por Florencia Chiesa del Centro de Ingeniera


del Software e Ingeniera del Conocimiento (CAPIS) Escuela de
Postgrado. Instituto Tecnolgico de Buenos Aires, Argentina.
Esta metodologa intenta organizar el proceso de seleccin de un
Sistema ERP, para que la empresa pueda escoger el sistema que mejor
cumpla con sus requisitos basndose en temas que no sean solo
econmicos. MSSE apunta a encontrar el producto adecuado en el
mercado evaluando aspectos funcionales, tcnicos, factores de
capacitacin, servicios de mantenimiento.
El objetivo fundamental de MSSE es proveer una gua de pasos
que ayude en la seleccin de un sistema ERP y la empresa consultora
que se encargar del trabajo de implementacin. Para la aplicacin de
MSSE la empresa debe haber tomado la decisin de implementar un
sistema ERP y no otro tipo de sistema. As mismo, se considera que la
organizacin ya ha realizado un trabajo de revisin de sus procesos y
sabe que reas estarn involucradas e impactadas por el cambio. MSSE
guiar al usuario por el proceso de seleccin y luego el armado del plan
general de trabajo del proyecto.

18

2.1.14.1. Estructura de MSSE

MSSE se organiza en tres fases las cules se dividen en actividades.

FASE 1 Seleccin del ERP


Actividad 1 Documentar necesidad

-Anlisis de necesidad.
-Determinar equipo del proyecto.

Actividad 2 Primera seleccin

-Bsqueda en el mercado.
-Primer contacto con proveedores
-Entrevistar

posibles

candidatos

recopilar informacin.
-Armado de listado de criterios a tener
en cuenta.
-Evaluar los candidatos.
-Documentacin

de

la

seleccin

armando del plan de trabajo.


Actividad 3 Seleccin final

-Organizar visita a los proveedores.


-Demostracin del producto.
-Decisin final - Negociacin

FASE 2 Seleccin del equipo de consultora


Actividad 1 Documentar bases de la -Organizar la bsqueda.
bsqueda

-Armar

listado

de

criterios

para

seleccionar consultora.
Actividad 2 Seleccin de candidatos

-Entrevistar

posibles

candidatos

recopilar informacin.
-Evaluar los candidatos.
-Decisin final Negociacin.
FASE 3 Presentacin y planificacin general del proyecto
Tabla 1 Estructura de MSSE

19

2.1.14.2. Fases de MSSE

2.1.14.2.1. Fase 1 Seleccin del ERP

2.1.14.2.1.1. Actividad 1 Documentar la necesidad

Los aspectos bsicos que se deben considerar son:


I. Anlisis de necesidad
El objetivo de este primer punto es documentar los aspectos
fundamentales que debe soportar el producto ERP que se selecciona
tales como, procesos a ser cubiertos, reas de la empresa que sern
afectadas con la implementacin, procesos de negocio alcanzados y
costo mximo que se pagar por la implementacin. El objetivo es asentar
una base de requerimientos para la bsqueda de proveedores.
II. Determinar equipo de Proyecto
Es importante que el proyecto este respaldado cien por ciento por
la direccin para obtener el xito. Se deben determinar las personas
involucradas en la seleccin y definir sus funciones y responsabilidades.
Se sugiere el siguiente equipo de personas:
Direccin: Responsables de la gestin de la empresa, cuyo objetivo
es tomar la decisin final en base al trabajo presentado por el equipo de
proyecto.
Gerente del proyecto: Directivo de alto nivel o responsable de
sistemas. Es la persona encargada de coordinar el proyecto y las
actividades del proceso de seleccin.

20

Equipo de proyecto: Personal de sistemas que trabaja tiempo


completo en el proyecto. En este proceso de seleccin realiza las tareas
de recopilar informacin, prepararla, ayuda en la toma de decisiones,
organizacin de reuniones y armado de cuestionarios. Trabajarn en la
implementacin del sistema seleccionado.
Grupo de usuarios: Formado por distintos usuarios de alto nivel de
las reas impactadas por el ERP. En el proceso de seleccin sern los
encargados de evaluar los ERP seleccionados segn sus conocimientos
del negocio.
Grupo de calidad: Dependiendo del tamao de la implementacin y
la organizacin, sta contar con personal con conocimientos en
metodologas de planificacin y desarrollo de sistemas, en tal caso ellos
tambin participarn en el proyecto.
Consultor externo: Si se tiene en cuenta que las empresas no
implementan con frecuencia sistemas ERP es normal no encontrar un
experto en seleccin de ERP dentro de las mismas, es por ello que se
recomienda incluir consultora externa en el equipo de proyecto.
Preferentemente el consultor debe ser neutral en relacin al
producto a elegir y no tiene por qu ser el que luego har la
implementacin del producto.
La documentacin de la actividad 1 debe incluir catlogo de
procesos involucrados, listado de reas impactadas, presupuesto mximo
disponible, listado de personas involucradas en el proceso de seleccin,
sus funciones, responsabilidades y la disposicin horaria, duracin
estimada de la actividad 2 y cronograma de tareas.

21

2.1.14.2.1.2. Actividad 2 Primera seleccin


Los aspectos bsicos que se deben considerar son:
I. Bsqueda en el Mercado
El objetivo de esta actividad es la bsqueda en el mercado de los
ERP disponibles, para lo cual se sugiere consultar en Internet,
exposiciones de software, revistas profesionales del rubro, consultar con
profesionales en otras empresas y armar un listado de todos los
proveedores de ERP encontrados.
II. Primer contacto con Proveedores
Se debe contactar a cada proveedor y se le solicita la mayor
cantidad de informacin posible.
En base al documento desarrollado en la actividad 1 eliminar
aquellos ERP que no cubran las reas de la empresa o los macro
procesos que se han listado como necesarios. Es importante reducir la
cantidad de candidatos a 5 aproximadamente ya que se llevar a cabo un
estudio ms profundo de cada uno que incluye: demostraciones de
producto, visitas de los usuarios al proveedor, entrevistas con personal
del proveedor, armado de informes por cada uno.
III. Entrevistar posibles candidatos y recopilar informacin
En esta fase se conciertan entrevistas con cada proveedor
seleccionado en el punto II de esta actividad con el objetivo de recopilar
toda la informacin posible tanto del proveedor como del producto;
especificaciones tcnicas del sistema, descripcin de los mdulos que lo
componen, funcionalidad de cada mdulo, catlogos, Artculos o trabajos
de experiencias de implementaciones del ERP en otras empresas. En la
entrevista se presenta al proveedor el documento preparado en la FASE 1,
se explica la actividad de la empresa y se solicita una propuesta de
implementacin que incluya detalles funcionales, tcnicos y econmicos
del producto y la implementacin.
Se prepara un reporte por cada ERP donde figura la presentacin
institucional de cada proveedor y un resumen de las caractersticas
funcionales de cada mdulo de cada ERP.

22

IV. Armado de listado de criterios


Desarrollar un listado de puntos de comparacin ponderados que
se adecue a las necesidades de la empresa que ser la base de trabajo
para las tareas posteriores y para la seleccin final.
Teniendo esto en cuenta se han identificado diferentes aspectos
que deben ser evaluados en el proceso de seleccin. En la tabla 5 se
detalla un listado de criterios ponderados para ser usado como modelo,
ste debe ser adaptado a las necesidades particulares de la empresa,
verificando que los aspectos seleccionados se puedan aplicar a la
organizacin en cuestin y que la ponderacin sugerida es adecuada para
la empresa.
Los criterios del listado son agrupados en seis categoras:
Aspectos funcionales del producto: Agrupa los criterios a evaluar
que estn ligados a las funciones que cumple el sistema y procesos que
contempla.

Aspectos tcnicos: Son aquellos relacionados con las


necesidades de hardware y equipamiento tcnico necesarios para utilizar
el producto.
Caractersticas propias del proveedor: Son aquellos criterios de
evaluacin que hacen a la empresa proveedor, como evolucin y
crecimiento, facturacin anual, ubicacin geogrfica, otros clientes y
experiencia.
Caractersticas del servicio: Se evalan puntos especficos del
servicio que brinda el proveedor como implementacin y soporte.
Aspectos econmicos: Son aquellos relacionados con costos de
licencias, de servicio de mantenimiento y de implementacin.
Aspectos estratgicos de la empresa: Los aspectos estratgicos
de la empresa estn fuertemente ligados a los planes de negocio y al plan
estratgico de la compaa, es por ello que se harn algunos ejemplos de
criterios a tener en cuenta pero deben ser preferentemente desarrollados
por la empresa.

23

Para armar el listado de criterios se siguen los siguientes pasos:


1) Tomando como modelo los criterios de la tabla 5, con los
conocimientos adquiridos de los ERP en funcin de la informacin
recopilada y el listado de las necesidades armado en actividad 1; armar el
listado de criterios que mejor aplique a la empresa.
2) Dividir los criterios en 6 grupos dependiendo si son de ndole
funcional, tcnica, econmica, del proveedor, del servicio o estratgico de
la empresa como se muestra tambin en la tabla 5.
3) Ponderar cada criterio segn su impacto dentro del grupo. La
suma de las ponderaciones de cada grupo debe ser igual a 100, siendo la
suma de todos los criterios igual a 600. (Ver tabla 5).
4) Ponderar cada uno de los 6 grupos, la suma debe ser igual a
100. Algunos de los criterios de seleccin deben ser considerados como
una gua til y no como criterios excluyentes. En caso de dudas en esta
etapa no es conveniente que prevalezcan los aspectos econmicos y
tecnolgicos sino los que hacen al producto funcionalmente es por esto
que el grupo funcional debe llevar la mayor ponderacin.
Una vez consensuado el listado, se documenta adecuadamente y
se distribuye al equipo de proyecto.

24

V. Evaluar los candidatos


En esta etapa el equipo debe concertar nuevas entrevistas con los
candidatos y recibir todas las propuestas solicitadas en el punto IV de
esta actividad y completar el listado armado en el punto anterior. Se
recomienda visitar las oficinas del proveedor, concertar reuniones con
personal comercial y tcnico para tener distintas visiones del producto.
Contactarse con empresas que ya usen los ERP en evaluacin y
escuchar ventajas y desventajas del producto.
Para completar el listado cada criterio ser clasificado con un valor
de 1 a 4, siendo 1= Malo, 2 = Regular, 3 = Bueno, 4 = Muy Bueno. Luego,
multiplicar el valor dado por la ponderacin del criterio. Sumar el valor
obtenido de todos los criterios de un mismo grupo y multiplicar por la
ponderacin del grupo y dividir por 100. As se obtendr la ponderacin
del grupo en general.
Repetir esta operacin para los 6 grupos en evaluacin y para
todos los ERP.
Una vez completo el listado con todos los datos recolectados,
comparar la informacin.
Encontrarn para un mismo aspecto distintos criterios de
evaluacin y mtodos, algunos ERP se cobran por mdulos, otros por
licencia de usuario; algunos proveedores dan servicio de consultara otros
no; algunos no permiten implementar con otra consultora que no sean
ellos.
Algunos puntos son difciles de medir ya que resultan subjetivos
como la confianza que inspira la empresa y el producto; para reflejar
todos estos puntos, que pueden quedar fuera de evaluacin, es
conveniente incorporar en el reporte final debajo del listado de criterios un
cuadro de ventajas y desventajas de cada ERP como se muestra en la
tabla 5. A los reportes armados para cada proveedor en el punto III de
esta actividad, se debe agregar el listado IV evaluado de esta actividad, el
listado de ventajas y desventajas y una copia de la propuesta. Luego de
esto es conveniente organizar una reunin de trabajo con el equipo de
proyecto y jefes de las reas impactadas para presentar las opciones,
discutir la evaluacin, comparar los valores obtenidos y seleccionar los
candidatos. Al finalizar esta actividad se debern seleccionar 2 o 3
productos ERP a lo sumo puesto que se har un trabajo ms detallado

25

para cada candidato.

VI. Documentacin de la seleccin y armado del plan de trabajo


El objetivo de este tem es documentar la seleccin de los 2 o 3
candidatos y hacer una presentacin formal a la direccin justificando
adecuadamente cada tem. Si sta es aprobada se debe armar un plan de
trabajo para la prxima actividad.
El equipo de proyecto se reunir con cada jefe de rea impactada
por el ERP para coordinar la disponibilidad horaria de cada usuario e
informar.
La documentacin final de la actividad 2 debe incluir el reporte para
cada proveedor con la informacin institucional, el listado de criterios
evaluado, el cuadro de ventajas y desventajas para cada ERP, el listado
de los ERP seleccionados, evaluacin realizada y razones de la seleccin,
el listado de usuarios que participarn en la prxima etapa y su
disponibilidad horaria y duracin estimada de la actividad 3.

26

2.1.14.2.1.3. Actividad 3 Seleccin final


Los aspectos bsicos que se deben considerar son:
I. Organizar visita a los proveedores
En este punto se organizar la logstica de las visitas a los
proveedores de los grupos de usuarios para presenciar distintas
demostraciones segn las reas involucradas. El propsito de estas
visitas es obtener un conocimiento ms profundo del producto, sus
funciones y la visin de la persona que realiza las tareas sobre el sistema
diariamente para evaluar las posibilidades de adaptacin del sistema a la
empresa. Teniendo el listado de usuarios y la disponibilidad horaria de
cada uno se coordina con el proveedor las demostraciones. Para ello es
conveniente preparar cuestionarios para los usuarios, para facilitar la
compaginacin de la informacin y la evaluacin posterior de la misma.
Es conveniente que los cuestionarios tengan dos secciones, una que
estar enfocada a la actividad particular de cada usuario (asociada en el
ERP a un mdulo) y otra donde se evalan aspectos generales del
producto. Se sugiere en la tabla 6 un cuestionario modelo a tener en
cuenta al momento de preparar los propios, en el mismo se listan ideas
para los mdulos que generalmente abarcan los sistemas ERP. Es
importante que los directivos, jefes de reas y analistas funcionales de
sistemas tambin vayan a las demostraciones, y si es posible completen
los cuestionarios que se les entreg a los usuarios ya que la visin del
producto desde distintas pticas enriquece la comparacin.
Al terminar esta tarea se tienen los cuestionarios modelos por
mdulo, el listado de usuarios que asistirn a las demostraciones y el
cronograma de visitas con los usuarios, proveedores, fechas y horarios.
II. Demostracin del Producto
En este punto los proveedores mostrarn el producto a los usuarios
seleccionados y ellos completarn en cada visita los cuestionarios
armados en el punto anterior. Los usuarios califican cada criterio
indicando en la columna de ponderacin (P) un valor del 0 a 5 segn se
explica en la cabecera de la tabla 6 Al finalizar las visitas se recopilan los
cuestionarios, se suman los puntajes de cada proveedor otorgado por
cada encuestado y se arma un promedio de puntos obtenidos por cada
producto. Se agrega al reporte armado para cada ERP en la actividad 2
los cuestionarios y puntaje total obtenido por ERP.

27

Al terminar este punto se tiene un reporte con la evaluacin


completa por candidato que incluye la informacin institucional, la
propuesta, el listado de criterios ponderados, las encuestas evaluadas
producto de las demostraciones, el cuadro de ventajas y desventajas y
todo comentario e informacin adicional que se tenga del proveedor y del
producto que se haya recopilado en estas dos actividades.
III. Decisin Final Negociacin
El equipo de proyecto se rene con la direccin de la empresa para
definir, basndose en la documentacin preparada en los puntos
anteriores, el producto ERP a comprar.
Una vez seleccionado se notifica al proveedor y se coordina una
reunin para la negociacin del contrato. Para esta reunin el proveedor
debe preparar dos estimaciones importantes: el costo y duracin de la
implementacin.
Finalmente se da la aprobacin final y se firma el contrato.

28

2.1.14.2.2 Fase 2 Seleccin del equipo de consultora


2.1.14.2.2.1. Actividad 1 Documentar fases de la bsqueda
Los aspectos bsicos que se deben considerar son:
I. Organizar la bsqueda
El paso siguiente es seleccionar quin va a implementar la
herramienta. En el caso de haber adquirido un ERP que solo puede ser
implementado por su proveedor esta fase no ser necesaria.
La bsqueda puede hacerse por Internet, revistas especializadas,
contactos con otras empresas que ya posean el producto.
Se preparar una presentacin con la documentacin de la FASE 1.
En esta documentacin se debe incluir, el producto seleccionado, las
reas y procesos que sern impactados, los mdulos que se
implementarn del ERP, descripcin de la actividad de la empresa, puntos
relevantes de la empresa como cantidad de sucursales, cantidad de
usuarios que tendr el sistema; el listado del equipo de trabajo y el listado
con las consultoras candidatas a implementar el producto.
II. Armado de un listado de criterios para seleccionar la consultora
El objetivo de esta etapa es desarrollar un listado de puntos de
comparacin ponderados adecuado para la empresa y el proyecto. En la
tabla 7 se detalla un listado de criterios ponderados para ser usado como
modelo, ste debe ser adaptado a las necesidades particulares de la
implementacin.

29

2.1.14.2.2.2. Actividad 2 Seleccin de candidatos


Los aspectos bsicos que se deben considerar son:
I. Entrevistar posibles candidatos y recopilar informacin
Como primer paso se contacta a las consultoras listadas en el
punto I de la actividad 2.1.14.2.1.1 se les presenta la documentacin
preparada en el punto I de la actividad 2.1.14.2.1.1 y se les solicita una
propuesta para la implementacin del ERP y los mdulos seleccionados.
El nmero ideal de candidatos para esta actividad es entre 5 y 7.
La propuesta que presente la consultora debe incluir:

Tiempo estimado de implementacin.


Fecha estimada de arranque del proyecto y de puesta en marcha
productiva.
Costos del proyecto, discriminando el costo de la implementacin
del costo de soporte post implementacin.
Listado de consultores del equipo de trabajo con los CV de cada
uno (para pedir referencias) y su funcin en el equipo.
Plan de contingencia en caso de no cumplir con el tiempo o los
costos estimados.
Alcance del trabajo: implementacin, mantenimiento, capacitacin
a usuarios y analistas.
Metodologa a utilizar.
Referencias de otros proyectos en los que han trabajado.
Listado con las obligaciones y recursos que tendr que proveer la
empresa (equipo de analistas funcionales y usuarios, equipamiento
(computadores, telfonos, puestos de trabajo, etc.)
Experiencia comprobable en la implementacin de los mdulos que
se implementarn en la empresa.

Al obtener las propuestas de las distintas consultoras el equipo de


proyecto completa el listado de criterios armado en el punto II de la
actividad 2.1.14.2.1.1.
Se prepara un reporte por consultora, el cual tendr el listado con la
ponderacin y valores obtenidos, las propuestas y otra informacin
relevante. Como cartula de los reportes de cada consultora se sugiere
completar y agregar un cuadro resumen con la informacin por consultora
como el que se muestra en la tabla 8.

30

Se organiza una reunin con el equipo de proyecto para presentar las


opciones, evaluar las propuestas y seleccionar los posibles candidatos. Al
finalizar esta etapa se debern seleccionar 2 o 3 consultoras para la
prxima tarea de evaluacin.
II. Evaluar los candidatos
En esta etapa se coordinarn reuniones con los gerentes de las 2 o 3
consultoras seleccionadas y con los consultores propuestos, la idea es
que expliquen la propuesta y su metodologa de trabajo. Se aprovechar
la oportunidad para verificar que la actividad de la empresa se ha
comprendido, validar el alcance de la actividad de la consultora y del
proyecto.
Las reuniones se harn preferentemente en las oficinas de la
consultora y asistirn el jefe de proyecto y algn directivo de ser necesario.
En una segunda reunin entre directivos y gerentes de ambas partes sin
los consultores se discuten temas econmicos, discrepancias que pueda
haber en los tiempos de implementacin, reemplazo de algn consultor
por otro si no hubiera gustado el perfil y otras diferencias que pudiera
haber. Es importante la dedicacin, el esmero y atencin que muestre el
proveedor ante sus demandas ya que revela la manera en que
responder cuando haya un problema o urgencia con el sistema.
Es muy importante siempre comparar la propuesta de la consultora
contra lo que el proveedor del ERP estim a nivel de costos y tiempo de la
implementacin y usarla como base para la negociacin.
Al finalizar esta etapa el jefe de proyecto deber agregar al reporte
armado en el punto anterior para cada consultora todos los datos,
opiniones, ventajas, desventajas y correcciones que hayan surgido de las
reuniones con cada proveedor.

31

III. Decisin Final Negociacin


Es conveniente que el jefe de proyecto se rena con la direccin de la
empresa para definir, basndose en los reportes preparados en el punto
anterior, la consultora que realizar la implementacin. Se revisar toda la
documentacin preparada, es por ello que los reportes deben ser lo ms
completos posibles.
Una vez seleccionada la consultora se le notifica y se coordina una
reunin para la negociacin del contrato. Para esta reunin la consultora
debe preparar una propuesta definitiva en base a la anterior
contemplando alguna observacin que haya surgido en las reuniones y
las negociaciones.
Finalmente se da la aprobacin final y se firma el contrato.

32

2.1.14.2.3. Fase 3 Presentacin y planificacin general del proyecto


Esta fase apunta a presentar a las partes involucradas y armar un
cronograma de implementacin no muy detallado pero que fije una fecha
para empezar a trabajar y los macro procesos.
Estos macro procesos que se deben tener en cuenta y para los que se
necesita coordinar recursos de los distintos proveedores, son los
siguientes:

La instalacin del producto y armado de los ambientes de trabajo.


En esta tarea trabajarn el proveedor de ERP, personal tcnico,
personal de base de la empresa y / o consultora. Estimar las
fechas y duracin de este trabajo, tener en cuenta la necesidad de
nuevos equipos y disponibilidad de los proveedores de hardware.
Una vez instalado el producto y creados los ambientes de trabajo
comienzan a trabajar los especialistas en seguridad que relevarn
usuarios, consultores y analistas que trabajarn en el proyecto y
crearn los perfiles y usuarios en el sistema.
Al mismo tiempo la consultora puede empezar a trabajar en el
levantamiento y documentacin de procesos con los usuarios.

La documentacin de esta ltima fase debe incluir un cronograma de


tareas a grandes rasgos y fechas de comienzo de trabajo de todas las
partes involucradas.

33

2.1.15. ERP System selection Key Factors


Factores claves para la seleccin de Sistemas ERP es una
Metodologa creada por el Departamento de Engenharia da Produo da
Escola Politcnica, Universidade de So Paulo, Brasil.

Esta metodologa tiene como objetivo principal identificar los


factores claves del proceso de seleccin de los sistemas ERP y, con esto,
establecer

el

grupo

de

procedimientos

que

pueden

seguir

las

organizaciones que se encuentran en esta situacin.

2.1.15.1. Estructura de ERP System selection Key Factors

A. PROCEDIMIENTOS INICIALES
-Modo de operar: identificacin del modo de operacin de la empresa.
-Determinacin de las necesidades sistmicas.
-Determinacin de los criterios de evaluacin.
B. SELECCIN DE PROVEEDORES
-Premisas bsicas en cuanto a la determinacin de los proveedores.
-Eleccin de los proveedores.
C. ANLISIS DEL SISTEMA
-Anlisis de la funcionalidad y utilidad.
-Evaluacin tcnica.
-Evaluacin de los clientes.
D. REFINAMIENTO DEL ANLISIS
-Simulacin de las situaciones normales y crticas.
-Anlisis de los elementos bsicos del propsito comercial.
DECISIN
Tabla 2 - Estructura de ESKF

2.1.16. Software libre

34

Software libre significa que el software respeta la libertad de los


usuarios y la comunidad. En trminos generales, los usuarios tienen la
libertad de ejecutar, copiar, distribuir, estudiar, modificar y mejorar el
software.

Un programa es software libre si los usuarios tienen las cuatro


libertades esenciales:

-La libertad de ejecutar el programa para cualquier propsito (libertad 0).

-La libertad de estudiar cmo funciona el programa, y cambiarlo para que


haga lo que usted quiera (libertad 1). El acceso al cdigo fuente es una
condicin necesaria para ello.

-La libertad de redistribuir copias para ayudar a su prjimo (libertad 2).

-La libertad de distribuir copias de sus versiones modificadas a terceros


(libertad 3). Esto le permite ofrecer a toda la comunidad la oportunidad de
beneficiarse de las modificaciones. El acceso al cdigo fuente es una
condicin necesaria para ello. (11)

35

2.1.17. GNU / Linux

GNU/Linux es uno de los trminos empleados para referirse a la


combinacin del ncleo o kernel libre similar a Unix denominado Linux
con el sistema GNU. Su desarrollo es uno de los ejemplos ms
prominentes de software libre; todo su cdigo fuente puede ser utilizado,
modificado y redistribuido libremente por cualquiera bajo los trminos de
la GPL (Licencia Pblica General de GNU, en ingls: General
PublicLicense) y otra serie de licencias libres. (12)

2.1.18. Caractersticas de las MYPES

Segn el TUO

de la Ley MYPE, estas unidades econmicas

para ser considerada como tal, deben reunir las siguientes caractersticas
concurrentes:

-Microempresa: De 1 a 10 trabajadores inclusive y ventas anuales hasta


el monto mximo de 150 unidades impositivas tributarias (UIT).

-Pequea empresa: De 1 hasta 100 trabajadores inclusive y ventas


anuales hasta el monto mximo de 1700 unidades impositivas tributaria
(UIT).

-Mediana y gran empresa: Ms de 100 trabajadores y ventas anuales


hasta de ms de 1700 unidades impositivas tributarias (UIT). (2)

36

2.1.19. Criterios para determinar que una MYPE es formal

La SUNAT toma en cuenta las siguientes variables para determinar


si una MYPE es o no formal:

-RUC Vigente.
-Rentas de tercera categora.
-Ventas anuales.
-Tipo de contribuyente.
-Actividad econmica. (13)

2.1.20. Situacin actual de las empresas manufactureras en la


provincia del Cusco

La provincia de Cusco concentra el 64.2% de las empresas


manufactureras de la regin, y le siguen a bastante distancia las
provincias

de

Canchis

La

Convencin

con

9.2%

8.4%,

respectivamente. Las 10 provincias restantes tienen menor nmero de


empresas manufactureras, como se podr apreciar en el siguiente cuadro
(Ver cuadro 1). En cuanto al tamao, son las Micro empresas las que
tienen el mayor nmero y se encuentran, principalmente, en la provincia
de Cusco. (14)

37

2.1.21. Distribucin total de empresas manufactureras en la Regin


del Cusco.

En cuanto a la distribucin del total de empresas manufactureras


por Divisin CIIU (actividad econmica a 2 dgitos) en las 13 provincias
tenemos que Elaboracin de alimentos y bebidas (CIIU 15) es la actividad
econmica que concentra al mayor nmero de empresas (803), seguida
por empresas que se dedican a la Fabricacin de muebles (CIIU 36, con
626), Productos de metal (CIIU 28, con 551), Edicin e impresin (CIIU 22,
con 443), Manufactura de madera (CIIU 20, con 410), Productos textiles
(CIIU 17, con 275) y Prendas de vestir (CIIU 18, con 242), entre las
principales actividades econmicas manufactureras de la Regin. En
menor proporcin tenemos otras actividades manufactureras como Otros
minerales no metlicos (CIIU 26). (Ver cuadro 2). (14)

38

CAPITULO III

METODOLOGA

3.1. Tipo de investigacin

Por el tipo de investigacin, la presente investigacin rene las


condiciones metodolgicas de una investigacin aplicada, en razn que,
se utilizaron los conocimientos de los sistemas integrados de planificacin
de recursos empresariales, a fin de aplicarlos en el proceso de estudio y
comparacin de los mismos.

3.2. Poblacin y muestra

3.2.1. Poblacin de estudio

Como poblacin se tom a todas la MYPES del sector


manufacturero de la ciudad del Cusco, siendo est de tipo finita.

3.2.2. Muestra de estudio

Como

muestra

representativa

se

tom

como

muestra

representativa a las empresas: Cermicas Ruiz Caro y Cermicas Kantu,


siendo est de tipo no probabilstico (determinstico) de carcter
intencional por conveniencia (Marcelo M. Gmez Introduccin a la
metodologa de la investigacin cientfica, 2006).

39

3.3. Instrumentos

Las tcnicas utilizadas para esta investigacin fueron la entrevista


de tipo personal y la observacin persona-directa cuyos instrumentos
correlativamente fueron las preguntas abiertas y las notas de campo.

3.4. Recoleccin y anlisis de datos

Para la recoleccin de datos y anlisis de datos se tom como


referencia inicialmente dos sistemas integrados de planificacin de
recursos

empresariales

basados

en

software

libre:

OpenERP

OpenBravo, luego de una investigacin inicial en las pginas web de


estos dos sistemas, adems de tomar como referencia tambin al ERP de
pago SAP.

3.4.1. Recoleccin y anlisis de datos de la empresa Cermica y Arte


Ruiz Caro SAC.

3.4.1.1. Breve descripcin de la empresa

Cermica

Arte

Ruiz

Caro

es

una

empresa

cusquea

especializada en la fabricacin de objetos cermicos a base de barro,


arena entre otros materiales, de acabado rstico con colores y acabados
artsticos.

40

3.4.1.2. Organigrama de la empresa

GERENTE PROPIETARIO

CONTABILIDAD

VENTAS

EXPORTACIN

TALLER DE HORNOS

SECRETARIA

TALLER DE PINTURAS

GALPON

TIENDA DE EXHIBICIN Y
VENTAS

Grafico 1 Organigrama Ruiz Caro (Fuente propia)

41

3.4.1.3. Proceso de bsico de fabricacin de la empresa

Grafico 2 Proceso Produccin Ruiz Caro (Fuente propia)

42

3.4.2. Recoleccin y anlisis de datos de la empresa Cermicas


Kantu

3.4.2.1. Breve descripcin de la empresa

Cermicas Kantu es una empresa cusquea dedicada a la


fabricacin de tacos, zcalos, mallas, lstelos (cenefas) y complementos
decorativos hechos de madera artesanal en cermica, porcelanato,
mrmol y vidrio.
Tiene ms de 30 aos de experiencia en el rubro de la cermica y casi 10
en la fabricacin de lstelos cermicos, lo cual les ha permitido desarrollar
productos de gran calidad y de innovador diseo; para la venta en todo el
pas as como al extranjero.

43

3.4.2.2. Organigrama de la empresa

JUNTA DE
SOCIOS

GERENCIA
GENERAL

SECRETARIA

INFORMATICA Y
TELECOMUNICA
CIONES

OFICINA DE
CONTABILIDAD

REA DE
PRODUCCIN

OFICINA DE
PRODUCCIN

AUDITORIA
INTERNA

REA DE ARTES
Y DISEO

OFICINA DE
MARKETING

OFICINA DE
INVESTIGACIN

REA DE
LOGISTICA

OFICINA DE
DISEO

OFICINA DE
ALMACN

REA DE
COSTOS

OFICINA DE
ALMACN
GENERAL LIMA

OFICINA DE
VENTAS LIMA

Grafico 3 Organigrama Kantu (Fuente propia)

44

3.4.2.2. Proceso bsico de fabricacin

Grafico 4 Proceso Produccin Kantu (Fuente propia)

45

3.4.3. Necesidades por reas de las empresas

3.4.3.1. Gerencia

La informacin necesaria bsicamente para la gerencia, es:


informacin bsica, informacin de productividad, informacin de
competencia e informacin de asignacin de recursos.

3.4.3.2. Contabilidad

-Estados financieros
-Facturaciones
-Crditos
-Entradas de Caja
-Compras e ingresos
-Acreedores varios
-Egresos de caja
-Remuneraciones
-Control de inventario
-Bienes de Uso
-Libro Mayor

46

3.4.3.3. Almacn

-Clculo del saldo de un cliente.


-Control de inventarios, hacer pedido si es necesario, hacer
promociones de mercanca o enviarla a otra tienda.
-Inicios y fines de temporadas por mercanca
-Control de venta de productos.
-Necesidades de compra por proveedor.
-Control de entradas, salidas y localizacin de la mercanca,
requisicin de mercancas.
-Pagos realizados a los proveedores y pagos realizados por los
clientes (monto y fecha de pago).
-Movimientos del mes (pagos, depuraciones).
-Catlogo de clientes.
Facturacin.

3.4.3.4. Ventas

-Resumen u hoja de entrega general (esta incluye de forma


concentrada el total de ventas del da as como el total de gastos
de operacin y el remanente de efectivo al final de da)
-Reporte de ventas por vendedor
-Reporte de ventas por producto
-Reportes de Compras del da
-Reportes de Devoluciones
-Comercio Electrnico

47

3.4.3.5. Recursos Humanos

-Registros controles de personal para efectos de pago de nmina,


ausencias, retrasos, disciplina.
-Informes sobre:
-Remuneracin
-Incentivos salariales
-Beneficios
-Reclutamiento y seleccin
-Plan de carreras profesionales
-Entrenamiento
-Desempeo
-Higiene
-Seguridad en un tipo de trabajo
-rea mdica.

3.4.3.6. Logstica

-Compras.
-Ventas.
-Inventarios.
-Punto de venta.
-CRM.
-Estadsticas.

48

3.4.4. Anlisis del ERP OpenERP.

Para el presente anlisis se tomaron los criterios dela tabla 3.

3.4.4.1. Aspectos funcionales

3.4.4.1.1. Propsito principal

OpenERP se especializa en el sector de la manufactura, teniendo


una mayor orientacin logstica, as como gran fortaleza en la amplia
cantidad de mdulos gratuitos disponibles.

3.4.4.1.2. reas soportadas

OpenERP cuenta con los siguientes mdulos principales:

49

Gestin de relaciones con el cliente (CRM)


OpenERP CRM y Gestin de ventas permiten el seguimiento de las
actividades de ventas desde el primer contacto hasta el final de la
realizacin del pedido de venta. La primera toma de contacto desde el
formulario de contacto en su sitio web es automticamente integrada en el
CRM. OpenERP permite hacer un seguimiento de todos los correos
electrnicos y los documentos intercambiados con los clientes.

Grafico 5 Mdulo CRM OpenERP (Fuente: Wikipedia.com)

50

Gestin de proyectos

OpenERP Gestin de Proyectos puede gestionar proyectos de


cualquier naturaleza. Pueden estar relacionados con los Servicios,
Soporte, Produccin o Desarrollo. Le permite organizar actividades en
tareas y planificar el trabajo necesario para completar estas tareas.

El sistema le permite planificar su asignacin de recursos sobre


una base a corto plazo y a largo plazo. Puede programar comunicaciones
automticas a travs de correo electrnico para informar a sus socios del
estado de avance del proyecto.

Los diagramas de Gantt proporcionan representaciones grficas de


sus proyectos, as como de la disponibilidad de recursos y la carga de
trabajo. Con la funcionalidad de CalDAV puede obtener acceso a la
informacin de programacin en un servidor remoto.

Grafico 6 Mdulo Proyecto OpenERP (Fuente: Openerpspain.com)

51

Gestin de Almacenes

Con la posibilidad de mltiples localizaciones de almacenes, y de


fijacin de stock mnimo para sus productos, OpenERP permite definir un
stock mnimo y de seguridad, con el fin de vincular acciones a dichos
eventos como pueden ser la generacin automtica de pedidos a
proveedores o el aviso mediante alertas por distintos canales.

La gestin de inventario se lleva a cabo con doble-entrada, tal


como en la contabilidad. Los lotes no se crean en ubicaciones de
inventario, sino que son movidos de una ubicacin a otra (Ej.: Una compra
es un movimiento de stock entre Proveedores y Depsito).

Consecuentemente, cuando se realiza un pedido de mercanca a


un proveedor, la ubicacin del proveedor recibe automticamente el lote
correspondiente. Luego, cuando se recibe la mercanca el lote
simplemente se mueve desde la ubicacin del proveedor a su previa
ubicacin Su inventario.

Grafico 7 Mdulo Almacn OpenERP (Fuente: Openerpweb.es)

52

Gestin contable y financiera

El mdulo contable de OpenERP provee contabilidad general,


analtica y presupuestaria, y cuenta con todas las funcionalidades para
llevar los libros contables de forma rigurosa. Puede ser usado como un
programa independiente o completamente integrado con los otros
mdulos de OpenERP para desarrollar su mximo potencial.

El mdulo de contabilidad financiera est pensado para gestionar


los datos econmicos de una empresa, siendo posible la utilizacin de
mltiples planes de cuentas de manera simultnea. Este mdulo permite
la generacin de presupuestos, informes, etc. Con este mdulo la
tesorera puede gestionar los flujos de caja y el efectivo con un alto nivel
de trazabilidad.

Grafico 8 Mdulo Contabilidad OpenERP (Fuente: Poiesisconsulting.com)

53

Gestin de compras

OpenERP gestiona automticamente todos los procesos asociados


con las rdenes de compra y el abastecimiento.

El mdulo de inventario puede calcular automticamente las


ordenes de aprovisionamiento conforme a las necesidades actuales y/o
futuras de su organizacin, y a los niveles de precios de sus proveedores
y contratos.

OpenERP implementa avanzadas funcionalidades de formas de


aprovisionamiento y compra: 30 das, fin de mes, pago a la vista, etc.

Grafico 9 Mdulo Compras OpenERP (Fuente: Poiesisconsulting.com)

54

Gestin de ventas

OpenERP permite una completa gestin y planificacin de las


oportunidades comerciales en tiempo real. Los procesos de venta y
presupuestos estn completamente integrados al mdulo de gestin de
clientes (CRM). La forma en que OpenERP puede acceder a la
informacin acerca de los clientes lo hace muy til para la administracin
de ventas.

Las herramientas de segmentacin le permiten generar en forma


automtica ofertas especiales para clientes disconformes o para clientes
que no han realizado pedidos en un determinado perodo de tiempo.
Adems, la segmentacin de ventas le permite asignar los representantes
comerciales a los mejores clientes y realizar un seguimiento continuo de
las oportunidades.

El servicio post-venta tambin es administrado por el sistema de


gestin de solicitudes.

Grafico 10 Mdulo Ventas OpenERP (Fuente: Poiesisconsulting.com)

55

Recursos humanos

OpenERP Recursos Humanos ofrece un conjunto completo de


herramientas que permite a las empresas gestionar los activos ms
importantes en su organizacin: su mano de obra. Incluye aplicaciones
para la gestin de contrataciones o evaluaciones de productividad.
Tambin proporciona herramientas para controlar y administrar las
asistencias, licencias y registros de horas.

Grafico 11 Mdulo RR.HH OpenERP (Fuente: Openerpspain.com)

56

Marketing

El mdulo de campaa de marketing est estrechamente


sincronizado con el mdulo de CRM. Inicialmente, vamos a considerar el
segmento que atendemos en la campaa como Prospecto. Se establecen
las metas para cada campaa, que sera considerado como un estado
deseado. Una vez que el Prospecto cumple nuestros criterios objetivos de
metas nosotros

cambiamos su estado para

convertirlo

en

una

Oportunidad(es decir, debemos dar un atencin enfocada a los


Prospectos). Una vez que el Prospecto cumple con nuestro objetivo final
se le considera como un socio / cliente y cerramos el Prospecto.

Grafico 12 Mdulo Marketing OpenERP (Fuente: I.ytimg.com)

57

Fabricacin

Fabricacin en OpenERPle permite administrar su cadena de


suministro de una manera completa y exacta. Puede administrar recursos
como los recursos humanos o mquinas. Ser capaz de crear listados de
materiales multinivel y sus correspondientes rutas para el montaje o la
fabricacin del producto final. Una herramienta programada entregar la
planificacin y pondr en marcha todas las rdenes de fabricacin y las
rdenes de compra cuando sea necesario. El sistema de control le
informar en caso de problemas durante el proceso de suministro.

Por ltimo, se puede analizar la eficiencia de la cadena gracias a


una lista de informes tiles.

Grafico 13 Mdulo Fabricacin OpenERP

58

3.4.4.1.3. Adaptabilidad y flexibilidad


OpenERP cuenta con un amplio parque de mdulos que extienden
enormemente la funcionalidad aportada por los mdulos oficiales. Esto le
permite dar soporte a casi cualquier tipo de aplicacin administrativa pero,
adems, dispone de un framework de desarrollo que permite extender de
forma rpida y ordenada las funcionalidades del sistema para cubrir sus
necesidades hasta donde sea preciso.

OpenERP dispone de cientos de mdulos, divididos en tres


categoras (oficiales, certificados y contribuidos), y diversas verticales
especficas para determinados sectores. Su acercamiento modular
permite comenzar una implantacin usando solamente un conjunto de
mdulos, que cubra sus necesidades ms crticas, e ir luego integrando
ms reas de su negocio. Esto permite implantaciones graduales, con
curvas de aprendizaje ms suaves y cambios paulatinos.

3.4.4.1.4. Facilidad de parametrizacin


OpenERP ha sido diseado para eliminar o reducir los costos de
desarrollo, adaptacin y aprendizaje. Incorpora un diseador de workflows,
pantallas e informes, ofrece dos tipos de interfaz (aplicacin de escritorio
y web), mens simplificados o extendidos, acceso basado en roles y un
sistema de bsquedas integrado.

3.4.4.1.5. Facilidad para hacer desarrollos propios


OpenERP es open source y se distribuye bajo licencia AGPL, por lo
que siempre dispondr del cdigo fuente y no est sujeto a licencias. Esto
le da la libertad de elegir el partner con el cul desee trabajar ahora y, si
no queda satisfecho, cambiarlo en el futuro o usar o contratar personal
propio. Tambin le da la libertad de elegir qu reas de su negocio llevar
a OpenERP, sin condicionantes del tipo todo o nada.

59

El desarrollo de mdulos se realiza editando archivos Python y


XML. No hay un editor oficial, aunque los tutoriales se decantan por
Eclipse o PyCharm + PyDev. Parte de la lgica de la aplicacin puede ser
cambiada desde la interfaz del cliente.
3.4.4.1.6. Interaccin con otros sistemas
OpenERP facilita mucho las integraciones con otros sistemas y los
intercambios de datos. Soporta XML/RPC y JSON/RPC, CSV y EDI, y
exporta informes directamente a formato PDF. Tambin facilita la
conectividad con otras aplicaciones, tales como suites ofimticas,
servicios de mapas y fotografas, clientes de correo, gestores de
contenidos y muchos ms.

3.4.4.1.7. Soporte especifico de algunos temas


OpenERP cuenta con un mdulo no oficial, lanzado por la
comunidad de desarrolladores en Francia, el cual posibilita la gestin del
ISO9001.
Asimismo cuenta con un mdulo oficial para la gestin de ebusiness as como la interaccin con interfaces tctiles.

3.4.4.1.8. Multi-Lenguaje
OpenERP cuenta con una amplia variedad de lenguajes entre
oficiales y aportes de la comunidad, lo cual facilita el trabajo entre
mltiples lenguajes o idiomas.

60

3.4.4.1.9. Localizaciones y presentaciones legales


OpenERP cuanta con un mdulo de Localizacin Peruana el cual
cuenta con las siguientes caractersticas:

Balance de Comprobacin
Balance General
Flujo de Efectivo
Prdidas y Ganancias
Registro Compras
Registro de Ventas
Libro Diario.
Libro Mayor.
Libro Caja y Bancos

3.4.4.1.10. Comunicacin con bancos


OpenERP cuenta con un mdulo de integracin con PayPal, el cual
facilita la generacin de rdenes de compa, cuantas y pagos, adems de
enva confirmaciones mediante correo electrnico.
3.4.4.1.11. Operaciones multimoneda
OpenERP cuenta con un amplio soporte para el trabajo multimoneda,
mediante mdulos y documentacin con ejemplos disponibles.

61

3.4.4.1.12. Herramientas amigables de reporting para el usuario


OpenERP cuenta con el mdulo JasperReports el cual es un
mdulo extendido que integra JasperReports biblioteca java con
OpenERP.

Grafico 14 Proceso Interno Reportes OpenERP (Fuente: Doc.odoo.com)

Se permite el uso de iReport para disear informes y utilizarlos en


OpenERP. Es compatible con internacionalizacin, sub-informes, tablas,
cdigos de barras.

62

3.4.4.2. ASPECTOS TECNICOS


3.4.4.2.1. Adaptabilidad a la estructura del cliente
Los requisitos de instalacin de OpenERP son mnimos considerando el
hardware disponible actualmente, lo que hace que sea altamente
adaptable a la estructura del cliente.
3.4.4.2.2. Distintos ambientes
OpenERP posee OERPenv la cual una herramienta de lnea de
comandos para crear, administrar y modificar el entorno OpenERP. Esta
herramienta es til para probar y desarrollar complementos, y administrar
a fuentes de OpenERP en el modo de desarrollar.
Uno de los beneficios que tiene es permitir convivir en el mismo ambiente
diferentes versiones de OpenERP.
3.4.4.2.3. Multiplataforma
Tanto el cliente como el servidor de OpenERP pueden ejecutarse sobre
sistemas operativos GNU/Linux, Windows y MacOS X. Su interfaz web
puede accederse desde cualquiera de los principales navegadores en un
PC y tambin desde smartphones y tablets. Esto le permite acceder a su
herramienta de gestin desde cualquier lugar.
3.4.4.2.4. Instalacin remota
La instalacin y soporte remoto es posible gracias a las funcionalidades
de acceso remoto del sistema operativo que alojara la aplicacin.

63

3.4.4.2.5. Cliente / Servidor


OpenERP tiene una arquitectura en la que separa claramente las
diferentes capas, por un lado tiene el servidor que maneja la lgica, al
igual que OpenBravo tiene la base de datos, y en un tercer nivel tenemos
las diferentes vistas. En este caso se ha utilizado Python para desarrollar
las diferentes capas.

Grafico 15 - Arquitectura de OpenERP (Fuente: Chelipinedaferrer.com)

OpenERP utiliza como arquitectura el modelo vista controlador MVC el


cual tiene la siguiente descripcin:

Grafico 10 - MVC de OpenERP (Fuente: Chelipinedaferrer.com)

64

El modelo est compuesto por una base de datos pero lo que nosotros
veremos a nivel de desarrollo ser nicamente el ORM, de hecho hasta la
fecha no he necesita tocar nada de la base de datos, ni siquiera aadir
una columna o una restriccin. Esto es posible debido a que cualquier
clase en OpenERP deriva de la clase osv.osv y est implementa el ORM.

A este puedes indicarle los atributos que necesitas, de que tipo son y l
se encargar del mapeo haciendo totalmente transparente el acceso a
datos.

La parte del controlador es completamente cdigo python. Por un lado


tendremos las clases que dan sustento a nuestras ventanas y si
queremos extenderlas por ejemplo aadiendo o sobrescribiendo mtodos
es muy sencillo, simplemente hay que utilizar herencia. Adems nadie nos
impide crearnos nuestras propias clases para hacer lo que se nos ocurra.

En cuanto a la vista esta se define en xml. Hay que recordar que en la


arquitectura de OpenERP tenamos un servidor al que nos conectbamos
por xml-rcp/net-rpc, esto quiere decir que el servidor le enva los datos al
cliente en xml y este ser el encargado de construir la interfaz en base a
esos datos.

65

3.4.4.2.6. Base de datos


OpenERP usa PostgreSQL que es un sistema gestor de bases de datos.
PostgreSQL es un Sistema de gestin de bases de datos relacional
orientado a objetos y libre, publicado bajo la licencia BSD.
Caractersticas
Algunas de sus principales caractersticas son, entre otras:
Alta concurrencia:
Mediante un sistema denominado MVCC (Acceso concurrente
multiversin, por sus siglas en ingls) PostgreSQL permite que mientras
un proceso escribe en una tabla, otros accedan a la misma tabla sin
necesidad de bloqueos. Cada usuario obtiene una visin consistente de lo
ltimo a lo que se le hizo commit. Esta estrategia es superior al uso de
bloqueos por tabla o por filas comn en otras bases, eliminando la
necesidad del uso de bloqueos explcitos.
Amplia variedad de tipos nativos:
PostgreSQL provee nativamente soporte para:
Nmeros de precisin arbitraria.
Texto de largo ilimitado.
Figuras geomtricas (con una variedad de funciones asociadas).
Direcciones IP (IPv4 e IPv6).
Bloques de direcciones estilo CIDR.
Direcciones MAC.
Arrays.

66

Adicionalmente los usuarios pueden crear sus propios tipos de datos, los
que pueden ser por completo indexables gracias a la infraestructura GiST
de PostgreSQL. Algunos ejemplos son los tipos de datos GIS creados por
el proyecto PostGIS.
Soporte para transacciones distribuidas:
Permite a PostgreSQL integrarse en un sistema distribuido formado por
varios recursos (p.ej, una base de datos PostgreSQL, otra Oracle, una
cola de mensajes IBM MQ JMS y un ERP SAP) gestionado por un
servidor de aplicaciones donde el xito ("commit") de la transaccin global
es el resultado del xito de las transacciones locales.
Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).

Ventajas
-Seguridad en trminos generales -Integridad en BD: restricciones en el
dominio -Integridad referencial - Afirmaciones (Assertions) -Disparadores
(Tiggers) -Autorizaciones -Conexin a DBMS -Transacciones y respaldos

67

3.4.4.2.7. Herramientas de lenguaje de programacin


La programacin en OpenERP trabajan de esta manera: primero
defines una clase en python que despus ser una tabla en la base de
datos, a esta clase le defines propiedades (columnas en openERP),
mtodos que harn la funcionalidad de la clase, claro si requieres algo
especfico pero sino, si solo quieres que haga un CRUD (Create, Read,
Update and Delete) pues no le implementas nada, luego necesitas definir
las formas de mostrarse los datos en la interface para ello se usan
archivos XML, en los que defines lo que llama OpenERP vistas (VIEW) en
general puedes usar dos vistas una llamada TREE que no es otra cosa
que el listado (una cuadricula o grilla) y la otra llamada FORM que es el
formulario propiamente dicho, tambin existen vistas como la de grafico al
estilo Gant o tipo grafico estadstico (estas dos ltimas no las he
implementado aun), bien tambin deberas definir los mens todo eso en
el archivo XML, as separas la lgica del diseo, todo muy sencillo para
un desarrollador, pero sin los asistentes de un IDE como Visual Studio es
algo engorroso trabajar (ya tengo en mente hacer un pequeo aplicativo
en .NET que me permita definir la interface de forma fcil y que se
encargue de escribir el XLM).

68

3.4.4.2.8. Seguridad
En OpenERP identificamos cuatro niveles de seguridad:
Nivel SO (Sistema Operativo)
Nivel Postgresql
Nivel OpenERP
Nivel Web
Nivel SO
El cual gestiona: Polticas para usuarios y grupos, usuario sudo y SSH.
Usuarios y grupos: Los servicios se puede ejecutar como usuarios o no
como ROOT.
Sudo: Sistema de control de ejecucin de comandos con privilegios de
sper usuario.
SSH: Es el nombre de un protocolo y del programa que lo implementa, y
sirve para acceder a mquinas remotas a travs de una red.
Nivel Postgresql
El cual gestiona: Listas de acceso, acceso del servidor, acceso de los
administradores.
En Postgresl tenemos dos tipos de usuarios: administrador y no
administrador.
Para una base de datos hay dos roles: Owner y otros.
Control usando ACL: El cual es un concepto de seguridad informtica
usado para fomentar la separacin de privilegios. Es una forma de
determinar los permisos de acceso apropiados a un determinado objeto,
dependiendo de ciertos aspectos del proceso que hace el pedido.
Nivel OpenERP
El cual gestiona: Listas de acceso, reglas de permisos, injection code.
Modelos: res_users / res_groups.
Autentificacin: Local, LDAP, OpenID, OAuth.
Injection code Controlado: Frontend/Cliente - Backend/Servidor.

69

Nivel Web
A nivel web:
OpenERP cuenta con certificados HTTPS a nivel de servidor y a nivel de
cliente.
Gestin con claves Planas y encriptadas.
Datos del sistema encriptado.
Invisibilidad de acciones en el servidor.
A nivel OpenERP se cuenta con los siguientes roles:
Grupos.
Accesos de Men.
Controles de Acceso.
Reglas.
Roles.

70

3.4.4.2.8.1. Descripcin de cada rol


USUARIOS: Son los usuarios del sistema de OpenERP que acceden al
aplicativo desde cualquiera de las opciones vlidas de clientes
actualmente disponibles en OpenERP (GTK, web, Koo, Mac). Los
usuarios representan a las personas fsicas. Estos se identifican con un
nombre de usuario y una contrasea.
Un usuario puede pertenecer a varios grupos y puede tener varios roles.
Adicionalmente, un usuario debe tener una accin establecida, que se
ejecuta cuando ste se conecta a la aplicacin, como puede ser que sea,
que cuando se conecte se abra el men de CRM. Las preferencias
facilitan la vida del usuario, as por ejemplo se puede determinar su
idioma de trabajo, como puede ser que sea el Ingls que se establezca
forma predeterminada.
GRUPOS: Los grupos determinan los derechos de acceso a los diferentes
recursos.
Hay tres tipos de derechos:
* El acceso a la escritura: la grabacin y creacin,
* El acceso a la lectura: lectura de un archivo,
* La ejecucin de acceso: los botones de flujos de trabajo o asistentes.
Un usuario puede pertenecer a varios grupos. Por ejemplo, el grupo de
comerciales y de CRM. Para configurar los derechos de acceso primero
hay que establecer los grupos.
Es importante que los grupos que sean representativos de las funciones
de trabajo de la empresa y no de sus empleados.
ROLES: Los roles nos permiten aplicar sobre los usuarios o grupos
definidos, acciones concretas como pueden ser que los usuarios que
pertenezcan al grupo de Account Manager, sean los nicos que puedan
eliminar facturas emitidas.

71

ACCESO A MENU: Los usuarios, en funcin del role que tengan


asignado, estarn facultados para acceder a determinadas secciones de
Men. As por ejemplo al grupo de usuarios comerciales, se les puede
establecer que no dispongan de acceso al men de rea financiera.
REGLAS: Es una herramienta que nos permite simplificar el proceso de
otorgar a determinado roles a grupos de usuarios. Especialmente til
cuando tenemos mltiples usuarios. As por ejemplo si deseamos que en
una organizacin de 18 comerciales cada cual vea las cuentas que tiene
asignada, es ms sencillo aplicar sobre el grupo reglas que hacerlo
usuario por usuario.

3.4.4.2.9. Back-Up
Hay tres enfoques fundamentalmente diferentes a la copia de seguridad
de datos en PostgreSQL:
SQL dump
Archivo de copia de seguridad a nivel de sistema
Copia de seguridad en lnea

72

SQL dump:
La idea detrs del mtodo SQL-dump es generar un archivo de texto con
comandos SQL que, cuando se alimenta de nuevo al servidor, volver a
crear la base de datos en el mismo estado en que se encontraba en el
momento de la descarga. PostgreSQL proporciona el programa de utilidad
pg_dump para este propsito.
Archivo de copia de seguridad a nivel de sistema:
Una estrategia de copia de seguridad alternativa es copiar directamente
los archivos que PostgreSQL utiliza para almacenar los datos en la base
de datos.
Copia de seguridad en lnea:
En todo momento, PostgreSQL mantiene una escritura por delante
registro (WAL) en el subdirectorio pg_xlog/ del directorio de datos del
clster. El registro describe cada cambio realizado en los archivos de
datos de la base de datos. La existencia del registro hace que sea posible
el uso de una tercera estrategia para realizar copias de seguridad de
bases de datos: podemos combinar una copia de seguridad de nivel de
sistema de archivos con copia de seguridad de los archivos WAL. Si la
recuperacin es necesaria, restauramos la copia de seguridad y, despus,
volver a partir de los archivos WAL copia de seguridad para que la copia
de seguridad hasta el tiempo actual.
3.4.4.2.10. Auditoria
OpenERP cuenta con el mdulo de auditora AudiTrails, el cual permite al
administrador realizar un seguimiento de cada operacin de los usuarios
en todos los objetos del sistema.

73

3.4.4.2.11. Gestor de configuraciones


OpenERP en sus distintas versiones posee un potente Gestor de
configuraciones Grafico, el cual posibilita una fcil y rpida configuracin
de todos los aspectos del sistema.
3.4.4.2.12. Documentacin
En la pgina principal de OpenERP se encuentra bastante documentacin
oficial entre la cual se encuentran manuales y un foro de consultas.
Adicionalmente estn disponibles algunos libros en otras pginas.
3.4.4.2.13. Documentacin Tcnica
En la pgina principal de OpenERP se encuentra documentacin sobre la
estructura y creacin de la base de datos, adems se encuentras los
cdigos fuentes y sus para la instalacin de los programas.
Adicionalmente se encuentran manuales y otros ejemplos en la pgina
principal de Postgresql.
3.4.4.2.14. Conectividad externa
Al ser multiplataforma OpenERP puede implementarse en su versin web
o mvil con lo cual se consigue una buena conectividad externa.
3.4.4.2.15. Compatibilidad con correo electrnico
OpenERP facilita la gestin y envo de correo electrnico en todos sus
mdulos.

74

3.4.5. Anlisis del ERP OpenBravo.


Para el presente anlisis se tomaron los criterios dela tabla 4 (Ver
anexos).

3.4.5.1. Aspectos funcionales

3.4.5.1.1 Propsito principal


OpenBravo se especializa en el sector ventas, teniendo una gran
inclinacin hacia dicho sector, adems de contar con una buena cantidad
de mdulos proporcionados por la comunidad.
3.4.5.1.2. reas soportadas
OpenBravo cuenta con los siguientes mdulos principales:
Gestin de datos maestros
Mediante el cual contribuye a la reduccin de errores centralizando los
datos en un nico repositorio compartido para que los productos,
componentes, listas de materiales, clientes, proveedores, empleados,
precios, descuentos, impuestos, categoras, etc.

Grafico 17 - Mdulo Gestin Datos Maestros OpenBravo (Fuente:


http://wiki.OpenBravo.com)

75

Gestin de compras
OpenBravo integra los aprovisionamientos con el inventario, la
contabilidad y la funcionalidad MRP, permitindole automatizar el proceso
e incrementar la eficiencia substituyendo las mltiples aplicaciones
inconexas por un sistema de negocio completamente integrado.

Grafico 18 Modulo Compras OpenBravo (Fuente: Forge.OpenBravo.com)

76

Gestin de ventas
OpenBravo le ofrece la mxima flexibilidad para configurar y adaptar los
diferentes subprocesos, permitiendo reducir los ratios de error y de DSO,
mejorando la satisfaccin del cliente y gestionando de manera ms
eficiente el trabajo.

Grafico 19 Modulo Ventas OpenBravo (Fuente: Openpyme.osl.ull.es)

77

Gestin financiera
La gestin financiera y contable de OpenBravo integra todas las
actividades contables, incluyendo cuentas a pagar, cuentas a cobrar,
contabilidad general, presupuestos, amortizacin de activos, y la gestin
de los periodos fiscales.

Grafico 20 Modulo Contabilidad y finanzas OpenBravo (Fuente: I.ytimg.com)

78

Gestin de inventario
Gestin activa de inventario y los costes con un acceso en tiempo real al
inventario disponible en el almacn o en trnsito, utilizando la comodidad
de los dispositivos mviles y compartiendo fcilmente la informacin del
inventario con los proveedores.

Grafico 21 Modulo Inventario y Almacn OpenBravo (Fuente: Xaure.hol.es)

79

3.4.5.1.3. Adaptabilidad y flexibilidad


OpenBravo puede configurarse fcilmente segn sus necesidades, y es lo
suficientemente flexible para adaptarse a esas particularidades que le
ayudan a diferenciarse y alcanzar el xito en el mercado.
Como OpenBravo es software libre, se tiene el control para poder decidir
cundo y cunto quiere invertir en cada momento, sin estar sujeto a
licencias o contratos exclusivos.
3.4.5.1.4. Facilidad de parametrizacin
OpenBravo puede instalarse en slo unas horas. Tras la definicin de sus
requerimientos y procesos de negocio, puede configurarse para
soportarlos en unos pocos das. Dependiendo del tamao del proyecto, en
pocas semanas es posible disponer de un sistema completamente
operativo con sus propios datos migrados desde las aplicaciones
antiguas, las integraciones necesarias con otros sistemas funcionando,
las requerimientos especficos desarrollados y sus empleados
perfectamente formados y capacitados para operar el sistema.
En OpenBravo no hay decisiones que sean irreversibles. Ello permite
poner el sistema en produccin ms rpidamente y que pueda adaptarse
segn la evolucin de las necesidades del negocio de manera flexible.
3.4.5.1.5. Facilidad para hacer desarrollos propios
El entorno de desarrollo de OpenBravo (abreviado como ODE) es un
marco de herramientas, metodologas y procesos para hacer que el
proceso de desarrollo de OpenBravo ERP ms fcil y para ayudar a los
desarrolladores a ser ms eficientes en tareas como la edicin de cdigo
fuente, depuracin, pruebas, despliegue y gestin de repositorios de
cdigo. ODE es compatible tanto con Oracle y PostgreSQL basan en los
ambientes. ODE est diseado para apoyar el proceso de desarrollo para
lo que la intencin es (contribuciones bsicas de OpenBravo ERP,
mdulos y cdigo personalizado) y cualquiera que sea el mbito de
aplicacin es (desde pequeas correcciones de errores para completar
nuevos mdulos funcionales).

80

3.4.5.1.6. Interaccin con otros sistemas


OpenBravo ha sido diseado de manera nativa en entorno web, lo que
habilita un acceso universal a la aplicacin desde cualquier dispositivo
conectable a la red, proporcionando simultneamente seguridad de
acceso y sencillez de implantacin al hacer innecesaria cualquier
instalacin en los equipos locales, ms all de un navegador
convencional.
Adicionalmente, ofrece una facilidad de uso similar a la de cualquier
pgina web y est integrado con las aplicaciones ofimticas de la
empresa (xls, pdf, etc.).
3.4.5.1.7. Soporte especfico en algunos temas
OpenBravo POS es un proyecto de punto de venta en software libre
desarrollado por OpenBravo. Funciona como un mdulo totalmente
integrado con OpenBravo ERP, con un completo flujo de informacin
desde la venta al pblico hasta el back office.
OpenBravo POS ofrece toda la gama de funcionalidades que el sector
minorista demanda: ventas, reembolsos, informes diarios, gestin de
efectivo, gestin de almacenes, etc.
3.4.5.1.8. Multi-Lenguaje
Al ser un proyecto basado en software libre OpenBravo tiene una amplia
variedad de idiomas, as como una Wiki que posibilita nuevas
traducciones voluntarias por parte de la comunidad.

81

3.4.5.1.9. Localizaciones y presentaciones legales


Para Per se cuenta con los siguientes mdulos.
Cuentas Contables Per:
El objetivo de este mdulo es facilitar un plan de cuentas contables tipo
que puede ser utilizado por aquellas empresas que no cuenten con uno
propio definido, o que contando con uno propio les ayude a configurarlo
en OpenBravo.
Traduccin espaol Per:
La funcin de ste mdulo consiste en habilitar el lenguaje Espaol en su
versin para Per. Este se encuentra basado en la traduccin original
hecha para Espaa habiendo hecho los cambios necesarios en aquella
terminologa aplicable a Per.
3.4.5.1.10. Comunicacin con bancos
Actualmente OpenBravo no cuenta con un mdulo oficial ni
comunitario de PayPal.
3.4.5.1.11. Operaciones multimoneda
Al ser un proyecto basado en software libre OpenBravo tiene una
amplia variedad de monedas, esto debido a los pases donde es usado.
3.4.5.1.12. Herramientas amigables de reporting para el usuario
OpenBravo ERP soporta dos tipos de informes: JasperReports con
informes de la interfaz y de servlets generados automticamente que son
slo un servlet que genera todos los contenidos de la pgina.
JasperReports se trata de una herramienta de cdigo abierto cuyas
principales caractersticas son:

82

Perfecta integracin con el servidor de aplicaciones Apache


Tomcat.
Al estar escrito en Java puede ser usado perfectamente dentro de
cualquier aplicacin desarrollada en este lenguaje (por supuesto,
aplicaciones Web) para generar contenidos dinmicos.
Genera informes estructurando sus datos en formato XML, lo cual
permite su perfecta integracin con otros elementos de la arquitectura.

Imagen 22 Diseo de informes en OpenBravo (Fuente: Presentacin Sistemas


Informticos, Seguridad, Domtica Aplicados).

83

3.4.5.2 Aspectos tcnicos


3.4.5.2.1. Adaptabilidad a la estructura del cliente
Los requisitos de instalacin de OpenBravo son mnimos considerando el
que este se ejecuta en un entorno web, lo que hace que sea altamente
adaptable a la estructura del cliente.
3.4.5.2.2. Distintos ambientes
OpenBravo no permite la instalacin en distintos ambientes.
3.4.5.2.3. Multi-Plataforma
OpenBravo solo tiene disponible la instalacin en un entorno web.
3.4.5.2.4. Instalacin remota
Se permite la instalacin remota de OpenBravo en sistemas operativos
basados en Linux que permitan el acceso remoto.
3.4.5.2.5. Cliente / Servidor
OpenBravo est desarrollado en Java JEE y se ejecuta sobre Tomcat (es
el recomendado por OpenBravo), su arquitectura es como la del siguiente
grfico:

Grafico 23 - Arquitectura de OpenBravo (Fuente: Chelipinedaferrer.com)

84

Su interfaz (vista) est centrada en el web.


La nica forma de conseguir una interfaz diferente a una basada en
tecnologa web es utilizando servicios web, este es el caso por ejemplo
del TPV (Terminal Punto de Venta), es la misma tecnologa que
podramos utilizar para integrar cualquier otro sistema externo. En el caso
de OpenERP el acceso al servidor est estandarizado, esto significa que
podemos desarrollar el cliente que queramos pero todos accedern de
forma estndar al servidor.
OpenBravo utiliza mucho cdigo en base de datos en forma de funciones
(procedimientos almacenados pl /sql), triggers y restricciones. En el patrn
MVC (Modelo Vista Controlador) de OpenBravo se desplaza gran parte de
la lgica (Controlador) a la capa de acceso a datos (Modelo), esto genera
varios problemas.
Por una parte se dispersa la lgica entre el controlador (cdigo java en el
contenedor de servlets Tomcat) y el Modelo (cdigo pl /sql, trigger y
restricciones en la base de datos).

85

Se cuenta con la herramienta DBSorucesmanagement, que permite


estandarizar de forma ms o menos elegante el cdigo en base de datos
y exportarlo a xml. Hasta el momento soportan Postgresql y Oracle y
aunque no es perfecto, no suelen haber muchos problemas graves, y los
que hay suelen solucionarse sin excesivas complicaciones, eso s, hay
que generar el cdigo pensando en esta compatibilidad.

El MVC de OpenBravo podra resumirse en el siguiente esquema.

Grafico 17: MVC de OpenBravo (Fuente: Chelipinedaferrer.com)

86

En el modelo tenemos por un lado la base de datos a la que


podremos acceder por sqlc. Sqlc es una herramienta que nos genera
clases java en base a una definicin en xml de sentencias sql, de este
modo podemos tener una clase en la que cada mtodo nos permitir
ejecutar una sentencia sql diferente. Esta es la herramienta de acceso a
datos y persistencia utilizada histricamente en OpenBravo.
A partir de la versin 2.50 se aadi una capa DAL (Data Access Layer)
implementada con Hibernate.
Respecto al controlador, esta es quiz la parte ms oscura de OpenBravo
ya que la lgica de negocio se reparte entre cdigo Java y cdigo Pl/sql
en base de datos lo que complica bastante tanto el desarrollo como la
independencia del SGBD (Sistema de gestin de bases de datos), esto
tambin provoca que la base de datos se vuelva muy lenta.
En cuanto a cdigo Java existe principalmente una clase de la que hereda
cualquier otro servlet, luego tendremos nuestras propias clases y mtodos
en java y por ltimo, y ya hablando de cdigo en base de datos,
tendremos una serie de triggers, funciones y restricciones.
La vista est compuesta por cdigo esttico en html, css y javascript.
Adems disponemos de una herramienta llamada xmlengine que viene a
ser un rellenador de plantillas. Por ejemplo, si tenemos un html con una
tabla y queremos rellenar esa tabla con datos xmlengine nos puede ser
til.

87

3.4.5.2.6. Base de datos


OpenBravo cuenta con soporte para bases de datos PostgreSQL y Oracle
Oracle Database es un sistema de gestin de base de datos objeto
relacional (u ORDBMS por el acrnimo en ingls de Object-Relational
Data Base Management System), desarrollado por Oracle Corporation.
Se considera a Oracle Database como uno de los sistemas de bases de
datos ms completos, destacando:
Soporte de transacciones.
Estabilidad.
Escalabilidad.
Soporte multiplataforma.
PostgreSQL que es un sistema gestor de bases de datos.
PostgreSQL es un Sistema de gestin de bases de datos relacional
orientado a objetos y libre, publicado bajo la licencia BSD.

88

3.4.5.2.7. Herramientas y lenguaje de programacin


Framework de aplicaciones ERP
OpenBravo ERP es una aplicacin desarrollada a travs de un marco de
desarrollo integrado incluido en la distribucin de OpenBravo ERP. Este
marco de desarrollo integrado se ocupa de una amplia gama de
conceptos en todas las reas involucradas en el proceso de desarrollo.
Lo ms relevante de nivel bajo a nivel alto:
La integracin con Eclipse IDE
Integracin con SMC (Mercurial)
Proceso automatizado de construccin
Proceso de actualizacin automatizada
Proceso automatizado deploy
Construido en infraestructura para varias necesidades comunes de
desarrollo:
Framework MVC (xmlEngine, HttpBaseServlet, SQLC)
Data_Access_Layer (basado en Hibernate )
Servidor Web y servlet-container (integracin con Apache-Tomcat y
apoyo a otras implementaciones de J2EE)
Informes (integracin con JasperReports motor)
XML y JSON REST Webservices
Envo por correo electrnico (integracin con el correo de Sun)
Planificacin de procesos (integracin con cuarzo)
Marco de desarrollo MDD (OpenBravo Diccionario de la Aplicacin )
Multi-idioma de apoyo interfaz de usuario
Construido en el modelo de seguridad
Construido en modelo de empresa
El soporte multi-moneda
El soporte multi-libro mayor
OpenBravo sigue un modelo de desarrollo impulsado enfoque (MDD).
Esto significa que OpenBravo utiliza un modelo agnstico tecnologa para
definir los componentes de aplicaciones, tales como ventanas y procesos.
Con base en este modelo de aplicacin, se generan cdigo y otros
artefactos de software.

89

OpenBravo modelo de datos de informacin -SO llamado Metadatos se


almacena en el Diccionario de la Aplicacin OpenBravo.
OpenBravo utiliza Java como lenguaje de programacin. Hay muchas
razones para elegir Java como lenguaje de programacin:
La naturaleza de cdigo abierto
Amplio soporte para el desarrollo a nivel de empresa
Arquitectura madura para aplicaciones web
Los desarrolladores de OpenBravo tienen tres maneras distintas para
desarrollar su cdigo. Siguiendo el enfoque MDD, ms comn es la de
editar el diccionario de la aplicacin de OpenBravo a travs de un
navegador web conectado a OpenBravo ERP. Sobre la base de la nueva
definicin del modelo de los artefactos de software se pueden generar
automticamente. Un desarrollador tambin puede conectarse
directamente a la base de datos de OpenBravo a travs de un cliente de
SQL (por ejemplo. PgAdmin, SQLDeveloper) para administrar los objetos
de esquema de base de datos (tablas, procedimientos, etc.).
Finalmente los desarrolladores pueden desarrollar su propio cdigo a
travs de un entorno de desarrollo integrado como Eclipse.

Imagen 25 Entorno de desarrollo de OpenBravo (Fuente: Wiki.OpenBravo.com)

90

Todos los artefactos de software OpenBravo se almacenan en archivos


de texto en el proyecto de desarrollo. Esto incluye la definicin de base de
datos y contenido. La gran ventaja de utilizar archivos de texto para
almacenar todos los artefactos de software es que es mucho ms fcil de
compartir y comparar los cambios realizados por los desarrolladores en un
entorno distribuido.
OpenBravo utiliza una herramienta llamada DBSourceManager de
administrar el cdigo fuente de base de datos. DBSourceManager es
capaz de leer de los objetos de esquema de base de datos y los datos del
diccionario de la aplicacin y exportarlos a archivos xml. Tambin puede
crear o actualizar una base de datos de OpenBravo de esos archivos xml.
El proceso para construir el sistema a partir del cdigo fuente de
OpenBravo incluye una serie de pasos para generar el cdigo en
diferentes niveles (DAL, WAD y otros) y juntos ese cdigo con otro cdigo
directamente escrito por desarrolladores. OpenBravo ha automatizado
este proceso a travs de tareas pequeas.

Imagen 26 Procesos de desarrollo de OpenBravo (Fuente: Wiki.OpenBravo.com)

91

3.4.5.2.8. Seguridad
OpenBravo a nivel de seguridad cuenta con las siguientes
caractersticas:
Acceso seguro a la aplicacin
Acceso seguro mediante HTTPS el cual proporciona a los usuarios la
posibilidad de autentificarse mediante LDAP, como en el Microsoft Active
Directory u OpenLDAP. Centralizando la autentificacin de los usuarios
con una nica contrasea para cada usuario, en lugar de para cada
aplicacin.
Capacidades de auditora
Se cuenta con un seguimiento detallado de la modificacin de datos con
informacin bsica acerca de quien cre/modific un registro o
funcionalidad ms avanzada de auditora. La auditora avanzada permite
un seguimiento ms potente y flexible sobre los cambios como filas
borradas o modificadas, campos modificados con el nuevo valor y el
anterior.
Seguridad funcional
Seguridad funcional para gestionar los derechos de acceso a entidades
como ventanas y procesos mediante una configuracin adecuada en los
usuarios y sus roles.
Seguridad de datos
La seguridad de datos gestiona los derechos de acceso a subconjuntos
de datos dentro de las entidades de Openbravo como ventanas y
procesos, activada mediante la configuracin del Nivel de Acceso a Datos
a nivel de tabla y el Nivel de Acceso de Usuario.

92

3.4.5.2.9. Back-Up
OpenBravo incluye una consola de administracin basada en web
con copia de seguridad y restauracin de las capacidades. Esta
herramienta copias de seguridad tanto OpenBravo ms los archivos del
sistema operativo pertinentes. La copia de seguridad resultante le permite
restaurar plenamente tanto OpenBravo y la aplicacin si se produce un
desastre.
Oracle cuenta con los siguientes mtodos para copia y restauracin de
datos:
Exportacin / Importacin
Son copias de seguridad de bases de datos "lgicos" en que extraen las
definiciones y datos lgicos de la base de datos en un archivo.
Copias de seguridad en frio o fuera de lnea
Consiste en poner fuera de lnea la base de datos y realizar una copia de
seguridad de todos los datos, registros y controles de archivos.
Las copias de seguridad en caliente o en lnea
Si la base de datos est disponible y en modo ARCHIVELOG se pueden
establecer los espacios de tabla a modo de copia de seguridad y copia de
seguridad de sus archivos
Las copias de seguridad de Recovery Manager (RMAN)
Mientras que la base de datos est fuera de lnea o en lnea, se puede
utilizar la utilidad "rman" para el respaldo la base de datos.
RMAN es la solucin preferida para copia de seguridad y recuperacin.
RMAN proporciona una interfaz comn para tareas de copia de seguridad
a travs de diferentes sistemas operativos host y ofrece varias tcnicas de
copia de seguridad que no estn disponibles a travs de mtodos
administrados por usuarios.

93

3.4.5.2.10. Auditoria
El mdulo de auditoria de OpenBravo permite el seguimiento detallado de
la modificacin de datos con informacin bsica acerca de quien
cre/modific un registro o funcionalidad ms avanzada de auditora. La
auditora avanzada permite un seguimiento ms potente y flexible sobre
los cambios como filas borradas o modificadas, campos modificados con
el nuevo valor y el anterior.
3.4.5.2.11. Gestor de configuraciones
Se puede configurar OpenBravo ERP en dos niveles diferentes: a
nivel de sistema y de nivel de cliente.
El sistema gestiona los datos del modelo y la fuente; es decir, la
estructura de datos subyacente del producto, para las tablas de base de
datos ejemplo, columnas, campos y mens.
El cliente gestiona los datos transaccionales; es decir, las caractersticas
especficas de su empresa y su actividad para las organizaciones, por
ejemplo: socios de negocio, productos, ventas y compras.
El sistema se crea automticamente al instalar OpenBravo ERP.
Cada instalacin de OpenBravo ERP puede tener un solo sistema, pero
varios clientes.
Para configurar se requieren dos funciones separadas.
El rol de administrador del sistema para configurar la funcin a nivel de
sistema. Al iniciar sesin en OpenBravo ERP, por primera vez, se inicia la
sesin como administrador del sistema por defecto.
Un rol de administrador de clientes. Cada cliente dentro del sistema tiene
su propio rol administrativo para uso exclusivo con ese cliente.
OpenBravo ERP crea el rol de administrador de cliente como parte del
proceso de instalacin del cliente inicial.

94

3.4.5.2.12. Documentacin
OpenBravo posee amplia documentacin en lnea mediante foros,
manuales en lnea y libros con descarga gratuita, todo esto en idioma
espaol.
3.4.5.2.13. Documentacin tcnica
A nivel de documentacin tcnica OpenBravo posee informacin bsica
en idioma espaol, para tener una mejor referencia se recomienda buscar
en fuentes de idioma ingls, donde se incluye mayor informacin as
como ejemplos prcticos de ayuda.
3.4.5.2.14. Conectividad externa
Al estar enteramente basado en web OpenBravo permite el acceso
universal debido a que no hay locales en las tiendas, almacenes u otras
instalaciones.
3.4.5.2.15. Compatibilidad con correo electrnico
Todos los mdulos principales de OpenBravo cuentan con la funcin de
envo de correo electrnico.

95

CAPITULO IV

RESULTADOS

Para el anlisis comparativo de las soluciones se tomaron en


cuenta las alternativas OpenBravo y OpenERP, y se tomaron los criterios
de aspectos funcionales, aspectos tcnicos y aspectos de estratgica de
cada proveedor.
Para la evacuacin de los sistemas ERP basados en software libre
se decidi evaluar aspectos referidos a la funcionalidad y caractersticas
tcnicas, tomando en cuenta la tabla 8, para finalmente tener como
indicador la suma de los valores en cada aspecto comparado.
El soporte del software no va a ser un gran problema si el
trabajador (Ingeniero de Sistemas) que administre el ERP sea bien
capacitado y pueda solucionar los problemas l mismo.

Tabla 5 Sistema de calificacin puntual

96

Tabla 6 Evaluacin de aspectos funcionales

97

Tabla 7 Evaluacin de aspectos tcnicos.

98

CAPITULO V

DISCUSIN
Basados en los resultados obtenidos en el captulo anterior se muestra los
cuadros estadsticos de la evaluacin en cada aspecto y el resultado final.
Para la evaluacin.

Tabla 8 Resultados de aspectos funcionales

99

Grafico 27 Evaluacin de aspectos funcionales

100

Tabla 9 Resultados de aspectos tcnico

101

Grafico 28 Resultados de aspectos tcnicos

102

Grafico 29 Resultados general a nivel de aspectos

103

Grafico 30 Resultado a nivel de ERPs

104

CONCLUSIONES

1. A nivel de pequeas y medianas empresas las alternativas ms


recomendables son OpenBravo y OpenERP por ser las ms completas y
con mayor cantidad de usuarios y soporte.
2. El sistema de planificacin de recursos empresariales que satisface
todas las necesidades de informacin en el proceso de negocio de las
medianas y pequeas empresas del Cusco es OpenERP.
3. Al usar software libre, el mismo trabajador de la pequea y/o mediana
empresa puede modificar el software segn las necesidades propias de la
empresa y no va a tener que pagar por cualquier modificacin como
sucede con el software propietario.
4. El sector de las pequeas y medianas empresas se presenta como un
entorno interesante para la aplicacin de ERPs basados en software libre
debido a la disponibilidad y la adaptacin rpida a las necesidades
bsicas de estos, adems de ser una interesante alternativa econmica al
no pagar licencias anuales.
5. Las principales necesidades de informacin de negocio de las
medianas y pequeas empresas son aquellas relacionadas al proceso
administrativo y de fabricacin definidas de acuerdo a las diferentes reas
listadas en el anlisis de las necesidades de informacin.
6. El sector de las pequeas y medianas empresas se presenta adems
como un reto para los ingenieros de sistemas debido a la resistencia al
cambio y a la desconfianza de facilitar cierta informacin por parte los
empresarios locales en Cusco.

105

RECOMENDACIONES

1. La intencin central de este proyecto fue mostrar la validez de los


sistemas empresariales de planificacin empresarial en el entorno de las
mypes del sector manufacturero; por lo tanto se recomienda a futuros
estudiantes e investigadores interesados en el tema, la complementacin
del estudio mediante un proyecto para implantar algn sistemas ERP
basado en software libre en alguna Mype de la ciudad para as poder
mostrar su validez en un entorno real de produccin.
2. Se recomienda incluir una mayor cantidad de alternativas de ERPs,
para as tener una mayor seleccin de alternativas as como una mayor
cantidad de mdulos y funciones para evaluar,
3. Se recomienda una mayor difusin a los empresarios locales mediante
charlas informativas y demostraciones para difundir los beneficios a nivel
de costos y facilidad de modificacin de los sistemas ERP basados en
software libre.

106

REFERENCIAS

Leon, ERP Demystified. 2nd ed. India. McGraw-Hill; 2008

Ley de promocin y formalizacin de la pequea y micro empresa.


Ley N 28015 (Diario Oficial El Peruano, 11-06-2003)

Len, C. y Otros. Gestin empresarial para agro negocios. 1st ed.


Per. USAT; 2007

Kalpakjian S., Schmid S.R. Manufactura, ingeniera y tecnologa.


5th ed. Mxico. Pearson Educacin; 2008

Sumario Ejecutivo. Las Siete Claves para una Manufactura de


Clase

Mundial.

http://www.cimatic.com.mx/articulos/claves-

manufactura-clase-mundial.php (accessed 27 Noviembre 2013).


6

Chiesa,

F.

Metodologa

para

la

seleccin

de

sistemas

ERP. Reportes Tcnicos en Ingeniera de Software.2004;6(1):21


7

Cimatic. Las ventajas de un sistema ERP para los fabricantes - 1


de 4. Las ventajas de un sistema ERP para los fabricantes.;1(1):3

(2012). Caractersticas fundamentales del ERP. [ONLINE] Available


at: http://www.informatica-hoy.com.ar/software-erp/Caracteristicasfundamentales-del-ERP.php. [Last Accessed 25 Noviembre 2013].

Leon, A. Enterprise Resource Planning. 2nd ed. India. McGraw-Hill;

2008
10

(2012). Comparativa entre ERP de software libre y propietario.


[ONLINE] Available at: http://www.informatica-hoy.com.ar/softwareerp/Comparativa-entre-ERP-de-software-libre-y-propietario.php.
[Last Accessed 30 Noviembre 2013].

11

Gnu.org (2013). Qu es software libre?. [ONLINE] Available at:


http://www.gnu.org/philosophy/free-sw.es.html. [Last Accessed 20
Noviembre 2013].

12

Wikipedia

(2013). GNU/Linux.

[ONLINE]

http://es.wikipedia.org/wiki/GNU_Linux.

[Last

Available

at:

Accessed

20

107

Noviembre 2013].
13

Direccin

General

de

Estudios

Econmicos,

Evaluacin

Competitividad Territorial, (2012). MYPE 2011, Estadsticas de la


micro y pequea empresa. 1st ed. Per: Ministerio de Produccin.
14

CENSO MANUFACTURA, 2007 SUNAT REGISTRO RUC, 2011

ELABORACIN:

PRODUCEDVMYPEDGI/Directorio

de

Empresas Industriales, Septiembre 2011


15

Ral Oltra Badenes. Sistemas Integrados de Gestin Empresarial.


Evolucin histrica y tendencias de futuro. 1st ed. Espaa.
EDITORIAL UNIVERSITAT POLITCNICA DE VALNCIA; 2012

108

ANEXOS

ANEXO 1
METODOLOGA PARA SELECCIN DE
SISTEMAS ERP

METODOLOGA PARA SELECCIN DE SISTEMAS ERP


Florencia Chiesa
Centro de Ingeniera del Software e Ingeniera del Conocimiento (CAPIS)
Escuela de Postgrado. Instituto Tecnolgico de Buenos Aires
Av. Madero 399 (C1106ACD), Buenos Aires Argentina.
http://www.itba.edu.ar/capis/webcapis/planma.html

Resumen: Un sistema ERP es una aplicacin informtica que permite gestionar todos los procesos de
negocio de una compaa en forma integrada. El propsito de este trabajo es proveer una gua de
pasos que ayude en la seleccin de un sistema ERP y la empresa consultora que se encargar del
trabajo de implementacin.
Palabras Clave: Sistema

1.

ERP. Procesos de Negocio Metodologas de Seleccin

INTRODUCCIN

MSSE es una Metodologa para la Seleccin de un


Sistema ERP. Intenta ordenar y sistematizar a los
encargados de elegir un sistema ERP en el proceso de
seleccin.
1.1.

Qu es un sistema ERP?

Un sistema ERP es una aplicacin informtica que


permite gestionar todos los procesos de negocio de una
compaa en forma integrada. Sus siglas provienen del
trmino en ingls ENTERPRISE RESOURCE
PLANNING. Por lo general este tipo de sistemas esta
compuesto de mdulos como Recursos Humanos,
Ventas, Contabilidad y Finazas, Compras, Produccin
entre otros, brindado informacin cruzada e integrada
de todos los procesos del negocio. Este software debe
ser parametrizado y adaptado para responder a las
necesidades especificas de cada organizacin. Una vez
implementado un ERP permite a los empleados de una
empresa administrar los recursos de todas las reas,
simular distintos escenarios y obtener informacin
consolidada en tiempo real.
La implementacin de esta herramienta en una
empresa conlleva un proceso de transformacin y
redefinicin de sus procesos. Su ciclo de vida consiste
en varias etapas empezando por la fase en la que se
decide implementar un sistema ERP y no otro tipo de
sistema. Le sigue el proceso de decidir qu ERP se
implementar y qu consultora llevar adelante el

proyecto. Una vez seleccionados comienza la fase de


implementacin en la que se parametrizar el sistema;
para esta fase la consultora que lleva el proyecto
propone una metodologa de trabajo, experiencia en
implementaciones y capacitacin. Luego le sigue la
etapa de uso y mantenimiento del sistema. Finalmente
se retira el producto cuando se considera que debe ser
reemplazado por otra tecnologa o que el enfoque que le
da a los procesos del negocio ya no son los adecuados.
1.2.

Importancia de contar con una


metodologa de seleccin

La importancia del impacto del ERP en los procesos


cotidianos de la organizacin y la inversin que la
misma debe hacer en trminos econmicos, hacen que
el proceso de seleccin de la herramienta sea un tema
delicado. Se debe tener en cuenta tambin que no es
una tarea que se haga frecuentemente y que se espera
un determinado retorno de la inversin en trminos
monetarios y de tiempo de uso.
MSSE se centra en la etapa de seleccin de la
herramienta ERP y la consultora que har el trabajo de
implementacin. Esta metodologa intenta organizar el
proceso de seleccin de un ERP para que la empresa
pueda escoger el sistema que mejor cumpla con sus
requisitos basndose en cuestiones que no sean solo
econmicas. MSSE apunta a encontrar el producto
adecuado en el mercado evaluando aspectos
funcionales, tcnicos, factores de capacitacin,
servicios de mantenimiento, ayuda a la seleccin de la

Reportes Tcnicos en Ingeniera de Software Vol. 6 N 1 (2004), pg. 17-37


ISSN: 1668-3137. CAPIS-EPG-ITBA (http:///www.itba.edu.ar/capis/rtis/index.htm).

empresa que har el trabajo de implementacin; y da


algunas pautas de la planificacin general del proyecto
y la puesta en marcha del mismo.

2.2.

MSSE se organiza en tres fases las cuales se dividen en


actividades:

MSSE no provee herramientas para definir si un


sistema ERP es la solucin adecuada para la empresa en
vez de otro tipo de sistema, ese trabajo debe ser una
etapa de investigacin previa, MSSE parte de la
premisa que se comprar un ERP y su objetivo es
ayudar a seleccionar uno.
1.3.

- Fase 1 Seleccin Del ERP


Actividad 1 Documentar Necesidad
o Anlisis De Necesidad
o Determinar Equipo De Proyecto
Actividad 2 Primera Seleccin
o Bsqueda En El Mercado
o Primer Contacto Con Proveedores
o Entrevistar Posibles Candidatos Y
Recopilar Informacin
o Armado De Listado De Criterios A
Tener En Cuenta
o Evaluar Los Candidatos
o Documentacin De La Seleccin Y
Armado Del Plan De Trabajo

Pilares de un ERP

El xito de la implementacin de un ERP implica un


cambio cultural y de procesos en la organizacin que se
apoya en 3 aspectos fundamentales: el producto, los
procesos y las personas, la combinacin y
sincronizacin de los mismos lleva al xito de la
implementacin.
- El producto se refiere al sistema ERP,
consideraciones tcnicas y funcionales.
- Los procesos son las funciones que deben ser
soportadas por el sistema ERP,.
- La implementacin de un ERP implica una
reingeniera de procesos cuyo objetivo es
adaptar a la empresa a los nuevos modelos de
negocio.
- Las personas son los recursos humanos, los
conocimientos
y
habilidades
de
los
involucrados en el ciclo de vida del sistema,
usuarios, analistas, consultores y directivos que
empujan el proyecto.
2.

Actividad 3 Seleccin Final


o Organizar Visitas A Los Proveedores
o Demostracin Del Producto
o Decisin Final Negociacin
- Fase 2 Seleccin Del Equipo De Consultara
Actividad 1 Documentar Bases De La
Bsqueda
o Organizar la bsqueda
o Armar listado de criterios para
seleccionar consultora
Actividad 2 Seleccin De Candidatos
o Entrevistar Posibles Candidatos Y
Recopilar Informacin
o Evaluar Los Candidatos
o Decisin Final Negociacin

MSSE METODOLOGA PARA LA


SELECCIN DE UN SISTEMA ERP
2.1.

Estructura de MSSE

Objetivos y alcances de MSSE

El objetivo fundamental de MSSE es proveer una


gua de pasos que ayude en la seleccin de un sistema
ERP y la empresa consultora que se encargar del
trabajo de implementacin.

- Fase 3 - Presentacin y Planificacin General


Del Proyecto
Lo primero que se realiza es la seleccin del sistema
a implementar (fase 1), luego se busca la empresa que
realizar el trabajo (fase 2) y finalmente se hace una
presentacin conjunta del equipo y se arma un plan
general del proyecto con el objetivo de que todas las
partes involucradas organicen sus recursos (fase 3).

Para la aplicacin de MSSE la empresa debe haber


tomado la decisin de implementar un sistema ERP y
no otro tipo de sistema. As mismo, se considera que la
organizacin ya ha realizado un trabajo de revisin de
sus procesos y sabe que reas estarn involucradas e
impactadas por el cambio.

Si la empresa por decisiones corporativas o de


cualquier ndole se viera obligada a implementar un
sistema ERP especfico, MSSE podra ser usada a partir
de la fase 2 para seleccionar la consultora. En cuyo caso
la metodologa puede utilizarse tambin para verificar

MSSE guiar al usuario por el proceso de seleccin


y luego el armado del plan general de trabajo del
proyecto.
18

que el sistema que se debe implementar cumple con las


necesidades de la empresa.
3.

los que trabajen con dedicacin completa al mismo. En


esta etapa se deben determinar las personas
involucradas en la seleccin y definir sus funciones y
responsabilidades.

FASE 1 SELECCIN DEL ERP


3.1.

Se sugiere que el siguiente equipo de personas se


encuentren involucradas en la implementacin ya que
tienen un rol importante en el desarrollo de la
organizacin:

Actividad 1 Documentar necesidad

Lo primero que se debe hacer es definir y establecer


el marco general de referencia para la seleccin de un
ERP. Los aspectos bsicos que se deben considerar son:
- La definicin de las reas y funciones de la
empresa que se abarcarn con el ERP, esta
definicin debe contemplar los planes
estratgicos de la empresa y debe tener una
visn a largo plazo.
- Los participantes en el proceso de
seleccin del sistema ERP.
3.1.1.

Anlisis de necesidad

El objetivo de este primer punto es documentar los


aspectos fundamentales que debe soportar el producto
ERP que se selecciona tales como, procesos a ser
cubiertos, reas de la empresa que sern afectadas con
la implementacin, procesos de negocio alcanzados y
costo mximo que se pagar por la implementacin. El
objetivo es asentar una base de requerimientos para la
bsqueda de proveedores. Este documento no debe ser
tomado como el anlisis de requerimientos sino como
las bases de lo que el producto ERP que se adquiera
debe cumplir.

Para armar este documento y decidir sobre el


alcance mximo del sistema es conveniente que se
renan los directivos de la empresa, junto con el jefe de
sistemas. Es importante que aunque no se vaya a
implementar todo en una primera etapa se arme un
documento con el alcance total deseado del sistema,
para que en un futuro se pueda ampliar sin
inconvenientes.

MSSE apunta a obtener un producto que sea lo mas


apropiado para la empresa, es decir no pagar un precio
muy elevado por un sistema que se usar en un diez por
ciento de su potencial ni por otro lado comprar un
sistema que resulte obsoleto al primer intento de
ampliacin.
3.1.2.

Direccin: Responsables de la gestin de


la empresa, cuyo objetivo es tomar la
decisin final en base al trabajo presentado
por el equipo de proyecto.
Gerente del proyecto: directivo de alto
nivel o responsable de sistemas. Es la
persona encargada de coordinar el proyecto
y las actividades del proceso de seleccin.
Equipo de proyecto: personal de sistemas
que trabaja tiempo completo en el
proyecto. En este proceso de seleccin
realiza las tareas de recopilar informacin,
prepararla, ayuda en la toma de decisiones,
organizacin de reuniones y armado de
cuestionarios.
Trabajarn
en
la
implementacin del sistema seleccionado.
Grupo de usuarios: formado por distintos
usuarios de alto nivel de las reas
impactadas por el ERP. En el proceso de
seleccin sern los encargados de evaluar
los ERP seleccionados segn sus
conocimientos del negocio.
Grupo de calidad: dependiendo del
tamao de la implementacin y la
organizacin, sta contar con personal con
conocimientos en metodologas de
planificacin y desarrollo de sistemas, en
tal caso ellos tambin participarn en el
proyecto.
Consultor externo: Si se tiene en cuenta
que las empresas no implementan con
frecuencia sistemas ERP es normal no
encontrar un experto en seleccin de ERP
dentro de las mismas, es por ello que se
recomienda incluir consultara externa en el
equipo de proyecto. Preferentemente el
consultor debe ser neutral en relacin al
producto a elegir y no tiene porque ser el
que luego har la implementacin del
producto.

La constitucin y el tamao de estos grupos


depender de las caractersticas de la implementacin
(tamao, alcance y complejidad).

Determinar equipo de proyecto

Antes de comenzar la bsqueda del ERP se debe


nombrar a los responsables del proyecto. Es importante
que el proyecto este respaldado cien por cien por la
direccin para llegar al xito pero no ser la direccin

La documentacin de la actividad 1 debe incluir


catlogo de procesos involucrados, listado de reas
19

impactadas, presupuesto mximo disponible, listado de


personas involucradas en el proceso de seleccin, sus
funciones, responsabilidades y la disposicin horaria,
duracin estimada de la actividad 2 y cronograma de
tareas. Es conveniente que se organice una reunin para
presentar las bases del proyecto e informar a las
personas involucradas su rol en mismo.
3.2.

tcnicos y econmicos
implementacin.

Bsqueda en el mercado

El objetivo de esta actividad es la bsqueda en el


mercado de los ERP disponibles, para lo cual se sugiere
consultar en Internet, exposiciones de software, revistas
profesionales del rubro, consultar con profesionales en
otras empresas y armar un listado de todos los
proveedores de ERP encontrados.
3.2.2.

producto

la

Para terminar esta fase se organiza la informacin


verificando que los datos recopilados son homogneos
para facilitar la comparacin. Se prepara un reporte por
cada ERP donde figura la presentacin institucional de
cada proveedor y un resumen de las caractersticas
funcionales de cada mdulo de cada ERP. Se sugiere
preparar una carpeta con divisiones por producto para ir
agregando toda la documentacin que se recoger en las
etapas siguientes.

Actividad 2 Primera Seleccin

3.2.1.

del

Armado de listado de criterios a


tener en cuenta

3.2.4.

El objetivo de esta etapa es desarrollar un


listado de puntos de comparacin ponderados
que se adecue a las necesidades de la empresa y
que ser la base de trabajo para las tareas
posteriores y para la seleccin final.

Primer contacto con proveedores

En un segundo paso de la actividad se contacta a


cada proveedor y se le solicita la mayor cantidad de
informacin posible. No es necesario todava concertar
entrevistas, el objetivo es recopilar la mayor cantidad
de informacin de cada uno

MSSE intenta ser una metodologa flexible, pensada


para ser usada por distintas empresas, de distintos
rubros con un objetivo en comn: seleccionar el sistema
ERP que mejor se adecue a la empresa, para su
posterior implementacin.

En base al documento desarrollado en la actividad 1


eliminar aquellos ERP que no cubran las reas de la
empresa o los macro procesos que se han listado como
necesarios. Es importante reducir la cantidad de
candidatos a 5 aproximadamente ya que se llevar a
cabo un estudio ms profundo de cada uno que incluye:
demostraciones de producto, visitas de los usuarios al
proveedor, entrevistas con personal del proveedor,
armado de informes por cada uno; de ser muchos
candidatos se incrementar el esfuerzo.

Para la comparacin y seleccin de un producto es


necesario tener un listado de criterios ponderados y
puntos de comparacin comunes. Teniendo esto en
cuenta se han identificado diferentes aspectos que
deben ser evaluados en el proceso de seleccin. En el
anexo 1 se detalla un listado de criterios ponderados
para ser usado como modelo, ste debe ser adaptado a
las necesidades particulares de la empresa, verificando
que los aspectos seleccionados se puedan aplicar a la
organizacin en cuestin y que la ponderacin sugerida
es adecuada para la empresa.
Los criterios del listado son agrupados en seis
categoras o grupos, ponderadas tambin:

Entrevistar posibles candidatos y


recopilar informacin

3.2.3.

En esta fase se conciertan entrevistas con cada


proveedor seleccionado en el punto 3.2.2 con el
objetivo de recopila toda la informacin posible tanto
del proveedor como del producto; especificaciones
tcnicas del sistema, descripcin de los mdulos que lo
componen, funcionalidad de cada mdulo, catlogos,
artculos
o
trabajos
de
experiencias
de
implementaciones del ERP en otras empresas.

En la entrevista se presenta al proveedor el


documento preparado en la fase 1, se explica la
actividad de la empresa y se solicita una propuesta de
implementacin que incluya detalles funcionales,
20

Los aspectos funcionales del producto:


bajo esta categora se agrupan todos los
criterios a evaluar que estn ligados a las
funciones que cumple el sistema y
procesos que contempla.
Los aspectos tcnicos: son aquellos
relacionados con las necesidades de
hardware
y
equipamiento
tcnico
necesarios para utilizar el producto.
Las caractersticas propias del proveedor:
aquellos criterios de evaluacin que hacen
a la empresa proveedor como evolucin y
crecimiento, facturacin anual, ubicacin

geogrfica, otros clientes y experiencia. Es


importante evaluar la solidez del
proveedor ya que si el proveedor deja de
existir la empresa se queda con un sistema
sin mantenimiento ni posibilidad de
evolucin.
Las caractersticas del servicio: en estos
aspectos se evala puntos especficos del
servicio que brinda el proveedor tanto de
implementacin como de soporte.
Los aspectos econmicos: son aquellos
relacionados con costos de licencias, de
servicio de mantenimiento y de
implementacin.
Los aspectos estratgicos de la empresa:
Los aspectos estratgicos de la empresa
estn fuertemente ligados a los planes de
negocio y al plan estratgico de la
compaa, es por ello que se darn
algunos ejemplos de criterios a tener en
cuenta pero deben ser preferentemente
desarrollados por la empresa.

el grupo funcional debe llevar la mayor


ponderacin. (Utilizar el Anexo 1 como
gua.)
Una vez consensuado el listado, se documenta
adecuadamente y se distribuye al equipo de proyecto.
3.2.5.

En esta etapa el equipo debe concertar nuevas


entrevistas con los candidatos y recibir todas las
propuestas solicitadas en el punto 3.2.4. y completar el
listado armado en el punto anterior. Se recomienda
visitar las oficinas del proveedor, concertar reuniones
con personal comercial y tcnico para tener distintas
visiones del producto. Contactarse con empresas que ya
usen los ERP en evaluacin y escuchar ventajas y
desventajas del producto.
Para completar el listado cada criterio ser
clasificado con un valor de 1 a 4, siendo 1= Malo, 2 =
Regular, 3 = Bueno, 4 = Muy Bueno. Luego multiplicar
el valor dado por la ponderacin del criterio. Sumar el
valor obtenido de todos los criterios de un mismo grupo
y multiplicar por la ponderacin del grupo y dividir por
100. As se obtendr la ponderacin del grupo en
general. Repetir esta operacin para los 6 grupos en
evaluacin y para todos los ERP. (Ver ejemplo en
anexo 1.)

Para armar el listado de criterios seguir los


siguientes pasos:
1.

2.

3.

4.

Evaluar los candidatos

Tomando como modelo los criterios del anexo


1, con los conocimientos adquiridos de los ERP
en funcin de la informacin recopilada y el
listado de las necesidades armado en actividad
1; armar el listado de criterios que mejor
aplique a la empresa.
Dividir los criterios en 6 grupos
dependiendo si son de ndole funcional,
tcnico, econmico, del proveedor, del
servicio o estratgico de la empresa como
se muestra tambin en el anexo 1.
Ponderar cada criterio segn su impacto
dentro del grupo. La suma de las
ponderaciones de cada grupo debe ser igual
a 100, siendo la suma de todos los criterios
igual a 600. (Ver anexo 1)
Ponderar cada uno de los 6 grupos, la suma
debe ser igual a 100. Algunos de los
criterios de seleccin deben ser
considerados como una gua til y no como
criterios excluyentes; por ejemplo si una
solucin parece adecuada pero implica un
gran cambio en la estructura de hardware
no se debe descartar directamente. Los
criterios de seleccin intentan dar un
enfoque global a la decisin y no quedarse
con un solo aspecto. En caso de dudas en
esta etapa no es conveniente que
prevalezcan los aspectos econmicos y
tecnolgicos sino los que hacen al
producto funcionalmente es por esto que

Una vez completo el listado con todo los datos


recolectados, comparar la informacin. Encontrarn
para un mismo aspecto distintos criterios de evaluacin
y mtodos, algunos ERP se cobran por mdulos, otros
por licencia de usuario; algunos proveedores dan
servicio de consultara otros no; algunos no permiten
implementar con otra consultora que no sean ellos.
Algunos puntos son difciles de medir ya que resultan
subjetivos como la confianza que inspira la empresa y
el producto; para reflejar todos estos puntos, que
pueden quedar fuera de evaluacin, es conveniente
incorporar en el reporte final debajo del listado de
criterios un cuadro de ventajas y desventajas de cada
ERP como se muestra en el anexo 1.
A los reportes armados para cada proveedor en el
punto 3.2.3, se debe agregar el listado 3.2.4 evaluado, el
listado de ventajas y desventajas y una copia de la
propuesta. Luego de esto es conveniente organizar una
reunin de trabajo con el equipo de proyecto y jefes de
las reas impactadas para presentar las opciones,
discutir la evaluacin, comparar los valores obtenidos y
seleccionar los candidatos. Al finalizar esta actividad se
debern seleccionar 2 o 3 productos ERP a lo sumo
puesto que se har una trabajo mas detallado para cada
21

candidato y de ser mas de 3 el esfuerzo ser muy


grande.

usted es el cliente y que la imagen que el proveedor de


a los usuarios impactar en la percepcin del producto
software que stos se lleven, como por ejemplo la
confianza; estos puntos deben ser evaluados y se
incluyen en los criterios generales. Se sugiere en el
anexo 2 un cuestionario modelo a tener en cuenta al
momento de preparar los propios, en el mismo se listan
ideas para los mdulos que generalmente abarcan los
sistemas ERP.

Documentacin de la seleccin y
armado del plan de trabajo

3.2.6.

El objetivo de este item es documentar la seleccin


de los 2 o 3 candidatos y hacer una presentacin formal
a la direccin justificando adecuadamente cada tem. Si
sta es aprobada se debe armar un plan de trabajo para
la prxima actividad.

Es importante que los directivos, jefes de reas y


analistas funcionales de sistemas tambin vayan a las
demostraciones, y
si es posible completen los
cuestionarios que se le dieron a los usuarios ya que la
visin del producto desde distintas pticas enriquece la
comparacin.

En la prxima actividad se har un refinamiento de


la seleccin realizada en la actividad 3.2.5 en funcin
de aspectos funcionales, es decir se evaluar si las
prestaciones que da el sistema son adecuadas. Para ello
se sugiere la participacin de usuarios claves de cada
sector para evaluar las funciones de cada mdulo. El
equipo de proyecto se reunir con cada jefe de rea
impactada por el ERP para coordinar la disponibilidad
horaria de cada usuario e informar.

Al terminar esta tarea se tienen los cuestionarios


modelos por mdulo, el listado de usuarios que asistirn
a las demostraciones y el cronograma de visitas con los
usuarios, proveedores, fechas y horarios.

La documentacin final de la actividad 2 debe


incluir el reporte para cada proveedor con la
informacin institucional, el listado de criterios
evaluado, el cuadro de ventajas y desventajas para cada
ERP, el listado de los ERP seleccionados, evaluacin
realizada y razones de la seleccin, el listado de
usuarios que participarn en la prxima etapa y su
disponibilidad horaria y duracin estimada de la
actividad 3.
3.3.
3.3.1.

3.3.2.

Demostracin del producto

En este punto los proveedores mostrarn el producto


a los usuarios seleccionados y ellos completarn en
cada visita los cuestionarios armados en el punto
anterior. Los usuarios califican cada criterio indicando
en la columna de ponderacin (P) un valor del 0 a 5
segn se explica en la cabecera del anexo 2.
Al finalizar las visitas se recopilan los cuestionarios,
se suman los puntajes de cada proveedor otorgado por
cada encuestado y se arma un promedio de puntos
obtenidos por cada producto. Se agrega al reporte
armado para cada ERP en la actividad 2 los
cuestionarios y puntaje total obtenido por ERP. Revisar
el informe con los usuarios y jefes de reas para
verificar que representa lo que ellos presenciaron.

Actividad 3 Seleccin final


Organizar visitas a los proveedores

En este punto se organizar la logstica de las visitas


a los proveedores de los grupos de usuarios para
presenciar distintas demostraciones segn las reas
involucradas. El propsito de estas visitas es obtener un
conocimiento ms profundo del producto, sus funciones
y la visin de la persona que realiza las tareas sobre el
sistema diariamente para evaluar las posibilidades de
adaptacin del sistema a la empresa.

Al terminar este punto se tiene un reporte con la


evaluacin completa por candidato que incluye la
informacin institucional, la propuesta, el listado de
criterios ponderados, las encuestas evaluadas producto
de las demostraciones, el cuadro de ventajas y
desventajas y todo comentario e informacin adicional
que se tenga del proveedor y del producto que se haya
recopilado en estas dos actividades.

Teniendo el listado de usuarios y la disponibilidad


horaria de cada uno se coordina con el proveedor las
demostraciones. Para las demostraciones es conveniente
preparar cuestionarios para los usuarios, para facilitar la
compaginacin de la informacin y la evaluacin
posterior de la misma. Es conveniente que los
cuestionarios tengan dos secciones, una que estar
enfocada a la actividad particular de cada usuario
(asociada en el ERP a un mdulo) y otra donde se
evalan aspectos generales del producto. Recuerde que

3.3.3.

Decisin final - negociacin

El equipo de proyecto se rene con la direccin de


la empresa para definir, basndose en la documentacin
preparada en los puntos anteriores, el producto ERP a
comprar.
22

Una vez seleccionado se notifica al proveedor y se


coordina una reunin para la negociacin del contrato.
Para esta reunin el proveedor debe preparar dos
estimaciones importantes: el costo y duracin de la
implementacin. Estos datos sern tenidos en cuenta
para la prxima fase que es la seleccin del equipo de
consultara.

Armado de un listado de criterios


para seleccionar la consultora

4.1.2.

Al igual que para seleccionar el ERP, para la


comparacin y seleccin de la consultora es necesario
tener un listado de criterios ponderados y puntos de
comparacin comunes. Teniendo esto en cuenta se han
identificado diferentes aspectos que deben ser
evaluados en el proceso de seleccin. En el anexo 3 se
detalla un listado de criterios ponderados para ser usado
como modelo, ste debe ser adaptado a las necesidades
particulares de la implementacin.

Finalmente se da la aprobacin final y se firma el


contrato.
4.

FASE 2 SELECCIN DEL EQUIPO DE


CONSULTORIA
4.1.

El objetivo de esta etapa es desarrollar un listado de


puntos de comparacin ponderados adecuado para la
empresa y el proyecto.

Actividad 1 Documentar bases de la


bsqueda

4.1.1.

4.2.

Organizar la bsqueda

Actividad 2 Seleccin de candidatos


Entrevistar posibles candidatos y
recopilar informacin

4.2.1.

Una vez seleccionado el producto que se va a


implementar el paso siguiente es seleccionar quin lo va
a implementar. La consultara externa para este punto
es fundamental puesto que la empresa raramente posee
expertos en el producto y los mdulos que se
implementarn.

Como primer paso se contacta a las consultoras


listadas en el punto 4.1.1, se les presenta la
documentacin preparada en el punto 4.1.1 y se les
solicita una propuesta para la implementacin del ERP
y los mdulos seleccionados. Para que el esfuerzo del
proceso de evaluacin no sea muy grande, el nmero
ideal de candidatos para esta actividad es entre 5 y 7.

Los sistemas ERP en algunos casos pueden ser


implementados solo por los proveedores del sistema; en
otros tienen consultoras asociadas que realizan el
trabajo y finalmente existen productos que pueden ser
implementados por cualquier consultora capacitada sin
necesidad de estar acreditada ante el proveedor.

La propuesta que presente la consultora debe


incluir:
-Tiempo estimado de implementacin.
-Fecha estimada de arranque del proyecto y
de puesta en productivo.
-Costos del proyecto, discriminado el costo
de la implementacin del costo de soporte
post implementacin.
-Listado de consultores del equipo de trabajo
con los CV de cada uno (para pedir
referencias) y su funcin en el equipo.
-Plan de contingencia en caso de no cumplir
con el tiempo o los costos estimados.
-Alcance del trabajo: implementacin,
mantenimiento, capacitacin a usuarios y
analistas.
-Metodologa a utilizar.
-Referencias de otros proyectos en los que
han trabajado.
-Listado con las obligaciones y recursos que
tendr que proveer la empresa; por ejemplo
equipo de analistas funcionales y usuarios,
equipamiento (computadores, telfonos,
puestos de trabajo, etc.)

En el caso de haber adquirido un ERP que solo


puede ser implementado por su proveedor esta fase no
ser necesaria. En el caso que el producto solo pueda
ser implementado por consultoras acreditadas se debe
pedir al proveedor del sistema ERP un listado con las
consultoras autorizadas. Si el producto puede ser
implementado por cualquier consultora se recomienda
pedir un listado al proveedor y buscar en el mercado
local otros candidatos. La bsqueda puede hacerse por
Internet, revistas especializadas, contactos con otras
empresas que ya posean el producto.
Se preparar una presentacin con la documentacin
de la fase 1. En esta documentacin se debe incluir, el
producto seleccionado, las reas y procesos que sern
impactados, los mdulos que se implementarn del
ERP, descripcin de la actividad de la empresa, puntos
relevantes de la empresa como cantidad de sucursales,
cantidad de usuarios que tendr el sistema; el listado del
equipo de trabajo y el listado con las consultoras
candidatas a implementar el producto.
23

-Experiencia
comprobable
en
la
implementacin de los mdulos que se
implementaran en la empresa.

estim a nivel costos y tiempo de la implementacin y


usarla como base para la negociacin.
Al finalizar esta etapa el jefe de proyecto deber
agregar al reporte armado en el punto anterior para cada
consultora todos los datos, opiniones, ventajas,
desventajas y correcciones que hayan surgido de las
reuniones con cada proveedor.

Al obtener las propuestas de las distintas consultoras


el equipo de proyecto completa el listado de criterios
armado en el punto 4.1.2. Se prepara un reporte por
consultora en donde conste el listado con la
ponderacin y valores obtenidos, las propuestas y otra
informacin relevante. Como cartula de los reportes de
cada consultora se sugiere completar y agregar un
cuadro resumen con la informacin por consultora
como el que se muestra en el anexo 4.

4.2.3.

Es conveniente que el jefe de proyecto se rena con


la direccin de la empresa para definir, basndose en
los reportes preparados en el punto anterior, la
consultora que realizar la implementacin. Se revisar
toda la documentacin preparada, es por ello que los
reportes deben ser lo ms completos posibles.

Con la documentacin preparada, se organiza una


reunin con el equipo de proyecto para presentar las
opciones, evaluar las propuestas y seleccionar los
posibles candidatos. Al finalizar esta etapa se debern
seleccionar 2 o 3 consultoras para la prxima tarea de
evaluacin, el nmero sugerido es para minimizar el
esfuerzo que requieren las reuniones y trabajo de
investigacin.

4.2.2.

Decisin final - negociacin

Una vez seleccionada la consultora se le notifica y


se coordina una reunin para la negociacin del
contrato. Para esta reunin la consultora debe preparar
una propuesta definitiva en base a la anterior
contemplando alguna observacin que haya surgido en
las reuniones y las negociaciones.

Evaluar los candidatos

En esta etapa se coordinarn reuniones con los


gerentes de las 2 o 3 consultoras seleccionadas y con
los consultores propuestos, la idea es que expliquen la
propuesta y su metodologa de trabajo. Se aprovechar
la oportunidad para verificar que la actividad de la
empresa se ha comprendido, validar el alcance de la
actividad de la consultora y del proyecto. As mismo
ser el primer contacto de la empresa con los
consultores que participarn en el proyecto, se sugiere
aprovechar la entrevista para repasar los currculums de
los consultores y conversar personalmente sobre sus
experiencias previas.

Finalmente se da la aprobacin final y se firma el


contrato.

Las reuniones se harn preferentemente en las


oficinas de la consultora y asistirn el jefe de proyecto y
algn directivo de ser necesario.

Estos macro procesos que se deben tener en cuenta


y para los que se necesita coordinar recursos de los
distintos proveedores, son los siguientes:

En una segunda reunin entre directivos y gerentes


de ambas partes sin los consultores se discuten temas
econmicos, discrepancias que pueda haber en los
tiempos de implementacin, reemplazo de algn
consultor por otro si no hubiera gustado el perfil y otras
diferencias que pudiera haber. Es importante la
dedicacin, el esmero y atencin que muestre el
proveedor ante sus demandas ya que revela la manera
en que responder cuando haya un problema o urgencia
con el sistema.

- La instalacin del producto y armado de


los ambientes de trabajo. En esta tarea
trabajarn el proveedor de ERP, personal
tcnico, personal de base de la empresa y / o
consultora. Estimar las fechas y duracin de
este trabajo, tener en cuenta la necesidad de
nuevos equipos y disponibilidad de los
proveedores de hardware.
- Una vez instalado el producto y creados
los ambientes de trabajo comienzan a trabajar
los especialistas en seguridad que relevarn
usuarios, consultores y analistas que trabajarn
en el proyecto y crearn los perfiles y usuarios
en el sistema.

5.

FASE 3 - PRESENTACIN Y
PLANIFICACIN GENERAL DEL
PROYECTO

Esta fase apunta a presentar a las partes


involucradas
y
armar
un
cronograma
de
implementacin no muy detallado pero que fije una
fecha para empezar a trabajar y los macro procesos.

Es muy importante siempre comparar la propuesta


de la consultora contra lo que el proveedor del ERP
24

- Al mismo tiempo la consultora puede


empezar a trabajar en el relevamiento y
documentacin de procesos con los usuarios.

este trabajo tan complejo que es el seleccionar que


herramienta ERP se usar.
MSSE apunta a cubrir todo el ciclo de seleccin y
de ser los ms flexible posible, adecundose a
implementaciones grandes y chicas. Sin embargo queda
mucho trabajo por hacer en esta rea. Se pueden
incorporar
estudios
para
determinar
porqu
implementar un ERP y no un sistema hecho a medida.
Se puede estudiar ms en profundo las actividades de la
fase 3 para desarrollar un plan de accin mas completo
una vez seleccionada la herramienta y la consultora.

Esta fase de presentacin y planificacin puede ser


muy corta como muy prolongada dependiendo de
alguna demora que pudiera surgir en las negociaciones
con los proveedores de hardware y la coordinacin que
todos los proveedores tengan los recursos disponibles
en el momento en que se los necesita.
La documentacin de esta ltima fase debe incluir
un cronograma consensuado de tareas a grandes rasgos
y fechas de comienzo de trabajo de todas las partes
involucradas.
6.

Espero MSSE sea de ayuda en esta etapa tan crtica


en el ciclo de vida de un ERP.

CONCLUSIN

7. BIBLIOGRAFA

La compra de un sistema ERP representa para la


empresa una gran inversin no solo econmica sino
tambin de otros recursos, como es el tiempo y esfuerzo
de sus empleados, y la migracin de informacin de un
sistema a otro con los riesgos que este proceso implica.
Se espera que un sistema ERP una vez implementado
dure unos cuantos aos y acompae a la empresa en sus
proyectos, planes y objetivos de negocio. Es por esto
que la seleccin de qu sistema ERP se implementar y
qu consultora har el trabajo de implementacin son
muy delicados.

Metodologa de planificacin y desarrollo de sistemas


de informacin MTRICA Versin 2. MAP,
1990.
An ERP Life-cycle-based research agenda. Jos M.
Esteves, Joan A. Pastor, 1999.
On formalisation of ERP System procurement. Xavier
Franch, Joan Pastor, 1999.
Towars the methodological acquisition of ERP
solutions for SMEs. Francesc Sistach, 1999.

Es importante poder seleccionar el sistema que


mejor se adecue a las necesidades de la empresa en
varios aspectos, no slo los econmicos sino
funcionales, estratgico, tcnicos e inherentes al
proveedor y su servicio. Es importante tambin
encontrar el equilibrio en el producto seleccionado para
que el ERP no quede obsoleto al poco tiempo de
implementacin pero tampoco que sea tan complejo
para la organizacin que ni sea aprovechado en un 10
por ciento de su funcionalidad.

Software Acquisition: Experiences with models and


methods. Gerhard Getto, DaimlerChrysler
research and technology Ulm, Germany, 2002.
Documentacin y manuales de usuario de SAP.
SAP Lder mundial en soluciones empresariales,
Perfil Corporativo. SAP Argentina, 2000.
J. D. Edwards One World: componentization for
business advantage. Hurwitz Group, 1998.

Todos estos puntos hacen pensar que esta etapa es


un proceso crtico, no obstante la seleccin de sistemas
ERP no es un rea de mucho estudio, ms bien se le ha
dedicado ms tiempo de estudio a las metodologas de
implementacin. Son pocas las metodologas que guen
a los directivos y miembros del equipo de proyecto en

Estimating strategic and tangible return on investment.


Benchmarking partners, SAP, 1996.

25

ANEXO
a.

Anexo 1 - Listado de criterios ponderados

Nombre del ERP:


Proveedor:
Evaluacin
1 = Malo
2 = Regular
3 = Bueno
4 = Muy bueno

Encabezado propuesto
Criterios de seleccin
1.- Aspectos Funcionales
Propsito principal
reas soportadas

Adaptabilidad y flexibilidad
Facilidad de parametrizacin
Facilidad para hacer desarrollos
propios
Interaccin con otros sistemas
Soporte especfico de algunos temas
Multi-lenguaje

Descripcin
rea funcional en la que se especializa o enfoca el sistema. El sistema en
general tendr una orientacin contable o logstica, determinar si la
fortaleza del sistema est en los mdulos que la empresa necesita.
reas o funciones de la empresa que son comprendidas y soportadas por el
ERP. Grado de cobertura de los requerimientos. Se reflejarn en lo
diferentes mdulos que se pueden implementar. Por ejemplo: Contable,
financiera, control de gestin, comercial, logstica, produccin, recurso
humanos, entre otros. Tener en cuenta cuales son imprescindibles.
Nivel de parametrizacin en general. En este punto se debera evaluar
cuanto de la empresa viene comprendido en el estndar, cuanto se puede
parametrizar y cuanto se debe desarrollar por fuera del estndar y si esto es
posible.
Evaluar si la necesidad de un cambio o el mantenimiento de la
parametrizacin en general no es una tarea muy compleja.
Posibilidad de desarrollar aplicaciones sobre el sistema que interacten con
la funcionalidad estndar.
Interfaces estndares que permitan comunicacin con otros sistemas o
posibilidad de desarrollo de las mismas.
Por ejemplo Y2K, normas ISO-9000, e-bussiness, agregar algn punto que
pueda ser importante por la actividad de la empresa.
Permite trabajar en distintos idiomas.

Pond X

Valor Y

10
10
5
5
5

Presentaciones legales.

Herramienta para extraccin de libro diario para posterior digitalizacin.


Estructuras de balance adaptables.

Comunicacin con Bancos

Comunicacin electrnica con bancos para manejo de depsitos, boletas,


acreditaciones en cuenta, por ejemplo sistema Datanet.

Ajuste por inflacin

Contempla procesos de ajuste por inflacin en caso de situacin


inflacionaria tanto para cuantas contables como stocks y activos fijos.

Operaciones multimoneda

Manejo de mltiples monedas, manejo de mltiples cotizaciones,


presentaciones de balance en varias monedas

TOTAL

5
8
100%

Ponderacin del grupo

26

8Y

Herramientas amigables de reporting Permite el anlisis matricial de la informacin. Herramientas que le


permitan al usuario editar sus propios reportes en base a libreras
para el usuario
predefinidas.
Esquematizacin de la estructura de Flexibilidad de las estructuras de datos para adaptarlas a la estructura de la
empresa. Soporta estructuras multisociedades es decir varias empresas en
la empresa
un mismo sistema. Posibilidad de diferenciar las operaciones y de hacer
anlisis conjuntos. Esquematizar a la empresa por unidades de negocio.

X*
Y

Posibilidad de adecuar el clculo de impuesto y presentaciones a las normas


impositivas Argentinas. Requerimientos impositivos, reportes de carcter
provincial y nacional: Percepciones de cada provincia, libro IVA compras,
IVA Ventas, SICORE.

Localizaciones

Pond

30%

Z=
P1 = Z * 0,30

2.- Aspectos tcnicos


Adaptabilidad a la estructura
instalada en el cliente
Distintos ambientes
Multiplataforma
Instalacin remota
Cliente / servidor
Base de datos
Herramientas y lenguaje de
programacin
Seguridad
Back-up
Auditoria

Es posible montar el ERP en el HW que posee el cliente

20

El ERP gestiona y permite trabajar con una estructura de servidores para desarrollo,
calidad y produccin. Posibilidad de tener distintos ambientes de trabajo.

10

No necesita una plataforma determinada, es posible que se ejecute en varias


plataformas
Permite instalacin y trabajo del personal tcnico en forma remota, sin estar en el
lugar fsico en donde esta el servidor?
Trabaja con una estructura cliente servidor

10

Bases de datos sobre la que puede trabajar el ERP, es el ERP multi-motor de BD?
Lenguaje de programacin del propio ERP que sirva para adaptar el sistema a las
funcionalidades requeridas.
Perfiles por transacciones y objetos de datos.
Metodologa de backups y de restore
Sistema de auditoria que guarde y permita evaluar accesos al sistema, transacciones
realizadas, actualizaciones, con fecha, hora y usuario.

5
5
10
5
5
2
5

Gestor de configuraciones

Posee herramientas que administran las distintas versiones de los desarrollos y la


parametrizacin.

Documentacin

El ERP posee: Documentacin, help on line en el idioma necesario, pgina de Internet


para mayor ayuda en linea.

Documentacin tcnica
Conectividad externa

Documentos sobre estructura de la base de datos, diseos, programas fuentes.

5
5

Compatibilidad con correo


electrnico

Permite derivar desde algunas aplicaciones mensajes al e-mail.

Soporta conexiones externas del tipo: Internet, EDI, Accesos remotos

5
100%

TOTAL
Ponderacin del grupo
3.- Aspectos sobre el proveedor
Caractersticas del proveedor
Perspectivas de evolucin
Ubicacin
Otras Implementaciones
Experiencia
Confianza

Solidez del proveedor: evolucin histrica, clientes, ganancias, cantidad de empleados.

25

Perspectivas del proveedor en el mercado deben ser buenas ya que si al proveedor le va


mal compraremos un ERP que quedar sin soporte.
Ubicacin de las oficinas. Soporte en la misma ciudad donde se ubican las oficinas.

25
20

Otros clientes del mismo rubro que usen el ERP, pedir contactos para poder consultar
en etapas posteriores. Cantidad de implementaciones.
Experiencia del ERP en general y en la industria de la empresa en particular
Criterio no cuantificable que queda a criterio de los miembros del equipo.

Ponderacin del grupo

Alcance de la implementacin en
caso de hacerla con el proveedor
Metodologa de implementacin
Tipo de implementacin
Tiempo estimado de
implementacin
Grado de participacin en la
implementacin
Garanta de correcta instalacin
del producto
Upgrade
Licencia
Soporte

15%

Libertad para realizar la implementacin con el proveedor o con una consultora.


Existencia de alguna ventaja de implementar directo con el proveedor del ERP.
Instalacin, Adaptacin / parametrizacin, Capacitacin tcnica, Capacitacin a
usuarios, Desarrollos a medida, Mantenimiento

15

Existencia de una metodologa de implementacin. Experiencias previas

15

Estrategia propuesta por el proveedor para la implementacin. mdulos recomendados


y soportados.
Tiempo estimado de implementacin estndar en base a los mdulos seleccionados
Usuarios requeridos por mdulo para soportar la implementacin. Transferencia del
know-how a los usuarios.
Problemas que estaran cubiertos por el proveedor y casos de los cuales el proveedor no
se hara responsable. Alcance de la garanta en tiempo, en aspectos funcionales y
tcnicos
Averiguar cada cuantos tiempo sacan una nueva versin al mercado. Tener en cuenta si
uno debe migrar obligatoriamente a la nueva versin al salir al mercado. De no ser as
consultar cuanto tiempo el proveedor soporta las versiones ms antiguas.
Alcance de la licencia. Incluye el soporte post venta. Alcance del soporte.
Posee repositorio de problemas y soluciones para analistas del ERP. El repositorio es
accesible por Internet. Existe un helpdesk para problemas no reportados en el
repositorio con un tiempo de respuesta aceptable y atencin 24 hs.

Ponderacin del grupo

27

Z=
P3 = Z * 0,15

10
5
5
5
10
10
10
15
100%

TOTAL

Z=
P2 = Z * 0,10

10
10
10
100%

TOTAL

4.- Aspectos sobre el servicio


Servicio de implementacin

10%

10%

Z=
P4 = Z * 0,10

5.- Aspectos econmicos


Costos del ERP

En funcin del presupuesto que se tiene y de los otros presupuestos recibidos


evaluar de el costo del sistema.
En funcin de los requerimientos de HW y
de lo que ya posee la empresa, evaluar el costo
que implica adquirir el equipamiento necesario
para el ERP.
Como se pagan las licencias, por nica vez al momento de la compra; o cuando ya
se implement o una vez por ao?
Como cobra el proveedor el ERP por ejemplo por cantidad de usuarios o modulo
activos o posibilidad de armar paquetes corporativos.
Existen polticas de financiacin.

Costo del HW
Licencias
Mtodo de precio
Financiacin
Contratos
Costos adicionales
Costo de capacitacin

Tipo de contratos que manejan. Revisarlo con el departamento de legales.


Adaptaciones, localizaciones,
Tener en cuenta la posibilidad de seleccionar a otro proveedor para la
implementacin
Costo estimado de consultara

Costo de implementacin
Costo de interfaces
Upgrade

Costo estimado de consultara, programadores y recursos


Costo del Upgrade. Se deben abonar nuevas licencias? Costo del proyecto de
migracin
Existe algn convenio entre el proveedor de ERP, el de consultara y el de HW de
manera de adquirir algn paquete de los 3 productos juntos. De existir consultar
por beneficios tcnicos y econmicos.

Paquete

Ponderacin del grupo

6.- Aspectos estratgicos


Plan estratgico de la empresa
Perspectivas de crecimiento
Nuevos proyectos en mira
Estimar necesidad de informacin
futura
Evaluar el horizonte temporal
Prever reestructuracin de personal

5
5
5
10
10
10
5
5
5

20%

20

Evaluar objetivos a corto y mediano plazo. Adquirir una herramienta en una


versin que no se vuelva obsoleta en poco tiempo.
Se debe tener en cuenta a la hora de seleccionar el ERP la cantidad de usuarios
que se conectaran al sistema. Si la empresa planea reducir o ampliar su plantel
considerar un numero realista. Si la empresa tiene una forma de trabajar en grupo
verificar que el ERP se ajuste a ella
El ERP soporta el trabajo descentralizado? Si la empresa planea mudar sus
oficinas contemplar la posibilidad que las oficinas del proveedor no estn cerca y
si da soporte remoto

15

Ponderacin del grupo

Z=
P5 = Z * 0,20

15
20
20

5
5
100%

TOTAL

Desventajas

10

Incluir en este punto proyectos de negocio que tenga la empresa que deban ser
soportados por el SW con el fin de verificar que estn cubiertos
Si la empresa planea crecer en operaciones con clientes se debe tener en cuenta el
volumen soportado por el sistema.
Incorporar actividad CRM, apertura de nuevas sucursales u oficinas. Verificar que
la futura estructura sea soportada tanto a nivel de HW como de estructura
funcional - lgica dentro del sistema
Futuros negocios, Nuevos proyectos

TOTAL

Ventajas y Desventajas
Ventajas

15

100%

TOTAL

Mudanzas

15

15%

Z=
P6 = Z * 0,15
= P1 + P2 + P3 + P4 + P5 + P6

Reservar una seccin del cuadro para ventajas generales que puedan surgir
de entrevistas con empresas que ya usan el ERP
Reservar una seccin del cuadro para desventajas generales que puedan
surgir de entrevistas con empresas que ya usan el ERP

28

b. Anexo 2 - Encuesta propuesta clasificada por mdulo


Nombre del usuario:
rea de trabajo del usuario:
Fecha:
Proveedor:
Mdulo: completar con el mdulo referenciado
Ponderacin:
0 = tem no evaluado
1 = tem evaluado no soportado por el ERP
2 = tem evaluado soportado por el ERP de manera incompleta
3 = tem evaluado soportado por el ERP con necesidad de varias modificaciones factibles
4 = tem evaluado soportado por el ERP de manera correcta
5 = tem evaluado soportado por el ERP y provee de valor agregado al trabajo
Encabezado propuesto de la encuesta
CRITERIOS
GENERAL
Multicompaa
Multimoneda
Multiplataforma simultanea
Multilenguaje - varios idiomas
Ayudas en pantalla en el idioma de trabajo de la empresa
Manuales en el idioma de trabajo de la empresa
Componentizacion (posibilidad de instalar mdulos por separado)
Procesamiento completo en tiempo real
Auditoria
Herramientas para monitoreo de recursos
Acceso directo a base de datos
Integracin dinmica con planillas de calculo
Apreciacin global del producto
Confianza
Conocimiento del producto por parte del proveedor
Calidad de atencin
Respuesta a las consultas
Presentacin general
CONTABILIDAD GENERAL
Soporta la divisin del rea contable en las distintas funciones de tesorera, cuentas a pagar, a cobrar, balance,
activos fijos?
Permite llevar al sistemas las figuras jurdicas y legales que tenga la empresa.
Permite armar un plan de cuentas segn estndares internacionales.
Plan de cuentas flexible pero que se adecua a normas legales.
Herramientas de reporte flexibles y amigables para armar estructuras de balance
Concepto de posiciones abiertas y compensadas de la cuentas contables.
Compensacin automtica de las posiciones de una cuenta segn criterios parametrizables.
Todos los movimientos de los dems mdulos se ven reflejados en las cuentas contables.
29

La parametrizacin que indica a que cuenta debe ir cada movimiento es sencilla y no demanda de un experto en
sistemas, puede ser gestionado directo por el usuario contable.
Gestiona ajuste manuales a la contabilidad, identificables por tipos de asientos.
Gestiona asientos en distintas monedas.
Conversin automtica de tipo de cambio en caso de trabajar con monedas distintas a la del pas.
Permite al usuario contable administrar los tipos de cambio
Ajustes por inflacin
Cruza fcilmente la informacin contable con la proveniente de otras reas que le dio origen.
Armado de balances para distintos pases
Armado de cuadro de resultados para distintos pases
Definicin de N balances para la sociedad
Definicin de N cuadros de resultados para la misma sociedad
CUENTAS A PAGAR
Maestro con capacidad y flexibilidad para adaptar a los datos de los proveedores
Gestiona de manera sencilla la deuda con el proveedor y los vencimientos.
Alta variedad de reportes para manejar los pagos a los proveedores.
Soporta realizar un pago en varios medios (bonos, pesos, etc.)?
Herramientas para armar archivos para informar pagos a los bancos y que ellos se encarguen de la emisin de
cheques y certificados.
Soporta correctamente temas impositivos?
Soporta el uso de retenciones de IIBB, maneja distintos porcentajes dependiendo la zona?
Provee reportes legales impositivos en el formato adecuado?
Permite emitir certificados de retencin
Permite pagar varias facturas con un pago.
Corrida de pagos que en base a varios parmetros genere una propuesta de lo que se debe pagar.
Emisin automtica de ordenes de pago.
Circuito de autorizacin de los pagos antes de ser emitidos
Conexin va Internet para que el proveedor pueda verificar el estado de la cuenta.
Gestiona anticipos
Conciliacin automtica de movimientos
Contempla el pago en otras monedas
Contempla las facturas de proveedores extranjeros
Posee herramientas de control de duplicidad de facturas
Bloqueo de facturas por defecto en las facturas o problemas con el proveedor
TESORERIA
Conciliacin bancaria
Permite emitir cheques desde el sistema en formularios preimpresos.
Gestin de chequeras externas, es decir si se le enva al banco un archivo con los pagos que debe realizar y este
emite los cheques, la numeracin de los mismos cuando ingresen en el ERP no ser consecutiva sino externa
dentro de un rango.
Definicin de N flujos de fondos diferentes
Control de fondos
Pagos electrnicos
Posicin de tesorera
Previsin de tesorera
Presupuesto de tesorera
30

Administracin de riesgo de mercado


Cartera de cheques para las cobranzas en cheques.
La cartera de cheques permite gestionar varios estados de los valores.
Cheques en custodia y diferidos
Administracin de cheques rechazados por diferentes motivos
CUENTAS A COBRAR
Maestro con capacidad y flexibilidad para almacenar datos de los clientes.
Esquema de clientes padres e hijos, o pagadores y solicitantes con varios puntos de entrega.
Compensacin de documentos en las cuentas de los deudores
Deuda refinanciada o deuda que se gestiona por cobranza externa
Facturas con distintos vencimientos
Pagos en otras monedas.
Facturas en otras monedas.
Gestiona clientes que tambin son proveedores y manejar cuentas nicas
Control de duplicidad de facturas
Aging de deuda por distintos rangos de vencimiento para analizar la deuda
Clasificacin de la deuda del cliente en distintos estados y distinta representacin contable
Herramientas de aviso de tipo calendario para gestionar la deuda.
Herramientas para emitir cartas de reclamos de pago en forma automtica
Cobros parciales
Control de riesgo para todo tipo de clientes
Control de crdito
CONTROL DE GESTION
Facturacin interna por servicios entre distintas reas
Distribucin de gastos en varios centros de costos
Distribucin por cantidades, por importes, por porcentajes, por volumen de venta, por cantidad de personas.
Manejo de presupuestos por reas.
Gestin de presupuestos en diferentes estados (en creacin, aprobado, definitivo).
Modificacin con cadena de aprobacin de un presupuesto aprobado.
Presupuestos por centro de costos
Presupuestos por periodo
Integracin de los presupuestos en un presupuesto global.
Control presupuestario en lnea
Clculo de desviaciones
Alarmas automticas para gestin de desvos.
Aplicacin automtica de tolerancias.
Administracin de ordenes de trabajo
Determinacin de costos en base a la actividad
Anlisis de rentabilidad
ADMINISTRACION DE INVERSIONES
Planificacin de la inversin
Gestin de ordenes de inversin
Presupuesto y control de la inversin
Proyecciones.
Simulaciones.
31

Comparacin con planes de inversin de aos previos.


Clculo de amortizaciones para simulacin
ACTIVOS FIJOS
Gestiona maestro de activos con capacidad para guardar datos necesarios
Cuadro de amortizacin especifico para cada pas segn requisitos legales
Seguimiento del ciclo de vida del activo
Registro de adquisicin
Registro de baja por venta u otra causa
Simulacin y registro de amortizaciones
Registro de amortizaciones por procesos colectivos.
Clculo de intereses
Ajustes por inflacin
Integracin con administracin de proyectos
Integracin con mdulo de mantenimiento para registrar mejoras de activos.
Administracin de bienes alquilados
Administracin de activos en construccin.
Procesamiento en masa de diferentes funcionalidades
Informes y reportes interactivos y flexibles.
COMPRAS
Maestro con capacidad y flexibilidad para adaptar a los datos de los proveedores
Maestro de los artculos y servicios que compra la empresa, flexible y con suficientes clasificaciones disponibles.
Circuito de compras separado en etapas donde cada usuario ingresa en el sistema su operacin
Herramienta que permita llevar un stock de los materiales stockebles.
Existe una operacin que permite a usuarios de las distintas reas ingresar una necesidad al sistema para luego
ser evaluadas por el departamento de compras
La necesidad ingresada contiene un precio sugerido y la suficiente especificacin para que compras pueda
negociar con los proveedores.
La necesidad que el usuario ingresa al sistema es direccionada al comprador que corresponde segn algn
circuito parametrizable.
Los usuarios no podrn ingresar necesidades de cualquier material sino los relacionados a su actividad
Los usuarios tendrn un presupuesto disponible por ao para compras de su rea que ser actualizado en linea.
El requerimiento ingresado por el rea solicitante es sometido a una aprobacin definida por la empresa antes de
ser dirreccionado al departamento de compras.
Los usuarios podrn controlar el grado de avance del flujo de aprobacin de sus requerimiento.
El departamento de compras posee una herramienta flexible para poder analizar los requerimientos hechos por
las reas y clasificarlos en los distintos estados dentro del circuito de compras
El departamento de compras en funcin de los requerimientos ingresados emitir un documento para solicitar
cotizacin a los proveedores del material a comprar.
El sistema permite automticamente enviar al proveedor la solicitud de cotizacin por mail, fax o imprimirla para
enviarla por correo.
Al recibir los presupuestos de los proveedores se podrn ingresar al sistema y podrn ser comparados
automticamente segn criterios indicados por el comprador
La herramienta de anlisis de presupuestos permite realizar grficos y reportes con tablas comparativas.
El comprador podr generar la orden de compra en funcin del presupuesto enviado o de las solicitud ingresada
por el usuario.
32

El precio pactado figura en la orden de compra.


El sistema evala la ultima compra realizada de dicho material y sugiere el mismo precio pactado en ese
momento.
La orden de compra ingresa en un circuito de aprobacin dentro del sistema antes de ser enviada al proveedor.
Los criterios del circuito de aprobacin son adaptables a la necesidad de cada empresa.
El sistema permite utilizar el mail para rutear la orden de compra que esta en el circuito de aprobacin.
El sistema posee una herramienta que permite al comprador y al rea solicitante ir siguiendo la cadena de
aprobacin de la orden
El sistema avisa al comprador cuando una orden esta completamente aprobada para enviarla a proveedor
El sistema no permite enviar al proveedor una orden no aprobada.
Si la orden es modificada el circuito de aprobacin se reinicia.
El sistema permite parametrizar que modificaciones y tolerancias reinician la estrategia de liberacin
La orden de compra puede ser enviada al proveedor por mail, fax o ser impresa para enviarla por correo.
La orden de compra puede ser impresa en original, duplicado y todas las copias necesarias identificando en el
documento cual es cada una.
El envo de la orden de compra al proveedor compromete presupuesto.
El sistema controla la fecha de entrega pactada con el proveedor.
Al recepcionar el rea solicitante la mercadera o servicio comprado el sistema permite ingresar el remita de
dicha entrega.
Al ingresar el remito el material es automticamente ingresado a stock si dicho material es stockeable.
El sistema controla que la cantidad ingresada en el remito sea igual o menor que la solicitada en la orden de
compra.
El sistema prev la posibilidad de ingresar el grado de conformidad del servicio prestado o compra realizada.
Cuando el proveedor enva la factura, cuantas a pagar podr controlar que el remito de dicha compra se haya
ingresado antes de asentar la factura en el sistema.
Compras podr controlar mediante algn reporte amigable el circuito de la compra en caso de ser contactado por
el proveedor para reclamar el pago.
Compras podr controlar mediante algn reporte amigable el circuito de la compra en caso de ser contactado por
el usuario para reclamar la entrega del material.
El sistema permite programar compras frecuentes
El sistema contiene una herramienta que permite pactar una compra anual con un plan de entregas peridico.
El sistema controla disponibilidad de ciertos materiales indicados y notifica al rea cuando el stock llega a un
nivel prefijado.
El sistema no permite ingresar una orden que exceda el presupuesto del rea.
El sistema tiene una herramienta con acceso va Internet que permite a los proveedores notificarse de las
compulsas nuevas, de las peticiones de oferta, del estado de sus facturas, del estado de sus pagos.
El sistema posee una herramienta de reporting flexible que permite al comprador analizar las compras realizadas.
Existe un reporte que permite comparar precios de distintas compras
Existe un reporte que permite comparar compras hechas a un proveedor
Existe un reporte que permite comparar compras hechas de un mismo material donde se listen precios pagados
por unidad, proveedor, cantidad comprada.
Existe un reporte para comparar compras hechas por las distintas reas.
33

Evaluacin de los proveedores


El mdulo posee reportes interactivos y flexibles.
LOGISTICA Y ABASTECIMIENTO
El sistema permite gestionar un maestro de materiales con capacidad de varios campos para almacenar de datos
de los materiales
El sistema permite estructurar la empresa en centros de abastecimiento, depsitos, almacenes, puntos de entrega,
etc.
El sistema permite asociar los materiales y productos a los distintos puntos de la estructura definida.
Maneja diferentes unidades de medida para almacenamiento
Maneja diferentes unidades de medida para compras
Maneja diferentes unidades de medida para consumo
Maneja diferentes unidades de medida para facturacin
Permite definir la relacin entre diferentes unidades
Gestiona materiales en distintos estados: disponibles, en transito, en control de calidad, bloqueado, reservado y
otros estados definidos por el usuario segn la industria.
Soporta el anlisis ABC
El sistema prev una herramienta para controlar el stock
Rotacin de stocks
Herramientas de aviso para notificar cuando haya piezas o materiales que estn faltando.
Posee herramientas para planificar disponibilidad analizando consumos previos
Maneja stock de seguridad
Disponibilidad por almacn
El stock se actualiza automticamente con el ingreso de los remitos por compra
El stock se actualiza automticamente con la baja por consumo de produccin o por venta
Gestiona ajustes de distintos tipos.
Gestiona asignacin de nmeros de lote
Permite la administracin de rutas y recorridos
Posee herramientas para optimizar los circuitos de camiones o cualquier medio de transporte.
Gestiona flota de camiones, autos o cualquier medio de transporte.
Permite administrar un maestro de chferes o personas relacionadas a los medios de transporte.
Posibilidad de implementar sistema de lectura por cdigo de barras.
COMERCIAL
Posee flexibilidad para armar la estructura de la empresa en diferentes categoras, niveles, divisiones, unidades,
oficinas de ventas, puestos de expedicin, puestos de carga, etc.
Permite gestionar las divisiones en unidades de negocio si existieran
Permite gestionar las ventas segn las vas de ventas o el canal, minorista, mayorista, etc
Permite gestionar las ventas segn el sectores
Administra pedidos de clientes
Cotizacin al clientes segn distintos criterios.
Orden de venta
Despacho de la mercadera
Planes de entrega
Verificacin de disponibilidad
Procesamiento de devoluciones.
Facturacin segn normas legales
Representa las transacciones arriba nombradas como operaciones diferentes y distinguibles.
34

Permite registrar actividades de preventa o markenting.


Descuentos y promociones
Permite registrar los llamados o visitas de los clientes a la empresa.
Permite clasificar dichos "contactos" segn su motivo y estado.
Gestiona el status de los contactos y su ciclo de vida.
Permite a travs de los contactos gestionar la relacin con el cliente para emitir estadsticas.
Administra consulta hechas por los clientes
Permite gestionar la cartera de clientes con diferentes ponderaciones
Determinacin de precios.
Controlar y gestionar precios
Planificacin de transporte.
Comercio exterior: mantiene datos para exportaciones, licencias, declaraciones, guas etc.
Posee herramientas de reporting flexibles que permiten analizar las ventas por diferentes caractersticas.
Permite sacar estadsticas de ventas
Permite analizar a travs de reportes comportamientos y tendencias almacenando informacin histrica
Procesamiento cruzado entre compaas.
Contratos y acuerdos de ventas
PRODUCCION
Herramientas para controlar y planificar la produccin
Integrado al modulo de ventas para poder planificar en funcin de las ventas
Planificacin de requerimiento de materiales
Pronsticos
Planificacin de recursos de fabricacin
Planificacin de capacidad
Control de la actividad de produccin
Colector de datos de planta
Control de piso de planta
Determinacin de costos
Administracin de proyectos
Administracin de recursos
Administracin de recetas
Planificacin de procesos
Programacin de procesos
Ejecucin de procesos
Administracin de procesos
Enlaces con sistemas LIMS, PCS y DMS
Administracin de informacin de produccin
MANTENIMIENTO
Planificacin de costos para el manteniendo de equipos en planta
Administracin objetos tcnicos y equipos
Estructura con almacenes, sitios tcnicos, emplazamientos, etc
Gestin de maestro de maquinaria
Relacin entre las ubicaciones tcnicas y los equipos.
Programacin del mantenimientos
35

Planificacin del mantenimiento de equipos.


Registro de operaciones sobre equipos, inspecciones, certificaciones, auditorias, etc.
Registro de alarmas y necesidades de reparacin
Planificacin de servicios.
Administracin de antecedentes
sistemas de reporting de mantenimiento para sacar estadsticas
CONTROL DE CALIDAD
Planificacin de la calidad inspeccin de calidad
Control de calidad
Notificaciones de calidad
Certificados de calidad
Sistema de reporting y estadstica para administracin de la calidad
c.

Anexo 3 - Listado de criterios ponderados para seleccionar la consultora

Criterios de seleccin

Pond X

1.- Aspectos generales


Solidez del proveedor
Soporte en el pas
Cantidad de implementaciones
Calidad de implementaciones
Evolucin histrica del proveedor
Perspectiva de evolucin futura
Metodologa de implementacin
Compromiso en tiempo y forma
Evaluacin del equipo asignado
Personal tercia rizado
TOTAL

Ponderacin del grupo

2.- Aspectos econmicos


Costo hora
Costo total
TOTAL

Ponderacin del grupo

36

Valor Y

Pond
X*Y

10%
10%
5%
10%
5%
5%
20%
15%
15%
5%
100%

Z=

40%

P1 = Z * 0,40

30%
70%
100%

Z=

60%

P2 = Z * 0,60

d. Anexo 4 Cuadro comparativo de propuestas de implementacin


Aspectos
Fecha de puesta en
productivo
Duracin del proyecto
Precio cerrado
Plazo cerrado
Costo
Implementacin
Soporte post
implementacin
Interfaces
Capacitacin equipo de
trabajo
Capacitacin usuarios
Instalacin inicial del ERP
Equipo de base
COSTO TOTAL

Consultora 1

Consultora 2

37

Consultora 3

Consultora 4

Consultora 5

ANEXO 2
LISTADO CRITERIOS PONDERADOS MSSE

Tabla 3 Listado Criterios Ponderados MSSE

CRITERIOS DE
DESCRIPCIN
SELECCIN
1. ASPECTOS FUNCIONALES
Propsito principal rea funcional en la que se especializa o enfoca el sistema. El sistema en general tendr una orientacin contable o
logstica, determinar si la fortaleza del sistema est en los mdulos que la empresa necesita.
reas soportadas
reas o funciones de la empresa que son comprendidas y soportadas por el ERP. Grado de cobertura de los
requerimientos. Se reflejaran en los diferentes mdulos que se pueden implementar. Por ejemplo: Contable, financiera,
control de gestin, comercial, logstica, produccin, recursos humanos, entre otros. Tener en cuenta cuales son
imprescindibles.
Adaptabilidad y
Nivel de parametrizacin en general. En este punto se debera evaluar cuanto de la empresa viene comprendido en el
flexibilidad
estndar, cuanto se puede parametrizar y cuanto se debe desarrollar por fuera del estndar y si esto es posible.
Facilidad de
Evaluar si la necesidad de un cambio o el mantenimiento de la parametrizacin en general no es una tarea muy
parametrizacin
compleja.
Facilidad para
Posibilidad de desarrollar aplicaciones sobre el sistema que interacten con la funcionalidad estndar.
hacer desarrollos
propios
Interaccin con
Interfaces estndares que permitan comunicacin con otros sistemas o posibilidad de desarrollo de las mismas.
otros sistemas
Soporte especifico Por ejemplo Y2K, normas ISO-9000, e-business, agregar algn punto que pueda ser importante por la actividad de la
de algunos temas
empresa.
Multi-Lenguaje
Permite trabajar en distintos idiomas
Localizaciones
Posibilidad de adecuar el clculo de impuesto y presentaciones a las normas impositivas de cada pas.
Presentaciones
Herramienta para extraccin del libro diario para posterior digitalizacin. Estructuras de balance adaptables.
legales
Comunicacin con Comunicacin electrnica con bancos para manejo de depsitos, boletas, acreditaciones en cuenta.
bancos
Ajuste por
Contempla procesos de ajuste por inflacin en casos de situacin inflacionaria tanto para cuentas contables como
inflacin
stocks y activos fijos.
Operaciones
Manejo de mltiples monedas, manejo de mltiples cotizaciones, presentaciones de balance en varias monedas.
multimoneda
Herramientas
Permite el anlisis matricial de la informacin. Herramientas que le permitan al usuario editar sus propios reportes en
amigables de
base a libreras predefinidas.
reporting para el
usuario
Esquematizacin
Flexibilidad de las estructuras de datos para adaptarlas a la estructura de la empresa. Soporta estructuras
de la estructura
multisociedades, es decir, varias empresas en un mismo sistema. Posibilidad de diferenciar las operaciones y de hacer
de la empresa
anlisis conjuntos. Esquematizar a la empresa por unidades de negocio.
TOTAL
Ponderacin de grupo 30%

POND X

VALOR Y

POND X * VALOR Y

8Y

100%

SUMATORIA

Valor Grupo = Sumatoria * 0.30


2. ASPECTOS TECNICOS
Adaptabilidad a la
Es posible montar el ERP en el HW que posee el cliente.
estructura
instalada en el
cliente
Distintos
El ERP gestiona y permite trabajar con una estructura de servidores para desarrollo, calidad y produccin. Posibilidad
ambientes
de tener distintos ambientes de trabajo.
Multiplataforma
No necesita una plataforma determinada, es posible que se ejecute en varias plataformas.
Instalacin remota Permite instalacin y trabajo del personal tcnico en forma remota, sin estar en el lugar fsico en donde est el
servidor.
Cliente / Servidor
Trabaja con estructura cliente servidor
Base de datos
Bases de datos sobre las que puede trabajar el ERP, Es el ERP multi-motor de BS?.
Herramientas y
Lenguaje de programacin del propio ERP que sirva para adaptar el sistema a las funcionalidades requeridas.
lenguaje de
programacin
Seguridad
Perfiles por transacciones y objetos de datos.
Back-up
Metodologa de backups y de restore.
Auditoria
Sistema de auditoria que guarde y permita evaluar accesos al sistema, transacciones realizadas, actualizaciones con
fecha, hora y usuario.
Gestor de
Posee herramientas que administran las distintas versiones de los desarrollos y la parametrizacin.
configuraciones
Documentacin
El ERP posee: Documentacin, help on line en el idioma necesario y pgina de internet para mayor ayuda en lnea.
Documentacin
Documentos sobre estructura de la base de datos, diseos, programas fuentes
tcnica
Conectividad
Soporta conexiones externas del tipo: Internet, EDI y accesos remotos.
externa
Compatibilidad
Permite derivar desde algunas aplicaciones mensajes al E-Mail.
con correo
electrnico
TOTAL
Ponderacin de grupo: 10%
Valor grupo: Sumatoria * 0.10
3. ASPECTOS SOBRE EL PROVEEDOR
Caractersticas
Solidez del proveedor, evolucin histrica, clientes, ganancias y cantidad de empleados.
del proveedor
Perspectivas de
Las perspectivas del proveedor en el mercado deben ser buenas ya que si al proveedor le va mal compraremos un ERP
evolucin
que quedar sin soporte.
Ubicacin
Ubicacin de las oficias. Soporte en la misma ciudad donde se ubican las oficinas.
Otras
Otros clientes del mismo rubro que usen el ERP, pedir contactos para poder consultar etapas posteriores. Cantidad de
implementaciones
implementaciones.
Experiencia
Experiencia del ERP en general y en la industria de la empresa en particular.
Confianza
Criterio no cuantificable que queda a criterio de los miembros del equipo.
TOTAL

100%

SUMATORIA

100%

SUMATORIA

Ponderacin de grupo: 15%


Valor grupo: Sumatoria * 0.15
4. ASPECTOS SOBRE EL SERVICIO
Servicio de
Libertar para realizar la implementacin con el proveedor o con una consultora.
implementacin
Existencia de algina ventaja de implementar directo con el proveedor del ERP.
Alcance de la
Instalacin, adaptacin / parametrizacin, capacitacin tcnica, capacitacin a usuarios, desarrollo a medida y
implementacin
mantenimiento.
en caso de
hacerla con el
proveedor
Metodologa de
Existencia de una metodologa de implementacin y experiencias previas.
implementacin
Tipo de
Estrategia propuesta por el proveedor para la implementacin, mdulos recomendados y soportados.
implementacin
Tiempo estimado
Tiempo estimado de implementacin estndar en base a los mdulos seleccionados.
de
implementacin
Grado de
Usuarios requeridos por mdulo para soportar la implementacin.
participacin en la
Transferencia del know-how a los usuarios.
implementacin
Garanta de
Problemas que estaran cubiertos por el proveedor y casos de los cuales el proveedor no se hara responsable.
correcta
Alcance de la garanta en tiempo, en aspectos funcionales y tcnicos.
instalacin del
producto
Upgrade
Averiguar cada cuanto tiempo sacan una nueva versin al mercado, tener en cuenta si uno debe migrar
obligatoriamente a la nueva versin al salir al mercado. De no ser as, consultar cuanto tiempo el proveedor soportar las
versiones ms antiguas.
Licencia
Alcance dela licencia, si esta incluye el soporte post-venta y el alcance del soporte.
Soporte
Posee repositorio de problemas y soluciones para analistas del ERP, el repositorio es accesible por internet, existe un
helpdesk para problemas no soportados en el repositorio con un tiempo de respuesta accesible a atencin 24 horas.
TOTAL
Ponderacin de grupo: 10%
Valor grupo: Sumatoria * 0.10
5. ASPECTOS ECONMICOS
Costos del ERP
En funcin del presupuesto que se tiene y de los otros presupuestos recibidos, se debe evaluar el costo del sistema.
Costo del HW
En funcin de los requerimientos del HW y de lo que ya posee la empresa, evaluar el costo que implica adquirir el
equipamiento necesario para el ERP.
Licencias
Como se pagan las licencias, si este pago es por nica vez al momento de la compra, o cuando ya se implement o si
es anual.
Mtodo de precio
Como cobra el proveedor el ERP, por ejemplo, por cantidad de usuarios o mdulo activo, o si existe la posibilidad de
armar paquetes corporativos
Financiacin
Evaluar si existen polticas de financiacin.
Contratos
Tipo de contratos que manejan, el cual debe ser revisado por el departamento de legales.
Costos
Adaptaciones y localizaciones.
adicionales

100%

SUMATORIA

Costo de
capacitacin
Costo de
implementacin
Costo de
interfaces
Upgrade
Paquete

Tener en cuenta la posibilidad de seleccionar a otro proveedor para la implementacin


Costo estimado de consultora.
Costo estimado de consultora, programadores y recursos.
Costo del upgrade, si se deben abonar nuevas licencias y el costo del proyecto de migracin.
Existe algn convenio entre el proveedor del ERP, el de consultora y el de HW, de manera que exista la posibilidad de
adquirir algn paquete de los 3 productos juntos. De existir consultar por beneficios tcnicos y econmicos.

TOTAL

100%

SUMATORIA

100%

SUMATORIA

Ponderacin de grupo: 20%


Valor grupo: Sumatoria * 0.20
6. ASPECTOS ESTRATGICOS
Estimar la
Futuros negocios y nuevos proyectos.
necesidad de
informacin futura
Evaluar el
Evaluar objetivos a corto y mediano plazo. Adquirir una herramienta en una versin que no se vuelva obsoleta en poco
horizonte
tiempo.
temporal
Prever
Se debe tener en cuenta a la hora de seleccionar el ERP la cantidad de usuarios que se conectaran al sistema. Si la
reestructuracin
empresa planea reducir o ampliar su plantel considerar un nmero realista. Si la empresa tiene una forma de trabajar en
de personal
grupo, verificar que el ERP se ajuste a ella.
Mudanzas
El ERP soporta el trabajo descentralizado?. Si la empresa planea mudar sus oficinas contemplar la posibilidad que las
oficinas del proveedor no estn cerca y si da soporte remoto.
TOTAL
Ponderacin de grupo: 20%
Valor grupo: Sumatoria * 0.20

ANEXO 3
LISTADO CRITERIOS PONDERADOS PARA
LA TESIS

TABLA 4 LISTADO CRITERIOS PONDERADOS PARA LA TESIS


CRITERIOS DE
DESCRIPCIN
SELECCIN
1. ASPECTOS FUNCIONALES
Propsito principal rea funcional en la que se especializa o enfoca el sistema. El sistema en general tendr una orientacin contable o
logstica, determinar si la fortaleza del sistema est en los mdulos que la empresa necesita.
reas soportadas
reas o funciones de la empresa que son comprendidas y soportadas por el ERP. Grado de cobertura de los
requerimientos. Se reflejaran en los diferentes mdulos que se pueden implementar. Por ejemplo: Contable, financiera,
control de gestin, comercial, logstica, produccin, recursos humanos, entre otros. Tener en cuenta cuales son
imprescindibles.
Adaptabilidad y
Nivel de parametrizacin en general. En este punto se debera evaluar cuanto de la empresa viene comprendido en el
flexibilidad
estndar, cuanto se puede parametrizar y cuanto se debe desarrollar por fuera del estndar y si esto es posible.
Facilidad de
Evaluar si la necesidad de un cambio o el mantenimiento de la parametrizacin en general no es una tarea muy
parametrizacin
compleja.
Facilidad para
Posibilidad de desarrollar aplicaciones sobre el sistema que interacten con la funcionalidad estndar.
hacer desarrollos
propios
Interaccin con
Interfaces estndares que permitan comunicacin con otros sistemas o posibilidad de desarrollo de las mismas.
otros sistemas
Soporte especifico Por ejemplo Y2K, normas ISO-9000, e-business, agregar algn punto que pueda ser importante por la actividad de la
de algunos temas
empresa.
Multi-Lenguaje
Permite trabajar en distintos idiomas
Localizaciones
Posibilidad de adecuar el clculo de impuesto y presentaciones a las normas impositivas de cada pas.
Presentaciones
Herramienta para extraccin del libro diario para posterior digitalizacin. Estructuras de balance adaptables.
legales
Comunicacin con Comunicacin electrnica con bancos para manejo de depsitos, boletas, acreditaciones en cuenta.
bancos
Ajuste por
Contempla procesos de ajuste por inflacin en casos de situacin inflacionaria tanto para cuentas contables como
inflacin
stocks y activos fijos.
Operaciones
Manejo de mltiples monedas, manejo de mltiples cotizaciones, presentaciones de balance en varias monedas.
multimoneda
Herramientas
Permite el anlisis matricial de la informacin. Herramientas que le permitan al usuario editar sus propios reportes en
amigables de
base a libreras predefinidas.
reporting para el
usuario
Esquematizacin
Flexibilidad de las estructuras de datos para adaptarlas a la estructura de la empresa. Soporta estructuras
de la estructura
multisociedades, es decir, varias empresas en un mismo sistema. Posibilidad de diferenciar las operaciones y de hacer
de la empresa
anlisis conjuntos. Esquematizar a la empresa por unidades de negocio.
TOTAL
Ponderacin de grupo 60%
Valor Grupo = Sumatoria * 0.60
CRITERIOS DE
DESCRIPCIN
SELECCIN

POND X

VALOR Y

POND X * VALOR Y

8Y

100%

POND X

SUMATORIA

VALOR Y

POND X * VALOR Y

2. ASPECTOS TECNICOS
Adaptabilidad a la
Es posible montar el ERP en el HW que posee el cliente.
estructura
instalada en el
cliente
Distintos
El ERP gestiona y permite trabajar con una estructura de servidores para desarrollo, calidad y produccin. Posibilidad
ambientes
de tener distintos ambientes de trabajo.
Multiplataforma
No necesita una platafoma determinada, es posible que se ejecute en varias plataformas.
Instalacin remota Permite instalacin y trabajo del personal tcnico en forma remota, sin estar en el lugar fsico en donde est el
servidor.
Cliente / Servidor
Trabaja con estructura cliente servidor
Base de datos
Bases de datos sobre las que puede trabajar el ERP, Es el ERP multi-motor de BS?.
Herramientas y
Lenguaje de programacin del propio ERP que sirva para adaptar el sistema a las funcionalidades requeridas.
lenguaje de
programacin
Seguridad
Perfiles por transacciones y objetos de datos.
Back-up
Metodologa de backups y de restore.
Auditoria
Sistema de auditoria que guarde y permita evaluar accesos al sistema, transacciones realizadas, actualizaciones con
fecha, hora y usuario.
Gestor de
Posee herramientas que administran las distintas versiones de los desarrollos y la parametrizacin.
configuraciones
Documentacin
El ERP posee: Documentacin, help on line en el idioma necesario y pgina de internet para mayor ayuda en lnea.
Documentacin
Documentos sobre estructura de la base de datos, diseos, programas fuentes
tcnica
Conectividad
Soporta conexiones externas del tipo: Internet, EDI y accesos remotos.
externa
Compatibilidad
Permite derivar desde algunas aplicaciones mensajes al E-Mail.
con correo
electrnico
TOTAL
Ponderacin de grupo: 40%
Valor grupo: Sumatoria * 0.40

100%

SUMATORIA

ANEXO 4
DOCUMENTACIN TCNICA DE OPENERP

Open Source RAD with OpenObject

Control). You also need to install the required dependencies (PostgreSQL


and a few Python libraries see documentation on doc.openerp.com).

PREAMBLE OpenERP is a modern Enterprise Management Software, released

Compilation tip: OpenERP being Python-based, no compilation step is needed

under the AGPL license, and featuring CRM, HR, Sales, Accounting,
Manufacturing, Inventory, Project Management, ... It is based on
OpenObject, a modular, scalable, and intuitive Rapid Application
Development (RAD) framework written in Python.

1
2
3

Typical bazaar checkout procedure (on Debian-based Linux)


$ sudo apt-get install bzr
# install bazaar version control
$ bzr branch lp:openerp
# retrieve source installer
$ cd openerp && python ./bzr_set.py
# fetch code and perform setup

Database creation

OpenObject features a complete and modular toolbox for quickly


building applications: integrated Object-Relationship Mapping (ORM)
support, template-based Model-View-Controller (MVC) interfaces, a report
generation system, automated internationalization, and much more.

After installation, run the server and the client. From the GTK client, use
FileDatabasesNew Database to create a new database (default super
admin password is admin). Each database has its own modules and
config, and demo data can be included.

Python is a high-level dynamic programming language, ideal for RAD,


combining power with clear syntax, and a core kept small by design.

The code samples used in this memento are taken from a


hypothetical idea module. The purpose of this module would be to help
creative minds, who often come up with ideas that cannot be pursued
immediately, and are too easily forgotten if not logged somewhere. It
could be used to record these ideas, sort them and rate them.
CONTEXT

Note: Modular development


OpenObject uses modules as feature containers, to foster maintainable and
robust development. Modules provide feature isolation, an appropriate level of
abstraction, and obvious MVC patterns.

Composition of a module

OpenERP is distributed as packages/installers for most platforms, but can


of course be installed from the source on any platform.

A module may contain any of the following elements:


business objects: declared as Python classes extending the osv.osv
OpenObject class, the persistence of these resources is completely
managed by OpenObject ;
data: XML/CSV files with meta-data (views and workflows
declaration), configuration data (modules parametrization) and demo
data (optional but recommended for testing, e.g. sample ideas) ;
wizards: stateful interactive forms used to assist users, often
available as contextual actions on resources ;
reports: RML (XML format), MAKO or OpenOffice report templates, to
be merged with any kind of business data, and generate HTML, ODT or
PDF reports.

OpenERP Architecture

Typical module structure

Each module is contained in its own directory within the server/bin/addons


directory in the server installation.

Package installation
Windows
Linux
Mac

all-in-one installer, and separate installers for server, client, and


webserver are on the website
openerp-server and openerp-client packages are available via
corresponding package manager (e.g. Synaptic on Ubuntu)
look online for package installers for the GTK client, as well as
tutorials for installing the server (e.g. devteam.taktik.be)

Note: You can declare your own add-ons directory in the configuration file of
OpenERP (passed to the server with the -c option) using the addons_path option.
4
5
6
7
8
9
10
11
12
13
14
15

addons/
|- idea/
|- demo/
|- i18n/
|- report/
|- security/
|- view/
|- wizard/
|- workflow/
|- __init__.py
|- __terp__.py
|- idea.py

#
#
#
#
#
#
#
#
#
#
#

The module directory


Demo and unit test population data
Translation files
Report definitions
Declaration of groups and access rights
Views (forms,lists), menus and actions
Wizards definitions
Workflow definitions
Python package initialization (required)
module declaration (required)
Python classes, the module's objects

Predefined attributes are used in the Python class to specify a business


object's characteristics for the ORM:
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

idea.py:

from osv import osv, fields


class idea(osv.osv)
idea
_name = 'idea.idea'
_columns = {
'name': fields.char('Title', size=64, required=True, translate=True),
'state': fields.selection([('draft','Draft'),
('confirmed','Confirmed')],'State',required=True,readonly=True),
# Description is read-only when not draft!
'description': fields.text('Description', readonly=True,
states={'draft': [('readonly', False)]} ),
'active': fields.boolean('Active'),
'invent_date': fields.date('Invent date'),
# by convention, many2one fields end with '_id'
'inventor_id': fields.many2one('res.partner','Inventor'),
'inventor_country_id': fields.related('inventor_id','country',
readonly=True, type='many2one',
relation='res.country', string='Country'),
# by convention, *2many fields end with '_ids'
'vote_ids': fields.one2many('idea.vote','idea_id','Votes'),
'sponsor_ids': fields.many2many('res.partner','idea_sponsor_rel',
'idea_id','sponsor_id','Sponsors'),
'score': fields.float('Score',digits=(2,1)),
'category_id' = many2one('idea.category', 'Category'),
}
_defaults = {
'active': lambda *a: 1,
# ideas are active by default
'state': lambda *a: 'draft',
# ideas are in draft state by default
}
def _check_name(self,cr,uid,ids):
for idea in self.browse(cr, uid, ids):
return 'spam' not in idea.name # Can't create ideas with spam!
_sql_constraints = [('name_uniq','unique(name)', 'Idea must be unique!')]
_constraints = [(_check_name,'Please avoid spam in ideas !', ['name'])]
idea() # Instantiate the class

Predefined osv.osv attributes for business objects


_name (required)

business object name, in dot-notation (in module namespace)

_columns (required)

dictionary {field names object fields declarations }

_defaults

dictionary: { field names functions providing defaults }

_auto

if True (default) the ORM will create the database table set
to False to create your own table/view within the init() method

_inherit

_name of the parent business object (for prototype inheritance)

_inherits

for multiple / instance inheritance mechanism: dictionary


mapping the _name of the parent business objects to the names
of the corresponding foreign key fields to use

_defaults['name'] = lambda cr,uid,context: 'default name'

The __init__.py file is the Python module descriptor, because an OpenERP


module is also a regular Python module.
16
17

__init__.py:

# Import all files & directories containing python code


import idea, wizard, report

The __terp__.py is the OpenERP descriptor and contains a single Python


dictionary with the actual declaration of the module: its name,
dependencies, description, and composition.

Installing from source

There are two alternatives: using a tarball provided on the website, or


directly getting the source using Bazaar (distributed Source Version

Key component of OpenObject, the Object Service (OSV) implements a


complete Object-Relational mapping layer, freeing developers from having
to write basic SQL plumbing.
Business objects are declared as Python classes inheriting from the osv.osv
class, which makes them part of the OpenObject Model, and magically
persisted by the ORM layer.

Building an OpenERP module: idea

Installing OpenERP

Tip: Installation procedure


The procedure for installing OpenERP is likely to evolve (dependencies and so
on), so make sure to always check the specific documentation (packaged & on
website) for the latest procedures. See http://doc.openerp.com/install

'version' : '1.0',
'author' : 'OpenERP',
'description' : 'Ideas management module',
'category': 'Enterprise Innovation',
'website': 'http://www.openerp.com',
'depends' : ['base'], # list of dependencies, conditioning startup order
'update_xml' : [
# data files to load at module init
'security/groups.xml',
# always load groups first!
'security/ir.model.access.csv', # load access rights after groups
'workflow/workflow.xml',
'view/views.xml',
'wizard/wizard.xml',
'report/report.xml',
],
'demo_xml': ['demo/demo.xml'],
# demo data (for unit tests)
'active': False,
# whether to install automatically at new DB creation

Object Service ORM

Tip: Useful links


Main website, with OpenERP downloads: www.openerp.com
Functional & technical documentation: doc.openerp.com
Community resources: www.launchpad.net/open-object
Integration server: test,openobject.com
Learning Python: doc.python.org
OpenERP E-Learning platform: edu.openerp.com

OpenERP uses the well-known client-server paradigm, with different


pieces of software acting as client and server depending on the desired
configuration.Client software
OpenERP provides a thick desktop client (GTK+) on all platforms, and a
web interface is also accessible using any modern browser.

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

18
19

__terp__.py:
{

'name' : 'Idea',

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

_constraints

list of tuples defining the Python constraints, in the form


(func_name, message, fields). (68)

p.1/7

ORM fields types

Predefined osv.osv attributes for business objects


_sql_constraints

list of tuples defining the SQL constraints, in the form


(name, sql_def, message). (67)

_log_access

If True (default), 4 fields (create_uid, create_date, write_uid,


write_date) will be used to log record-level operations, made
accessible via osv's perm_read() function

_order

Name of the field used to sort the records in lists (default: 'id')

_rec_name

Alternative field to use as name, used by osv's name_get()


(default: _name)

_sql

SQL code to create the table/view for this object (if _auto is
False) can be replaced by SQL execution in the init() method

_table

SQL table name to use (default: _name with dots '.' replaced by
underscores '_')

Inheritance mechanisms

boolean(...) integer(...) date(...)


datetime(...) time(...)

'active': fields.boolean('Active'),
'priority': fields.integer('Priority'),
'start_date': fields.date('Start Date'),

char(string,size,translate=False,..)
text(string, translate=False, )

Text-based fields
float(string, digits=None, ...)

Dynamic attribute with specific access rights


obj: object (required)
type: type of equivalent field

translate: True if field values can be


translated by users
size: maximum size for char fields (41,45)

Floating-point value with


arbitrary precision and scale

ORM fields types


property(obj, type='float', view_load=None, group_name=None, )

Tip: relational fields symmetry

digits: tuple (precision, scale) (57) . If digits

is not provided, it's a float, not a decimal type.

selection(values, string, ...)

values: list of values (key-label tuples) or


function returning such a list (required) (42)

Field allowing selection among


a set of predefined values
binary(string, filters=None, ...)

Field for storing a file or binary


content.
reference(string, selection, size,..)

Field with dynamic relationship


to any other object, associated
with an assistant widget

name

filters: optional filename filters

many2one(obj, ondelete='set null', )


(50)

one2many(obj, field_id, ) (55)

Relationship towards a parent


object (using a foreign key)
Virtual relationship towards
multiple objects (inverse of
many2one)

obj: _name of destination object (required)


field_id: field name of inverse many2one, i.e.

corresponding foreign key (required)

many2many(obj, rel, field1, field2, )


(56)

Bidirectional multiple
relationship between objects

obj: _name of destination object (required)


ondelete: deletion handling, e.g. 'set null ',
'cascade', see PostgreSQL documentation

obj: _name of destination object (required)


rel: relationship table to use (required)
field1: name of field in rel table storing the id

of the current object (required)


field2: name of field in rel table storing the id
of the target object (required)
Functional fields

ORM field types

Objects may contain 3 types of fields: simple, relational, and functional.


Simple types are integers, floats, booleans, strings, etc. Relational fields
represent the relationships between objects (one2many, many2one,
many2many). Functional fields are not stored in the database but
calculated on-the-fly as Python functions. Relevant examples in the idea
class above are indicated with the corresponding line numbers (XX,XX)

ORM fields types


Common attributes supported by all fields (optional unless specified)

string: field label (required)


required: True if mandatory
readonly: True if not editable
help: help tooltip
select: 1 to include in search

views and optimize for list


filtering (with database index)

function(fnct, arg=None, fnct_inv=None, fnct_inv_arg=None, type='float',


fnct_search=None, obj=None, method=False, store=False, multi=False,)

Functional field simulating a real field, computed rather than stored

context: dictionary with contextual

parameters (for relational fields)


change_default: True if field should be usable
as condition for default values in clients
states: dynamic changes to this field's
common attributes based on the state field
(42,46)

fnct: function to compute the field value (required)


def fnct(self, cr, uid, ids, field_name, arg, context)
returns a dictionary { idsvalues } with values of type type
fnct_inv: function used to write a value in the field instead
def fnct_inv(obj, cr, uid, id, name, value, fnct_inv_arg, context)
type: type of simulated field (any other type besides 'function')
fnct_search: function used to search on this field
def fnct_search(obj, cr, uid, obj, name, args)
returns a list of tuples arguments for search(), e.g. [('id','in',[1,3,5])]
obj: model _name of simulated field if it is a relational field
store, multi: optimization mechanisms (see usage in Performance Section)

active

archive flag for record deletion, records are hidden if False

parent_id

defines tree structure on records, and enables child_of operator in search


criteria

Working with the ORM

Inheriting from the osv.osv class makes all the ORM methods available on
business objects. These methods may be invoked on the self object within
the Python class itself (see examples in the table below), or from outside
the class by first obtaining an instance via the ORM's pooler system.

Relational fields
domain: optional restriction in the form of
arguments for search (see search())

unique name used by default for labels in forms, lists, etc.


if missing, use _rec_name to specify another field to use

sequence defines order, and allows drag & drop reordering in lists

selection: model _name of allowed objects

'contact': fields.reference('Contact',[
('res.partner','Partner'),
('res.partner.contact','Contact')], 128)

one2many many2one + many2one one2many = many2many

The following fields have pre-defined semantics in OpenObject

types and corresponding label (same format as


values for selection fields) (required)
size: size of text column used to store it (as
text: 'model_name,object_id' ) (required)

Common attributes supported by


relational fields

many2many many2many are symmetric when inversed (swap field1 and field2)

Special fields

'picture': fields.binary('Picture',
filters='*.png,*.gif')

one2many many2one are symmetric

71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

ORM usage sample

class idea2(osv.osv):
idea2
_name = 'idea.idea2'
_inherit = 'idea.idea'
def _score_calc(self,cr,uid,ids,field,arg,context):
res = {}
# This loop generates only 2 queries thanks to browse()!
for idea in self.browse(cr,uid,ids):
sum_vote = sum([v.vote for v in idea.vote_ids])
avg_vote = sum_vote/len(idea.vote_ids)
res.update(idea.id, avg_vote)
return res
_columns = {
# Replace static score with average of votes
'score':fields.function(_score_calc,type='float',method=True)
}
idea2()

ORM Methods on osv.osv objects


self.pool('object_name') may be used to

OSV generic accessor

obtain a model class from anywhere


Common parameters, used by
multiple methods

cr: database connection (cursor)


uid: id of user performing the operation
ids: list of record ids, or single integer when

values: dictionary of field values for the

there is only one id


context: optional dictionary of contextual
parameters, such as user language
e.g. { 'lang': 'en_US', ... }
create(cr, uid, values,
context=None)

Creates a new record with the


specified value
Returns: id of the new record

record
idea_id = self.create(cr, uid,
{ 'name': 'Spam recipe',
'description' : 'spam & eggs',
'inventor_id': 45,
})

related(f1, f2, , type='float', ) Shortcut field equivalent to browsing chained fields


f1,f2,...: chained fields to reach target (f1 required) (51)
type: type of target field

Simple fields

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

p.2/7

ORM Methods on osv.osv objects


search(cr, uid, args, offset=0,
args: list of tuples specifying search criteria
limit=None, order=None,
offset: optional number of records to skip
context=None, count=False)
limit: optional max number of records to
Returns: list of ids of records
matching the given criteria

ORM Methods on osv.osv objects


fields_view_get(cr, uid,
view_id: id of the view or None
view_id=None, view_type='form',
view_type: type of view to return if view_id
context=None, toolbar=False)
Returns a dictionary describing
the composition of the requested
view (including inherited views
and extensions)

return

order: optional columns to sort by (default:


self._order )
count: if True, returns only the number of

records matching the criteria, not their ids

name_get(cr, uid, ids, context={})

Returns tuples with the text


representation of requested
objects for to-many relationships

#Operators: =, !=, >, >=, <, <=, like, ilike,


#in, not in, child_of, parent_left, parent_right
#Prefix operators: '&' (default), '|', '!'
#Fetch non-spam partner shops + partner 34
ids = self.search(cr, uid,
[ '|', ('partner_id', '!=', 34),
'!', ('name', 'ilike', 'spam'), ],
order='partner_id' )

read(cr, user, ids, fields=None,


context=None)

Returns: list of dictionaries with


requested field values
write(cr, uid, ids, values, context=None)

Updates records with given ids


with the given values.
Returns: True
copy(cr, uid, id, defaults,context=None)

Duplicates record with given id


updating it with defaults values.
Returns: True
unlink(cr, uid, ids, context=None)

name_search(cr, uid, name='',


args=None, operator='ilike',
context=None, limit=80)

fields: optional list of field names to return

Returns list of object names


matching the criteria, used to
provide completion for to-many
relationships. Equivalent of
search() on name + name_get()

(default: all fields)


results = self.read(cr, uid, [42,43],
['name', 'inventor_id'])
print 'Inventor:', results[0]['inventor_id']

values: dictionary of field values to update

self.write(cr, uid,
{ 'name': 'spam & eggs',
'partner_id': 24,
})

defaults: dictionary of field values to update

before saving the duplicate object

export_data(cr, uid, ids, fields,


context=None)

Exports fields for selected objects,


returning a dictionary with a
datas matrix. Used when
exporting data via client menu.

self.unlink(cr, uid, [42,43])

Deletes records with the given ids


Returns: True
browse(cr, uid, ids, context=None)

Fetches records as objects,


allowing to use dot-notation to
browse fields and relations
Returns: object or list of objects
requested
default_get(cr, uid, fields,
context=None)

Returns: a dictionary of the


default values for fields (set on
the object class, by the user
preferences, or via the context)
perm_read(cr, uid, ids, details=True)

Returns: a list of ownership


dictionaries for each requested
record

Returns a dictionary of field


dictionaries, each one describing
a field of the business object

Imports given data in the given


module Used when exporting data
via client menu

fields: list of field names


data: data to import (see export_data())
mode: 'init' or 'update' for record creation
current_module : module name
noupdate: flag for record creation
filename: optional file to store partial import

fields: list of field names

class idea(osv.osv):
idea
(...)
_columns = {
'name' : fields.char('Name',size=64)
(...)
def test_fields_get(self,cr,uid):
assert(self.fields_get('name')['size'] == 64)

100
101
102

state for recovery

103
104
105
106
107
108
109
110
111
112
113

XML files declared in a module's update_xml attribute contain record


declarations in the following form:

Each type of record (view, menu, action) support a specific set of child
entities and attributes, but all share the following special attributes:
Copyright 2010 Open Object Press - All rights reserved See license on page 7.

reconnect many2one using name_search()

many2one_field:id

reconnect many2one based on object's xml_id

many2one_field.id

reconnect many2one based on object's database id

many2many_field

reconnects via name_search(), repeat for multiple values

many2many_field:id

reconnects with object's xml_id, repeat for multiple values

many2many_field.id

reconnects with object's database id, repeat for multiple values

one2many_field/field creates one2many destination record and sets field value


ir.model.access.csv
"id","name","model_id:id","group_id:id","perm_read","perm_write","perm_create","perm_unlink"
"access_idea_idea","idea.idea","model_idea_idea","base.group_user",1,0,0,0
"access_idea_vote","idea.vote","model_idea_vote","base.group_user",1,0,0,0

Action declaration
<record model="ir.actions.act_window" id="action_id">
<field name="name">action.name</field>
<field name="view_id" ref="view_id"/>
<field name="domain">[list of 3-tuples (max 250 characters)]</field>
<field name="context">{context dictionary (max 250 characters)}</field>
<field name="res_model">object.model.name</field>
<field name="view_type">form|tree</field>
<field name="view_mode">form,tree,calendar,graph</field>
<field name="target">new</field>
<field name="search_view_id" ref="search_view_id"/>
</record>

id
name
view_id
domain
context
res_model
view_type
view_mode
target
search_view_id

Common XML structure

<?xml version="1.0" encoding="utf-8"?>


<openerp>
<data>
<record model="object_model_name" id="object_xml_id">
<field name="field1">value1</field>
<field name="field2">value2</field>
</record>
<record model="object_model_name2" id="object_xml_id2">
<field name="field1" ref="module.object_xml_id"/>
<field name="field2" eval="ref('module.object_xml_id')"/>
</record>
</data>
</openerp>

column containing identifiers for relationships

many2one_field

Actions are declared as regular records and can be triggered in 3 ways:


by clicking on menu items linked to a specific action
by clicking on buttons in views, if these are connected to actions
as contextual actions on an object

To construct a module, the main mechanism is to insert data records


declaring the module interface components. Each module element is a
regular data record: menus, views, actions, roles, access rights, etc.

87
88
89
90
91
92
93
94
95
96
97
98
99

id (xml_id)

Menus and actions

False) to make exported data compatible with


import_data() (may prevent exporting some
fields)

Building the module interface

details : if True, *_uid fields are replaced

with the name of the user


returned dictionaries contain: object id (id),
creator user id (create_uid ), creation date
(create_date), updater user id (write_uid ),
update date (write_date)

fields: list of field names


context may contain import_comp (default:

Tip: use read() through webservice calls, but always browse() internally

defs = self.default_get(cr,uid,
['name','active'])
# active should be True by default
assert defs['active']

Common CSV syntax


CSV files can also be added in update_xml, and the records will be inserted
by the OSV's import_data() method, using the CSV filename to determine
the target object model. The ORM automatically reconnects relationships
based on the following special column names:

name: object name to search for


operator : operator for name criterion
args, limit: same as for search() )

fields: list of field names

perms = self.perm_read(cr,uid,[42,43])
print 'creator:', perms[0].get('create_uid', 'n/a')

fields_get(cr, uid, fields=None,


context=None)

import_data(cr, uid, fields, data,


mode='init', current_module='',
noupdate=False, context=None,
filename=None)

idea = self.browse(cr, uid, 42)


print 'Idea description:', idea.description
print 'Inventor country code:',
idea.inventor_id.address[0].country_id.code
for vote in idea.vote_ids:
print 'Vote %2.2f' % vote.vote

# Ideas should be shown with invention date


def name_get(self,cr,uid,ids):
res = []
for r in self.read(cr,uid,ids['name','create_date'])
res.append((r['id'], '%s (%s)' (r['name'],year))
return res

used instead of element content to reference another record (works


cross-module by prepending the module name)

Tip: XML RelaxNG validation


OpenObject validates the syntax and structure of XML files, according to a
RelaxNG grammar, found in server/bin/import_xml.rng.
For manual check use xmllint: xmllint relax-ng /path/to/import_xml.rng <file>

def test_fields_view_get(self,cr,uid):
idea_obj = self.pool.get('idea.idea')
form_view = idea_obj.fields_view_get(cr,uid)

# Countries can be searched by code or name


def name_search(self,cr,uid,name='',
args=[],operator='ilike',context={},
limit=80):
ids = []
if name and len(name) == 2:
ids = self.search(cr, user,
[('code', '=', name)] + args,
limit=limit, context=context)
if not ids:
ids = self.search(cr, user,
[('name', operator, name)] + args,
limit=limit, context=context)
return self.name_get(cr,uid,ids)

the unique (per module) XML identifier of this record (xml_id)

ref

eval used instead of element content to provide value as a Python expression,


that can use the ref() method to find the database id for a given xml_id

is None ('form','tree', ...)


toolbar: True to include contextual actions

id

114
115

identifier of the action in table ir.actions.act_window, must be unique


action name (required)
specific view to open (if missing, highest priority view of given type is used)
tuple (see search() arguments) for filtering the content of the view
context dictionary to pass to the view
object model on which the view to open is defined
set to form to open records in edit mode, set to tree for a tree view only
if view_type is form, list allowed modes for viewing records (form, tree, ...)
set to new to open the view in a new window
identifier of the search view to replace default search form (new in version 5.2)

Menu declaration
The menuitem entity is a shortcut for declaring an ir.ui.menu record and
connect it with a corresponding action via an ir.model.data record.
<menuitem id="menu_id" parent="parent_menu_id" name="label" icon="icon-code"
action="action_id" groups="groupname1,groupname2" sequence="10"/>

id
parent
name
action
icon
groups
sequence

identifier of the menuitem, must be unique


id of the parent menu in the hierarchy
Optional menu label (default: action name)
identifier of action to execute, if any
icon to use for this menu (e.g. terp-graph, STOCK_OPEN, see doc.opernerp.com)
list of groups that can see this menu item (if missing, all groups can see it)
integer index for ordering sibling menuitems (10,20,30..)

p.3/7

Form Elements

Views and inheritance

116
117
118
119
120
121
122
123
124

Generic view declaration


<record model="ir.ui.view" id="view_id">
<field name="name">view.name</field>
<field name="model">object_name</field>
<field name="type">form</field> # tree,form,calendar,search,graph,gantt
<field name="priority" eval="16"/>
<field name="arch" type="xml">
<!-- view content: <form>, <tree>, <graph>, -->
</field>
</record>

id
name
model
type
priority
arch

unique view identifier


view name
object model on which the view is defined (same as res_model in actions)
view type: form, tree, graph, calendar, search, gantt (search is new in 5.2)
view priority, smaller is higher (default: 16)
architecture of the view, see various view types below

Forms

(to view/edit records)


Forms allow creation/edition or resources, and correspond to <form> elements.

Allowed elements
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156

Calendars

Common attributes for all elements:


string: label of the element
nolabel: 1 to hide the field label
colspan: number of column on which the field must span
rowspan: number of rows on which the field must span
col: number of column this element must allocate to its child elements
invisible: 1 to hide this element completely
eval: evaluate this Python code as element content (content is string by default)
attrs: Python map defining dynamic conditions on these attributes: readonly,
invisible , required based on search tuples on other field values
field
automatic widgets depending on the corresponding field type. Attributes:
string: label of the field, also for search (overrides field name)
select: 1 to show the field in normal search, 2 for advanced only
nolabel: 1 to hide the field label
required: override required field attribute
readonly: override readonly field attribute
password: True to hide characters typed in this field
context: Python code declaring a context dictionary
domain: Python code declaring list of tuples for restricting values
on_change: Python method call to trigger when value is changed
groups: comma-separated list of group (id) allowed to see this field
widget: select alternative widget (one2many_list, many2many, url,
email, image, float_time, reference, text_wiki, text_html, progressbar)
properties dynamic widget showing all available properties (no attribute)
button
clickable widget associated with actions. Specific attributes:
type: type of button: workflow (default), object, or action
name: workflow signal, function name (without parentheses) or
action to call (depending on type)
confirm: text of confirmation message when clicked
states: comma-separated list of states in which this button is shown
icon: optional icon (all GTK STOCK icons e.g. gtk-ok)
separator horizontal separator line for structuring views, with optional label
newline
place-holder for completing the current line of the view
label
free-text caption or legend in the form
group
used to organise fields in groups with optional label (adds frame)
notebook, notebook elements are tab containers for page elements. Attributes:
page
name: label for the tab/page
position : tabs position in notebook (inside, top, bottom, left, right)

Views form a hierarchy. Several views of the same type can be declared
on the same object, and will be used depending on their priorities. By
declaring an inherited view it is possible to add/remove features in a view.

all (see form elements below)

<form string="Idea form">


<group col="6" colspan="4">
<group colspan="5" col="6">
<field name="name" select="1" colspan="6"/>
<field name="inventor_id" select="1"/>
<field name="inventor_country_id" />
<field name="score" select="2"/>
</group>
<group colspan="1" col="2">
<field name="active"/><field name="invent_date"/>
</group>
</group>
<notebook colspan="4">
<page string="General">
<separator string="Description"/>
<field colspan="4" name="description" nolabel="1"/>
</page>
<page string="Votes">
<field colspan="4" name="vote_ids" nolabel="1" select="1">
<tree>
<field name="partner_id"/>
<field name="vote"/>
</tree>
</field>
</page>
<page string="Sponsors">
<field colspan="4" name="sponsor_ids" nolabel="1" select="1"/>
</page>
</notebook>
<field name="state"/>
<button name="do_confirm" string="Confirm" icon="gtk-ok" type="object"/>
</form>

Views used to display date fields as calendar events (<calendar> parent)

Attributes

Allowed elements
161
162
163

a dictionary of field names and their updated values


a dictionary of field names and their updated domains of value

warning a dictionary with a title and message to show a warning dialog

Lists/Trees

Lists include field elements, are created with type tree, and have a <tree>
parent element.

Attributes

colors: list of colors mapped to Python conditions


editable: top or bottom to allow in-place edit
toolbar : set to True to display the top level of object

hierarchies as a side toolbar (example: the menu)


Allowed elements field, group, separator, tree, button, filter, newline
157
158
159
160

date_delay: name of field containing event duration

or

field (to define the label for each calendar event)

<calendar string="Ideas" date_start="invent_date" color="inventor_id">


<field name="name"/>
</calendar>

Bar chart typically used to show project schedule (<gantt> parent element)
same as <calendar>
Attributes

Allowed elements

field, level

level elements are used to define the Gantt chart levels, with
the enclosed field used as label for that drill-down level
164
165
166
167
168

<gantt string="Ideas" date_start="invent_date" color="inventor_id">


<level object="idea.idea" link="id" domain="[]">
<field name="inventor_id"/>
</level>
</gantt>

Charts (Graphs)

Views used to display statistical charts (<graph> parent element)


Tip: charts are most useful with custom views extracting ready-to-use statistics

Attributes

type: type of chart: bar, pie (default)


orientation : horizontal, vertical

Allowed elements field, with specific behavior:


first field in view is X axis, 2nd one is Y, 3rd one is Z
2 fields required, 3rd one is optional
group attribute defines the GROUP BY field (set to 1)
operator attribute sets the aggregation operator to use for
other fields when one field is grouped (+,*,**,min,max)
169
170
171
172

<graph string="Total idea score by Inventor" type="bar">


<field name="inventor_id" />
<field name="score" operator="+"/>
</graph>

Search views (new in 5.2)

Search views are used to customize the search panel on top of list views,
and are declared with the search type, and a top-level <search> element.
After defining a search view with a unique id, add it to the action opening
the list view using the search_view_id field in its declaration.
Allowed elements field, group, separator, label, search, filter, newline,
properties

In addition to what can be done with states and attrs attributes, functions
may be called by view elements (via buttons of type object, or on_change
attributes on fields) to obtain dynamic behavior. These functions may alter
the view interface by returning a Python map with the following entries:

domain

color: name of field for color segmentation


date_start: name of field containing event start date/time
day_length: length of a calendar day in hours (default:
date_stop: name of field containing event stop date/time

Gantt Charts

Dynamic views

value

filter elements allow defining button for domain filters


adding a context attribute to fields makes widgets that alter the

search context (useful for context-sensitive fields, e.g. pricelistdependent prices)


173
174
175
176
177
178
179
180
181
182
183
184
185

<search string="Search Ideas">


<group col="6" colspan="4">
<filter string="My Ideas" icon="terp-partner"
domain="[('inventor_id','=',uid)]"
help="My own ideas"/>
<field name="name" select="1"/>
<field name="description" select="1"/>
<field name="inventor_id" select="1"/>
<!-- following context field is for illustration only -->
<field name="inventor_country_id" select="1" widget="selection"
context="{'inventor_contry': self}"/>
</group>
</search>

<tree string="Idea Categories" toolbar="1" colors="blue:state==draft">


<field name="name"/>
<field name="description"/>
</tree>

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

p.4/7

id
name
osv
on_create

Expressions used in OpenERP report templates


[[ <content> ]]

Predefined expressions:
objects contains the list of records to print
data comes from the wizard launching the report
user contains the current user (as per browse())
time gives access to Python time module
repeatIn(list,'var','tag') repeats the current parent element named tag for
each object in list, making the object available as var during each loop
setTag('tag1','tag2') replaces the parent RML tag1 with tag2
removeParentNode('tag') removes parent RML element tag
formatLang(value, digits=2, date=False, date_time=False, grouping=True,
monetary=False) can be used to format a date, time or amount according

View Inheritance

Existing views should be modifying through inherited views, never


directly. An inherited view references its parent view using the inherit_id
field, and may add or modify existing elements in the view by referencing
them through XPath expressions, specifying the appropriate position .
Tip: XPath reference can be found at www.w3.org/TR/xpath
position
inside: placed inside match (default) before: placed before match

186
187
188
189
190
191
192
193
194
195
196

replace: replace match

after: placed after match

<!-- improved idea categories list -->


<record id="idea_category_list2" model="ir.ui.view">
<field name="name">id.category.list2</field>
<field name="model">ir.ui.view</field>
<field name="inherit_id" ref="id_category_list"/>
<field name="arch" type="xml">
<xpath expr="/tree/field[@name='description']" position="after">
<field name="idea_ids" string="Number of ideas"/>
</xpath>
</field>
</record>

double brackets content is evaluated as a Python


expression based on the following expressions

219
220
221
222
223
224

197
198
199
200
201

setLang('lang_code') sets the current language and locale for translations


Report declaration

Reports

There are several report engines in OpenERP, to produce reports from


different sources and in many formats.

<record id="act_confirmed" model="workflow.activity">


<field name="name">confirmed</field>
<field name="wkf_id" ref="wkf_idea"/>
<field name="kind">function</field>
<field name="action">action_confirmed()</field>
</record>

split_mode

<!-- The following creates records in ir.actions.report.xml model -->


<report id="idea_report" string="Print Ideas" model="idea.idea"
name="idea.report" rml="idea/report/idea.rml" >
<!-- Use addons/base_report_designer/wizard/tiny_sxw2rml/tiny_sxw2rml.py
to generate the RML template file from a .sxw template -->

id
name
string
model
rml, sxw, xml, xsl
auto

Workflow Activities (nodes)

id
wkf_id
name
flow_start
flow_stop
join_mode

to the locale

unique report identifier


name for the report (required)
report title (required)
object model on which the report is defined (required)
path to report template sources (starting from addons), depending on report
set to False to use a custom parser, by subclassing report_sxw.rml_parse and
declaring the report as follows:

kind

set to False to suppress report header (default: True)


comma-separated list of groups allowed to view this report
set to True to link the report with the Print icon (default: True)
specify report type keyword (default: client_print_multi)

subflow_id
action

report_sxw.report_sxw(report_name, object_model,rml_path,parser=customClass)

header
groups
menu
keywords

Special expressions used inside report templates produce dynamic data


and/or modify the report structure at rendering time.
Custom report parsers may be written to support additional expressions.

Alternative Report Formats (see doc.openerp.com)


sxw2rml
rml
xml,xsl:rml
odt2odt
mako

OpenOffice 1.0 templates (.sxw) converted to RML with


sxw2rml tool, and the RML rendered in HTML or PDF
RML templates rendered directly as HTML or PDF
XML data + XSL:RML stylesheets to generate RML
OpenOffice templates (.odt) used to produce directly
OpenOffice documents (.odt) (As of OpenERP 5.2)
Mako template library used to produce HTML output, by
embedding Python code and OpenERP expressions within
any text file (As of OpenERP 5.2)

202
203
204
205
206
207
208
209
210
211
212
213

Workflow Transitions (edges)


225
226
227
228
229
230
231

Workflows may be associated with any


object in OpenERP, and are entirely
customizable.
Workflows are used to structure and manage
the lifecycles of business objects and
documents, and define transitions, triggers,
etc. with graphical tools.
Workflows, activities (nodes or actions) and
transitions (conditions) are declared as XML
records, as usual. The tokens that navigate
in workflows are called workitems.

identifiers of the source and destination activities


name of a button of type workflow that triggers this transition
reference to the role that user must have to trigger the transition (see Roles)
Python expression that must evaluate to True for transition to be triggered

Security
Access control mechanisms must be combined to achieve a coherent
security policy.

Group-based access control mechanisms

Groups are created as normal records on the res.groups model, and granted
menu access via menu definitions. However even without a menu, objects
may still be accessible indirectly, so actual object-level permissions
(create,read,write,unlink) must be defined for groups. They are usually
inserted via CSV files inside modules. It is also possible to restrict access
to specific fields on a view or object using the field's groups attribute.

Workflows are declared on objects that possess a state field (see the
example idea class in the ORM section)

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

<record id="trans_idea_draft_confirmed" model="workflow.transition">


<field name="act_from" ref="act_draft"/>
<field name="act_to" ref="act_confirmed"/>
<field name="signal">button_confirm</field>
<field name="role_id" ref="idea_manager"/>
<field name="condition">1 == 1</field>
</record>

Tip: The Web client features a graphical workflow editor, via


the CustomiseManage Workflows link in lists and forms.

Workflow declaration

<record id="wkf_idea" model="workflow">


<field name="name">idea.basic</field>
<field name="osv">idea.idea</field>
<field name="on_create" eval="1"/>
</record>

Conditions are evaluated in this order: role_id, signal, condition expression

act_from, act_to
signal
role_id
condition

Workflows

214
215
216
217
218

unique activity identifier


parent workflow identifier
activity node label
True to make it a 'begin' node, receiving a workitem for each workflow instance
True to make it an 'end' node, terminating the workflow when all items reach it
logical behavior of this node regarding incoming transitions:
XOR: activate on the first incoming transition (default)
AND: waits for all incoming transitions to become valid
logical behavior of this node regarding outgoing transitions:
XOR: one valid transition necessary, send workitem on it (default)
OR: send workitems on all valid transitions (0 or more), sequentially
AND: send a workitem on all valid transitions at once (fork)
type of action to perform when node is activated by a transition:
dummy to perform no operation when activated (default)
function to invoke a function determined by action
subflow to execute the subflow with subflow_id, invoking action to determine
the record id of the record for which the subflow should be instantiated. If action
returns no result, the workitem is deleted.
stopall to terminate the workflow upon activation
if kind subflow, id of the subflow to execute (use ref attribute or search with a tuple)
object method call, used if kind is function or subflow. This function should also
update the state field of the object, e.g. for a function kind:
def action_confirmed(self, cr, uid, ids):
self.write(cr, uid, ids, { 'state' : 'confirmed' })
# perform other tasks
return True

Tip: RML User Guide: www.reportlab.com/docs/rml2pdf-userguide.pdf


Example RML report extract:
<story>
<blockTable style="Table">
<tr>
<td><para style="Title">Idea name</para> </td>
<td><para style="Title">Score</para> </td>
</tr>
<tr>
<td><para>[[ repeatIn(objects,'o','tr') ]] [[ o.name ]]</para></td>
<td><para>[[ o.score ]]</para></td>
</tr>
</blockTable>
</story>

unique workflow record identifier


name for the workflow (required)
object model on which the workflow is defined (required)
if True, a workitem is instantiated automatically for each new osv record

232
233
234

ir.model.access.csv
"id","name","model_id:id","group_id:id","perm_read","perm_write","perm_create","perm_unlink"
"access_idea_idea","idea.idea","model_idea_idea","base.group_user",1,1,1,0
"access_idea_vote","idea.vote","model_idea_vote","base.group_user",1,1,1,0

p.5/7

Roles

Roles are created as normal records on the res.roles model and used only
to condition workflow transitions through transitions' role_id attribute.

Wizards

Wizards describe stateful interactive sessions with the user through


dynamic forms. As of OpenERP v5.0, wizards make use of the
osv_memory in-memory persistence to allow constructing wizards from
regular business objects and views.

Wizard objects (osv_memory)


235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252

In-memory objects are created by extending osv.osv_memory:


from osv import fields,osv
import datetime
class cleanup_wizard(osv.osv_memory):
cleanup_wizard
_name = 'idea.cleanup.wizard'
_columns = {
'idea_age': fields.integer('Age (in days)'),
}
def cleanup(self,cr,uid,ids,context={}):
idea_obj = self.pool.get('idea.idea')
for wiz in self.browse(cr,uid,ids):
if wiz.idea_age <= 3:
raise osv.except_osv('UserError','Please select a larger age')
limit = datetime.date.today()-datetime.timedelta(days=wiz.idea_age)
ids_to_del = idea_obj.search(cr,uid, [('create_date', '<' ,
limit.strftime('%Y-%m-%d 00:00:00'))],context=context)
idea_obj.unlink(cr,uid,ids_to_del)
return {}
cleanup_wizard()

292
293
294
295
296
297
298
299
300
301
302
304
303
305
306
307
308
309
310
311
312
313
314
315
316
317
318

<record id="wizard_idea_cleanup" model="ir.ui.view">


<field name="name">idea.cleanup.wizard.form</field>
<field name="model">idea.cleanup.wizard</field>
<field name="type">form</field>
<field name="arch" type="xml">
<form string="Idea Cleanup Wizard">
<label colspan="4" string="Select the age of ideas to cleanup"/>
<field name="idea_age" string="Age (days)"/>
<group colspan="4">
<button string="Cancel" special="cancel" icon="gtk-cancel"/>
<button string="Cleanup" name="cleanup" type="object" icon="gtk-ok"/>
</group>
</form>
</field>
</record>

Wizard execution
268
269
270
271
272
273
274
275

Such wizards are launched via regular action records, with a special target
field used to open the wizard view in a new window.
<record id="action_idea_cleanup_wizard" model="ir.actions.act_window">
<field name="name">Cleanup</field>
<field name="type">ir.actions.act_window</field>
<field name="res_model">idea.cleanup.wizard</field>
<field name="view_type">form</field>
<field name="view_mode">form</field>
<field name="target">new</field>
</record>

WebServices XML-RPC

OpenERP is accessible through XML-RPC interfaces, for which libraries


exist in many languages.
276
277
278
279
280
281
283
282
284
285
286
287
288
289
290
291

Python example

import xmlrpclib
# ... define HOST, PORT, DB, USER, PASS
url = 'http://%s:%d/xmlrpc/common' % (HOST,PORT)
sock = xmlrpclib.ServerProxy(url)
uid = sock.login(DB,USER,PASS)
print "Logged in as %s (uid:%d)" % (USER,uid)
# Create a new idea
url = 'http://%s:%d/xmlrpc/object' % (HOST,PORT)
sock = xmlrpclib.ServerProxy(url)
args = {
'name' : 'Another idea',
'description' : 'This is another idea of mine',
'inventor_id': uid,
}
idea_id = sock.execute(DB,uid,PASS,'idea.idea','create',args)

// Create a new idea


$arrayVal = array(
'name'=>new xmlrpcval("Another Idea", "string") ,
'description'=>new xmlrpcval("This is another idea of mine" , "string"),
'inventor_id'=>new xmlrpcval($uid, "int"),
);
$msg = new xmlrpcmsg('execute');
$msg->addParam(new xmlrpcval($DB, "string"));
$msg->addParam(new xmlrpcval($uid, "int"));
$msg->addParam(new xmlrpcval($PASS, "string"));
$msg->addParam(new xmlrpcval("idea.idea", "string"));
$msg->addParam(new xmlrpcval("create", "string"));
$msg->addParam(new xmlrpcval($arrayVal, "struct"));
$resp = $client->send($msg);
?>

Each module can provide its own translations within the i18n directory, by
having files named LANG.po where LANG is the locale code for the country
and language combination (e.g. fr_FR.po). Translations will be loaded
automatically by OpenERP for all enabled languages.
Developers always use English when creating a module, then export the
module terms using OpenERP's gettext POT export feature
(Administration>Translations>Export a Translation File without specifying a
language) , to create the module template POT file, and then derive the
translated PO files.
Many IDE's have plugins or modes for editing and merging PO/POT files.

Wizards use regular views and their buttons may use a special cancel
attribute to close the wizard window when clicked.

Tip: The GNU gettext format (Portable Object) used by OpenERP is integrated
into LaunchPad, making it an online collaborative translation platform, with
automatic translation features.
319
320
321
322
323
324

As Enterprise Management Software typically has to deal with large


amounts of records, you may want to pay attention to the following antipatterns, to obtain consistent performance:
Do not place browse() calls inside loops, put them before and access
only the browsed objects inside the loop. The ORM will optimize the
number of database queries based on the browsed attributes.
Avoid recursion on object hierarchies (objects with a parent_id
relationship), by adding parent_left and parent_right integer fields on your
object, and setting _parent_store to True in your object class. The ORM will
use a modified preorder tree traversal to be able to perform recursive
operations (e.g. child_of ) with database queries in O(1) instead of O(n)
Do not use function fields lightly, especially if you include them in
tree views. To optimize function fields, two mechanisms are available:
multi: all fields sharing the same multi attribute value will be
computed with one single call to the function, which should then
return a dictionary of values in its values map
store: function fields with a store attribute will be stored in the
database, and recomputed on demand when the relevant trigger
objects are modified. The format for the trigger specification is as
follows: store = {'model': (_ref_fnct, fields, priority)} (see example below)

<?
include('xmlrpc.inc'); // Use phpxmlrpc library, available on sourceforge
// ... define $HOST, $PORT, $DB, $USER, $PASS
$client = new xmlrpc_client("http://$HOST:$PORT/xmlrpc/common");
$msg = new xmlrpcmsg("login");
$msg->addParam(new xmlrpcval($DB, "string"));
$msg->addParam(new xmlrpcval($USER, "string"));
$msg->addParam(new xmlrpcval($PASS, "string"));
resp = $client->send($msg);
uid = $resp->value()->scalarval()
echo "Logged in as $USER (uid:$uid)"

Internationalization

Views
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267

Performance Optimization

PHP example

|- idea/
|- i18n/
| - idea.pot
| - fr_FR.po
| - es_ES.po
| (...)

#
#
#
#
#

The module directory


Translation files
Translation Template (exported from OpenERP)
French translation
Spanish translation

Tip: By default OpenERP's POT export only extracts labels inside XML files or
inside field definitions in Python code, but any Python string can be translated
this way by surrounding it with the tools.translate._ method (e.g. _('Label') )

325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342

343
344
345
346
347
348

def _get_idea_from_vote(self,cr,uid,ids,context={}):
res = {}
vote_ids = self.pool.get('idea.vote').browse(cr,uid,ids,context=context)
for v in vote_ids:
res[v.idea_id.id] = True # Store the idea identifiers in a set
return res.keys()
def _compute(self,cr,uid,ids,field_name,arg,context={}):
res = {}
for idea in self.browse(cr,uid,ids,context=context):
vote_num = len(idea.vote_ids)
vote_sum = sum([v.vote for v in idea.vote_ids])
res[idea.id] = {
'vote_sum': vote_sum,
'vote_avg': (vote_sum/vote_num) if vote_num else 0.0,
}
return res
_columns = {
# These fields are recomputed whenever one of the votes changes
'vote_avg': fields.function(_compute, method=True,

string='Votes Average',
store = {'idea.vote': (_get_idea_from_vote,['vote'],10)},multi='votes'),
'vote_sum': fields.function(_compute, method=True, string='Votes Sum',
store = {'idea.vote': (_get_idea_from_vote,['vote'],10)},multi='votes'),
}

Community / Contributing

OpenERP projects are hosted on LaunchPad(LP), where all project resources


may be found: Bazaar branches, bug tracking, blueprints, roadmap, FAQs, etc.
Create a free account on launchpad.net to be able to contribute.

Launchpad groups

Rapid Application Development


Module recorder

The base_module_record module can be used to export a set of changes in


the form of a new module. It should be used for all customizations that
should be carried on through migrations and updates. It has 2 modes:
Start/Pause/Stop mode, where all operations (on business objects or
user interface) are recorded until the recorder is stopped or paused.
Date- and model-based mode where all changes performed after a
given date on the given models (object types) are exported. .

Report Creator (view) and Report Designer (print) modules

Group*

Members

Bazaar/LP restrictions

OpenERP Quality
Team (~openerp)

OpenERP Core Team

Can merge and commit on


official branches.

OpenERP Commiters
(~openerp-commiter)

Selected active
community members

Can mark branches to be merged


into official branch. Can commit
on extra-addons branch

OpenERP Drivers
(~openerp-drivers)

Selected active
community members

Can confirm bugs and set


milestones on bugs / blueprints

OpenERP Community
(~openerp-community)

Open group, anyone


can join

Can create community branches


where everyone can contribute

*Members of upper groups are also members of lower groups

The base_report_creator module can be used to automate the creation of


custom statistics views, e.g. to construct dashboards. The resulting
dashboards can then be exported using the base_module_record module.

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

p.6/7

License
Copyright 2010 Open Object Press. All rights reserved.
You may take electronic copy of this work and distribute it if you don't change
the content. You can also print a copy to be read by yourself only.
We have contracts with different publishers in different countries to sell and
distribute paper or electronic based versions of this work (translated or not)
in bookstores. This helps to distribute and promote the Open ERP product. It
also helps us to create incentives to pay contributors and authors with the
royalties.
Due to this, grants to translate, modify or sell this work are strictly forbidden,
unless Tiny SPRL (representing Open Object Press) gives you a written
authorization for this.
While every precaution has been taken in the preparation of this work, the
publisher and the authors assume no responsibility for errors or omissions, or
for damages resulting from the use of the information contained herein.
Published by Open Object Press, Grand Rosire, Belgium

Copyright 2010 Open Object Press - All rights reserved See license on page 7.

p.7/7

ANEXO 5
RESULTADO DE LA ENCUENTA DE MICRO Y
PEQUEA EMPRESA 2013

444444444444444444444

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa





  


aa aaaaaaaaaaaaaaaaaaaaa aaaaaaaaaa
  





    

nnnnnnnnnnnn

 






















 





  



3333333333333333333333333333333333333333333333333333333333








3
3333333333333333333333333333333333333333333333333333333333

nnnnn




 






























+
+



 
 

 
 

 

 
 












































 















 
 









  


3333333333333333333333333333333333333333333333333333333333





















 









.




 
















 







 






















 




 


 
























333333333 3333333333333333 33333333 3 333 3333
















 

 
 

 

 

 



 
  


 

 

 

 



   




 

 





 
 
 
 







 












 




3333333333333333333333333333333333333333333333333333333333




















 

 











333333333 3333333333333333 33333333 3 333 3333




nnnnnnnn






..

 *


 *

 *

*

3333333333333333333333333333333333333333333333333333333333333333

      


  
  

     



  


  
  


     

 


3333333333333333333333333333333333333333333333333333333333

 *

 *

 *

 

 *

3 333333333333333333333 3 333 333333333 3333 33333333333333333333333333333333333333 33333 33


3333333333333333333333333333333333333333 3333333333


 



 
 
 

  





 
 

 



.

*
*

 *

 *

 *

 *

 *

*

*

333 33333333333333 3333333333333333 3333333333333333333333333333333





 

   

 

    




 

 

   

 

    

 
 

 

 

 

 

 

 

 


333333333 3333333333333333 33333333 3 333 3333

 *

.

 *

 *








 *


*



 *

3333333333333 3333333333333333 3333333333333333333333333333333


" "
$$

 

" "


$$
 

 

& 





& 


& 


&  &


 *

.


 *

3333333333333333 33333333333333333333333333



 



 


 






 


 

3
3333333333333333333333333333333333333333333333333333333333

 *

.

 *

 *

 *

3333333333333333333333333333333333333333333 3333333333333333333333333333333
3333333333333333333 333333333333333333333333333333333










 
 



 
 
 

 

    
, 


 



*



*  

 

 

 

  

 




 

 
 

 *

.

 *
 * 


333333333 3333333333333333 33333333 3 333 3333

 

 




 *

 

 *
 *

3333333333333333333333333333333333333333333333333333333333333333333
33333333333333333333 33333333




  






  
 













 





    
   






  



 



 *

.




 *

 *

 *

333333333333333333333333333333333333333333333333333333333333333333 3333333333
33 33333333333333333333 333333333333333333333 333333

((

3

&

 

3$

&& 

3

$$

3

#

 



 




3



3



3

 

3



33



3



3



3



333


3333333333333333333333333333333333333333333333333333333333

 *

.






 *

 *

 




 


 *

 * 

333333333333333333333333333333333333333333333333333333333333333333333
33333333333 33333333333 33333333333333333333333333333333333



!!





















 *

..

.

  

*

 *

 *
 *


333333333 3333333333333333 33333333 3 333 3333

* 

3333333333333333333333333333333333333333333333333333333333333 333333333
3333333333333333333333333333333333333333333333333333

' '  














' 

 
  

&




  


&


  

  


 










 




 
# 



 



 *

...


 *

 *

 *

* 

33333333333333333333333333333333333333333333333333333333333333333 333333
33333333333333333333333333333333333333333333333333333333333



   


 



 





 



 




   










3333333333333333333333333333333333333333333333333333333333

 *

. .




 *

 *

*

* 

33333333333333333333333333333333333333333333333333333 333333333333333333333
33333333333333333333333333333333 333333333333333333333333333

//



$ 


 




 





--













*




..










3333333333333333 33333333333333333333333333333333333333333333
/  



 
  
  *
&
  *
& 

* 


 
** 


333333333 3333333333333333 33333333 3 333 3333