Implementacion Sistemas

Ttol: Mejora e innovacion de procesos: Implantacion de un nuevo sistema de
informacion en una pyme

Autor: Marc Blando Coll
Data: 30/03/12
Directora: Tamara Alvarez

Seijas
Empresa de la directora: Ponent: Pere Botella Lopez
Departament del ponent: Ingeniera de Servicios y Sistemas de Informacion
Titulacio: Ingeniera Informatica
Centre: Facultat dInformàtica de Barcelona (FIB) Universitat: Universitat
Politècnica de Catalunya (UPC) BarcelonaTech
.
Universidad Politecnica
de Cataluna
FACULTAD
DE I NFORM ATICA
DE
BARCELONA
Ingeniera Informatica
de procesos: Implantacion
de un
Mejora e innovacion
en una pyme
nuevo sistema de informacion
Autor: Marc Blando Coll
Universidad Politecnica
de Cataluna
FACULTAD
DE I NFORM ATICA
DE
BARCELONA
Ingeniera Informatica
Departamento: Ingeniera de Servicios y Sistemas de Informacion
de procesos: Implantacion
de un
Mejora e innovacion
en una pyme
nuevo sistema de informacion
Alumno: Marc Blando Coll
Director/Ponente: Tamara Alvarez

Seijas/Pere
Botella Lopez
Este trabajo se encuentra bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.5 Espana.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Spain License.
http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es
Me lo contaron y lo olvide. Lo vi y lo entend. Lo hice y lo aprend.

Confucio, 551-479 a.c.
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas
cosas.
Albert Einstein, 1879-1955.
VIII
Memorias dedicadas a toda mi familia, a Jennifer, el amor de mi vida y a mi gato

Newton, por darme su carino cuando mas lo necesitaba. Sin su apoyo y paciencia
no hubiera sido posible.
IX
Agradezco a mi ponente y a las personas de la empresa que ha hecho posible este

proyecto por su ayuda, sugerencias y correcciones.

Indice
general
1. Introduccion
1.1. Alcance de proyecto . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . .
1.4. Presentacion alumno y motivacion . . . . . . . . . . . . . . . . . .
1.5. Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1. Cadena de valor . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2. Tecnologas de la informacion (TI) . . . . . . . . . . . . . .
1.5.3. Sistema de informacion (SI) . . . . . . . . . . . . . . . . .
1.5.4. Planificacion de recursos empresariales (ERP) . . . . . . . .
1.5.5. Administracion basada en la relacion con los clientes (CRM)
1.5.6. La gestion de las relaciones con los proveedores (SRM) . .
1.5.7. Software propietario . . . . . . . . . . . . . . . . . . . . .
1.5.8. Software libre . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.5.9. Virtualizacion . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.5.10. Cloud Computing . . . . . . . . . . . . . . . . . . . . . . .
14
1.5.11. Proceso de negocio . . . . . . . . . . . . . . . . . . . . . .
17
1.5.12. Innovacion y mejora de procesos . . . . . . . . . . . . . . .
18
1.5.13. Reingeniera de procesos . . . . . . . . . . . . . . . . . . .
18
1.5.14. Metodologa de desarrollo de software tradicional . . . . . .
19
1.5.15. Metodologas a giles de desarrollo de software . . . . . . . .
22
1.5.16. Mapeo objeto-relacional . . . . . . . . . . . . . . . . . . .
24
I
I NDICE GENERAL
1.5.17. Protocolo XML-RPC . . . . . . . . . . . . . . . . . . . . .
25
1.5.18. Patron de diseno Modelo-Vista-Controlador (MVC) . . . .
25
2. Analisis inicial
27
2.1. Situacion inicial de la empresa . . . . . . . . . . . . . . . . . . . .
27
2.2. Analisis de la necesidad de un cambio . . . . . . . . . . . . . . . .
31
2.3. Consideraciones previas al cambio . . . . . . . . . . . . . . . . . .
39
2.4. Virtudes y defectos del sistema de informacion actual . . . . . . . .
46
2.5. Procesos actuales de la empresa . . . . . . . . . . . . . . . . . . .
48
2.5.1. Servicio generico . . . . . . . . . . . . . . . . . . . . . . .
48
2.5.2. Seleccion de comerciales . . . . . . . . . . . . . . . . . . .
72
2.5.3. Formacion y supervision de comerciales . . . . . . . . . . .
78
2.5.4. Recopilar clientes potenciales . . . . . . . . . . . . . . . .
80
2.5.5. Contabilidad . . . . . . . . . . . . . . . . . . . . . . . . .
82
2.5.6. Gestion de agenda . . . . . . . . . . . . . . . . . . . . . .
84
2.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
3. Propuesta de innovacion y mejora
89
3.1. Problema a revolver . . . . . . . . . . . . . . . . . . . . . . . . . .
89
3.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
3.3. Estructura de la propuesta . . . . . . . . . . . . . . . . . . . . . . .
91
3.4. Innovacion tecnologica . . . . . . . . . . . . . . . . . . . . . . . .
92
3.4.1. Alternativas disponibles . . . . . . . . . . . . . . . . . . .
92
3.4.2. Seleccionar una alternativa . . . . . . . . . . . . . . . . . .
97
3.4.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . 138

3.4.4. Metodologa de implantacion y desarrollo . . . . . . . . . . 152
3.5. Mejora e innovacion de procesos . . . . . . . . . . . . . . . . . . . 154
3.5.1. Cadena de valor . . . . . . . . . . . . . . . . . . . . . . . . 155
3.5.2. Adaptacion de procesos al nuevo sistema de informacion . . 156
3.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
II
I NDICE GENERAL
4. Implantacion
161
4.1. Preparacion de la arquitectura que soportara el sistema . . . . . . . 162

4.2. Formacion inicial sobre openERP. . . . . . . . . . . . . . . . . . . 165
4.3. Configuracion inicial openERP y migracion de los primeros datos
en el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.4. Preparacion de los entornos de trabajo . . . . . . . . . . . . . . . . 166
4.5. Desarrollo iterativo de requisitos y formacion continuada . . . . . . 167
4.5.1. Especificacion y priorizacion de requisitos . . . . . . . . . . 167
4.5.2. Desarrollo de los requisitos . . . . . . . . . . . . . . . . . . 168
4.5.3. Prueba de los cambios realizados para cumplir los requisitos
y formacion sobre los mismos . . . . . . . . . . . . . . . . 168
4.5.4. Incorporacion de los cambios aprobados al entorno de produccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.5.5. Analizar cumplimiento objetivos y alcance del proyecto . . 169
4.6. Detalles tecnicos de la implantacion . . . . . . . . . . . . . . . . . 170
5. Analisis final
173
Bibliografa
179
A. Preguntas previas para determinar la necesidad de un nuevo sistema de

informacion
185
B. Consideraciones previas para empezar con la seleccion de un nuevo sistema de informacion
189
III

Indice
de figuras
1.1. Fases del ciclo de vida del RUP . . . . . . . . . . . . . . . . . . . .
20
1.2. Estructura general de Metrica v3 . . . . . . . . . . . . . . . . . . .
21
1.3. Proceso scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.4. Patron de diseno MVC . . . . . . . . . . . . . . . . . . . . . . . .
26
2.1. Vision global de un servicio . . . . . . . . . . . . . . . . . . . . .
51
2.2. Prospeccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2.3. Cierre de presupuesto . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.4. Gestion de presupuestos . . . . . . . . . . . . . . . . . . . . . . .
60
2.5. Apoyo tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
2.6. Gestion proveedores . . . . . . . . . . . . . . . . . . . . . . . . .
65
2.7. Gestion de servicio . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.8. Gestion de facturas de cliente . . . . . . . . . . . . . . . . . . . . .
69
2.9. Gestion de comisiones . . . . . . . . . . . . . . . . . . . . . . . .
71
2.10. Seleccion de comerciales . . . . . . . . . . . . . . . . . . . . . . .
73
2.11. Publicacion oferta . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
2.12. Seleccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
2.13. Formacion y supervision de comerciales . . . . . . . . . . . . . . .
79
2.14. Recopilar clientes potenciales . . . . . . . . . . . . . . . . . . . . .
81
2.15. Contabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
2.16. Gestion de agenda . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.1. Criterios de seleccion de SI para PubliFringe. Criterios Funcionales
100
V
I NDICE DE FIGURAS
3.2. Criterios de seleccion de SI para PubliFringe. Criterios Tecnicos . . 101
3.3. Criterios de seleccion de SI para PubliFringe. Criterios Economicos
y Amplitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.4. Logo de Abanq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.5. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . 115
3.6. Muestra ventana de Abanq . . . . . . . . . . . . . . . . . . . . . . 118
3.7. Logo de OpenBravo . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.8. Muestra ventana de OpenBravo . . . . . . . . . . . . . . . . . . . . 124
3.9. Logo de OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.10. Arquitectura de OpenERP . . . . . . . . . . . . . . . . . . . . . . 128
3.11. Arquitectura tecnica de OpenERP . . . . . . . . . . . . . . . . . . 129
3.12. Muestra ventana de OpenERP . . . . . . . . . . . . . . . . . . . . 130
3.13. Logo de Dolibarr . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.14. Muestra ventana de Dolibarr . . . . . . . . . . . . . . . . . . . . . 134
3.15. Arquitectura con servidor dedicado . . . . . . . . . . . . . . . . . . 146
3.16. Arquitectura con servidor virtualizado . . . . . . . . . . . . . . . . 148
3.17. Cadena de valor PubliFringe . . . . . . . . . . . . . . . . . . . . . 155
4.1. Arquitectura openERP . . . . . . . . . . . . . . . . . . . . . . . . 170
VI

Indice
de cuadros
2.1. Virtudes y defectos del sistema actual . . . . . . . . . . . . . . . .
46
3.1. Estructuracion de la propuesta . . . . . . . . . . . . . . . . . . . .
92
3.2. Lista ordenada de criterios segun su prioridad . . . . . . . . . . . . 104

3.3. Tabla de comparacion de las 4 alternativas . . . . . . . . . . . . . . 137
3.4. Estimacion de costes con servidor dedicado . . . . . . . . . . . . . 150
3.5. Estimacion de costes de virtualizacion . . . . . . . . . . . . . . . . 150
3.6. Estimacion de costes de cloud computing . . . . . . . . . . . . . . 150
5.1. Planificacion inicial del proyecto . . . . . . . . . . . . . . . . . . . 174
5.3. Planificacion extendida del proyecto . . . . . . . . . . . . . . . . . 176
5.4. Costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 176
VII
Captulo 1
Introduccion
En este proyecto de final de carrera (PFC) se detallara la realizacion de un proceso de innovacion y mejora en una empresa. La empresa en cuestion, PubliFringe
Publicidad al Lmite , tiene como objetivos crear una estrategia CRM y mejorar o in-
novar en sus procesos de negocio.

Como la empresa no dispone de un sistema integral de informacion 1.5.3, se requerira la implantacion de un nuevo sistema de informacion que de soporte a sus
procesos de negocio.
Este proceso de innovacion y mejora comenzara con un analisis de la empresa
que determinara la situacion inicial de e sta, sus problemas, sus necesidades y objetivos a largo plazo y consultora sobre sistemas de informacion.
A continuacion se propondran varias alternativas de mejora e innovacion y se escogera una de ellas. En el siguiente paso, se detallara todo el proceso de implantacion
de los cambios en la empresa.
Los miembros de la empresa no tienen experiencia previa en la implantacion de
sistemas integrados de informacion ni tienen nociones de como son o como funcionan. Eso les impide ver las posibilidades que ofrecen estos sistemas, como ver hasta
donde podran mejorar los procesos de la empresa, detectar la magnitud del esfuerzo
que supone planificar y ejecutar un proyecto de estas caractersticas o incluso detectar a tiempo los riesgos, errores tpicos o causas de fracaso en las implantaciones. . .
1

C API TULO 1. I NTRODUCCI ON
Marc, con algo mas de experiencia en el tema y con los conocimientos adquiridos
durante la carrera, debera guiar y asesorar a la empresa durante todo el proceso
de implantacion. No solo para instalar o desarrollar un software, sino implantar un
nuevo sistema de informacion para sacarle el mayor provecho y conseguir mejorar e
innovar en la empresa.
1.1. A LCANCE DE PROYECTO
1.1.
Alcance de proyecto
En este proyecto se pretende detallar un caso de implantacion de un nuevo sistema de informacion buscando la innovacion o mejora de los procesos de una empresa pequena con unos recursos limitados. Este documento no pretende exponer
una metodologa o gua a seguir, mas bien es un caso practico.
Para realizar este proyecto, se va a realizar una seleccion de metodologas y buenas practicas que se consideren apropiadas segun las necesidades de la empresa y
del proyecto.
Tras la implantacion, se realizara un analisis final para ver si se han cumplido
los objetivos, problemas encontrados y posibles planes u objetivos futuros tras el
proyecto. Finalmente, se incluira una planificacion del proyecto y sus costes.
Cabe destacar que es probable que el proceso de implantacion sea demasiado
largo como para que lo abarque un proyecto de final de carrera. Si fuera el caso, se
abarcaran las partes crticas de la implantacion, dejando el resto al menos planificada
en el analisis final del proyecto.
1.2.
Objetivos del proyecto
En este proyecto se busca proveer de mejoras e innovaciones tecnologicas en

la empresa. Los principales objetivos de este proyecto son implantar una estrategia
CRM en la organizacion, intentar innovar o mejorar los procesos de la empresa e
implantar un sistema de informacion integrado que de soporte a los cambios.
1.3.
Estructura del proyecto
Las principales partes de este proyecto son:

3

Introduccion:
En este captulo se detalla el alcance del proyecto as como sus objetivos y
estructura. Tambien se dara a conocer el alumno autor del proyecto y sus motivaciones. Por u ltimo este captulo contendra una serie de conceptos que resultaran u tiles para entender el proyecto.
Analisis inicial:
Durante este captulo se analizara la situacion inicial de la empresa para entrar en contexto. Se comprobara si la empresa esta preparada para cumplir los
objetivos del proyecto. Tambien se concienciara a la empresa sobre consideraciones previas del proyecto as como causas comunes de fracasos en este tipo
de proyectos.
Propuesta: En este capitulo se expondra una propuesta a desarrollar para cumplir
los objetivos del proyecto y cumpliendo las restricciones detectadas en el
captulo anterior.
Analisis final: Durante este captulo se mostrara la planificacion del proyecto y se sacaran las conclusiones finales sobre el proyecto. Se analizara si se
han cumplido los objetivos del proyecto, las posibles incidencias o problemas
surgidos durante el proyecto y estudio de posibles proyectos de mejora futuros.
1.4.
Presentacion alumno y motivacion
El responsable de la realizacion de este proyecto sera Marc Blando Coll. De entre todos los perfiles de conocimiento que aporta la carrera de ingeniera informatica,
Marc ha sentido un especial interes por la ingeniera del software, los sistemas de
informacion y la gestion de la informacion en las organizaciones. Su interes por el
mundo empresarial le ha acercado tambien temas de gestion TI, por ello, ha aprendido y obtenido la certificacion de Fundamentos ITIL v3. ITIL, (del ingles Information
4
1.5. C ONCEPTOS
Technology Infrastructure Library), es un conjunto de conceptos y buenas practicas
para la gestion de servicios de tecnologas de la informacion, el desarrollo de tecnologas de la informacion y las operaciones relacionadas con la misma en general.
Tambien obtuvo experiencia en implantacion de sistemas de informacion 1.5.3 cuando dirigio una implantacion de un ERP 1.5.4 en la empresa familiar.
En una sociedad donde las tecnologas de la informacion son cada vez es mas
utilizados por las empresas, es necesario que existan personas capaces de disenar,
implementar y gestionar estas tecnologas. Pero no solo deben entender los temas
tecnologicos, deben ser capaces de entender a la sociedad, las empresas y sus actividades para ofrecer sistemas que cubran sus necesidades. Estas personas son un
vnculo entre las tecnologas de la informacion y los que necesitan dichas tecnologas.
La mayor motivacion de Marc es ser capaz de aprovechar sus conocimientos
para ayudar a la sociedad o las empresas, en resumen, construir algo de valor.
La empresa PubliFringe tiene unas necesidades tecnologicas que, Marc debera identificar durante el proyecto interactuando con los empleados. Debera intermediar con
la empresa y ayudarla a encontrar e implantar una solucion tecnologica que cubra sus
necesidades. Esta experiencia le requerira poner en practica sus conocimientos tecnologicos y practicas de ingeniera adquiridos durante la carrera. Ademas, tendra la
oportunidad de adquirir nuevos conocimientos y profundizar en temas ya conocidos.
Esta situacion es especialmente motivadora.
1.5.
Conceptos
En esta seccion se explicaran brevemente conceptos cuya definicion se considera

necesaria para para entender el proyecto. El objetivo de este apartado no es conocer
al detalle cada concepto, solo extraer una idea general, ya que algunos de estos
conceptos son extensos y complejos de detallar en profundidad y se escapan del
alcance de este proyecto.
5

1.5.1.
Cadena de valor
La cadena de valor empresarial, o cadena de valor, es un modelo teorico que

permite describir el desarrollo de las actividades de una organizacion empresarial
generando valor al cliente final.
La cadena de valor ayuda a determinar las actividades o competencias distintivas
que permiten generar una ventaja competitiva.
El concepto ha sido extendido mas alla de las organizaciones individuales. Tambien puede ser aplicado al estudio de la cadena de suministro as como a redes de
distribucion. La puesta a disposicion de un conjunto de productos y servicios al
consumidor final moviliza diferentes empresas, cada una de los cuales gestiona su
cadena de valor. Las interacciones sincronizadas de esas cadenas de valor locales
crean una cadena de valor ampliada que puede llegar a ser global.
La cadena de valor de una empresa se debe enlazar con las cadenas de valor de
sus proveedores, distribuidores y clientes. Una red de valor consiste en sistemas de
informacion que mejoran la competitividad en toda la industria promoviendo el uso
de estandares y al dar a las empresas la oportunidad de trabajar de manera mas eficiente con sus socios de valor.
1.5.2.
Tecnologas de la informacion (TI)
Las tecnologas de la informacion son el a rea de la gestion de la tecnologa y

abarca gran variedad de a reas que incluyen procesos, programas informaticos, sistemas de informacion, equipos de computacion, lenguajes de programacion, y las
construcciones de datos.
En resumen, todo lo que hace que los datos, informacion o conocimiento percibido
en cualquier formato visual que sea, a traves de cualquier mecanismo de distribucion
6
1.5. C ONCEPTOS
multimedia, se considera parte del dominio de TI.
TI ofrece a las empresas cuatro conjuntos de servicios basicos para ayudar a ejecutar la estrategia de negocio: la automatizacion de procesos de negocio, proporcionando la informacion, conexion con los clientes y las herramientas de productividad.
1.5.3.
Sistema de informacion (SI)
Un sistema de informacion es un conjunto organizado de elementos, que pueden

ser personas, datos, actividades o recursos materiales en general. Estos elementos
interactuan entre s para procesar informacion y distribuirla de manera adecuada en
funcion de los objetivos de una organizacion.
Otro concepto relacionado son los sistemas integrales de informacion (SII), estos
sistemas integran o centralizan la informacion misional de una organizacion facilitando su uso a lo largo y ancho de todas las a reas de la Organizacion. Los SII cubren
los procesos de negocio de un tipo de organizacion especfica.
Unos ejemplos de SII son los sistemas ERP y CRM.
1.5.4.
Planificacion de recursos empresariales (ERP)
Los ERP (por sus siglas en ingles, Enterprise resource planning) son sistemas
integrales de gestion para la empresa. Se caracterizan por estar compuestos por
diferentes partes integradas en una u nica aplicacion que automatizan muchas de las
practicas de negocio asociadas con los aspectos operativos o productivos de una empresa.

1.5.5.
Administracion basada en la relacion con los clientes (CRM)
CRM (por sus siglas en ingles, Customer relationship management), es un modelo de gestion empresarial orientada al cliente.
Su objetivo principal es ayudar a las empresas a conseguir posibles clientes y
fidelizar a los actuales. Esto se consigue alcanzando la satisfaccion total del cliente
mediante el entendimiento de sus necesidades y expectativas.
Existe software pensado para dar soporte a esta estrategia, llamado tambien
CRM. Es importante destacar que el software CRM no es equivalente a la estrategia
CRM. Implantar el software no garantiza que una empresa siga una estrategia CRM
ni que obtenga los beneficios de dicha estrategia. Lo realmente importante para implantar una estrategia CRM es la cultura de la empresa. El software CRM se usa para
dar soporte a dicha estrategia.
1.5.6.
La gestion de las relaciones con los proveedores (SRM)
SRM (por sus siglas en ingles, Supplier Relationship Management) es un termino

que describe los metodos y procesos de una empresa o una institucion que compra.
Esto puede ser para la compra de suministros de uso interno, la compra de materias
primas para el consumo durante el proceso de fabricacion, o para la adquisicion de
bienes de inventario para ser revendidos como productos en la distribucion y venta
al por menor.
Gestionar el desempeno de los proveedores: La aplicacion de tecnologas, procesos, polticas y procedimientos para apoyar el proceso de compra (Supplier
Relationship Management).
El proveedor de gestion de relaciones con el proceso: Un proceso de proporcionar la estructura de como las relaciones con los proveedores sera desarrol8
1.5. C ONCEPTOS
lada y mantenida.
Las teoras economicas de la oferta y la demanda: La gestion de la oferta se
considera generalmente como un sistematico proceso de negocio que incluye
mas funciones que los tradicionales de compra, tales como la coordinacion
interna de entrada y de pre-produccion logstica y la gestion de inventario.
1.5.7.
Software propietario
El software propietario es cualquier programa informatico en el que el usuario

tiene limitaciones para usarlo, modificarlo o redistribuirlo.
Para la Fundacion para el Software Libre este concepto se aplica a cualquier software que no es libre o que solo lo es parcialmente (semilibre), sea porque su uso,
redistribucion o modificacion esta prohibida, o requiere permiso expreso del titular
del software. La persona fsica o jurdica al poseer los derechos de autor sobre un
software tiene la posibilidad de controlar y restringir los derechos del usuario sobre
su programa, lo que en el software no libre implica por lo general que el usuario solo
tendra derecho a ejecutar el software bajo ciertas condiciones, comunmente fijadas
por el proveedor, que signifique la restriccion de una o varias de las cuatro libertades.
En el caso de la soluciones comerciales que son software propietario para sistemas de informacion integrado como ERP o CRM, existen numerosas ventajas y
desventajas. Entre las ventajas, generalmente se ven:
Buen control de calidad del software.
Personal de soporte muy cualificado.
Software muy especfico (verticalizacion).
Las marcas conocidas tiene las ventajas anadidas de un gran grupo de usuarios,
difusiones de numerosas publicaciones sobre el uso y aplicacion del software.
9

Mucha documentacion al respecto.
Se invierte mucho en investigacion y desarrollo del software propietario.
Entre las desventajas, generalmente se ven:

Licencia costosa.
No se dispone del codigo fuente, lo que impide, entre otras cosas, la correccion
de errores.
Soporte tecnico ineficiente. Pueden tardar mucho en dar con una solucion satisfactoria para el cliente.
Cursos de aprendizaje costosos.
Es ilegal y/o costoso realizar modificaciones y adaptaciones propias del software.
Si el proveedor desaparece o abandona el producto, el producto dejara de ser
actualizado y mejorado.
1.5.8.
Software libre
El software libre es la denominacion del software que respeta la libertad de los

usuarios sobre su producto adquirido y, por tanto, una vez obtenido puede ser usado,
copiado, estudiado, modificado y redistribuido libremente. Segun la Free Software
Foundation, el software libre se refiere a la libertad de los usuarios para ejecutar,
copiar, distribuir, estudiar, modificar el software y distribuirlo modificado. El software libre suele estar disponible gratuitamente, o al precio de costo de la distribucion a traves de otros medios; sin embargo no es obligatorio que sea as, por lo
tanto no hay que asociar software libre a software gratuito.o freeware, ya que, conservando su caracter de libre, puede ser distribuido comercialmente. Tampoco debe
10
1.5. C ONCEPTOS
confundirse software libre con software de dominio publico. Este

u ltimo es aquel
software que no requiere de licencia, pues sus derechos de explotacion son para toda
la humanidad, porque pertenece a todos por igual. Cualquiera puede hacer uso de e l,
siempre con fines legales y consignando su autora original.
En el caso de la soluciones comerciales que son software libre para sistemas de
informacion integrado como ERP o CRM, existen numerosas ventajas y desventajas.
Entre las ventajas, generalmente se ven:
Hay acceso al codigo fuente, lo que permite modificaciones y adaptaciones
propias del software. Tambien permite aplicar parches o actualizaciones de
terceros.
Se puede obtener soporte de cualquier empresa con la formacion adecuada.
Entre las desventajas, generalmente se ven:
El software puede estar incompleto.
La licencia puede cambiar a una cerrada, por ejemplo motivada por falta de
beneficios.
Falta de responsabilidad. Este software se entrega sin garantas de funcionamiento, por lo que es importante documentarse bien antes de implantar un sistema
de informacion integrado de software libre para evitar problemas.
Puede ser dificil entender la estructura interna del software sin formacion especfica. Puede ser necesaria formacion tanto para el uso como para la modificacion del software.
1.5.9.
Virtualizacion
La virtualizacion es la creacion, a traves de software, de una version virtual de

algun recurso tecnologico, como puede ser una plataforma de hardware, un sistema
11

operativo, un dispositivo de almacenamiento u otros recursos de red.
Dicho de otra manera, se refiere a la abstraccion de los recursos de una computadora, llamada Hypervisor o VMM (Virtual Machine Monitor) que crea una capa de
abstraccion entre el hardware de la maquina fsica (host) y el sistema operativo de
la maquina virtual (virtual machine, guest), dividiendose el recurso en uno o mas
entornos de ejecucion.
Esta capa de software (VMM) maneja, gestiona y arbitra los cuatro recursos
principales de una computadora (CPU, Memoria, Almacenamiento y Conexiones de
Red) y as podra repartir dinamicamente dichos recursos entre todas las maquinas
virtuales definidas en el computador central. Esto hace que se puedan tener varios
ordenadores virtuales ejecutandose en el mismo ordenador fsico.
Tal termino es antiguo, se viene usando desde 1960, y ha sido aplicado a diferentes aspectos y a mbitos de la informatica, desde sistemas computacionales completos, hasta capacidades o componentes individuales.
La virtualizacion se encarga de crear una interfaz externa que encapsula una
implementacion subyacente mediante la combinacion de recursos en localizaciones
fsicas diferentes, o por medio de la simplificacion del sistema de control. Un avanzado desarrollo de nuevas plataformas y tecnologas de virtualizacion ha hecho que
en los u ltimos anos se haya vuelto a prestar atencion a este concepto.
La maquina virtual en general simula una plataforma de hardware autonoma incluyendo un sistema operativo completo que se ejecuta como si estuviera instalado.
Tpicamente varias maquinas virtuales operan en un computador central. Para que el
sistema operativo guest funcione, la simulacion debe ser lo suficientemente grande
(siempre dependiendo del tipo de virtualizacion).
Existen diferentes formas de virtualizacion: es posible virtualizar el hardware de
12
1.5. C ONCEPTOS
servidor, el software de servidor, virtualizar sesiones de usuario, virtualizar aplicaciones y tambien se pueden crear maquinas virtuales en una computadora de escritorio.
Entre los principales proveedores de software que han desarrollado tecnologas
de virtualizacion integrales (que abarcan todas las instancias: servidor, aplicaciones,
escritorio) se encuentran, por ejemplo VMware y Microsoft.
Indices de utilizacion mas altos. Antes de la virtualizacion, los ndices de utilizacion del servidor y almacenamiento en los centros de datos de las empresas
rondaban menos del 50 % (de hecho, del 10 % al 15 % de los ndices de utilizacion fueron los mas comunes). A traves de la virtualizacion, las cargas de
trabajo pueden ser encapsuladas y transferidas a los sistemas inactivos o sin
uso.
Consolidacion de Recursos. La virtualizacion permite la consolidacion de multiples recursos de TI. Mas alla de la consolidacion de almacenamiento, la virtualizacion proporciona una oportunidad para consolidar la arquitectura de sistemas, infraestructura de aplicacion, datos y base de datos, interfaces, redes,
escritorios, e incluso procesos de negocios, resultando en ahorros de costo y
mayor eficiencia.
Uso/costo menor energa. La electricidad requerida para que funcionen los
centros de datos de clase empresarial ya no esta disponible en suministros
ilimitados, y el costo esta en una espiral ascendente. Por cada dolar gastado
en un servidor hardware, un dolar adicional es gastado en energa (incluyendo el costo de los servidores en funcion y los enfriadores). Utilizando virtualizacion para consolidar hace posible cortar el consumo total de energa y
ahorrar dinero de una manera significativa.
Ahorros de espacio. La extension del servidor permanece como un serio problema en la mayora de los centros de datos empresariales, pero la expansion
13

del centro de datos no es siempre una opcion, con los costos de construccion promediando miles de dolares por pie cuadrado. La virtualizacion puede
aliviar la tension mediante la consolidacion de muchos sistemas virtuales en
menos sistemas fsicos.
Recuperacion de desastre/continuidad del negocio. La virtualizacion puede
incrementar la disponibilidad de los ndices del nivel de servicio en general y
proporcionar nuevas opciones de soluciones para la recuperacion de desastre.
Costos de operacion reducidos La empresa promedio gasta $8 dolares en
mantenimiento por cada $1 dolar invertido en nueva infraestructura. La virtualizacion puede cambiar el radio de servicio-a administracion reducir la carga
total de trabajo administrativo, y cortar el total de costos de operacion.
1.5.10.
Cloud Computing
Cloud computing es un nuevo modelo de prestacion de servicios de negocio y

tecnologa, que permite al usuario acceder a un catalogo de servicios estandarizados
y responder a las necesidades de su negocio, de forma flexible y adaptativa, en caso
de demandas no previsibles o de picos de trabajo, pagando u nicamente por el consumo efectuado. Cloud computing es el siguiente gran paso en outsourcing.
El modelo Cloud computing es una abstraccion que se puede dividir en 3 capas:
Software como servicio (SaaS): Un ejemplo de este servicio sera Google
Apps que ofrece servicios de negocio basicos como correo electronico. Consiste en una aplicacion completa ofrecida como un servicio, bajo demanda y
una sola instancia (en la insfraestrutura del proveedor) puede servir a multiples
clientes.
Plataforma como servicio (PaaS): Es la encapsulacion de una abstraccion de
un ambiente de desarrollo y el empaquetamiento de una carga de servicios.
Un ejemplo de estos servicios sera Google App Engine.
14
1.5. C ONCEPTOS
Infraestructura como servicio (IaaS): Es un medio de entregar almacenamiento
basico y capacidades de computo como servicios estandarizados en la red.
Amazon Web Services sera un ejemplo de IaaS, cuyos servicios EC2 y S3
ofrecen computo y servicios de almacenamiento respectivamente.
A continuacion se exponen las principales ventajas y desventajas de este modelo.
Ventajas
Integracion probada de servicios Red. Por su naturaleza, la tecnologa
de Cloud Computing se puede integrar con mucha mayor facilidad y
rapidez con el resto de sus aplicaciones empresariales (tanto software
tradicional como Cloud Computing basado en infraestructuras), ya sean
desarrolladas de manera interna o externa.
Prestacion de servicios a nivel mundial. Las infraestructuras de Cloud
Computing proporcionan mayor capacidad de adaptacion, recuperacion
de desastres completa y reduccion al mnimo de los tiempos de inactividad.
Una infraestructura 100 % de Cloud Computing permite al proveedor de
contenidos o servicios en la nube prescindir de instalar cualquier tipo de
hardware, ya que e ste es provisto por el proveedor de la infraestructura o
la plataforma en la nube. La belleza de la tecnologa de Cloud Computing
es su simplicidad. . . y el hecho de que requiera mucha menor inversion
para empezar a trabajar.
Implementacion mas rapida y con menos riesgos. Podra empezar a trabajar muy rapidamente gracias a una infraestructura de Cloud Computing.
No tendra que volver a esperar meses o anos e invertir grandes cantidades
de dinero antes de que un usuario inicie sesion en su nueva solucion. Sus
aplicaciones en tecnologa de Cloud Computing estaran disponibles en
cuestion de das o horas en lugar de semanas o meses, incluso con un
nivel considerable de personalizacion o integracion.
15

Actualizaciones automaticas que no afectan negativamente a los recursos de TI. Si actualizamos a la u ltima version de la aplicacion, nos veremos obligados a dedicar tiempo y recursos (que no tenemos) a volver a
crear nuestras personalizaciones e integraciones. La tecnologa de Cloud
Computingno le obliga a decidir entre actualizar y conservar su trabajo,
porque esas personalizaciones e integraciones se conservan automaticamente durante la actualizacion.
Contribuye al uso eficiente de la energa. En este caso, a la energa requerida para el funcionamiento de la infraestructura. En los datacenters
tradicionales, los servidores consumen mucha mas energa de la requerida realmente. En cambio, en las nubes, la energa consumida es solo la
necesaria, reduciendo notablemente el desperdicio.
Desventajas
La centralizacion de las aplicaciones y el almacenamiento de los datos
origina una interdependencia de los proveedores de servicios.
La disponibilidad de las aplicaciones esta ligada a la disponibilidad de
acceso a Internet.
Los datos sensibles del negocio no residen en las instalaciones de las
empresas por lo que podra generar un contexto de alta vulnerabilidad
para la sustraccion o robo de informacion.
La confiabilidad de los servicios depende de la saludtecnologica y financiera de los proveedores de servicios en nube. Empresas emergentes
o alianzas entre empresas podran crear un ambiente propicio para el
monopolio y el crecimiento exagerado en los servicios. La disponibilidad de servicios altamente especializados podra tardar meses o incluso
anos para que sean factibles de ser desplegados en la red.
La madurez funcional de las aplicaciones hace que continuamente esten
modificando sus interfaces, por lo cual la curva de aprendizaje en empresas de orientacion no tecnologica tenga unas pendientes significativas,
16
1.5. C ONCEPTOS
as como su consumo automatico por aplicaciones.
La informacion de la empresa debe recorrer diferentes nodos para llegar
a su destino, cada uno de ellos (y sus canales) son un foco de inseguridad.
Si se utilizan protocolos seguros, HTTPS por ejemplo, la velocidad total
disminuye debido a la sobrecarga que estos requieren.
Escalabilidad a largo plazo. A medida que mas usuarios empiecen a compartir la infraestructura de la nube, la sobrecarga en los servidores de
los proveedores aumentara, si la empresa no posee un esquema de crecimiento o ptimo puede llevar a degradaciones en el servicio.
1.5.11.
Proceso de negocio
Un proceso es un conjunto de actividades o eventos organizados que se realizan

o suceden bajo ciertas circunstancias con un fin determinado. Existen muchos tipos
de procesos dentro de la rama de ciencias y tecnologa.
Un proceso de negocio es un conjunto de tareas relacionadas logicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio
tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una funcion pueda ser aplicada. Cuando una funcion es aplicada
a las entradas de un metodo, tendremos ciertas salidas resultantes. Los procesos de
negocio tiene las siguientes caractersticas relevantes para el proyecto:
Pueden ser medidos y estan orientados al rendimiento.
Tienen resultados especficos.
Entregan resultados a clientes, empleados de una empresa u a otros procesos.
Responden a alguna accion o evento especfico.
Las actividades deben agregar valor a las entradas del proceso.
17

1.5.12.
Innovacion y mejora de procesos
La innovacion es el rompimiento en tiempo y espacio de un proceso, producto

o servicio, que se presenta con una nueva cualidad incremental o radical y que es
aceptado por el cliente. Su impacto puede ser economico, social o ambiental. Con
innovacion incremental se refiere a la creacion de valor anadido sobre un producto,
proceso o servicio ya existente, agregandole cierta mejora. Una innovacion radical
supone un cambio o introduccion de un nuevo producto, servicio o proceso que no
se conoca antes.
Basada en nuevas tecnologas y en trabajadores motivados, la innovacion de procesos se basa en el compromiso de la alta direccion con una vision estrategica. Su
a mbito es amplio y cruza multiples funciones en la empresa. Las empresas que se
embarcan en la innovacion de procesos normalmente buscan multiplicar la mejora
de sus resultados en costes, tiempo o calidad.
No debemos confundir el concepto de innovacion de procesos con mejora de
procesos. La innovacion, persigue un nivel de cambio radical, mientras que la mejora
pretende realizar el proceso en la misma forma, pero con un nivel de eficiencia o
efectividad mas alto. Ahora bien, en cualquier sistema de calidad que persiga la meta
de la calidad total, ambos conceptos deben de coexistir equilibradamente, ya que
algunos procesos son objeto de innovacion y otros son mejorados constantemente.
1.5.13.
Reingeniera de procesos
Reingeniera de procesos consiste en una reconcepcion fundamental y una vision

holstica de una organizacion. Es el pensamiento nuevo y el rediseno fundamental
de los procesos operativos y la estructura organizacional, orientado hacia las competencias esenciales de la organizacion, para lograr mejoras dramaticas en el desempeno organizacional. Implica rehacer los sistemas de informacion y de organizacion, formas de trabajar en equipo y los medios por las que dialogan entre s y con
los clientes.
18
1.5. C ONCEPTOS
La reingeniera de procesos es radical hasta cierto punto, ya que busca llegar a

la raz de las cosas, no se trata solamente de mejorar los procesos, sino y principalmente, busca reinventarlos, con el fin de crear ventajas competitivas osadas, con
base en los avances tecnologicos.
Las etapas de la reingeniera pueden ser las siguientes:
Identificacion de los procesos estrategicos y operativos existentes o necesarios, y creacion de un mapa (un modelo) de dichos procesos.
Jerarquizacion del mapa de procesos para su rediseno, y determinacion de los
procesos clave, aquellos que se abordaran primero o con mayor interes.
Desarrollo de la vision de los nuevos procesos mejorados.
Reingeniera (creacion y rediseno) de procesos, realizada por consultores externos, especialistas internos, o una mezcla de ambos.
Preparacion y prueba de los nuevos procesos (procesos pilotos).
Procesos posteriores de mejora continua.
1.5.14.
Metodologa de desarrollo de software tradicional
Estas metodologas tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software mas eficiente.
Para ello, se hace e nfasis en la planificacion total de todo el trabajo a realizar y una
vez que esta todo detallado, comienza el ciclo de desarrollo del producto software.
Se centran especialmente en el control del proceso, mediante una rigurosa definicion
de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentacion detallada.
19

Las metodologas tradicionales no se adaptan adecuadamente a los cambios, por
lo que no son metodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.
Rational Unified Process (RUP) y Metrica v3 s on algunos ejemplos de estas
metodologas.
Proceso Unificado de Rational (RUP)
RUP (por sus siglas en ingles, Rational Unified Process) es un proceso formal
que provee un acercamiento disciplinado para asignar tareas y responsabilidades
dentro de una organizacion de desarrollo. Su principal objetivo es asegurar la produccion de software de alta calidad, que cumpla las necesidades de sus usuarios
finales, que sea realizado en las fechas acordades y con el presupuesto disponible.
Figura 1.1: Fases del ciclo de vida del RUP
Metrica v3
Metrica v3 es una metodologa de planificacion, desarrollo y mantenimiento de
sistemas de informacion. Promovida por el Ministerio de Administraciones Publicas
20
1.5. C ONCEPTOS
del Gobierno de Espana para la sistematizacion de actividades del ciclo de vida de
los proyectos software en el a mbito de las administraciones publicas. Los objetivos
de esta metodologa son:
Proporcionar o definir Sistemas de Informacion que ayuden a conseguir los
fines de la Organizacion mediante la definicion de un marco estrategico para
el desarrollo de los mismos.
Dotar a la Organizacion de productos software que satisfagan las necesidades
de los usuarios dando una mayor importancia al analisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologas de
la Informacion y las Comunicaciones, permitiendo una mayor capacidad de
adaptacion a los cambios y teniendo en cuenta la reutilizacion en la medida de
lo posible.
Facilitar la comunicacion y entendimiento entre los distintos participantes en
la produccion de software a lo largo del ciclo de vida del proyecto, teniendo en
cuenta su papel y responsabilidad, as como las necesidades de todos y cada
uno de ellos.
Facilitar la operacion, mantenimiento y uso de los productos software obtenidos.
Figura 1.2: Estructura general de Metrica

v3
21

1.5.15.
Metodologas a giles de desarrollo de software
El desarrollo a gil de software es un marco de trabajo conceptual de la ingeniera

de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de
vida del proyecto. Existen muchos metodos de desarrollo a gil y la mayora minimiza
riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado
en una unidad de tiempo es llamado una iteracion, la cual debe durar de una a cuatro
semanas.
Estas metodologas nacen como respuesta a las desventajas de las metodologas
de desarrollo tradicionales, como la rigidez a la hora de permitir cambios retrasados
durante el proyecto y la pesadez de los procesos que ejecutan. Como resultado de
esta nueva teora se crea un Manifiesto Agil,

cuyas principales ideas son:
Los individuos y las interacciones entre ellos son mas importantes que las
herramientas y los procesos empleados.
Es mas importante crear un producto software que funcione que escribir documentacion exhaustiva.
La colaboracion con el cliente debe prevalecer sobre la negociacion de contratos.
La capacidad de respuesta ante un cambio es mas importante que el seguimiento estricto de un plan.
Entre los principales metodos a giles tenemos el XP (eXtreme Programming),

Scrum, AUP (Agile Unified Process) entre otras.
Scrum
Scrum es un marco de trabajo para la gestion y desarrollo de software basada en
un proceso iterativo e incremental utilizado comunmente en entornos basados en el
22
1.5. C ONCEPTOS
desarrollo a gil de software. Es un modelo de referencia que define un conjunto de
practicas y roles, y que puede tomarse como punto de partida para definir el proceso
de desarrollo que se ejecutara durante un proyecto. Los roles principales en Scrum
son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director
de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es
definida por el equipo), el equipo crea un incremento de software potencialmente
entregable (utilizable). El conjunto de caractersticas que forma parte de cada sprint
viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman
parte del sprint se determinan durante la reunion de Sprint Planning. Durante esta
reunion, el Product Owner identifica los elementos del Product Backlog que quiere
ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el
siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que
significa que los requisitos estan congelados durante el sprint.
Scrum permite la creacion de equipos autoorganizados impulsando la co-localizacion
de todos los miembros del equipo, y la comunicacion verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los
clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no pueden ser facilmente
enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una
aproximacion pragmatica, aceptando que el problema no puede ser completamente
entendido o definido, y centrandose en maximizar la capacidad del equipo de entregar rapidamente y responder a requisitos emergentes.
23

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum,
que van desde notas amarillas post-it pizarras hasta paquetes de software. Una de
2
las mayores ventajas de Scrum es que es muy facil de aprender, y requiere muy poco
esfuerzo para comenzarse a utilizar.
Aunque surgio como modelo para el desarrollo de productos tecnologicos, tambien se emplea en entornos que trabajan con requisitos inestables y que requieren
rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Puede ser utilizado en equipos de mantenimiento de software, o
en una aproximacion de gestion de programas: Scrum de Scrums.
Figura 1.3: Proceso scrum
1.5.16.
Mapeo objeto-relacional
El mapeo objeto-relacional (mas conocido por su nombre en ingles, ObjectRelational mapping, o sus siglas ORM) es una tecnica de programacion para convertir datos entre el sistema de tipos utilizado en un lenguaje de programacion orientado
a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia. En la practica esto crea una base de datos orientada a objetos virtual, sobre
24
1.5. C ONCEPTOS
la base de datos relacional. Esto posibilita el uso de las caractersticas propias de la
orientacion a objetos (basicamente herencia y polimorfismo).
1.5.17.
Protocolo XML-RPC
XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML

para codificar los datos y HTTP como protocolo de transmision de mensajes.
Es un protocolo muy simple ya que solo define unos cuantos tipos de datos y
comandos u tiles, ademas de una descripcion completa de corta extension. La simplicidad del XML-RPC contrasta con la mayora de protocolos RPC que tiene una
documentacion extensa y requiere considerable soporte de software para su uso.
1.5.18.
Modelo-Vista-Controlador (MVC)
Patron de diseno
Modelo Vista Controlador (MVC) es un patron de arquitectura de software que

separa los datos de una aplicacion, la interfaz de usuario, y la logica de negocio en
tres componentes distintos. El modelo es el Sistema de Gestion de Base de Datos
y la Logica de negocio, y el controlador es el responsable de recibir los eventos de
entrada desde la vista.
Modelo: Esta es la representacion especfica de la informacion con la cual
el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y
su controlador facilitando las presentaciones visuales complejas. El sistema
tambien puede operar con mas datos no relativos a la presentacion, haciendo
uso integrado de otras logicas de negocio y de datos afines con el sistema
modelado.
Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario, e
invoca peticiones al modelo y, probablemente, a la vista.
25

de diseno
MVC
Figura 1.4: Patron
En el diagrama anterior, las lneas continuas de las flechas que van desde el
controlador hasta vista y el modelo significa que el controlador dispone de un acceso
completo a la vista y el modelo. La lnea discontinua de la flecha que va desde la vista
al controlador significa que el punto de vista tiene un acceso indirecto al controlador.
Las razones de este diseno son:
Desde la Vista hasta el Modelo: El modelo enva notificacion a la vista cuando sus datos se ha modificado con el fin de la vista para volver a trazar su
contenido. El modelo no tiene por que saber el funcionamiento interno de la
vista para realizar esta operacion. Sin embargo, la vista necesita tener acceso
a las partes internas del modelo.
Desde la Vista hasta el controlador: La razon por la cual la vista tiene un
acceso limitado al controlador se debe a que las dependencias de la vista en
el controlador necesitan ser mnimas: el controlador puede ser sustituido en
cualquier momento.
26
Captulo 2
Analisis inicial
En este captulo se detallara el problema que ha iniciado este proyecto y se recopilara informacion suficiente para poder buscar una solucion al problema.
Cabe mencionar que en este captulo se aplicara parte de una metodologa propuesta por Javier Celma Marquez [43] que se continuara aplicando en el captulo
posterior. Es una metodologa adaptada para empresas pequenas o micro-empresas
para seleccionar sistema ERP 1.5.4. En este caso se ha adaptado ligeramente para
abarcar cualquier tipo de sistema de informacion y para incluir un proceso de innovacion. Esta metodologa pretende ahorrar costes de consultora externa a una
micro-empresa ayudando a seleccionar una solucion tecnologica apropiada.
2.1.
Situacion inicial de la empresa
PubliFringe
Publicidad al Lmite
es una micro-empresa de Barcelona con un ano de vida
fundada por dos jovenes, Peter y Olivia. Fundaron la empresa lanzando una plataforma de busqueda de servicios profesionales por Espana, dividido por zonas. Esta
plataforma se diferencia de otras similares exigiendo a las pymes que se publican
en la plataforma un nivel de calidad tanto en la informacion que proporcionan a los
usuarios como en los servicios ofrecidos. Esto favorece a los usuarios de la plataforma que buscan servicios ya que obtiene ciertas garantas de calidad que en otros
buscadores no se consiguen. Las empresas que se publicitan por la plataforma con27

C API TULO 2. A N ALISIS
INICIAL
siguen mas clientes y los usuarios obtienen la confianza de poder encontrar servicios
de calidad en el buscador.
PubliFringe ha detectado una necesidad por parte de las Pymes de publicitarse.
A raz de todo esto, PubliFringe ha decidido recientemente abrirse camino hacia
todos los aspectos de la publicidad para Pymes: Diseno y produccion de tarjetas,
servicios de imprenta, hasta diseno y desarrollo de paginas web, posicionamiento
en buscadores y publicidad online. Todo para ayudar a las empresas a ganar mas
clientes mediante publicidad.
Actualmente dispone de un miembro mas en plantilla: Walter, un comercial experimentado con experiencia en tareas de supervision de comerciales en una compana de seguros. Walter supervisa mas de una docena de comerciales autonomos
que ofrecen los servicios de publicidad disponibles a las pymes de Cataluna, con expectativas de seguir aumentando la fuerza de ventas y la zona de accion. Entre estos
comerciales autonomos, algunos tienen escasa experiencia como comerciales, otros
tienen algo mas y otros tienen bastante aunque no tienen experiencia en temas de
marketing y publicidad. La empresa reune a los comerciales autonomos cada cierto
tiempo para formarlos en temas comerciales.
A nivel organizativo la empresa no esta estructurada en departamentos debido
a que tiene pocos miembros. Sin embargo, se pueden distinguir 5 roles de trabajo.
Una sola persona puede llegar a desempenar varios roles si fuera necesario y tiene
la aptitudes necesarias para desempenarlo. Los roles son:
Comercial: Este rol lo desempenan, al menos, todos los comerciales autonomos
de la empresa. Quien desempena este rol se encarga de establecer contacto con
los clientes y fidelizarlos.
Supervisor comercial: Quien desempena este rol se encarga de supervisar a los
comerciales, controlando y formando a los comerciales autonomos que, generalmente, tienen una menor implicacion con la empresa que los supervisores
28
INICIAL DE LA EMPRESA
2.1. S ITUACI ON
comerciales.
Tecnico: Este rol se encarga de gestionar y ejecutar los servicios ofrecidos
por la empresa: desarrollo y mantenimiento web, posicionamiento SEO/SEM,
redes sociales, gestionar el buscador de servicios de la empresa, preparar estrategias de marketing. . . Estos servicios requieren conocimientos tecnicos especficos para su gestion y ejecucion por lo que las personas que desempenan
este rol suelen tener conocimientos tecnicos especficos en al menos una de
las a reas que cubre la empresa.
Gerente: Este rol lo desempenan Olivia y Peter, los fundadores de la empresa.
Este rol coordina a todos los demas y todas las decisiones importantes han de
ser aprobadas a traves de este. Se encarga de guiar a la empresa para que todo
funcione de acuerdo a los objetivos estrategicos de la empresa.
Administrativo: Quien desempena este rol se encarga de la parte administrativa de la empresa: facturacion, contabilidad, controlar cobros y pagos. . . Por
ahora, los gerentes son los que normalmente desempenan este rol.
PubliFringe actualmente trabaja sin un sistema integrado de informacion por lo
que tiene problemas cuando almacenan informacion ya que cada miembro de la empresa y los autonomos poseen sus propios ficheros y documentos para almacenar la
informacion. Eso conlleva que haya mucha informacion repetida y desfasada, causando ineficiencia en sus procesos y problemas de comunicacion.
Hasta ahora ha sido posible trabajar porque la empresa cuenta con pocos miembros en plantilla y hasta ahora se ha dado bastante libertad a los comerciales autonomos.
Los comerciales autonomos disponen de un catalogo de servicios y productos con
precios estimados para poder ofrecer a los clientes. Si existe la posibilidad, los comerciales pueden elaborar o proponer presupuestos a medida segun las necesidades
de los clientes o al menos informar a la empresa de dichas necesidades. Estos presupuestos a medida deben ser analizados y aprobados por la empresa.
29

INICIAL
Se hace bastante evidente pues, la necesidad de implantar un nuevo sistema integrado de informacion. Con esa idea en mente, la empresa realizo un convenio de
cooperacion educativa para conseguir que un joven ingeniero informatico planificara
y ejecutara este proyecto.
30

2.2. A N ALISIS
DE LA NECESIDAD DE UN CAMBIO
2.2.
Analisis de la necesidad de un cambio
En esta seccion se analizara la necesidad que hay de un cambio de sistema de

informacion a traves de una serie de afirmaciones. Aunque parece evidente la necesidad de un nuevo sistema de informacion tras un analisis preliminar, se ha decidido
realizar este analisis desde varios puntos de vista dentro de la empresa. En el analisis
no solo se podra determinar la necesidad, tambien se detectaran los principales motivos de esa necesidad desde varios puntos de vista: comercial, tecnico, administrativo y global. Estos motivos nos ayudaran a determinar funcionalidades o requisitos
del nuevo sistema de informacion 1.5.3.
Los entrevistados para este analisis seran:
Marc Blando Coll, con su vision de responsable del proyecto, consultor de
sistemas de informacion, y su punto de vista tecnico.
Walter, con su vision comercial.
Olivia y Peter, como gerentes con una vision mas global de la empresa.
Algunas afirmaciones parecen similares. Se debe a que refuerzan el mismo motivo

comun de necesidad pero desde otro enfoque. Los entrevistados escogeran entre las
afirmaciones disponibles, las que consideren que se ajustan a la empresa. Despues,
entre las escogidas, seleccionaran las que mas les afecten o con las que se sientan
mas identificados, por orden de prioridad. Juntando las selecciones de cada entrevistado, se podran detectar los principales motivos de necesidad entre los distintos
enfoques que existen en la empresa. A continuacion, las afirmaciones con las conclusiones:
Existe la necesidad de un sistema de informacion actualizado si:
31

INICIAL
1. Surgen necesidades de gestion administrativa o de informacion que no
cubre el sistema actual:
Todos los entrevistados coinciden en la importancia de este punto. Esta gestion

no aporta valor a la empresa y se realiza de manera ineficiente perdiendo tiempo de trabajo que podra utilizarse para otras tareas que aporten valor.
2. Se realizan tareas de forma poco racional o con mucho trabajo:
Vuelven a coincidir todo el equipo, se pierde mucho tiempo gestionando la informacion desperdigada de la empresa, sincronizando informacion, copiando
informacion repetida. . .
3. Se quieren mejorar los sistemas de trabajo, los procesos existentes en la
actualidad y los flujos intermedios de datos:
Similar a la anterior, vuelven a coincidir. Quieren mejorar los procesos existentes con el nuevo sistema de informacion.
4. Se quiere actuar de forma mas global, en mas ubicaciones y con distintas
actividades:
En esta afirmacion la mitad del equipo coincide en su importancia. Es necesario que el nuevo sistema sea capaz de escalar. Dada la naturaleza del negocio, la empresa podra a largo plazo expandirse con relativa facilidad a otras
ubicaciones.
5. El hardware de la empresa esta anticuado en prestaciones:
No existen problemas de hardware con el sistema de informacion actual. Es

suficiente un ordenador portatil o movil para operar.
32

2.2. A N ALISIS
6. El sector, el tipo de actividad y la competencia hacen que surja la necesidad de instalar un nueva sistema de gestion mas eficaz:
Este punto lo consideran todos importante, coinciden en que los nuevos servicios ofrecidos requieren un sistema de informacion mas eficaz y eficiente para
estar a la altura de los competidores.
7. Se necesita gestionar y estructurar mejor el conocimiento del negocio y
aumentar la independencia empresa-empleado:
La mayora ha considerado especialmente importante este punto, coinciden en

que eso mejorara la eficiencia de las tareas a realizar.
8. Se dispone de un sistema de informacion desfasado en prestaciones:
Las herramientas de ofimatica que utilizan en el sistema de informacion actual

no se encuentra desfasado en prestaciones. Sin embargo no es suficientemente
eficaz ni eficiente, se requiere un sistema de integral de informacion.
9. Los usuarios del sistema deben entrar la misma informacion varias veces
en distintos puntos del sistema:
Por unanimidad se coincide en la importancia en este punto, al no integrar

toda la informacion de la empresa, se debe introducir varias veces la misma
informacion.
aplica10. Los usuarios usan software online, hojas de calculo o pequenas
ciones de bases de datos para hacer su trabajo o mantener la informacion
que necesitan para desempenarlo:
Todos coinciden en este punto, es similar a otras afirmaciones. Cada uno tiene
su propio sistema para gestionar la informacion que necesita.
33

INICIAL
11. Se necesita mucho tiempo para analizar los datos de la empresa puesto
que estan muy repartidos y resulta difcil unirlo y sacar conclusiones de
ellos:
Todo el equipo coincide en que cuesta usar la informacion para tomar decisiones.
12. Se tienen problemas de gestion de inventario, no se sabe que tienes en el
inventario y lo que cuesta:
Dada la naturaleza de la empresa, no se dispone de inventario fsico.

13. Hay quejas crecientes de los trabajadores respecto a que no pueden trabajar lo rapido que querran por culpa del sistema
Hay pocos trabajadores en plantilla y no se han recibido quejas de los comerciales autonomos.
14. Cada vez es mas difcil cumplir los requisitos que se piden de formato y
tiempos de entrega cuando se nos pide cierta informacion tanto por parte
de los clientes como de los partners:
Se tarda demasiado en elaborar propuestas/presupuestos a los clientes por falta

de organizacion en parte y por tardanza de respuesta de los proveedores.
15. No se esta sacando el suficiente provecho de internet:
Algunos opinan que se podra mejorar el sistema aprovechando internet, por

ejemplo, distribuyendo facilmente informacion integrada entre los comerciales
autonomos distribuidos por Cataluna.
34

2.2. A N ALISIS
16. Se ha pensado o descrito las actuales virtudes y deficiencias de nuestro
actual sistema, y las deficiencias son importantes como para afectar significativamente al rendimiento global de la empresa:
Esta afirmacion engloba muchas de las otras afirmaciones importantes para el

equipo, todo el equipo coincide en su importancia.
17. La empresa no podra funcionar sin la presencia del gerente:
Uno de los gerentes considera importante esta afirmacion, mucha de la informacion necesaria para la toma de decisiones no esta registrada en ningun sitio,
solo los gerentes la conocen.
18. Si un comercial deja la empresa se perdera el negocio:
Dada la manera de gestionar a los comercial no se da el caso.

19. Da la sensacion de no poder controlar la empresa, ya no se conocen todos
los detalles del negocio o no se conocen todos los productos que se venden
y sus precios:
La mayora coinciden en la importancia de esta afirmacion. Faltan metricas

para controlar los procesos que se ejecutan en la empresa para calcular costes,
buscar fallos. . .
ellos que la empresa quera abordar pero el sistema actual no podra abarcar las nuevas actividades:
La mitad del equipo coinciden en la importancia de este punto. El sistema

35

INICIAL
actual no esta preparado para soportar gestiones de nuevas actividades o procesos relativamente complicados.
21. Se necesita que algunos clientes tengan una entrada al sistema y actualmente no la tienen:
Todo el equipo opina que convendra que algunos clientes pudieran acceder
al sistema para repetir servicios ya solicitados previamente para acelerar la
ejecucion del servicio.
22. No se conocen que productos o servicios del negocio dan mas rentabilidad
economica:
Casi todo el equipo coincide en que es importante conocer con seguridad la

rentabilidad de los servicios ofrecidos, y actualmente no se conoce con exactitud.
Ahora se mostrara, por orden de prioridad, las afirmaciones mas importantes
segun cada entrevistado:
Marc
en distintos puntos del sistema
2. Se quieren mejorar los sistemas de trabajo, los procesos existentes en la
actualidad y los flujos intermedios de datos
ellos
4. Se quiere actuar de forma mas global, en mas ubicaciones y con distintas
actividades
Olivia
36

2.2. A N ALISIS
ellos
actual sistema, y las deficiencias son importantes como para afectar significativamente al rendimiento global de la empresa
en distintos puntos del sistema
Peter
ellos
2. Se necesita que algunos clientes tengan una entrada al sistema y actualmente no la tienen
3. Los usuarios usan software online, hojas de calculo o pequenas aplicaciones de bases de datos para hacer su trabajo o mantener la informacion
que necesitan para desempenarlo
Walter
1. Se realizan tareas de forma poco racional o con mucho trabajo
2. Los usuarios usan software online, hojas de calculo o pequenas aplicaciones de bases de datos para hacer su trabajo o mantener la informacion
que necesitan para desempenarlo
actual sistema, y las deficiencias son importantes como para afectar previas que significativamente al rendimiento global de la empresa
4. Se necesita que algunos clientes tengan una entrada al sistema y actualmente no la tienen
37

INICIAL
A partir de las conclusiones de cada miembro del equipo, se puede afirmar que
existe una clara necesidad. Los principales motivos son, por orden de prioridad:
1. Los usuarios del sistema deben entrar la misma informacion varias veces en
distintos puntos del sistema. Los usuarios usan software online, hojas de calculo o pequenas aplicaciones de bases de datos para hacer su trabajo o mantener
la informacion que necesitan para desempenarlo
2. Se quieren mejorar los sistemas de trabajo, los procesos existentes en la actualidad y los flujos intermedios de datos
3. Se necesita mucho tiempo para analizar los datos de la empresa puesto que
estan muy repartidos y resulta difcil unirlo y sacar conclusiones de ellos.
4. Se necesita que algunos clientes (y comerciales) tengan una entrada al sistema
y actualmente no la tienen
38
2.3. C ONSIDERACIONES PREVIAS AL CAMBIO
2.3.
Consideraciones previas al cambio
En esta seccion se detallaran una serie de consideraciones que debe tener en

cuenta la empresa para conocer si estan preparados para realizar el cambios. Ademas
se obtendra informacion sobre posibles limitaciones o restricciones durante la implantacion del nuevo sistema. Esta seccion ayudo a los gerentes de la empresa a
considerar temas que no haban tenido en cuenta a la hora de ejecutar este proyecto.
1. Se ha calculado el presupuesto que tiene la empresa para adquirir un nuevo sistema de informacion.:
Se destino, sin incluir el contrato del alumno para el proyecto de implantacion

del nuevo sistema (unos 3.000 euros), un presupuesto de unos 500 euros por el
proceso de implantacion y un mantenimiento de unos 100 euros ano. Este presupuesto tan bajo va a ser muy restrictivo a la hora de proponer una solucion
tecnologica ya que descartaremos las soluciones que impliquen mas coste. El
mayor peso de la inversion de este proyecto esta en la contratacion del alumno. Cabe destacar que, a medida que la empresa crezca y aumenten el numero
de comerciales, se preve aumentar los costes de mantenimiento escalados al
numero de usuarios y volumen del sistema de informacion. Dada la situacion
actual de la empresa, la empresa no puede invertir mas en este proyecto, de
momento. Se espera poder invertir mas a mitad del proceso de implantacion.
2. Se ha pensado en el tipo de sistema de informacion que podra interesar
y los motivos.:
Antes de iniciar el proyecto los gerentes de la empresa pensaron que un CRM

sera un sistema apropiado, ya que buscan implantar una estrategia CRM y el
sistema les sera u til para dar soporte a la estrategia.
3. La empresa dispone de personal con conocimientos informaticos que pueda abordar el proyecto.:
39

INICIAL
El responsable del proyecto es el u nico miembro del proyecto con conocimientos informaticos para abordar el proyecto. Hara de jefe de proyecto, analista,
disenador y programador. Peter, gerente tecnico, posee uno conocimientos
basicos sobre tecnologa y colaborara estrechamente en el proyecto tanto como para describir el problema y necesidades concretas como en tareas tecnicas
sencillas.
4. Se tiene claro que el lder del proyecto es el gerente de la empresa, en referencia a la estrategia y los objetivos de e ste:
En la empresa se tiene muy claro, ambos gerentes estaran muy presentes durante todo el proyecto.
5. Se ha considerado si se deben efectuar muchos cambios en las funciones
y sistemas de los trabajos actuales.:
La intencion es mejorar o innovar en algunos procesos, por lo que esperan

cambios.
6. Se ha analizado si el tipo de hardware existente es el adecuado para trabajar con el sistema de informacion:
Estan concienciados de que si deciden mantener su nuevo sistema de informacion en la propia empresa, deberan adquirir un hardware apropiado para
mantener el sistema, teniendo en cuenta la seguridad, las copias de seguridad. . . Una vez seleccionada la solucion a implantar, esta previsto decidir si
externalizar la infraestructura de hardware necesaria o adquirir hardware propio para construir la infraestructura necesaria.
7. Se ha medido el impacto que puede tener en la manera de trabajar de los
usuarios en un nuevo sistema.:
40
Se estima que haya problemas sobretodo con los comerciales autonomos. Aun
as hay pocas personas implicadas en los cambios por lo que sera relativamente
facil formarlos para los cambios.
8. Se ha valorado el tiempo adicional que necesitan la personas implicadas.:
Se ha tenido en cuenta este tiempo adicional, la empresa es consciente del
esfuerzo adicional que supone implantar un nuevo sistema.
9. Se puede realizar la implantacion con los recursos actuales.:
Los recursos, tanto economicos como humanos, son bastante limitados pero
suficientes para realizar la implantacion. Al haber solo una persona ejecutando
la implantacion con un presupuesto tan limitado, existen riesgos de retrasos en
la implantacion. Pero la necesidad del cambios es muy fuerte.
10. Existe personal suficiente para trabajar e introducir los datos en el nuevo
sistema, valorando la cantidad de datos y la comprobacion de los mismos.:
En principio, todos los miembros de la empresa colaboraran en esta tarea. Aun
as se intentara, en la medida de lo posible, automatizar estas tareas.
11. Se ha analizado el impacto que tendra, desde el punto de vista de recursos
humanos, el nuevo sistema en toda su amplitud.:
No habra impacto en este aspecto. La idea es mantener o aumentar el numero
de empleados tras la implantacion, mejorando la eficiencia y control de los
procesos.
el tipo de empresa, actividad, facturacion,
12. Se ha analizado que, segun
compras, etc... es necesario implantar un determinado tipo de sistema.:
41

INICIAL
Sera interesante buscar e implantar una solucion pensada para el sector de
servicio.
13. Se ha tenido en cuenta la existencia de todos los programas de gestion y
bases de datos que existen en la empresa, para ser trasladados al nuevo
sistema de informacion.:
Se recopilaran todos los programas y bases de datos utilizados hasta ahora y

migrarlos al nuevo sistema.
14. Se ha pensado el tiempo de formacion y practicas que deberan invertir
los usuarios y como van a disponer de mas tiempo para realizar su tarea
habitual, y al mismo tiempo, ir adaptandose al nuevo sistema.:
Existiran pocos usuarios y algunos con pocos conocimientos tecnicos pero

otros muy implicados durante la implantacion. Se estima invertir pocas horas
en formacion a los usuarios del sistema.
15. Se ha analizado la cantidad de datos de los programas antiguos que deben
ser correctos para trasladarlos a la nueva aplicacion.:
Existen muchos datos obsoletos, durante la migracion se debera estudiar con

mas profundidad
16. Se ha pensado en la forma de realizar el cambio de sistema, evitando procesos paralelos y trabajos adicionales.:
Se elaborara una estrategia para ejecutar una migracion de datos lo mas rapidamente posible y durante ese proceso se ira usando el sistema antiguo y el
nuevo conjuntamente hasta que el sistema antiguo este totalmente migrado.
Se pensara una forma de no repetir la introduccion de datos entre los dos sistemas.
42

17. Se han definido los objetivos y mejoras a realizar con el nuevo sistema de
informacion a nivel de departamento y puesto de trabajo.:
De manera global se ha establecido como objetivo implantar una estrategia

CRM para acercarse a las necesidades del cliente innovando o mejorando los
procesos actuales en los procesos de trabajo actuales, en las proximos captulos de este proyecto se daran mas detalles.
18. Se ha analizado el nivel de seguridad de datos que se quiere tener en la
la actividad y sector.:
empresa, sabiendo que es variable segun
Los datos que contendra el sistema deben ser protegidos, por lo que debera disponer de un buen control de acceso a esos datos.
19. Se han tenido en cuenta los plazos previos a la instalacion, los plazos de la
misma y la fecha de implantacion final.:
En posteriores captulos se detallara la planificacion y el alcance del proceso

de implantacion, ya que esto dependera de la solucion a implantar.
20. Se ha evaluado la posibilidad de implantar un sistema de informacion por
modulos, eligiendo los mas importantes y dejando el resto para mas adelante.:
Esta posibilidad esta bien contemplada. Dados los escasos recursos disponibles
y el tiempo fijado para la finalizacion de este proyecto, es probable que no haya
tiempo para implantar todas las partes esperadas del sistema. Se debera implantar por modulos las partes del sistema por orden de prioridad, dejando el
sistema abierto a futuras mejoras, tal vez menos prioritarias.
21. Se ha evaluado el coste de adquirir un nuevo hardware, o bien, actualizar
el ya existente.:
43

INICIAL
Dado el escaso presupuesto para la implantacion se intentara, en la medida

de lo posible, utilizar un hosting externo para el sistema. Es posible que se
haga una pequena inversion en hardware si saliera mas rentable que el hosting
externo.
22. Se ha valorado el coste del mantenimiento para el nuevo hardware y software necesarios.:
Se ha estimado un presupuesto para este mantenimiento, dado el escaso numero

de usuarios iniciales, unos 100 euros anuales.
23. Se ha valorado el coste adicional de personal anadido:

nuevas incorporaciones, formacion, practicas y creacion de manuales.:
Se esta considerando la posibilidad, dependiendo de la complejidad del nuevo

sistema, la creacion de manuales, sesiones de formacion y practicas.
24. Se ha analizado quien posee la mejor gestion de conocimiento de la empresa para colaborar en la implantacion del nuevo sistema.:
Los gerentes tienen la mejor gestion del conocimiento para colaborar en el

proyecto.
En esta seccion, ademas de considerar la preparacion de la empresa para la implantacion, se ha obtenido las siguientes conclusiones:
1. La solucion a proponer se basara en una solucion comercial de software libre 1.5.8: Esto se debe a los escasos recursos economicos y de personal. El
software privado 1.5.7, por su elevado coste, queda fuera del alcance de las
posibilidades de la empresa. Y el software a medida, debido al escaso personal cualificado destinado al proyecto, tambien se puede descartar. De entre
44

todo el software libre, convendra escoger entre las soluciones con mas distribuidoras o las que se puedan modificar facilmente ya que se espera realizar
inversiones en modificaciones y soporte a largo plazo.
2. Se debera planificar la migracion de datos, limpiando o clasificando los datos
obsoletos.
3. La solucion tecnologica propuesta debera poder externalizarse en un hosting
externo. Se ha visto en el captulo anterior que existe una necesidad de acceso
de usuarios del exterior de la empresa, como clientes y comerciales. Se puede
plantear inicialmente una pequena inversion en hardware si a corto y medio
plazo, saliera mas rentable que el hosting externo.
45

INICIAL
2.4.
Virtudes y defectos del sistema de informacion

actual
En esta seccion se describiran las virtudes y defectos del sistema de informacion

actual. El objetivo es poder ver los principales defectos del sistema actual para eliminarlos con el nuevo sistema. Las virtudes del sistema actual se intentaran mantener
en el nuevo sistema.
Virtudes
Defectos
Informes muy personalizables
Redundancia de datos
Flexibilidad en procesos y datos
Falta de integridad en los datos

Inexistencia de sistemas de copias de seguridad
Gran diversidad de software a utilizar
Gestion del conocimiento centrado en el gerente
Dificultad para generar informes en papel
Falta de coordinacion con los comerciales
Datos dispersos en ficheros
Cuesta filtrar y agrupar la informacion
Cuadro 2.1: Virtudes y defectos del sistema actual
Las virtudes del sistema, principalmente la flexibilidad, son comunes en las organizaciones sin un sistema integral de informacion 1.5.3. En esta situacion, cada
miembro de la organizacion, bajo ciertos estandares impuestos en la organizacion,
puede guardar y gestionar la informacion como quiera, usando desde papel y lapiz
hasta aplicaciones de software especficas. En una situacion as es relativamente facil
cambiar el formato y el tipo informacion que se almacena. Cuando ya se dispone de
un sistema integral de informacion, al ser sistemas grandes y complejos, suele ser
mas complicado realizar este tipo de cambios en el sistema. Por tanto probablemente
esta virtud se pierda o debilite debido a la naturaleza de los sistemas integrales de
informacion que se planea implantar.
46
ACTUAL
2.4. V IRTUDES Y DEFECTOS DEL SISTEMA DE INFORMACI ON
Entre los defectos del sistema actual resalta la falta de integridad en los datos y
el hecho de introducir varias veces los mismos datos en el sistema. La integracion
de todos los datos de la empresa que se pretende conseguir al implantar un sistema
integral de informacion, ayudara a solucionar el resto de defectos encontrados en
el sistema actual. En el sistema de informacion que se pretende implantar se debera tener en cuenta las metricas y controles necesarios en los procesos para mejorar
el control y coordinacion de los comerciales, facilitar la generacion de informes, la
seguridad, sistemas de copias de seguridad. . .
47

INICIAL
2.5.
Procesos actuales de la empresa
En esta seccion se detallaran los procesos mas importantes de la empresa. La

informacion de esta seccion se ha obtenido a base de realizar entrevistas a los miembros de la empresa. Se empezara detallando todo el proceso que implica la venta,
ejecucion y fidelizacion de un servicio generico de publicidad ofrecido a un cliente.
Este proceso es el mas importante y el que mas valor aporta al cliente. Luego se
continuara detallando otros procesos como la seleccion de comerciales, formacion y
supervision de comerciales. Estos dos u ltimos procesos ayudan a mantener orden y
control sobre la fuerza de venta. Finalmente se terminara detallando los procesos de
recoleccion de clientes potenciales y la gestion de la agenda.
En los proximos apartados se procedera a explicar con mas detalle los procesos.
Se va a utilizar la notacion a notacion BPMN (Business Process Modelling Notation)
propuesta por Javier Celma Marquez en su metodologa [43]. Es recomendable leer
la notacion de sus anexos sobre BPMN, aunque es bastante intuitivo interpretar la
notacion.
2.5.1.
Servicio generico
Un comercial iniciara el proceso de prospeccion. Durante este proceso puede

ocurrir que:
Se termine la prospeccion sin e xito. En este caso finaliza el proceso principal.
Se solicite apoyo tecnico. En cuyo caso un tecnico ejecutara el proceso de
apoyo tecnico.
Se enve una solicitud de presupuesto, acabando el proceso de prospeccion
con e xito.
Se enve informacion sobre una necesidad de un cliente, en cuyo caso el proceso de gestion de presupuestos elaborara un presupuesto a medida para satisfacer esa necesidad.
48
2.5. P ROCESOS ACTUALES DE LA EMPRESA

Si la prospeccion acaba con e xito, entre el departamento tecnico y la administracion se gestionara el presupuesto. Durante la gestion del presupuesto puede ocurrir que:
Se aprueba el presupuesto solicitado por el comercial o se ha elaborado con
e xito un presupuesto a medida viable que satisface la necesidad del cliente. En
cuyo caso se enviara al comercial el documento del presupuesto para que e ste
pueda entregarselo al cliente.
Se soliciten nuevos proveedores necesarios para evaluar los costes del servicio
presupuestado. En este caso el proceso de gestion de proveedores respondera a
esta solicitud.
Se rechace el presupuesto o no se pueda satisfacer una necesidad dada del
cliente. en este caso se informa al comercial de los motivos y se le proporcionan sugerencias para una posible renegociacion del presupuesto o para ofrecer
otras opciones para satisfacer al cliente.
Si PubliFringe no llega a aprobar un presupuesto que solicite el cliente entonces
acaba el proceso principal sin e xito.
En caso contrario, hay un presupuesto en manos del cliente aprobado por PubliFringe. Entonces el comercial realiza un proceso de cierre de venta, en el cual
puede pasar que:
El cliente acepta el presupuesto.
El cliente rechaza el presupuesto y no hay posibilidades de renegociar, en
cuyo caso el proceso de gestion de presupuesto marcara el presupuesto como
no cerrado. En este caso terminara el proceso principal sin e xito.
El cliente rechaza el presupuesto pero solicita un nuevo presupuesto, que queda pendiente de aprobar el nuevo presupuesto en el proceso de gestion de
presupuestos.
49

INICIAL
Se detecte una nueva necesidad del cliente, en cuyo caso el proceso de gestion
de presupuestos elaborara un presupuesto a medida para satisfacer esa necesidad.
Se solicite apoyo tecnico. En cuyo caso un tecnico ejecutara el proceso de
apoyo tecnico.
Solo en el caso en el que el cliente acepta un presupuesto, el proceso principal
continua. En este caso por un lado se ejecutara el proceso de gestion del servicio y
por otro el proceso de gestion de facturas a clientes.
En cuanto se cobra la factura del cliente se inicia el proceso de gestion de comisiones.
Tanto de la gestion del servicio, como de la gestion de comisiones se acaban emitiendo facturas (proveedores necesarios para ejecutar el servicio y las comisiones de
los comerciales respectivamente) que inician el proceso de gestion de proveedores.
El servicio puede ser entregable o continuado. Si el servicio es continuado, se
procedera a su mantenimiento hasta que el cliente decida finalizar el servicio. El
comercial, durante el mantenimiento del servicio, puede realizar un seguimiento con
el cliente para evaluar su satisfaccion y para ofrecer otros servicios.
En cualquier caso, cuando se finaliza un servicio y se han cobrado y pagado todas
las facturas correspondientes, termina el proceso principal. El comercial mantiene el
contacto con cliente para evaluar su satisfaccion y para ofrecer otros servicios.
50
global de un servicio
Figura 2.1: Vision
51

INICIAL
Prospeccion
1. Un comercial, usando sus propios contactos o los contactos proporcionados
por la empresa, contacta con un cliente potencial.
2. El comercial se presenta, presenta a la empresa y ofrece los servicios disponibles.
3. Durante una reunion con un cliente potencial puede ocurrir:
El cliente potencial no tiene interes en los servicios que ofrece la empresa. Dado el caso termina el proceso principal.
El cliente potencial muestra interes, pero no quiere o no puede contratar
los servicios ofrecidos en ese momento o simplemente el cliente potencial no ha tenido tiempo de escuchar los servicios ofertados. En este caso,
se programa otra reunion con el cliente potencial, volviendo al punto 3.
Los comerciales no pueden resolver las dudas tecnicas del cliente potencial. En este caso se solicita apoyo tecnico y el proceso de apoyo tecnico
se iniciara. El comercial debera sincronizar la disponibilidad del cliente
con la de los tecnicos de la empresa. Cuando se haya conseguido programar una reunion se volvera al punto 3, esta vez con apoyo tecnico.
Durante la reunion se prepara un presupuesto para algun servicio. En este
caso el comercial confirma los datos del cliente, se enva una solicitud de
presupuesto al proceso de gestion de presupuestos y termina el proceso
de prospeccion.
Durante la reunion el comercial, el cliente o entre ambos proponen una
necesidad por parte del cliente. En este caso el comercial contacta con
la empresa para explicarles la necesidad del cliente. Si la empresa lograra preparar un presupuesto a medida viable, el comercial recibira ese
presupuesto para entregarselo al cliente. Si el presupuesto se aceptara, el
comercial confirma los datos del cliente, se contacta con la empresa para
confirmarles la aceptacion del presupuesto a medida y termina el proceso de prospeccion. En caso de no conseguir un presupuesto a medida o
52

que el cliente no acepte el presupuesto a medida propuesto, el comercial
puede dar por terminado el proceso de prospeccion o intentar concertar
otra cita, volviendo al punto 3.
53

Figura 2.2: Prospeccion

INICIAL
54

Cierre de presupuesto
1. El comercial espera a que PubliFringe apruebe el presupuesto si e ste necesita
una confirmacion (en caso de ser un presupuesto a medida que no este en el
catalogo de precios entregados a los comerciales autonomos). Si no necesita
confirmacion de la empresa se pasa al punto 6.
2. Si se aprueba el presupuesto, se pasa al punto 6.
3. Si no se aprueba, el comercial recibira informacion sobre los motivos y las
posibilidades de renegociacion. En este caso el comercial contactara con el
cliente e intentara elaborar un nuevo presupuesto.
4. Si no se puede renegociar el presupuesto, se notifica de ello a la empresa y
termina el proceso de cierre de presupuesto.
5. Si se consigue elaborar un nuevo presupuesto o se detecta una nueva necesidad
del cliente, se enva la informacion a la empresa y se vuelve al punto 1.
6. El comercial realiza un seguimiento al cliente para intentar cerrar el presupuesto. Durante este seguimiento puede ocurrir que:
El cliente acepta el presupuesto. En cuyo caso se confirman los datos fiscales del cliente y se enva a la empresa. En este caso finaliza el proceso
de cierre de presupuesto.
El cliente rechaza el presupuesto y no hay posibilidades de renegociar,
en cuyo caso se notificara a la empresa. En este caso termina el proceso
de cierre de presupuesto.
El cliente rechaza el presupuesto pero solicita un nuevo presupuesto o se
detecta una nueva necesidad del cliente, volviendo al punto 5.
Se solicite apoyo tecnico. En este caso se solicita apoyo tecnico y el
proceso de apoyo tecnico se iniciara. El comercial debera sincronizar la
disponibilidad del cliente con la de los tecnicos de la empresa. Cuando
55

INICIAL
se haya conseguido programar una reunion se volvera al punto 6, esta
vez con apoyo tecnico.
El cliente no pueda decidir cerrar el presupuesto en ese momento. En
este caso, se programa otra reunion con el cliente, volviendo al punto 6.
56
Figura 2.3: Cierre de presupuesto
57

INICIAL
Gestion de presupuestos
1. Llega una solicitud de presupuesto o una necesidad de un cliente. En caso de
recibir una necesidad por parte del cliente se transforma en un presupuesto a
medida.
2. Un tecnico analiza si en el servicio estipulado en el presupuesto se requiere
principalmente servicios o productos de algun proveedor.
3. Si se requieren principalmente servicios o productos de algun proveedor se
busca en la base de datos de proveedores si ya existe algun proveedor adecuado
segun las condiciones de precio, tiempo y calidad exigidas en el presupuesto.
4. En el caso en el que se encuentre uno apropiado, se contacta con dicho proveedor para confirmar si mantienen las condiciones. En caso negativo se vuelve
al punto 3. En caso afirmativo ir al punto 8.
5. En caso de no encontrar ningun proveedor apropiado en la base de datos, se
ejecutara en proceso de gestion de proveedores para intentar conseguir algun
proveedor nuevo apropiado. Si la gestion de proveedores encuentra algun proveedor apropiado se vuelve al punto 4, en caso negativo se pasa al punto 6.
6. Si no hacen falta proveedores (o no se encuentran apropiados) se realiza un
analisis del servicio presupuestado para comprobar si es viable su ejecucion
u nicamente con los recursos internos de la empresa.
7. Si no es viable la ejecucion del servicio, se contacta con el comercial indicando el rechazo del presupuesto y proporcionando los motivos y posibles
soluciones o estrategias de renegociacion del presupuesto. Si es viable se pasa
al punto 8.
8. Un administrativo confirma los datos del cliente a traves de su comercial y
elabora un presupuesto formal. Este presupuesto se enva al comercial del
cliente.
9. Luego registra el presupuesto en la base de datos de presupuestos.
58

10. Semanalmente se realiza un seguimiento de presupuestos abiertos en el que
se registran los presupuestos rechazados, se va controlando que el comercial
contacte con el clientes para cerrar el presupuesto y se analizan posibles problemas que tenga el comercial para cerrar el presupuesto.
59
de presupuestos
Figura 2.4: Gestion

INICIAL
60

Apoyo tecnico
1. Llega una solicitud de apoyo tecnico indicando los motivos y temas a tratar.
2. Un tecnico analiza la disponibilidad de los tecnicos.
3. Si no hay disponibilidad se contacta con el comercial comunicandole el rechazo de la solicitud y proporcionandole una estimacion de horas disponibles.
Despues el proceso termina.
4. En el caso en el haya algun tecnico apropiado para el apoyo tecnico se confirma al comercial la asistencia.
5. El tecnico seleccionado analiza el problema o consulta tecnica a resolver y si
es posible prepara una estrategia para vender algun servicio junto al comercial.
6. El da de la reunion programada por el comercial, el tecnico apoya al comercial
durante la reunion con el cliente.
61

Figura 2.5: Apoyo tecnico

INICIAL
62

Gestion proveedores
Este proceso se encarga de la relacion con los proveedores de la empresa. Por un
lado busca y establece relaciones con nuevos proveedores. Por otro lado mantiene la
relacion y se asegura que cumple con los precios y calidad prometidos.
1. Llega una solicitud de nuevos proveedores por una necesidad de la empresa o
por una necesidad especfica por algun presupuesto. Si llega una factura de un
proveedor ir al punto 5.
2. Un tecnico o administrativo realiza un estudio de mercado basandose en las
necesidades de la solicitud y las necesidades de la empresa en busca de proveedores apropiados.
3. Se contacta con los proveedores candidatos para fijar precios, comisiones y establecer relacion de negocios. Todos los proveedores que se consideren apropiados para satisfacer la solicitud e incluso proveedores que puedan ser interesantes para la empresa se registran en la base de datos de la empresa.
4. Se responde a la solicitud de proveedores con el candidato escogido o indicando que se han encontrado proveedores apropiados y termina el proceso.
5. Un administrativo revisa la factura y se asegura que la calidad y el precio del
servicio o producto provedo sean los acordados.
6. Si la factura es de domiciliacion se revisa que el pago se haya realizado correctamente.
7. Si han ocurrido errores en la domiciliacion o en la calidad del producto o
servicio provedo o en los precios, se contacta con el proveedor para intentar
resolver los errores. En este caso se registran los errores en la base de datos de
los proveedores para tener en cuenta el error en futuras operaciones y asegurarse que el error se ha corregido o compensado.
8. Si la factura es de transferencia y no ha habido errores se realiza la transferencia pocos das antes de su vencimiento.
63

INICIAL
9. Si no han ocurrido errores o los errores ya han sido solucionados y registrados,
termina el proceso.
64
proveedores
Figura 2.6: Gestion
65

INICIAL
Gestion de servicio
1. Llega una solicitud de servicio, especificado en un presupuesto aceptado.
2. Un gerente evalua que recursos internos de la empresa se necesitan para su
ejecucion y asigna a un tecnico el trabajo.
3. Se le proporciona al tecnico toda la informacion y recursos necesarios para
su ejecucion. Si fuera necesario se contratan los productos o servicios de los
proveedores externos necesarios para la ejecucion del servicio.
4. Si el tecnico necesitara informacion mas tecnica o especfica sobre el cliente,
contactara con el cliente para obtener la informacion.
5. El tecnico trabaja para realizar el servicio.
6. Si el servicio es entregable se entrega al cliente y termina el proceso. En caso
contrario se mantiene el servicio hasta que el cliente decida prescindir del
servicio.
66
de servicio
Figura 2.7: Gestion
67

INICIAL
Gestion de facturas de cliente
1. Llega un aviso de presupuesto aceptado.
2. Un administrativo busca el presupuesto en la base de datos y lo marca como
aceptado.
3. Confirma con el comercial los datos fiscales del cliente.
4. Se registra la factura en la base de datos de facturas.
5. Elabora una factura formal para el cliente y en la fecha acordada en el presupuesto se enva la factura.
6. Se va controlando si la factura emitida se cobra. Si no se cobrara la factura, el
administrativo contactara con el comercial para comunicarselo y el comercial
contactara con el cliente para intentar solucionar el impago.
7. Una vez la factura esta pagada se comprueba que sea e l u ltimo pago estipulado en la factura (la factura se paga en multiples pagos). En caso afirmativo
terminara el proceso. En caso negativo se pasara al punto 5.
68
de facturas de cliente
Figura 2.8: Gestion
69

INICIAL
Gestion de comisiones
1. Hay nuevas facturas cobradas asociadas a un comercial.
2. A final del mismo mes, un administrativo comprueba las facturas asociadas a
ese comercial y se calcula la comision.
3. Se confirma con el comercial que la comision es correcta.
4. Si no hay errores y el comercial esta conforme entonces el comercial emitira una factura a la empresa como proveedor con la comision pactada. As terminara el proceso.
70
de comisiones
Figura 2.9: Gestion
71

INICIAL
2.5.2.
Seleccion de comerciales
1. Surge una necesidad de nuevos comerciales.

2. Un gerente o un supervisor comercial elaboran una estrategia de seleccion. En
e sta estrategia, se pueden obtener criterios de seleccion de candidatos, numero
de nuevos comerciales necesarios, medios de publicacion de ofertas, preguntas
para las entrevistas, condiciones del puesto de trabajo, margen de negociacion
con los candidatos. . .
3. Los gerentes estudian la estrategia propuesta y la aprueban si la ven apropiada.
Si no la aprobaran terminara el proceso principal.
4. El supervisor comercial afectado realiza un proceso de publicacion de la oferta
de trabajo basandose en la estrategia a seguir.
5. Tras el proceso de publicacion de la oferta de trabajo se obtiene un conjunto
de candidatos que pasaran un proceso de seleccion tras el cual se seleccionan
y contratan nuevos comerciales.
6. Si tras el proceso de seleccion no se ha cubierto la necesidad entonces se
vuelve al punto 4. En caso contrario finaliza el proceso principal.
72
de comerciales
Figura 2.10: Seleccion
73

INICIAL
Publicacion oferta
1. Un supervisor comercial publica ofertas de trabajo usando los medios pensados en la estrategia elaborada para la seleccion de comerciales. Los requisitos
y criterios solicitados en la publicacion tambien variaran en funcion de la estrategia a seguir.
2. A medida que llegan currculum vtae se va realizando un primer filtro en base
al currculum vtae de los candidatos registrando los seleccionados en una base
de datos.
3. Se espera hasta la fecha de plazo para la inscripcion o hasta que haya suficientes candidatos que hayan pasado el primer filtro.
4. Si tras la fecha de cierre no hay suficientes candidatos se vuelve al punto 1.
En caso contrario el proceso finaliza.
74
oferta
Figura 2.11: Publicacion
75

INICIAL
Seleccion
1. En un segundo filtro, un supervisor comercial contacta por telefono con los
candidatos que han pasado el primer filtro para presentarles la empresa y explicarles las condiciones del puesto de trabajo. Durante e stas llamadas la empresa puede decidir que un candidato no pasa el segundo filtro. Tambien el
propio candidato podra rechazar el puesto.
2. Se programan entrevistas con los candidatos que han pasado el segundo filtro.
Pueden requerirse varias entrevistas por candidato.
3. Para cada candidato pendiente:
4. Si el candidato acepta el puesto y la empresa lo aprueba, se programa una
sesion formativa y de firma de contrato. Se pasa al punto 6.
5. Si el candidato rechaza la oferta o la empresa decide no aceptarlo, se pasa al
punto 6.
6. Si no quedan candidatos pendientes termina el proceso.
7. Basandose en la estrategia de seleccion, se determina si el proceso de seleccion
debe continuar. En caso negativo finaliza el proceso.
8. Considerar si se requieren cambios en las condiciones del puesto ofrecido e
incluso volver a reconsiderar candidatos filtrados si fuera necesario. Volver al
punto 3.
76

Figura 2.12: Seleccion
77

INICIAL
2.5.3.
Formacion y supervision de comerciales
1. Si el supervisor comercial recibe nuevos contactos de clientes potenciales, los

redistribuye entre sus comerciales en funcion de su zona de actividad, merito. . .
2. Cada 15 das cada comercial debe enviar a su supervisor comercial un informe
de actividad en un formulario estandar propuesto por la empresa o en uno
propio.
3. El supervisor recopila esa informacion y la guarda en una base de datos.
4. El supervisor analiza la informacion sobre las actividades de sus comerciales:
prospeccion, cierre de presupuestos, problemas, dudas. . . para encontrar problemas o puntos donde mejorar.
5. Cada 2 semanas (o cada mes, para comerciales de fuera de Barcelona) el supervisor comercial convoca a sus comerciales a una reunion para intentar solventar los errores o problemas detectados. En las reuniones tambien se realizan
sesiones de formacion comercial.
78
y supervision
de comerciales
Figura 2.13: Formacion
79

INICIAL
2.5.4.
Recopilar clientes potenciales
1. Si surge una necesidad de nuevos clientes potenciales, un supervisor comercial

realiza busquedas por internet, gremios, anuncios. . .
2. Si el supervisor comercial, gerente o cualquier miembro de la empresa encuentra algun contacto de cliente potencial se registra su informacion en una
base de datos de clientes potenciales.
3. Estos contactos encontrados se distribuyen entre los supervisores comerciales
en funcion de la zona de accion de sus comerciales, meritos. . .
80
Figura 2.14: Recopilar clientes potenciales
81

INICIAL
2.5.5.
Contabilidad
1. Cada semana un administrativo solicita a los empleados los tickets de gastos

de empresa para registrarlos en la contabilidad. Ademas, se revisa tanto el
correo fsico como electronico. Si han llegado facturas de proveedores nuevas
o si se han emitido facturas a clientes nuevas, se contabilizan.
2. Cada 3 meses se enva a una gestora la informacion registrada de contabilidad,
facturas de clientes, proveedores, gastos. . .
82
Figura 2.15: Contabilidad
83

INICIAL
2.5.6.
Gestion de agenda
1. Cada miembro de la empresa gestiona su disponibilidad con sus propias agendas o alguna agenda compartida.
2. En cuanto llega una solicitud de disponibilidad, el solicitado comprueba su
agenda y registra los eventos a los que ha sido solicitado: citas con clientes,
reuniones. . . En caso de no estar disponible se comunica al solicitante.
84
de agenda
Figura 2.16: Gestion
85

INICIAL
2.6.
Conclusiones
En este captulo se ha analizado la empresa, se ha entrevistado a sus empleados

para detallar el problema que va a solucionar este proyecto. En esta fase tambien
se ha guiado y asesorado a los gerentes de la empresa sobre las implicaciones y
consideraciones a tener durante la implantacion de un nuevo sistema de informacion
1.5.3. Para ello se ha aplicado como base de este analisis parte de una metodologa
propuesta por Javier Celma Marquez [43] para la seleccion de un ERP en una microempresa.
De este analisis de la empresa se han extrado las principales necesidades para un
cambio de sistema de informacion:
3. Se quieren mejorar los sistemas de trabajo, los procesos existentes en la actualidad y los flujos intermedios de datos.
y actualmente no la tienen
Tambien se ha dado a conocer a los gerentes una serie de consideraciones a tener
en cuenta en una implantacion de un sistema de informacion 1.5.3. De ah se han
obtenido las siguientes restricciones para el proyecto:
1. La solucion a proponer se basara en una solucion comercial de software libre:
Esto se debe a los escasos recursos economicos y de personal. El software privado 1.5.7, por su elevado coste, queda fuera del alcance de las posibilidades
de la empresa. Y el software a medida, debido al escaso personal cualificado
destinado al proyecto, tambien se puede descartar.
86
2.6. C ONCLUSIONES
2. Se debera planificar la migracion de datos, limpiando o clasificando los datos
obsoletos.
3. La infraestructura de hardware se intentara externalizar segun la solucion escogida en los siguientes captulos. Si saliera mas economico disenar e implementar una infraestructura propia no se descarta esta opcion.
Tambien se han analizado las virtudes y defectos del sistema actual para eliminar los
defectos con el nuevo sistema y mantener, en la medida de lo posible, las virtudes.
Los defectos principales son la redundancia de datos y su falta de integridad, ya
que tambien son causa tambien de otros defectos encontrados durante el analisis.
Tambien han surgido problemas debido a la falta de sistemas de copias de seguridad.
Se han perdido datos o se han estropeado ordenadores que contenan datos que al
trabajar sin ellos han supuesto un retraso.
Por u ltimo se han estudiado los principales procesos de la empresa. Este estudio
nos servira a la hora de proponer una solucion para intentar mejorar la forma de
proceder actual o incluso innovar con algun proceso nuevo.
87
Captulo 3
Propuesta de innovacion y mejora

En en captulo anterior se ha analizado a la empresa. De e se captulo se han
obtenido un conjunto de problemas y necesidades que en e ste captulo trataremos
para buscar una solucion que satisfaga a la empresa y no incumpla las restricciones
para el proyecto encontradas en el captulo anterior. A lo largo de este captulo, se
aprovecharan partes de la metodologa propuesta por Javier Celma Marquez [43].
3.1.
Problema a revolver
En esta seccion se resumiran los problemas y restricciones encontrados en el

analisis del captulo anterior.
Principales problemas detectados:
89
Y MEJORA
C API TULO 3. P ROPUESTA DE INNOVACI ON
y actualmente no la tienen.
Principales defectos detectados:
1. Redundancia de datos.
2. Falta de integridad en los datos.
3. Inexistencia de sistemas de copias de seguridad.
4. Gran diversidad de software a utilizar.
5. Gestion del conocimiento centrado en el gerente.
6. Dificultad para generar informes en papel.
7. Falta de coordinacion con los comerciales.
8. Datos dispersos en varios ficheros.
9. Dificultad para filtrar y agrupar la informacion.
Las gran mayora de problemas y defectos encontrados pueden solucionarse utilizando un sistema de informacion integrado 1.5.3, como por ejemplo un ERP 1.5.4.
Uno de estos sistemas correctamente adaptado a la empresa no solo puede solucionar
los problemas y defectos mencionados, sino que puede llegar a mejorar en gran medida los procesos actuales mejorando la eficiencia en las tareas y comprimiendo los
procesos horizontalmente e incluso verticalmente.
Como uno de los objetivos estrategicos de la empresa es aplicar una estrategia
CRM 1.5.5, convendra tambien implantar sistema de informacion integrado que
pudiera dar soporte a dicha estrategia.
El desarrollo completamente a medida de un sistema de informacion integrado
queda descartado debido a que no hay suficiente tiempo ni recursos para ello. Se
90
3.2. O BJETIVOS
va a buscar una solucion comercial que se ajuste a las necesidades de la empresa.
Si fuera necesario, la solucion comercial debera poder modificarse para adaptar sus
funcionalidades a la empresa.
Tas un estudio entre las soluciones comerciales de software libre 1.5.8 y software
propietario 1.5.7, se ha determinado que una solucion comercial de software propietario 1.5.7 de ERP/CRM queda descartada debido a su elevado coste de adquisicion,
de adaptacion a la empresa y de mantenimiento. Los precios de este tipo de software
queda fuera del presupuesto para el proyecto.
3.2.
Objetivos
Una vez determinados los problemas que deben solucionarse, se pueden extraer
los objetivos que debe cumplir la propuesta a planificar. Los objetivos de la propuesta tambien deberan estar alineados con los objetivos estrategicos de la empresa y del
proyecto.
Objetivos de la propuesta:
1. Implantar un nuevo sistema de informacion que de soporte a la empresa.
2. Dar soporte a la estrategia CRM de la empresa.
3. Mejorar los procesos de la empresa.
4. Innovar en los procesos y las herramientas de trabajo.
5. Debe soportar un aumento de clientes, comerciales, empleados y ventas.
3.3.
Estructura de la propuesta
En esta seccion se divide la propuesta en dos bloques:
91
Y MEJORA
Mejora e innovacion de procesos
Innovacion tecnologica
Cadena de valor
Alternativas disponibles
Adaptacion de procesos al nuevo sistema de informacion
Seleccionar una alternativa

Arquitectura del sistema
Metodologa de implantacion y des
de la propuesta
Cuadro 3.1: Estructuracion
3.4.
Innovacion tecnologica
En esta parte de la propuesta se detalla la parte de la propuesta que tiene que ver
con la empresa y su cultura organizativa. Un proceso de implantacion de un sistema
de informacion es largo y costoso. Por eso es interesante aprovechar para aplicar
cambios y mejoras en la empresa ya que, una vez el nuevo sistema de informacion
este implantado, el sistema de informacion puede quedar muy cerrado para aceptar
cambios y mejoras posteriores. En el segundo bloque se detalla la parte tecnologica
de la propuesta: Que tecnologas usar? Bajo que arquitectura? Como implantar
el sistema?.
Se propondra una solucion de software y arquitectura sobre la que funcionara el
sistema. Tambien se mostraran las alternativas y la seleccion de la propuesta final.
Tambien se propondra una metodologa para el desarrollo de la implantacion.
3.4.1.
Alternativas disponibles
En esta parte se recopilara las alternativas para implantar el nuevo sistema de

informacion 1.5.3. Tras el analisis inicial a la empresa y durante el estudio de la
propuesta se han restringido las posibles alternativas. Como ya se ha comentado anteriormente una propuesta para este proyecto sera una solucion comercial ya que
se descarto elaborar una solucion completamente a medida. Hay muchas soluciones
comerciales en el mercado pero en el caso de este proyecto tambien se descartaran
92
TECNOL OGICA
3.4. I NNOVACI ON
las soluciones comerciales de software privado 1.5.7 debido a su elevado precio y
a que no suelen permitir modificaciones y adaptaciones con personal interno de la
empresa.
Se ha realizado un estudio de mercado preliminar, filtrando las restricciones mencionadas anteriormente. Tambien se han buscando, a grandes rasgos, soluciones que
se ajusten a la empresa. Estas soluciones son las alternativas encontradas acompanadas de una breve descripcion:
Abanq:
AbanQ es un paquete software ERP 1.5.4 creado por InfoSiAL en el que participan colaboradores de todo el mundo. AbanQ es multiplataforma y es software ERP 1.5.4 de codigo libre 1.5.8 profesional, encontrandose ya en algunas
de las mas importantes distribuciones de Linux. InfoSiAL es una empresa informatica dedicada a la investigacion y desarrollo de software, servicios de
Internet, servicios informaticos y formacion. Existen modulos con diversas
funcionalidades (incluidas funcionalidades CRM 1.5.5) a la venta a un precio
asequible. Ademas permite la creacion de nuevos modulos propios. Tambien
cabe destacar que el alumno responsable de la implantacion ya ha realizado
una implantacion y ha desarrollado modulos con Abanq.
aDempiere:
ADempiere es un proyecto guiado por la comunidad la cual desarrolla y soporta una solucion de codigo abierto para negocios del mismo nombre, la cual
ofrece la funcionalidad de Planificacion de recursos empresariales, Administracion de la Relacion con los Clientes y Administracion de la Cadena de
Suministro (derivado de sus siglas en ingles: ERP 1.5.4, CRM 1.5.5, SRM
1.5.6 respectivamente).
CK-ERP:
93
Y MEJORA
CK-ERP es un programa ERP 1.5.4 y CRM 1.5.5 de codigo libre distribuido bajo licencia GNU/GPL, que consta de 17 modulos. Su interfaz online, es
bastante simple pero es facilmente adaptable a las necesidades de cualquier
empresa.
Compiere:
Compiere es una aplicacion para negocios de codigo abierto, ERP 1.5.4 y
CRM 1.5.5 destinada para las empresas de pequeno y mediano tamano y con
una gran expansion en el mercado anglosajon en los u ltimos anos. Compiere
esta desarrollada usando J2EE. La aplicacion y el codigo fuente se provee
sobre la base de distribucion libre bajo una licencia basada en la licencia publica Mozilla. Puede ser configurada y extendida dentro de la aplicacion y por
medio de la adicion de componentes modulares. La documentacion y el soporte solo estan disponibles mediante pago.
Dolibarr:
Dolibarr ERP/CRM es un software completamente modular para gestion de
PYMES, profesionales independientes, auto emprendedores o asociaciones.
En terminos mas tecnicos, es un ERP 1.5.4 y CRM 1.5.5. Es un proyecto
OpenSource que se ejecuta en el seno de un servidor Web. Proyecto basado en
un servidor WAMP, MAMP o LAMP: Apache, MySQL, PHP. Destaca frente
a otras soluciones comerciales por su busqueda de simplicidad.
ERP5:
ERP5 es un software completo ERP 1.5.4 que incluyen funcionalidades de
CRM 1.5.5, SRM 1.5.6, gestion de la produccion (MRP), gestion de diseno de
producto (PDM), contabilidad, recursos humanos y el comercio electronico.
KEME-Contabilidad:
94
TECNOL OGICA
3.4. I NNOVACI ON
Programa de contabilidad multiplataforma. Genera los libros obligatorios, libros del IVA, registros de amortizaciones. Plan de cuentas personalizable,
asientos automaticos. . .
OpenBravo:
Openbravo ERP Comunity Edition es una aplicacion que puede ser accedida
como codigo abierto pero con muchas restricciones y una version de codigo
propietario con todas las funcionalidades activas, de gestion empresarial del
tipo ERP 1.5.4 destinada a empresas de pequeno y mediano tamano. La estructura de datos de la aplicacion esta basada originalmente en una version antigua
de Compiere, proyecto con el cual no mantiene compatibilidad alguna.
OpenERP:
OpenERP es un sistema ERP 1.5.4 y CRM 1.5.5. Tiene componentes separados en esquema Cliente-servidor. Anteriormente se le conocio como TinyErp. Entre sus caractersticas estan la contabilidad analtica, contabilidad financiera, gestion de almacenes/inventario, gestion de ventas y compras, automatizacion de tareas, campanas de marketing, ayuda tecnica y punto de
venta. Dentro de la construccion misma del software se hace uso intensivo
de flujos de trabajo que se pueden integrar con los modulos.
OpenTaps:
OpenTaps Open Source ERP + CRM es un sistema ERP 1.5.4 y CRM 1.5.5,
de libre distribucion. El sistema esta disenado para reunir todos los aspectos
de una compana, desde los clientes hasta el inventario y la contabilidad, desde
tiendas en linea hasta el taller y el almacen.
Libertya:
Libertya es un software de gestion ERP 1.5.4 de software libre 1.5.8. Ha sido
95
Y MEJORA
disenado poniendo foco en las empresas del segmento Pyme. Soporta, entre
otras cosas, la gestion de productos, precios, almacenes, contabilidad. . .
Phreebooks:
PhreeBooks se ha desarrollado como un ERP 1.5.4 de codigo abierto basado
en la web para pequenos negocios. El objetivo de PhreeBooks es proporcionar
una solucion de bajo costo para las pequenas empresas.
SaltOS:
SaltOS es su solucion Cloud Computing de Gestion Empresarial definitiva.
Integra las funcionalidades de CRM 1.5.5 y ERP 1.5.4. Ademas esta licenciado como software libre bajo la licencia GPL-3.0.
SugarCRM:
SugarCRM es un sistema CRM 1.5.5 basado en LAMP (Linux-Apache-MySQLPHP), desarrollado por la empresa SugarCRM. Tiene tres versiones, una de
ellas libre y otras dos versiones con componentes no-libres y con un costo
por usuario. SugarCRM es una aplicacion CRM muy completa para negocios
de distinto tamano. Esta disenada para facilitar la gestion de ventas, oportunidades, contactos de negocios y mas. A partir de la version 4.5, tambien
esta disponible una version que permite utilizar SQL Server como base de
datos; y la empresa ha firmado acuerdos con, Microsoft para poder expandir
su mercado sobre servidores con Windows.
Tryton:
Tryton es una plataforma informatica general sobre la cual se desarrolla una
solucion de negocios ERP 1.5.4 por medio de los modulos de Tryton. La
plataforma junto con los modulos oficiales estan cobijados por la licencia
96
TECNOL OGICA
3.4. I NNOVACI ON
GPLv3. Tryton se origino a partir de la version 4.2 de TinyERP (que posteriormente se rebautizo como openERP).
vTiger:
VTiger CRM es una aplicacion de codigo abierto y PHP para la gestion de
relaciones con clientes, una solucion realmente potente y gratuita que surgio a
partir del software de SugarCRM. VTiger esta pensado para pequenas y medianas empresas.
WebERP:
WebERP se trata de un proyecto de codigo libre, orientado a ofrecer a pequenas
y medianas empresas, una aplicacion potente y sostenible, que les permita
ahorrar recursos y costos, a la hora de implementar un sistema ERP 1.5.4.
xTuple PostBooks:
PostBooks es un sistema integrado de informacion 1.5.3 del tipo ERP 1.5.4/CRM
1.5.5 de software libre 1.5.8. Esta desarrollada usando base de datos PostgreSQL, y el framework Qt en C++. Lo ha desarrollado la empresa xTuple,
que tambien es autora de otras ediciones xTuple ERP de pago.
3.4.2.
Seleccionar una alternativa
En esta parte se va a profundizar en las diferentes alternativas con el fin de seleccionar la alternativa que mejor se ajuste a las necesidades de PubliFringe. Para
conseguir que la alternativa escogida sea apropiada se necesita conocer y priorizar
los criterios que se van a usar para seleccionar dichas alternativas. Estos criterios de
seleccion se deben ajustar a las necesidades de PubliFringe y nos ayudaran a estimar
que alternativa es mas apropiada segun dichas necesidades. A continuacion se utilizara una metodologa extrada de la propuesta de Javier Celma Marquez [43] para
identificar y priorizar los criterios. Se basa en tecnicas y herramientas para la toma
97
Y MEJORA
de decisiones multicriterio. Esto ayudara al equipo a tomar una mejor decision sobre
que alternativa elegir.
Tras una entrevista del alumno con los gerentes de la empresa se dibujaron 4
arboles de valores. La explicacion sobre como construir este a rbol valorado para
una toma de decisiones multicriterio esta incluido en la propuesta de Javier Celma
Marquez [43]. Las hojas de estos arboles representan los criterios que se deben evaluar en cada alternativa. Los criterios estan clasificados usando la raz y los nodos
intermedios.
La prioridad o peso de un criterio corresponde a la importancia del mismo dentro
del grupo de criterios identificados. Para obtener la prioridad o peso de cada criterio
se han de multiplicar los pesos de todos los nodos que forman el camino entre la raz
de a rbol y la hoja que representa el criterio.
Los principales grupos de criterios corresponden con las races de los arboles:
1. Criterios funcionales: Este grupo engloba los criterios que evaluaran el grado
de soporte de la alternativa con las funcionalidades requeridas y su capacidad
de adaptacion a nuevas funcionalidades.
2. Criterios tecnicos: Estos criterios evaluan las necesidades tecnicas de la alternativa.
3. Criterios economicos: Estos criterios evaluan los costes que suponen estas
alternativas.
4. Criterios de amplitud y localizacion: Estos criterios evaluaran el grado de
madurez de la alternativa y el soporte (proveedores) que hay disponibles.
Los pesos que se han otorgado a cada grupo de criterios tras la entrevista con los
gerentes es de 55 % 20 % 15 % y 10 % respectivamente.
98
TECNOL OGICA
3.4. I NNOVACI ON
Esta distribucion de peso tiene parte de subjetividad y esta consensuada entre el
alumno y los gerentes. No existen distribuciones de pesos correctas o incorrectas.
Depende de las necesidades de cada caso y un toque de subjetividad por parte de los
decisores.
En el caso que se esta tratando en este proyecto, esta distribucion refleja la importancia de que la alternativa escogida se adapte lo maximo posible a las necesidades
de PubliFringe y que facilite la introduccion de modificaciones propias. Eso minimizara y facilitara el desarrollo a media sobre la alternativa escogida.
A continuacion se muestran los a rboles de valores y la lista de criterios ordenada
por prioridad:
99
Y MEJORA
de SI para PubliFringe. Criterios Funcionales

Figura 3.1: Criterios de seleccion
100
TECNOL OGICA
3.4. I NNOVACI ON
de SI para PubliFringe. Criterios Tecnicos
101
Y MEJORA
de SI para PubliFringe. Criterios Economicos

y Amplitud
102
TECNOL OGICA
3.4. I NNOVACI ON
Las alternativas que se van a evaluar ya han pasado varios filtros, como las restricciones encontradas durante el analisis del captulo anterior, como la eleccion de
incluir solo soluciones de software libre y economicas. Durante la investigacion de
mercado con la que se han encontrado las alternativas, tambien se han ido descartando alternativas que, de manera subjetiva o intuitivamente, se notaba que no eran aptas
para ser la solucion comercial escogida. Un ejemplo de sera las soluciones comerciales demasiado verticales que no coinciden con las necesidades de PubliFringe,
soluciones poco maduras, soluciones en otros idiomas. . .
Por eso hay que destacar que los criterios con menor peso no significa que no
sean importantes. Los criterios se usaran principalmente para comparar alternativas
que ya de por s son aptas para ser escogidas. En otras palabras, ayudaran a tomar
una mejor decision (o al menos una decision mas precisa respecto a las necesidades
de PubliFringe que se han detectado) sobre la alternativa a escoger.
La alternativa escogida no tiene porque cubrir exactamente todas las necesidades
de PubliFringe (aunque idealmente se quiere que la alternativa las cubra). La alternativa podra ser modificada o adaptada mas adelante para cubrir las necesidades
que falten. El objetivo es escoger una alternativa que inicialmente cubra el mayor
conjunto posible de necesidades (preferiblemente las necesidades mas importantes)
para evitar en la medida de lo posible el coste del desarrollo a medida.
103
Y MEJORA
A continuacion la lista de criterios ordenada por prioridad o peso que se usaran
para evaluar las alternativas:
Criterios especficos
Peso
Gestion de clientes
0,0792
Adaptacion a procesos crticos
0,07425
Facilidad para anadir desarrollos propios
0,06875
Informes personalizables
0,06875
Documentacion para desarrolladores
0,064
Gestion de proveedores
0,0594
Gestion de comerciales
Areas
soportadas
0,0594
0,05775
Coste de las actualizaciones
0,054
Coste del soporte
0,054
Online/Offline
0,05
N distribuidores cercanos
0,05
Interaccion con otros sistemas
0,033
Coste de la implantacion
0,03
N implantaciones
0,03
Control de usuarios
0,025
Backups
0,025
Gestion de facturas
0,02475
0,02475
N distribuidores
0,02
Documentacion para usuarios
0,016
Coste de la Formacion
0,012
Multiplataforma
0,01
Hardware Clientes
0,01
Cuadro 3.2: Lista ordenada de criterios segun

su prioridad
104
TECNOL OGICA
3.4. I NNOVACI ON
A continuacion se detalla cada criterio:
1. Adaptacion a procesos crticos: Este criterio evalua que los puntos fuertes de
las alternativas se adapten a los procesos crticos de la empresa. Los procesos
crticos son aquellos que se centran en la base del negocio. Es importante ver
como se adaptan a e stos para que al implantar una alternativa no se pierda
flexibilidad.
2. Gestion de clientes: Ya se ha visto anteriormente que uno de los puntos
fuertes y objetivos de mejora de PubliFringe son los clientes. Por tanto, es
especialmente interesante que la alternativa escogida ofrezca un buen soporte
a la gestion de clientes de PubliFringe. Este criterio evalua el grado de satisfaccion de PubliFringe al soporte que ofrece la alternativa a la gestion de
clientes.
3. Documentacion para desarrolladores: Este criterio evalua la cantidad, y calidad de documentacion tecnica y la comunidad de desarrolladores de la alternativa a evaluar. Este criterio es interesante para facilitar el desarrollo a media
sobre la alternativa.
4. Areas
soportadas: Este criterio evalua cuantas a reas o funcionalidades de la
empresa son cubiertas por la alternativa. Este criterio nos ayuda a reducir la
necesidad de desarrollos propios sobre las alternativas.
5. Facilidad para anadir

desarrollos propios: Este criterio evalua el nivel de
dificultad de desarrollo sobre la alternativa y la facilidad para anadir nuevas
funcionalidades a la alternativa sin comprometer las funcionalidades ya existentes ni romper futuras versiones o mejoras de la alternativa.
6. Informes personalizables: Evalua la capacidad y facilidad para elaborar informes personalizados.
7. Coste de actualizaciones: Evalua el coste de mantenimiento de las actualizaciones de la alternativa.
105
Y MEJORA
8. Coste de soporte: Evalua el coste del soporte de los proveedores de la alternativa en caso de que fueran necesarios.
9. Gestion de comerciales: Se ha visto anteriormente la importancia de los comerciales en PubliFringe. Este criterio evalua el grado de satisfaccion de PubliFringe al soporte que ofrece la alternativa a la gestion de comerciales.
10. Online/Offline: Este criterio evalua si la alternativa es online u offline. En
PubliFringe existe la necesidad de que parte de la informacion que contenga
el nuevo sistema debera ser accesible desde cualquier parte (por los comerciales autonomos). Una alternativa online facilitara el acceso ya que suelen
ser usados mediante navegadores web.
11. N distribuidores cercanos: Esta alternativa evalua la cercana respecto a la
empresas de los distribuidores del software a la hora de solicitar soporte.
12. Interaccion con otros sistemas: Evalua la capacidad o facilidad de interactuar con otros sistemas como el de impresion, herramientas ofimaticas, servidor
de correo. . .
13. Coste de la implantacion: Evalua el coste de la implantacion incluyendo el
coste de licencia, arquitectura. . .
14. N implantaciones: Este criterio es una manera de evaluar la madurez de la
alternativa. Que haya habido numerosas implantaciones hace suponer que el
software a sido probado con frecuencia y por tanto se han corregido fallos. Si
hay numerosas empresas que lo usan da que pensar que el SII 1.5.3 funciona.
15. Documentacion para usuarios: Este criterio evalua la cantidad, y calidad
de documentacion de usuario disponible y la comunidad de usuarios de la
alternativa a evaluar. Este criterio es interesante para facilitar la formacion del
personal que va a usar el nuevo sistema.
16. Gestion de facturas: Este criterio evalua el soporte que da la alternativa a las
necesidades de PubliFringe en la gestion de facturas.
106
TECNOL OGICA
3.4. I NNOVACI ON
17. Gestion de presupuestos: Evalua el soporte que da la alternativa a las necesidades de PubliFringe en la gestion de presupuestos.
18. Gestion de proveedores: Evalua el soporte que da la alternativa a las necesidades de PubliFringe en la gestion de proveedores.
19. Coste de la formacion: Evalua el coste de la formacion de usuarios y desarrolladores de la alternativa.
20. Multiplataforma: Evalua sobre que plataformas puede utilizarse el sistema y
si se ajusta a las necesidades de la empresa.
21. Hardware Clientes: Evalua los requisitos de hardware puede utilizar el sistema y si se ajusta a las necesidades de la empresa.
22. N Distribuidores: Evalua el numero de distribuidores en el mundo de esta
alternativa. Un gran numero es una forma de medir el e xito y la madurez de la
alternativa
23. Control de usuarios: Evalua el soporte de la alternativa para el control de
los usuarios. En el caso de PubliFringe se debe controlar el acceso de los
comerciales autonomos al sistema y restringirles el acceso exclusivamente a
los datos que necesiten.
24. Backups: Evalua el soporte a la realizacion de copias de seguridad.
Una vez identificados y pesificados los criterios, se procede a evaluar las alternativas: Abanq, aDempiere, CK-ERP, Compiere, Dolibarr, ERP5, KEME-Contabilidad,
OpenBravo, OpenERP, OpenTaps, Libertya, Phreebooks, SaltOS, SugarCRM, Tryton, vTiger, WebERP, xTuple PostBooks.
Hay demasiadas alternativas como para profundizar en todas ellas, sera demasiado costoso en tiempo y recursos. Por tanto, se procedera a pasar varios filtros hasta
que queden entre 2 y 4. Se buscara que los filtros aplicados descarten rapidamente
las peores alternativas para PubliFringe. Las alternativas finalistas se investigaran y
107
Y MEJORA
evaluaran en profundidad segun los criterios identificados.
La secuencia de filtros que se aplicaran consisten en investigar las alternativas y
encontrar las que no cumplan o no satisfagan lo suficiente un determinado criterio.
El primer filtro usara el criterio con mas prioridad o peso (Gestion de clientes), si
no se han podido descartar suficientes alternativas se aplicara el siguiente filtro. El
siguiente filtro usara el siguiente criterio con mayor peso (Adaptacion a procesos
crticos) y as sucesivamente hasta que se haya reducido lo suficiente la lista de alternativas o no queden mas criterios.
A continuacion se aplican los filtros:
Filtro 1: Gestion de clientes
KEME-Contabilidad no pasa el filtro debido a que es un SI basicamente de
contabilidad. Su gestion de clientes es insuficiente para PubliFringe. aDempiere tampoco cumple las expectativas en cuanto a gestion de clientes.
Quedan: Abanq, CK-ERP, Compiere, Dolibarr, ERP5, OpenBravo, OpenERP, OpenTaps, Libertya, Phreebooks, SaltOS, SugarCRM, Tryton, vTiger,
WebERP y xTuple PostBooks.
Filtro 2: Adaptacion a procesos crticos
Compiere, ERP5, OpenTabs, Phreebooks, Tryton y xTuple PostBooks no pasan
el filtro debido a que no soportan localizacion espanola o lo hacen de manera insuficiente (no solo traduccion, sino contabilidad, localidades, impuestos,
temas culturales. . . ).
Quedan: Abanq, CK-ERP, Dolibarr, OpenBravo, OpenERP, Libertya, SaltOS,
SugarCRM, vTiger y WebERP.
Filtro 3: Facilidad para anadir

desarrollos propios
Aunque unas alternativas mejor que otras, todas pasan este filtro.
108
TECNOL OGICA
3.4. I NNOVACI ON
Filtro 4: Informes personalizables
Todas pasan este filtro aunque algunas alternativas destacan por sus soluciones
a nivel de usuario.
Filtro 5: Documentacion desarrolladores
En este filtro SaltOS y CK-ERP no pasa por tener una documentacion inexistente o insuficiente.
Quedan: Abanq, Dolibarr, OpenBravo, OpenERP, Libertya, SugarCRM, vTiger
y WebERP.
Filtro 6: Gestion de proveedores
SugarCRM no pasa este filtro ya que su soporte a la gestion de proveedores
no cumple las expectativas esperadas.
Quedan: Abanq, Dolibarr, OpenBravo, OpenERP, Libertya, vTiger y WebERP.
Filtro 7: Gestion de comerciales
Libertya y WebERP no cumplen las expectativas en cuanto a la gestion de
comerciales. Sin embargo Libertya puede integrarse con SugarCRM y podra
suplir sus carencias. En el caso de no encontrar ninguna alternativa u nica que
cumpla con las expectativas y necesidades de PubliFringe, e sta combinacion
de 2 alternativas podra tenerse en cuenta.
Quedan: Abanq, Dolibarr, OpenBravo, OpenERP y vTiger.
Filtro 8: Areas
soportadas
vTiger no pasa el filtro ya que no soporta el a rea de contabilidad de manera
que cumpla con las expectativas de PubliFringe.
Quedan: Abanq, Dolibarr, OpenBravo y OpenERP.
Quedan 4 alternativas finalistas. Se ha reducido lo suficiente el numero de alternativas como para poder profundizar mas el analisis en las alternativas restantes.
Se va a realizar una comparacion entre las alternativas usando las tecnicas que se
109
Y MEJORA
usan en la toma de decisiones multicriterio. Hay que escoger entre Abanq, Dolibarr,
OpenBravo y OpenERP. Estan identificados los criterios que PubliFringe considera
importante.
Pero antes de empezar con la evaluacion de las 4 alternativas se recopilara mas
informacion y se analizara con mas profundidad cada alternativa restante. A continuacion se presenta mas informacion sobre las alternativas finalistas:
Figura 3.4: Logo de Abanq
Abanq
Abanq es software libre de tipo ERP 1.5.4 orientado a la administracion, gestion
comercial, produccion o comercio electronico, entre otras aplicaciones. Esta solucion comercial fue creada por InfoSiAL en el que participan colaboradores de todo
el mundo, que es una empresa informatica dedicada a la investigacion y desarrollo
de software, servicios de Internet, servicios informaticos y formacion.
Abanq es el producto principal de InfoSiAL y ha sido galardonado con el primer
premio del concurso de creacion de empresas de base tecnologica convocado por
INNOVARED.
110
TECNOL OGICA
3.4. I NNOVACI ON
InfoSiAL, mediante un plan de certificacion busca articular una red a nivel mundial de companeros tecnologicos, para la prestacion de servicios derivados de AbanQ,
as como su implantacion, desarrollo y distribucion.
Su objetivo es poder ofrecer soluciones y soporte a los clientes finales en cualquier
parte del mundo, de una forma profesional y eficaz, y avaladas por empresas con la
suficiente solvencia y capacidad. Al mismo tiempo tambien es un objetivo crear un
espacio de colaboracion entre companeros tecnologicos para compartir conocimientos, compartir y reducir costes de desarrollo y aumentar as la productividad y la
competitividad.
Pueden ser partners todas aquellas empresas, instituciones o personas fsicas que
obtengan una de las certificaciones expedidas por InfoSiAL. InfoSiAL. En Barcelona
existen actualmente 2 partners: Sistemes i Xarxes Informàtiques Calidae S.L. y
Neotica Solutions.
InfoSiAL tambien ofrece un sistema de creditos para utilizar horas de soporte, en
caso de necesitar ayuda con la instalacion, alguna consulta, necesitar alguna modificacion a medida. . .
De manera gratuita se puede descargar el programa cliente y los modulos basicos.
Modulos basicos
Facturacion
Modulo Principal
111
Y MEJORA
Empresas
Clientes
Proveedores
Ejercicios fiscales
Series de facturacion
Impuestos
Bancos
Cuentas bancarias
Descuentos
Formas de pago
Tipos de Rappel
Agentes comerciales
Departamentos
Usuarios
Grupos de clientes y tarifas
Divisas
Pases y provincias
Modulo Almacen
Artculos
Familias de artculos
Tarifas
Almacenes
Regularizaciones de Stock
Transferencias de Stock
Modulo Facturacion
112
TECNOL OGICA
3.4. I NNOVACI ON
Presupuestos de cliente
Pedidos de cliente
Albaranes de cliente
Facturas de cliente
Pedidos de proveedor
Albaranes de proveedor
Facturas de proveedor
Modulo Tesorera
Recibos de clientes
Remesas de recibos de clientes
Modulo Informes
Informes de facturacion
Informes de tesorera
Informes de almacen (Inventarios)
Contabilidad (integrada)
Modulo Principal
Ejercicios fiscales
Asientos manuales
Asientos predefinidos
Regularizaciones de I.V.A
Gestion del plan contable
Cuentas contables
113
Y MEJORA
Subcuentas contables
Cuentas especiales
Conceptos de partidas
Codigos de balance
Modulo de informes
Libro diario
Libro mayor
Balance de sumas y saldos
Balance de situacion y Balance de perdidas y ganancias
Informes de facturas recibidas y emitidas (listado de I.V.A.)
Tambien existen varios modulos y extensiones a la venta que incluyen funcionalidades como CRM, control de acceso, TPV, modulos para sectores comerciales especficos, comercio-online, modulo para migraciones. . .
114
TECNOL OGICA
3.4. I NNOVACI ON
Figura 3.5: Arquitectura del Sistema
Arquitectura del Sistema

Todo se almacena en la base de datos, que puede ser PostgreSQL o MySQL.
Solo el servidor puede acceder directamente a ella, sirviendo a los clientes los datos
y los modulos de aplicacion, y gestionando el control de acceso a los usuarios.
Los clientes son las maquinas que se encuentran conectadas directamente al
SGBD (sistema gestor de base de datos) pudiendo acceder a la base de datos. En
cada terminal o maquina cliente se ejecuta el software que denominamos aplicacion
base.
El gestor de base de datos se encarga de almacenar y mantener dos tipos de informacion.
115
Y MEJORA
En la zona de datos de la base de datos se almacenan los datos concretos que

la aplicacion maneja y que tienen sentido para el usuario (datos de clientes, facturas. . . ).
Los modulos contienen la informacion necesaria para implementar las aplicaciones de usuario: formularios, definiciones de tablas y campos, codigo de los scripts
que realizan los procesos, formato y definicion de los informes.
Tipos de metadatos que se encuentran en los modulos:
tables: Definiciones de las tablas. Cada tabla se define en un archivo de extension mtd.
forms: Definiciones de los formularios. Cada formulario se define en un archivo de extension ui.
scripts: Definiciones de los scripts. Cada script se define en un archivo de
extension qs.
queries: Definiciones de las consultas. Cada consulta se define en un archivo
de extension
qry reports: Definiciones de los informes. Cada informe se define en un archivo de extension kut.
translations: Listados de traducciones. Cada listado de traducciones para un
determinado idioma se define en un archivo de extension ts.
Desde el punto de vista de un programador o usuario avanzado, el SGBD funciona como un servidor de paginas web, mientras que la aplicacion base hace las
veces de un navegador. La aplicacion base no es mas que un interprete de los datos
que recibe del SGBD. Cuando la aplicacion base se conecta al SGBD, descarga del
mismo tanto los datos como los metadatos. En Abanq los formularios y la funcionalidad residen en el servidor de la base de datos, no en la aplicacion base, al igual que
116
TECNOL OGICA
3.4. I NNOVACI ON
las paginas web no residen en el navegador.
Siguiendo con la analoga web, podemos comparar los scripts de Abanq con
scripts de Javascript que son descargados al navegador y ejecutados en el ordenador
del internauta; los formularios podran ser tablas o formularios HTML, tambien
aparecen en el navegador pero proceden as mismo del servidor.
Requisitos mnimos
Para el servidor:
Servidor dedicado con sistema operativo Linux
Procesador 2 Ghz
Memoria Ram 1Gb
Discos duro Ultra ATA, recomendable SCSI o Serial ATA
Para los terminales:
Procesador 0.8 Ghz
Memoria 256 Mb
Sistemas operativos: Linux, MacOSX 10.4 Tiger o posterior, Windows 2000
o NT
Para el software de bases de datos:
PostgreSQL 8.2 o superior
MySQL 4.1 o superior
117
Y MEJORA
Figura 3.6: Muestra ventana de Abanq
Casos de e xito
Existen numerosos casos de e xito implantando Abanq. Hay casos de empresas
como Graficas Goyza, Magar Oil, Hecanflor hasta administraciones locales de varios municipios de Albacete y Cuenca.
El alumno humildemente tambien cuenta con caso de e xito con esta solucion tecnologica. Realizo una implantacion de Abanq en la empresa familiar Ciclos Blando
S.L.
Ciclos Blando S.L. esta al servicio del ciclista desde 1.925, hoy da estan espe118
TECNOL OGICA
3.4. I NNOVACI ON
cializados en ciclismo deportivo, sobre todo de ruta. Se ofrecen bicicletas, componentes, vestuario, accesorios, recambios, servicio de taller y estudios biomecanicos.
Antes de la implantacion de Abanq, usaban un sistema de DATISA que hacia

tiempo que estaba obsoleto. El principal objetivo de la implantacion de Abanq era
conseguir una mejora de usabilidad del sistema y eficiencia de los procesos de Ciclos
Blando.
Se preparo arquitectura para Abanq y se instalo.
Se realizo una migracion desde el antiguo sistema.
Se realizaron una serie de adaptaciones menores en los modulos basicos para

ajustar a las necesidades de Ciclos Blando.
Se desarrollaron dos modulos para Ciclos Blando: El gestor de encargos y el

generador de etiquetas. Estos modulos extendan las funcionalidades de los
modulos basicos de Abanq para satisfacer unas necesidades especficas de Ciclos Blando.
El resultado fue exitoso porque se consiguio una mejora significativa en usabilidad,

una importante mejora en la eficiencia de los procesos de Ciclos Blando e incluso
mejorar algunos procesos.
La experiencia personal del alumno con Abanq es positiva. Por tanto, Abanq,
como alternativa, tiene una gran ventaja por la experiencia previa que dispone el
alumno.
119
Y MEJORA
Figura 3.7: Logo de OpenBravo
OpenBravo
Openbravo ERP es un sistema de gestion empresarial de tipo ERP orientada
como una aplicacion web y destinada a empresas de pequeno y mediano tamano.
Hay dos tipos de ediciones:
Openbravo Community Edition, libre y gratuita, con soporte y funciones limitadas as como actualizaciones restringidas y sin garanta de correccion de
fallos.
Openbravo Basic Edition y Professional Edition, con elementos privativos y
comerciales, que requiere la compra de una licencia, esta version soportada
provee actualizaciones de codigo, funcionalidad, incluye los modulos comerciales y soporte directo.
La estructura de datos de la aplicacion esta basada originalmente en una version
antigua de Compiere, proyecto con el cual no mantiene compatibilidad alguna.
OpenBravo S.L., la empresa detras de OpenBravo ERP, ofrece certificaciones
para ser partner y varios cursos de formacion tanto para usuarios como para desarrolladores que ahorran mucho tiempo de auto-aprendizaje. En Espana existen numeros
partners. En Barcelona everis es un Gold Partner de OpenBravo.
120
TECNOL OGICA
3.4. I NNOVACI ON
Las ediciones Basic y Professional se escapan del presupuesto de PubliFringe,
al menos a corto/medio plazo. Es interesante saber que es facil migrar de una Comunity Edition a una edicion de pago. Esta investigacion se basara en la edicion
Community ya que es la que se implantara inicialmente.
Modulos basicos
Gestion de datos maestros, tales como clientes, proveedores. . .

Gestion de aprovisionamiento, es decir, las compras, desde el pedido al proveedor hasta la factura y pago al mismo.
Gestion de almacenes, controlando las existencias de la empresa.
Gestion de proyectos y servicios, si la empresa en cuestion realiza dicha actividad.
Gestion de la produccion, si la empresa en cuestion realiza funcion productiva.
Gestion comercial y de las relaciones con los clientes, con todo el proceso asociada a las ventas y su facturacion. La gestion de pedidos de clientes
esta preparada para que pueda realizarse desde algunos dispositivos PDA.
Gestion financiera y contable de la empresa, desde el plan de cuentas, hasta la
cuenta de resultados, pasando por la gestion de los activos, y los inevitables
impuestos.
Los componentes clave del lado servidor incluyen:
Lenguaje de programacion: Openbravo utiliza Java 2 SE en el servidor.
121
Y MEJORA
Base de datos: PostgreSQL y Oracle son totalmente compatibles.
Sistema operativo del servidor: Openbravo es compatible con Microsoft Windows Server ,distribuciones Linux estandar y otros sistemas operativos de
servidor que soporten Java 2 SE.
Java frameworks: JBoss Hibernate de Red Hat se utiliza para mapeos objeto
/ relacional independientes de la base de datos, mientras que JBoss Weld
ofrece la inyeccion de dependencia y la gestion del ciclo de vida contextual.
Java Servlet Container: Se suministra Apache Tomcat como contenedor de
referencia.
Servidor Web: El servidor HTTP Apache se despliega como el servidor web
por defecto.
Informes / BI: Openbravo incluye JasperReports de Jaspersoft para realizar
informes dimensionales y flexibles, crear e imprimir documentos comerciales
como o rdenes de compra y facturas, y satisfacer otras necesidades de informes
y analisis.
La interfaz de usuario se utiliza Javascript y tecnicas Ajax estandar para mejorar
la experiencia de usuario, en los navegadores modernos, incluyendo las u ltimas versiones de: Google Chrome, Firefox, Microsoft Internet Explorer y Apple Safari.
La principal biblioteca de Javascript utilizada por Openbravo es la Smartclientde
Isomorphic Software. Esta incluye una amplia seleccion de componentes de interfaz de usuario que Openbravo utiliza para ofrecer una experiencia de usuario ERP
caracterizada por la facilidad de adopcion para los principiantes, el rendimiento y la
productividad.
Requisitos mnimos
122
TECNOL OGICA
3.4. I NNOVACI ON
Servidor:
Sistema operativo:
Microsoft Windows 2000, XP, Vista.
Linux: Ubuntu, rPath, CentOS, Debian, Gentoo, openSUSE.
FreeBSD.
Mac OS X.
OpenSolaris.
Red Hat.
Solaris 10.
Bases de datos compatibles:
Oracle 10g R2 o 11g, las ediciones Standard o Enterprise (11g recomendado).
PostgreSQL 8.3.5 o superior, con el apoyo OSSP-uuid habilitado.
Java 2 Platform Standard Edition 6.0 o superior.
Apache-Tomcat 6.0.x.
Apache-Ant 1.7.0 o superior (1.7.1 recomendado).
Tecnologas utilizadas: Java, PL/SQL, XML, HTML/CSS, PDF.
Requisitos de hardware: Con 3 usuarios concurrentes en el caso mas habitual y como mucho 20 usuarios concurrentes, con un ancho de banda
de 2Mbps: Dual Core, 2 GB RAM, disk 10000 rpm.
Cliente:
Navegadores: Firefox 3.0 o superior, Internet Explorer 7.0
123
Y MEJORA
Figura 3.8: Muestra ventana de OpenBravo
Casos de e xito
Existen numerosos caso de e xito por todo el mundo, se mencionaran tres casos:
Galenicum: Compana especializada en el sourcing de principios activos y
otras materias primas para la industria farmaceutica europea implanto Openbravo ERP en 2 meses, y obtuvo una completa visibilidad sobre la rentabilidad
de sus operaciones internacionales, as como de sus proyectos de co-desarrollo
con otros laboratorios.
Bertotz: Grupo empresarial dedicado a la distribucion de suministros tecnologicos y a la ingeniera integral llave en mano en diversos pases de
Latinoamerica. Necesitaban un sistema ERP de bajo coste y alto valor para uso
compartido, que permitiera un facil acceso y recuperacion de la informacion.
Openbravo otorgo funciones de automatizacion a medida que simplificaron
124
TECNOL OGICA
3.4. I NNOVACI ON
las transacciones diarias entre las empresas del grupo.
Dalys: Compana dedicada a la distribucion de productos de limpieza y de seguridad laboral. Tena como principal reto el analisis de los margenes en su
negocio as como poder gestionar los colores, tallas y numeros de referencia
de sus productos. Con Openbravo ERP se consiguio calcular el coste del producto, as como evitar tener que dar de alta numerosos productos y a su vez
llevar un control del almacen en funcion de las caractersticas de los mismos.
Figura 3.9: Logo de OpenERP
OpenERP
OpenERP, anteriormente se le conocio como TinyErp, es un completo sistema
de gestion empresarial ERP que cubre las necesidades de las a reas de contabilidad,
ventas, compras, y almacen, entre otras.
OpenERP soporta multiples monedas, multiples companas y multiples contabilidades. Ademas incorpora funcionalidades de gestion de documentos para agilizar la
colaboracion entre departamentos y equipos en la empresa; y permite trabajar remotamente mediante una interfaz web desde cualquier maquina conectada a Internet.
OpenERP esta traducido actualmente a mas de 15 idiomas y dispone de soporte multiidioma, que se puede asignar a usuarios del sistema, clientes o proveedores.
La empresa detras de esta solucion es OpenERP S.A. Hace algunos anos una
compana belga asumio el desarrollo de un sistema ERP libre. Esta empresa, de
nombre Tiny(pequeno en ingles, trataba de describir la sencillez de su nucleo,
estable y robusto) inicio el desarrollo de un sistema modular, configurable, clienteservidor, escrito en Python, usando como base de datos PostgreSQL. Les llevo algun
125
Y MEJORA
tiempo perfeccionarlo, mientras sus clientes crecan con el programa. Al final el producto fue tan exitoso que decidieron llamarlo OpenERP en honor a su licencia libre
y a su filosofa abierta. Actualmente, la empresa matriz OpenERP S.A. continua en
Belgica, cuenta con mas de 85 partners en mas de 28 pases y socios de la talla de
Sun Microsystems, y Softinnova, que en Febrero de 2010 adquirio el 30 % de la empresa por 3 millones de euros.
OpenERP es un ejemplo de construccion de comunidades, abierto, participativo
y dinamico. Con capacidad para colaborar con socios que ofrecen soluciones privativas SAP y eleccion transparente de tecnologas indudablemente libres, tambien es
un excelente ejemplo de un modelo economico sustentable.
Dispone de mucha informacion para el usuario (completos manuales, una gran
comunidad de usuarios. . . ) y para el desarrollador (documentacion tecnica, foros,
una gran comunidad de desarrolladores. . . )
Las funcionalidades de OpenERP, como ya se ha mencionado se agrupan en
modulos. Dentro de la construccion misma del software se hace uso intensivo de flujos de trabajo que se pueden integrar con los modulos. Existen numerosos modulos
libres, hechos por la comunidad de usuarios. Tambien existen modulos comerciales.
OpenERP, tambien dispone de un sistema para certificar los modulos que son de
calidad y a los que garantizan soporte.
Modulos basicos
Empresas
Facturacion, cobros y pagos
Contabilidad
126
TECNOL OGICA
3.4. I NNOVACI ON
Estadsticas
Productos
Recursos humanos
Control de inventario
Gestion de Clientes y Proveedores
Gestion de Compras
Gestion de Almacenes
Workflow de procesos
Gestion de proyectos
Gestion de Produccion/Fabricacion
Gestion de Ventas
Gestion de informes
Gestor documental
Para acceder a un servidor OpenERP se puede hacer a traves de un navegador web
o a traves de una aplicacion cliente GTK. Se pueden usar ambos indistintamente en
el mismo servidor. Las dos maneras son muy similares, aunque es recomendable
usar el navegador web en clientes alejados del servidor, ya que toleran mejor los retrasos en el flujo de datos que la aplicacion GTK. Para clientes cercanos al servidor
(misma maquina o red local o cercana) es mejor usar la aplicacion GTK.
127
Y MEJORA
El servidor de la base de datos es PostgreSQL. Contiene todas las bases de datos
utilizadas por el servidor de OpenERP. Contiene los datos del sistema y muchos elementos de configuracion de openERP.
El servidor openERP contiene toda de la logica de negocio y se asegura de que

se gestione de forma o ptima. El servidor web de openERP (open Object client web)
que se encarga de que se puede acceder a openERP desde los navegadores webs. Estos 3 componentes pueden instalarse en la misma maquina o en distintas maquinas
segun se prefiera.
Los protocolos utilizados en la comunicacion cliente-servidor son XML-RPC

desde clientes linux (con posibilidad de utilizar conexion segura) y NET-RPC desde
clientes windows.
Figura 3.10: Arquitectura de OpenERP
128
TECNOL OGICA
3.4. I NNOVACI ON
Figura 3.11: Arquitectura tecnica

de OpenERP
Requisitos mnimos
El servidor openERP puede montarse en Windows, Linux y Mac OS X. El servidor debe soportar un servidor PostgreSQL (1GHz de Procesador Minimo, 512 de
RAM, es suficiente).
El cliente puede usarse desde cualquier navegador web o desde la aplicacion

cliente de openerp, disponible tambien para windows, Linux y Mac OS X. Estos
necesitan el hardware mnimo para poder usar un navegador web comun.
129
Y MEJORA
Figura 3.12: Muestra ventana de OpenERP
Casos de e xito
Existen numerosos casos de e xito con esta solucion, entre muchas otras, se muestran a continuacion algunas:
Se completo una integracion exitosa de osCommerce (conocido programa de
software libre de comercio electronico y administracion online) con openERP. El
proyecto se realizo para my360shops.com una distribuidora de EEUU. El proyecto
integraba diversas tiendas web con el sistema openERP.
En Malayalam Music Industry, se opto por implantar openERP para gestionar
sus recursos. Se implemetaron unos modulos a medida ajustado a las necesidades de
la industria de la musica. Implementaban funcionalidades de gestion de produccion
de vdeos, canciones. . . inventario, ventas, comprar, recursos humanos e integracion
con su tienda online www.eastcoastaudios.in.
130
TECNOL OGICA
3.4. I NNOVACI ON
Figura 3.13: Logo de Dolibarr
Dolibarr
Dolibarr ERP/CRM es un software de Planificacion de recursos empresariales y
administracion de la relacion con los clientes open source para la pequena y mediana
empresa, autonomos o asociaciones. Es un proyecto OpenSource que se ejecuta en
el seno de un servidor Web, siendo pues accesible desde cualquier lugar disponiendo
de una conexion a Internet. Utiliza una estructura con modulos funcionales.
El desarrollo se inicio por Rodolphe Quiedeville, partiendo de cero. Rodolphe llevo principalmente el desarrollo del producto hasta lograr una victoria en los trofeos del
software libre en 2003 en la categora de Gestion Empresarial.
Dolibarr viene a completar la oferta de numerosas aplicaciones de esta categora
(OpenBravo, OpenERP, Compiere. . . ), pero desmarcandose por el hecho de que se
hace todo lo posible para proporcionar simplicidad:
Simple de instalar, con instaladores para los que ignoran como instalar un
servidor Web.
Simple de usar, funciones modulares para no sobrecargar los menus, informaciones claras y concisas.
Simple de desarrollar, sin frameworks pesados. De hecho Dolibarr integra su
propia arquitectura que permita a cualquier desarrollador empezar a trabajar
inmediatamente, sin tener conocimiento de otra cosa que no sea PHP.
131
Y MEJORA
Dolibarr.es ofrece formacion a nivel de usuario/administracion y a nivel de usuario
avanzado y desarrollo. Dolibarr dispone de una wiki propia que incluye una completa documentacion para usuarios y desarrolladores. Tambien dispone de un registro
de Preferred Partners. Un Dolibarr Preferred Partner.es un proveedor de servicios
entorno a Dolibarr ERP-CRM, que se ha comprometido a demostrar su credibilidad
y experiencia en torno al producto, ofreciendo una garanta de calidad y de profesionalidad en sus servicios. Dolibarr.es se encarga periodicamente de revisar que se
esten cumpliendo con las normas establecidas para Dolibarr Preferred Partners. Hay
algunos partners en Espana como 2byte.es Soluciones Informaticas S.L. que opera
en Valencia.
Modulos basicos
Modulos principales:
Catalogo de clientes y/o clientes potenciales y/o proveedores.
Anuario de clientes, clientes potenciales, proveedores.
Anuario de contactos fsicos.
Gestion de cuentas bancarias/Cajas.
Gestion de presupuestos.
Gestion de pedidos.
Gestion de contratos de servicio.
Gestion de facturacion.
Gestion de stock.
Control de pagos.
Domiciliaciones bancarias.
Gestion de envos.
132
TECNOL OGICA
3.4. I NNOVACI ON
E-Mailing.
Funciones de exportacion.
Agenda.
Otros modulos:
Generacion de PDF (para facturas, presupuestos. . . ).
Gestion de miembros de una asociacion.
Gestion de favoritos.
Interface con Webcalendar/Phenix.
Informes.
Conectividad LDAP.
Gestion de subvenciones.
Gestion de notificaciones.
Modulo Paybox.
Modulo tracker Bit Torrent.
ClickToDial (con Asterisk).
Dolibarr esta desarrollado en PHP. De momento solamente soporta la base de
datos MySQL. Ha sido disenado para funcionar con la mas amplia gama de servidores o hosts posible. As Dolibarr funciona con todas las configuraciones de PHP
y no requiere ningun modulo PHP especfico o complementario.
Dolibarr esta organizado en modulos y consta de una serie de componentes: objetos de negocio, menus, pestanas, paneles, temas, permisos, sistema de autenticacion,
sistema de traduccion. . .
133
Y MEJORA
Requisitos mnimos
Los requisitos mnimos, es una servidor con una distribucion Apache 2.X, MySQL
5.X y PHP 5.2.X o superior. En hardware:
Procesador Intel Dual Core 1.8 Ghz, AMD Dual Core 1.8 Ghz (o superior)
Memoria RAM de 1 GB (800 Mhz)
Disco Duro 2 GB disponibles
Figura 3.14: Muestra ventana de Dolibarr
Casos de e xito
En la wiki de esta solucion se puede encontrar una larga lista de empresas que
usan esta solucion. En Espana hay empresas como:
134
TECNOL OGICA
3.4. I NNOVACI ON
10-4 Zona Policial, dedicada al suministro de uniformidad y equipos para las
Fuerzas y Cuerpos de Seguridad, Proteccion Civil, servicios sanitarios, armamento, materiales de proteccion, seguridad, telecomunicaciones, equipacion
de vehculos, senalizacion y servicios en general, para corporaciones y profesionales del sector. - http://www.10-4zonapolicial.es
Bloc Nacionalista Valencia, es la organizacion unitaria del nacionalismo valenciano progresista. - http://www.bloc.ws/
DentalCost, una empresa que ofrece instrumental dental - http://www.dentalcost.es/
VSport, una tienda de enfocada en el deporte del tenis mesa. - http://www.vsport.es/
2byte.es, la empresa informatica que tambien es Dolibarr Preferred Partners http://www.2byte.es/
entre otros. . .
Una vez investigados mas a fondo las 4 alternativas finalistas, se va a mostrar la
evaluacion de las 4 alternativas. Se han evaluado las alternativas usando todos los
criterios identificados y priorizados en pasos anteriores. A cada criterio evaluado
sobre una alternativa, se le ha puesto una nota sobre 10 puntos. Esta nota tiene una
parte subjetiva, sacada entre las opiniones del alumno y los gerentes de la empresa.
Se ha evaluado pensando en las necesidades de la empresa y cada evaluador ha usado
su punto de vista (perfil comercial, perfil administrativo, consultor, tecnico etc. . . ).
La nota final de cada sobre cada criterio ha sido una media consensuada entre los
evaluadores.
Para poder llevar a cabo la evaluacion de manera satisfactoria, se instalaron y
configuraron de manera basica las 4 alternativas. Esto permitio a los evaluadores explorar con mas precision los criterios. Para los gerentes supuso una primera toma de
contacto con sistemas de informacion integrados, con los que no estaban familiarizados.
135
Y MEJORA
Para obtener la nota global de una alternativa, hay que aplicar la media de las notas obtenidas al evaluar cada criterio sobre dicha alternativa. Hay que recordar que
no todos los criterios tienen la misma importancia. Como ya se ha visto en pasos
anteriores, cada criterio tiene un peso asignado que corresponde a la importancia del
mismo dentro del grupo de criterios identificados. Para representar eso, se aplica el
peso del criterio a la nota.
A continuacion, una tabla con la evaluacion de los 4 criterios:
136
3
10
7
8
9
8
8
7
Interaccion con otros sistemas
Facilidad para anadir desarrollos propios
Informes personalizados
Gestion de clientes
Gestion de comerciales
Gestion de facturas
Gestion de proveedores
9
6
7
6
4
6
Requerimientos de hardware cliente
Online/Offline
Documentacion tecnica
Documentacion de usuario
Gestion de usuarios
Backups
6
5
4
Coste soporte
Coste formacion
Coste actualizaciones
137
N Implantaciones
6,708
0,03
0,05
0,02
0,054
0,012
0,054
0,03
0,025
0,025
0,016
0,064
0,05
0,01
0,01
0,0594
0,02475
0,02475
0,0594
0,0792
0,06875
0,06875
5,5
4,80205
0,03
0,05
0,02
0,054
0,012
0,054
0,03
0,025
0,025
0,016
0,064
0,05
0,01
0,01
0,0594
0,02475
0,02475
0,0594
0,0792
0,06875
0,06875
0,033
0,05775
0,07425
Peso
Openbravo
Nota
0,03
0,05
0,02
0,054
0,012
0,054
0,03
0,025
0,025
0,016
0,064
0,05
0,01
0,01
0,0594
0,02475
0,02475
0,0594
0,0792
0,06875
0,06875
0,033
0,05775
0,07425
7,235175
7,5
8,5
Peso
OpenERP
Nota
de las 4 alternativas
Cuadro 3.3: Tabla de comparacion
N Distribuidores cercanos
Total
N Distribuidores
Amplitud y localizacion
Coste implantacion
Economicos
Multiplataforma
Tecnicos
0,05775
6
0,033
0,07425
Peso
Abanq
Nota
Adaptacion a procesos crticos
Areas
soportadas
Funcionales
Ponderaciones
Criterios/SI
0,03
0,05
0,02
0,054
0,012
0,054
0,03
0,025
0,025
0,016
0,064
0,05
0,01
0,01
0,0594
0,02475
0,02475
0,0594
0,0792
0,06875
0,06875
0,033
0,05775
0,07425
6,502575
7,5
Peso
Dolibarr
Nota
TECNOL OGICA
3.4. I NNOVACI ON
Y MEJORA
La alternativa que ha obtenido una mayor puntuacion a sido openERP. Muy de
cerca a openERP quedan Abanq y Dolibarr. La experiencia del alumno en la alternativa Abanq queda reflejada en cierta forma con la nota asignada a la evaluacion
del criterio Facilidad para anadir desarrollos propios (se ha puesto un 10, cuando
en realidad seria un poco inferior, para reflejar la experiencia del alumno en esta
alternativa). Aun as openERP ha demostrado una gran flexibilidad y una gran variedad de modulos que hacen que sea, de entrada, la alternativa que mas se ajusta a
los criterios.
Tras repasar el proceso de seleccion utilizado y ver el resultado obtenido, tanto
el alumno como los gerentes estan de acuerdo con que openERP es una buena alternativa. Por eso se opta por utilizar openERP en el nuevo sistema de informacion.
3.4.3.
Arquitectura del sistema
Una vez decidido que se utilizara openERP en la implantacion, falta decidir la

arquitectura del nuevo sistema de informacion.
Aunque los requisitos de hardware y software de las soluciones comerciales son
parecidas, sus diferencias podran resultar en un diseno de arquitectura diferente.
Por ese motivo no se puede tomar una decision definitiva hasta haber escogido la
alternativa que se pretende implantar.
Ya se conocen los requisitos mnimos de hardware y software necesarios para implantar la solucion openERP. Pero ademas de los requisitos de software y hardware
de la solucion escogida, existen otros factores a tener en cuenta a la hora. Tambien
hay que tener en cuenta la necesidad de confidencialidad, integridad y disponibilidad
de los datos del sistema, riesgos de cadas del sistema, coste de construccion, coste
de mantenimiento, coste de restablecimiento del sistema en caso de cada. . .
Se proponen 3 posibles caminos sobres los que empezar a disenar una arquitec138
TECNOL OGICA
3.4. I NNOVACI ON
tura:
Externalizar todos o parte de los servicios TI a proveedores externos.
Disenar una arquitectura con servidor interno dedicado.
Disenar una arquitectura virtualizada 1.5.9 con servidor interno.
A cada una de estas 3 alternativas se analizaran sus riesgos y sus costes. Se
escogera la alternativa que cumpla las necesidades de disponibilidad confidencialidad e integridad de PubliFringe. A continuacion se realizara un repaso previo de
la situacion y necesidades de PubliFringe, incluyendo nueva informacion relevante
para disenar una arquitectura apropiada. El alumno entrevistara a los gerentes de la
empresa para recopilar la informacion necesaria.
PubliFringe dispone de una oficina con internet compartido entre varias empresas. Es necesario que haya personal que pueda acceder al sistema openERP desde
internet (los comerciales autonomos). Estimando a lo alto, a corto y medio plazo se
puede esperar que haya no mas de 10 empleados internos y unos 50 comerciales en
activo trabajando en PubliFringe.
Los comerciales accederan desde internet para realizar consultas o introducir
datos puntualmente. El personal interno trabajara bastante mas activamente con el
sistema openERP.
De manera imprescindible el sistema debera estar disponible de Lunes a Viernes
de 09:00 a 19:00 (el horario mas habitual de trabajo). Idealmente podra estar disponible
mas horas e incluso los fines de semana, ya que los comerciales autonomos tienen
sus propios horarios.
No se preven picos de maxima concurrencia ya que el grueso de usuarios (los
comerciales) son independientes entre s, trabajan en sus propio horarios, con sus
propios clientes y sus accesos son puntuales.
139
Y MEJORA
La mayora de procesos de PubliFringe (prospeccion, facturacion, gestion de
proveedores. . . ) podran continuar sin excesivos problemas durante una semana con
el sistema de informacion fuera de servicio (por alguna avera por ejemplo). En
general son procesos que no requieren de informacion previa del sistema (prospeccion, prepara un nuevo presupuesto. . . ). Los usuarios del sistema podran apuntar sus
datos en alguna hoja de calculo. El sistema openERP dispone de funcionalidades de
migracion que permiten introducir en el sistema datos desde una hoja de calculo por
lo que, una vez restaurado el sistema, podran introducir los datos al sistema mas
rapidamente.
Existen otros procesos en PubliFringe que dependen de informacion que se encuentra en el sistema (facturacion, cierre de presupuestos. . . ). De todos estos procesos los mas crticos son los que interrumpen o deterioran de manera directa la calidad
del servicio ofrecido a los clientes (cierre de presupuestos, gestion de clientes. . . ).
Tanto para ofrecer presupuestos como solicitudes de asesoramiento PubliFringe garantiza una respuesta a sus clientes en no mas de 72 horas. Para poder garantizar una
respuesta o ptima en un tiempo aceptable, en la mayora de casos se requiere de la
informacion que contiene el sistema.
De lo analizado anteriormente se concluye que el sistema de informacion debera
poder restaurarse en no mas de 48 horas para no comprometer a la continuidad del
negocio.
A continuacion se detallaran las 3 propuestas realizando un analisis de riesgos
y los planes de contingencia necesarios para cumplir las necesidades de PubliFringe.
Arquitectura con servidor dedicado

Se necesita montar el servidor openERP (con sus requisitos: PostgreSQL, servidor web. . . ) y un servidor de ficheros compartidos. El servidor de ficheros compartidos es necesario para compartir informacion entre el personal interno (excluyendo
140
TECNOL OGICA
3.4. I NNOVACI ON
a los comerciales) de PubliFringe (pdf, imagenes, software, backups de ficheros,
backups del sistema de informacion del servidor. . . ).
Para montar estos dos servicios es suficiente una maquina con Ubuntu Server
instalado para albergar el servidor openERP y el servidor de ficheros compartidos
(se utilizara Samba en este caso).
Mas adelante, si fuera necesario, se podra mejorar la arquitectura separando el
servidor openERP y la base de datos PostgreSQL en maquinas distintas. Tambien
se podran replicar los servidores y utilizar balanceadores de carga mediante arquitecturas mas complejas. Por ahora, dado el tamano y necesidades de PubliFringe es
suficiente.
La oficina donde esta situada PubliFringe tiene acceso a un router con wifi y con
acceso a internet. Comparten intranet y la salida a internet con otras oficinas. Esta
situacion no es deseable ya que el nuevo sistema de informacion va a contener datos
que requieren estar protegidos (datos clientes, contabilidad. . . ) y fuera del alcance de
personas externas a PubliFringe. Una primera idea recomendable para solucionar esta situacion sera crear una red privada para PubliFringe, utilizando un router/firewall
propio que separe la red privada de la red interna compartida e internet.
Como los comerciales autonomos accederan desde internet, existira una transferencia de datos confidenciales de PubliFringe a traves de internet. Una buena idea
para evitar eso es cifrar las comunicaciones a traves de una red VPN. Una VPN (Virtual Private Network) es una tecnologa de red que permite una extension de la red
local sobre una red publica o no controlada, como por ejemplo Internet. Para hacerlo posible de manera segura es necesario proporcionar los medios para garantizar
la autentificacion y autorizacion, la integridad de toda la comunicacion, la confidencialidad y el no repudio (evitar que el emisor pueda negar que envio la transmision).
Se propone montar un servidor VPN, con openVPN. OpenVPN es una solu141
Y MEJORA
cion de conectividad basada en software: SSL (Secure Sockets Layer) VPN Virtual
Private Network (red virtual privada), OpenVPN ofrece conectividad punto-a-punto
con validacion jerarquica de usuarios y host conectados remotamente, resulta una
muy buena opcion en tecnologas Wi-Fi (redes inalambricas EEI 802.11) y soporta una amplia configuracion, entre ellas balanceo de cargas. Existe mucha documentacion para montar y configurar esta solucion (Bibliografa [13]).
El servidor openVPN permitira a usuarios externos (a traves de Internet) acceder al servicio openERP de manera segura, manteniendo las transmisiones protegidas.
Si se permitiera el acceso al servidor openERP y al servidor de ficheros compartidos
exclusivamente a traves de la red VPN, todas las comunicaciones usando los datos
confidenciales del sistema de informacion estaran protegidos. Esto permitira, para
reducir los costes de esta arquitectura, prescindir del router/firewall que creaba la
red privada para PubliFringe. Esto hara que las maquinas de PubliFringe quedaran
dentro de la red interna que crea el router con acceso a internet (red interna compartida con otras empresas). Sin embargo, como los datos confidenciales que PubliFringe
quiere proteger estaran dentro de la red VPN las otras empresas que compartieran la
red interna con PubliFringe no podran acceder a esos datos ni a sus comunicaciones.
Para que los usuarios que quisieran conectarse a la red VPN desde Internet, necesitaran conocer la IP Publica. Esta IP es dinamica por lo que se utilizara un servicio
de DNS dinamico. El router con conexion a internet debera redirigir el trafico de las
conexiones VPN hacia la maquina con el servidor VPN.
Se ha propuesto hasta ahora:
Una maquina que haga de servidor:
Ubuntu Server
Base de datos PostgreSQL
Servidor openERP
Servidor web para openERP
142
TECNOL OGICA
3.4. I NNOVACI ON
Servidor de comparticion de ficheros (Samba).
Servidor openVPN
Servicio DNS dinamico.
Firewall para permitir el acceso a los servicios exclusivamente a traves
de la red VPN.
Un router/firewall (opcional, para crear red interna sin compartir con el resto
de empresas)
Maquinas locales de PubliFringe
Con esta arquitectura, el sistema de informacion puede cubrir las necesidades
de seguridad, accesibilidad y disponibilidad de PubliFringe. Falta analizar los posibles riesgos que puedan afectar al sistema de informacion impidiendole cubrir estas
necesidades.
Los principales riesgos que preocupan en PubliFringe son:
Perdida de datos.
Datos de openERP.
Datos de las maquinas locales de PubliFringe.
Datos del servidor de ficheros compartidos.
Interrupcion de servicio (a causa de una avera, fallo en la red, en la maquina
que hace de servidor. . . ).
El servicio crtico es el sistema openERP, como se ha analizado previamente. Debe restaurarse antes de 48 horas.
Acceso no autorizado.
Los datos de PubliFringe no deberan ser accesibles por personas ajenas
a la empresa.
143
Y MEJORA
Los comerciales no deberan poder acceder al servidor de ficheros compartidos ni a otros servicios del servidor.
Dentro del sistema openERP no debera poder acceder a datos no autorizados.
Para reducir riesgos de perdida de datos, se propone montar un sistema de copias
de seguridad de la siguiente manera:
En cada maquina local se asignaran (como estandar) lugares especficos donde
guardar datos que se deseen proteger (pdf, imagenes, vdeos. . . ). De esta manera, mediante algun software para realizar acciones programadas (Cobian por
ejemplo) se podran realizar copias periodicamente hacia una ubicacion compartida concreta en el servidor de ficheros compartidos.
Periodicamente se realiza una copia de la base de datos que contenga la informacion del sistema openERP y se guarda en una ubicacion compartida concreta en el servidor de ficheros compartidos.
Periodicamente se realiza una copia de seguridad de las ubicaciones compartidas (incluyendo copias de seguridad de las maquinas locales, copias de
seguridad de openERP y la informacion compartida) hacia algun medio de almacenamiento portatil. As se puede sacar la copia de seguridad de las oficinas
de PubliFringe.
Con el sistema de copias de seguridad propuesto se consigue que existan varias
copias de seguridad en diversas partes. Eso ayuda a no perder toda la informacion
incluso si todos las maquinas de la oficina de PubliFringe resultaran danados (por
alguna catastrofe).
Para reducir riesgos de interrupcion del servicio openERP convendra conocer
los puntos de maxima actividad y asegurarse que el sistema soporta la carga. Evitar
que otras actividades (como las copias de seguridad) coincidan con estos picos para
no sobrecargar el sistema.
144
TECNOL OGICA
3.4. I NNOVACI ON
Hay muchas posibles amenazas sobre el sistema y a veces no es posible prevenirlas todas. A continuacion se propone una serie de medidas y planes de contingencia
que pueden ayudar a restablecer el servicio dentro de los lmites propuestos (48 horas):
Mantener una imagen del servidor (con el sistema openERP) para poder reinstalar el sistema mas rapidamente en caso de avera en el hardware.
El sistema openERP es capaz de importar datos desde hojas de calculo. Por
tanto si se disponen de las plantillas basicas que se usan a diario, es posible
no interrumpir completamente el servicio a nuevos clientes o nuevos procesos de venta. Se puede trabajar anadiendo datos en las hojas de calculo. Una
vez restaurado el sistema, se puede importar rapidamente los datos al sistema
openERP. Esta solucion no permite acceder a informacion del sistema openERP (ya que esta fuera de servicio).
En una o varias maquinas de la oficina (sin contar con el servidor) tienen el
servicio openERP configurado de manera basica para que solo funcione en
la red local. Si se carga la u ltima copia de seguridad del sistema openERP
en el momento que caiga el servicio, se dispondra de un sistema openERP
secundario para el personal de la oficina. Este sistema openERP secundario
se puede utilizar para continuar el servicio hasta que el sistema principal sea
restaurado.
Respecto al acceso no autorizado a los datos del sistema, se reduce el riesgo al
mantener los datos dentro de una red privada virtual. Mediante el firewall del servidor y la red VPN el sistema queda restringido al personal de PubliFringe. Mediante
los certificados necesitados para entrar a la red VPN se diferenciara entre comerciales y personal interno. Los comerciales solo tendran acceso al servicio web de
openERP mientras que el personal interno tendra acceso al resto de servicios. Otro
nivel de seguridad que se tendra en cuenta sera el que incluye el sistema openERP.
El sistema openERP dispone de un sistema de permisos, reglas, grupos. . . para restringir el acceso de los datos del sistema solo a los usuarios autorizados.
145
Y MEJORA
A continuacion un esquema de la arquitectura del sistema de informacion propuesto para PubliFringe:
Figura 3.15: Arquitectura con servidor dedicado
Arquitectura con servidor virtualizado

En la arquitectura anterior hay una sola maquina ofreciendo todos los servicios.
Idealmente la arquitectura anterior se podra mejorar si se separaran los servicios
que ofrece la arquitectura en diferentes maquinas. Esta separacion de los servicios
aportara una mayor seguridad, mejor escalabilidad, mejor portabilidad. . . Pero el
coste de adquirir y mantener mas maquinas, no compensara ya que el presupuesto
es bajo y no se aprovechara todo el rendimiento de las maquinas dadas las necesidades actuales de PubliFringe.
Dadas las necesidades de PubliFringe, se podra virtualizar 1.5.9 la arquitectura
anterior separando los diferentes servicios en diferentes maquinas virtuales.
146
TECNOL OGICA
3.4. I NNOVACI ON
Existen productos (como VMware ESX) que permiten ejecutar maquinas virtuales sin utilizar un sistema operativo completo por lo que puede montarse un servidor de maquinas virtuales que dedique sus recursos de hardware casi exclusivamente
para la ejecucion de las maquinas virtuales.
Si se mantiene como base la arquitectura anterior, el cambio respecto a esta sera

la separacion de los servicios en diferentes maquinas virtuales. La maquina que hacia
de servidor dedicado, en esta arquitectura sera el servidor de maquinas virtuales
ofreciendo sus recursos hardware a las maquinas virtuales. Las maquinas virtuales
estaran conectadas entre s en una red virtual. El punto de entrada y salida de esa
red sera la interfaz de red fsica de la maquina fsica. Las maquinas virtuales seran:
Firewall u nico con acceso directo a la entrada (interfaz de red fsica).
Servidor openVPN, detras del firewall.
Servidor de comparticion de ficheros, detras del servidor openVPN.
Servidor web openERP, detras del servidor openVPN y conectado al servidor

openERP.
Servidor openERP, detras del servidor openVPN.
Servidor con base de datos PostgreSQL, detras del servidor openERP.

147
Y MEJORA
Figura 3.16: Arquitectura con servidor virtualizado
Externalizar todos o parte de los servicios TI a proveedores externos

Esta alternativa tiene la gran ventaja de que no hay que invertir en infraestructura
TI para implantar el sistema de informacion. Mediante la contratacion de servicios
de cloud computing PaaS o IaaS 1.5.10 se podra implantar el sistema de informacion delegando aspectos tecnicos de la infraestructura TI (IaaS) o de la plataforma
(PaaS) al proveedor externo.
Un servicio de hosting convencional no es suficiente en el caso de PubliFringe
debido a que la instalacion del sistema openERP requiere un acceso especial que
este tipo de servicio no suele conceder.
148
TECNOL OGICA
3.4. I NNOVACI ON
Con un servicio de SPV (Servidor privado virtual) se podra montar el sistema

openERP. Se contrata un servidor con una cantidad de recursos determinados (CPU,
memoria, capacidad de almacenamiento, capacidad de transmision de datos. . . ).
Para esta alternativa hace falta buscar proveedores capaces de mantener los servicios que necesita PubliFringe accesibles desde internet. Convendra tambien estudiar
los SLA (acuerdos de nivel de servicio) para ver si se ajustan a las necesidades de
seguridad, disponibilidad. . .
Respecto a las arquitecturas anteriores, muchas de las cuestiones que se plantean

quedaran delegadas al proveedor (dependiendo de los SLA).
Seleccion de una arquitectura
Para seleccionar una arquitectura es importante evaluar los costes de cada alternativa y evaluar las diferencias de costes con las ventajas y desventajas que aporta
cada alternativa.
Los costes de los servicios y recursos necesarios para cada alternativa se obtendran a partir de los precios de mercado (precio estimado medio). Tambien se calcula
el coste anual del servicio/recurso en funcion de su coste y su vida u til media.
A continuacion se muestran las tablas de estimaciones de costes para cada alternativa.
149
Y MEJORA
Servidor dedicado
Coste
Vida util
Coste anual
Servidor
600,00 C
3 anos
200,00 C
Router/firewall
200,00 C
5 anos
40,00 C
Disco duro externo
100,00 C
5 anos
20,00 C
Mantenimiento
100,00 C
1 ano
100,00 C
Total
360,00 C
Recurso/Servicio
de costes con servidor dedicado

Cuadro 3.4: Estimacion
Virtualizacion
Coste
Vida util
Coste anual
Servidor
600,00 C
3 anos
200,00 C
Router/firewall
200,00 C
5 anos
40,00 C
Disco duro externo
100,00 C
5 anos
20,00 C
Mantenimiento
100,00 C
1 ano
100,00 C
Total
360,00 C
Recurso/servicio
de costes de virtualizacion
Cloud Computing
Recurso/servicio
Coste
Vida util
Coste anual
Servidor privado virtual
40,00 C
1 mes
480,00 C
Total
480,00 C
de costes de cloud computing

150
TECNOL OGICA
3.4. I NNOVACI ON
Tanto la alternativa del servidor dedicado como la alternativa de la virtualizacion
requieren una inversion inicial en los recursos que requieren ambas arquitecturas
(aunque una vez adquiridos los recursos se amortizan con los anos). En cambio con
la alternativa basada en cloud computing no se adquieren recursos ya que los gestiona el proveedor del servicio de cloud computing.
En la evaluacion de costes se detecta que los costes de la alternativa de la arquitectura basada en cloud computing se estiman superiores al resto de alternativas
(debido a que las necesidades de PubliFringe en recursos TI son muy bajos). Esta alternativa proporciona muchas ventajas interesantes para PubliFringe que es la
simplicidad de gestion de la infraestructura, baja inversion inicial, flexibilidad, escalabilidad. . . Sin embargo en PubliFringe se ha considerado que las ventajas no
compensan de manera suficiente la diferencia de coste frente a las otras alternativas
y las desventajas que aporta esta arquitectura: dependencia de internet (los servicios
del sistema de informacion no estan en red local como en las otras alternativas),
datos confidenciales del negocio protegidos por un tercero. . .
La alternativa de la virtualizacion y la del servidor dedicado se estima que tendran costes similares ya que invierten en los mismos recursos TI (se planean usar
licencia gratuitas tanto para sistemas operativos como tecnologas de virtualizacion).
La virtualizacion 1.5.9 presenta muchas ventajas sobre la alternativa con servidor
dedicado. Permite utilizar al maximo cada maquina fsica. Tambien ofrece flexibilidad, facilidad para anadir nuevos servicios, migrar servicios a otras maquinas fsicas
menos ocupadas, restaurar el sistema con mas facilidad. . . La separacion de servicios
en diferentes maquinas virtuales aumenta la seguridad, facilita el mantenimiento. . .
La principal desventaja de la virtualizacion es la reduccion de rendimiento Un
sistema operativo virtualizado nunca alcanzara las mismas cotas de rendimiento que
si estuviera directamente instalado en hardware. Dado que se introduce una capa
intermedia en la gestion del hardware para gestionar las peticiones de acceso y la
concurrencia al mismo. Existen otras desventajas como que es posible que algunas
151
Y MEJORA
caractersticas de hardware no se aprovechen como debera (hardware virtual obsoleto, aceleracion de vdeo por hardware. . . ). Aunque la virtualizacion permita separar
servicios en diferentes maquinas virtuales independientes, todas estas dependen de
la estabilidad de la maquina fsica.
La alternativa escogida tras considerar todo lo anterior ha sido la arquitectura con
servidor dedicado. La decision ha estado renida con la opcion de virtualizacion. La
opcion de virtualizacion puede aportar beneficios incluso a pequenos negocios con
pocos servidores. Sin embargo se ha descartado debido a que con un solo servidor
fsico la virtualizacion no aprovechara de manera suficiente sus ventajas como para
compensar el coste de sus desventajas (la reduccion global de rendimiento debido a
la virtualizacion puede requerir un servidor fsico mas potente que en la alternativa
con servidor dedicado). Tampoco se ha tenido la oportunidad de probar a fondo las
tecnologas gratuitas de virtualizacion (como ESXi de VMware).
A largo plazo, si aumentara la carga de utilizacion del sistema y se necesitaran
mas servidores, la eleccion podra cambiar. Aumentaran los costes de adquisicion
y mantenimiento de hardware, aumentara la complejidad del sistema. . . Llegados
a este punto tanto la alternativa de cloud computing como la alternativa de virtualizacion aprovecharan sus ventajas. La eleccion entre una u otra dependera de
la estrategia de PubliFringe en ese momento (externalizar TI o no) y de un nuevo
analisis de costes basado en las necesidades de ese momento futuro.
3.4.4.
Metodologa de implantacion y desarrollo
Queda proponer como realizar todo lo propuesto en este capitulo durante la fase
de implantacion. Existen numerosas metodologas para el desarrollo de proyectos.
Cada metodologa tiene sus ventajas y desventajas. Se suelen basar en buenas practicas de desarrollo y gestion de proyectos.
Para este proyecto se van a descartar adoptar una metodologa de desarrollo tradi152
TECNOL OGICA
3.4. I NNOVACI ON
cional 1.5.14 (metodologas formales, rgidas y exhaustivas). Se descartan debido a
que los requisitos concretos para el nuevo sistema de informacion no estan inicialmente claros, por lo que probablemente iran cambiando a medida que avance la
implantacion. Esto es debido a que los miembros de la empresa no tienen experiencia previa ni contacto con otros sistemas de informacion integrados 1.5.3 por lo que
les es mas difcil planificar los requisitos.
Para este proyecto sera mas apropiado una metodologa de desarrollo a gil 1.5.15
que estan mas preparadas para requisitos cambiantes y adecuada para equipos de trabajo pequenos como es el caso de este proyecto.
Para la gestion de el proyecto se propone la utilizacion de la metodologa Scrum
1.5.15. Es una metodologa a gil muy conocida y utilizada. Se va a simplificar la
metodologa para adaptarla a las necesidades de PubliFringe.
El equipo de trabajo y sus roles seran:
Peter: Product Owner y Beta tester.
Olivia: Product Owner y Beta tester.
El alumno: Consultor, Scrum Master y desarrollador.
Los product owner, asesorados por el consultor, iran especificando requisitos
(Blacklog). Se priorizaran los requisitos para determinar que requisitos se desarrollaran primero.
Una vez implementada la arquitectura que soportara el sistema de informacion,
quedara implantar el sistema openERP. Para ello se dispondra de 3 entornos de trabajo: el entorno de desarrollo y configuracion, el entorno de prueba y el entorno
de produccion. Inicialmente los 3 entornos seran una instalacion basica del sistema
openERP (3 bases de datos diferentes independientes).
153
Y MEJORA
El ciclo de trabajo sera el siguiente:
Se especifican y priorizan los requisitos.
En el entorno de desarrollo se desarrollan los requisitos por orden de prioridad.
Una vez desarrollado un requisito, se implantan las modificaciones en el entorno de prueba.
Los Beta testers prueban que las modificaciones anadidas buscando errores y
asegurandose que el requisito se cumple y resulta u til.
Una vez el requisito esta probado y se considera apto, se implanta en el entorno
de produccion donde puede ser utilizado en el da a da.
En cualquier momento del ciclos si surgen nuevos requisitos o mejoras de los
ya existentes se vuelve primer paso.
Con este ciclo de trabajo se consigue un entorno de produccion incremental que
se puede empezar a utilizar aunque el sistema no este terminado del todo. Tambien
se pueden migrar los datos del antiguo sistema de informacion es este entorno.
3.5.
Mejora e innovacion de procesos
En este primera parte se analizan los procesos de la empresa previos a la implantacion detallados en el captulo anterior. A traves de varias reuniones con los
miembros de la empresa, se buscara donde se genera mayor valor para el cliente
y donde estan los puntos debiles, de poco valor o mucho coste. Tambien se planificaran los cambios o mejoras que se pretenden conseguir durante la implantacion y
se pensaran los primeros requisitos.
154
DE PROCESOS
3.5. M EJORA E INNOVACI ON
3.5.1.
Cadena de valor
La mayora de servicios y productos que ofrece la empresa son externalizados a

sus proveedores. Se puede decir que PubliFringe es una distribuidora de productos y
servicios de marketing online y offline. Los clientes de PubliFringe son Pymes que
tienen una necesidad de publicitarse. PubliFringe, con sus conocimientos y experiencia, asesora al cliente sobre como rentabilizar su inversion en publicidad y busca
los proveedores apropiados segun las necesidades de calidad y precio que tenga el
cliente. La cadena de valor 1.5.1 de PubliFringe podra resumirse como lo siguiente:
Figura 3.17: Cadena de valor PubliFringe
El valor para el cliente generado por los servicios, productos y actividades de

logstica, se genera casi en su totalidad a traves de los proveedores de PubliFringe.
En PubliFringe se considera que donde mas valor aporta es en las las actividades de
abastecimiento y las actividades de marketing y venta. Las actividades de abastecimiento aportan valor a los clientes ya que la experiencia de PubliFringe y su relacion
con sus proveedores ayudan a encontrar los servicios con la calidad y precio deseados. Por otra parte las actividades de marketing y venta aportan valor tanto a los
clientes como a los proveedores de PubliFringe. Los proveedores consiguen mas
clientes a traves de PubliFringe y los clientes obtienen asesoramiento y atencion
personalizada.
155
Y MEJORA
PubliFringe ya haba detectado al iniciar este proyecto la importancia de las actividades de marketing y ventas. Ahora, tras el analisis inicial y el estudio de la
propuesta, se ha detectado y valorado tambien las actividades de abastecimiento.
Durante la propuesta de mejora e innovacion de procesos no solo se buscara soporte para una estrategia CRM 1.5.5 como hasta ahora se haba planeado. Se buscara tambien mejorar la relacion con los proveedores (SRM 1.5.6) para reforzar aun
mas el valor que genera PubliFringe.
3.5.2.
Adaptacion de procesos al nuevo sistema de informacion
Los sistemas ERP 1.5.4 del mercado generalmente ofrecen soporte a un conjunto de procesos genericos de empresa. Estos procesos propuestos generalmente son
fruto de la experiencia de los desarrolladores del sistema ERP 1.5.4 y suelen seguir
buenas practicas a la hora de disenarlos. Por otro lado, estos procesos suelen ser
muy genericos y por tanto ofrecen poca diferenciacion. Las empresas buscan diferenciarse de sus competidores no solo con productos y servicios diferenciadores sino
tambien mejorando la eficacia y eficiencia de sus propios procesos. El extremo de
desarrollar un sistema de informacion completamente a medida para una empresa es
muy costoso. Por eso se suele buscar el equilibrio entre adaptarse a procesos genericos propuestos por un determinado sistema de informacion y adaptar el sistema de
informacion a procesos especficos de la empresa. Una buena practica es adaptarse a
los procesos propuestos por los sistemas de informacion a excepcion de los procesos
que mas valor aporten a la empresa. Estos

u ltimos se desarrollan a medida o adaptando el sistema de informacion a los procesos propios de la empresa para conseguir
una diferenciacion que aporte valor.
En el caso de PubliFringe se intentara adaptar todo lo posible a los procesos
de PubliFringe a los procesos propuestos por el sistema openERP. As se ahorraran
156
3.6. C ONCLUSIONES
costes de desarrollo. Como PubliFringe no dispone de un sistema de informacion
integrado, solo adaptandose a los procesos que propone openERP habra una gran
mejora ya que se obtendran todas las ventajas que ofrecen este tipo de sistemas. La
excepcion seran los procesos clave de PubliFringe detectados en su cadena de valor
(gestion de clientes y proveedores). Estos procesos e adaptaran a las necesidades
especficas de PubliFringe ya que el coste de desarrollo de cualquier mejora en esos
procesos aportara mas valor que si se invierte en mejorar y adaptar procesos que no
aportan valor.
3.6.
Conclusiones
En esta seccion se repasara la propuesta para ver si cumple los objetivos.

Objetivos de la propuesta:
1. Implantar un nuevo sistema de informacion que de soporte a la empresa.
La propuesta incluye la implantacion de un nuevo sistema de informacion
integrado a partir de una solucion comercial: openERP. La propuesta tambien
incluye una arquitectura sobre la que sostener el sistema y una metodologa
para ejecutar la implantacion.
2. Dar soporte a la estrategia CRM de la empresa.

El sistema openERP tiene de base funcionalidades que dan soporte a dicha
estrategia. Tambien esta planificado que haya adaptaciones a las necesidades
especficas de PubliFringe ya que es una de las a reas que mas valor aporta.
3. Mejorar los procesos de la empresa.
157
Y MEJORA
La adaptacion de los procesos de PubliFringe a los propuestos por el sistema
openERP implica muchas mejoras respecto a los procesos actuales. En general se mejorara la eficiencia de los procesos evitando introducir varias veces
la misma informacion en el sistema, automatizando tareas, acortando tiempos de espera por toma de decisiones. . . Un ejemplo sera la gestion de presupuestos. Actualmente los comerciales, tras reunirse con el cliente, solicitan
a PubliFringe un presupuesto. En PubliFringe se preparan presupuesto los en
funcion de la informacion que disponen de los proveedores (productos, servicios ofrecidos, precios. . . ) y la informacion proporcionada por el comercial.
Este proceso puede llegar a ser un cuello si no hay suficiente personal con
la responsabilidad de aceptar presupuestos (y la informacion que necesita).
En cambio adaptandose al nuevo sistema (con toda la informacion integrada) un comercial puede preparar un presupuesto a traves del catalogo de productos, servicios y precios. As quien deba aprobar el presupuesto tan solo
debe repasarlo, reduciendo as la carga de trabajo (incluso en caso de ser un
presupuesto estandar saltarse el paso de la aprobacion). De esta manera los
comerciales pueden trabajar de manera mas independiente pero sin perder el
control sobre ellos. Con todo esto los clientes consiguen presupuestos mas
rapidamente, cosa que aumenta el valor del servicio.
4. Innovar en los procesos y las herramientas de trabajo.

Los procesos de gestion y relacion con los clientes al comenzar el proyectos se
consideraba una parte muy importante en PubliFringe antes de comenzar este
proyecto (se ve reflejado en el segundo objetivo). Pero durante el desarrollo,
tras el analisis de la cadena de valor se ha detectado tambien como foco de
valor el proceso de gestion y relacion con los proveedores. Esto ha supuesto
un cambio de mentalidad durante los proximos pasos del proyecto. Se buscara mejorar e innovar estos nuevos procesos, hasta ahora descuidados.
158
3.6. C ONCLUSIONES
5. Debe soportar un aumento de clientes, comerciales, empleados y ventas.
El nuevo sistema integral de informacion aporta suficientes mejoras en la
gestion global de la empresa como para soportar dicho aumento sin perder
el control. La arquitectura que soporta el sistema tambien esta preparada para
una carga superior a la actual (basada en una estimacion a medio plazo).
El coste adicional estimado de la propuesta se limita a la adquisicion de los
recursos necesarios para preparar la arquitectura del sistema (ya que la adquisicion
de la solucion openERP es gratuita).
Servidor dedicado
Coste
Vida util
Coste anual
Servidor
600,00 C
3 anos
200,00 C
Router/firewall
200,00 C
5 anos
40,00 C
Disco duro externo
100,00 C
5 anos
20,00 C
Mantenimiento
100,00 C
1 ano
100,00 C
Total
360,00 C
Recurso/Servicio

Con una inversion adicional de unos 1.000 C (coste anual 360,00 C) se puede
implementar la propuesta. Esta propuesta ademas de cumplir los objetivos del proyecto tambien soluciona los problemas y defectos del sistema actual.
Principales problemas detectados del sistema actual:
159
Y MEJORA
y actualmente no la tienen.
Principales defectos detectados del sistema actual:
1. Redundancia de datos.
2. Falta de integridad en los datos.
3. Inexistencia de sistemas de copias de seguridad.
4. Gran diversidad de software a utilizar.
5. Gestion del conocimiento centrado en el gerente.
6. Dificultad para generar informes en papel.
7. Falta de coordinacion con los comerciales.
8. Datos dispersos en varios ficheros.
9. Dificultad para filtrar y agrupar la informacion.
160
Captulo 4
Implantacion
Una vez elaborada la propuesta queda la implantacion de la propuesta en PubliFringe. En este captulo se detallara este proceso de implantacion que se inicio en
PubliFringe a finales de Noviembre de 2011. En los proximos captulos se comentara la planificacion del proyecto as como un analisis final sobre el proyecto donde
se explicaran los principales problemas surgidos as como posibles mejoras para el
futuro.
El proceso de implementacion se dividio en varias partes:
1. Preparacion de la arquitectura que soportara el sistema.
2. Formacion inicial sobre openERP.
3. Configuracion inicial openERP y migracion de los primeros datos en el sistema.
4. Preparacion de los entornos de trabajo.
5. Desarrollo iterativo de requisitos y formacion continuada:
a) Especificacion y priorizacion de requisitos.
b) Desarrollo de los requisitos.
c) Prueba de los cambios realizados para cumplir los requisitos y formacion
sobre los mismos.
161

C API TULO 4. I MPLANTACI ON
d) Incorporacion de los cambios aprobados al entorno de produccion.
e) Analizar cumplimiento objetivos y alcance del proyecto.
4.1.
Preparacion de la arquitectura que soportara el

sistema
Siguiendo la propuesta, se adquirieron los recursos necesarios para la implementacion de la arquitectura. Se adquirio una maquina HP Proliant, especialmente
pensada para pequenas empresas.
Ubuntu Server 11.10
Se realizo una instalacion basica de Ubuntu Server 11.10 (Oneiric Ocelot)

sobre la maquina HP Proliant que hara de servidor dedicado. Se aplico un
particionado LVM (Logical Volume Manager). LVM es un esquema de particionamiento de disco que trae un nivel de flexibilidad para la gestion de disco
que no es posible con el metodo tradicional. Con LVM se puede, si es necesario, que aumente el tamano de particion mientras que el sistema esta en funcionamiento, sin necesidad de desmontar la particion. Tambien puede agregar
otro disco en el sistema si el disco viejo se llena. Hay muchos mas beneficios
de usar LVM, pero estas dos son razones mas que suficientes para considerar
su uso.
Servidor de comparticion de ficheros
Se instalo y configuro el servidor de ficheros Samba. Se compartio un disco

duro extrable conectado al servidor. Este recurso se oculto de la red por seguridad y se bloqueo solo para accesos de usuarios conocidos (con usuario y
contrasena).
162
DE LA ARQUITECTURA QUE SOPORTAR A EL SISTEMA

4.1. P REPARACI ON
Servidor openERP y servidor web openERP
Se instalo y configuro el sistema openERP 6.0.0.3, usando Python 2.7 y PostgreSQL 9.1. Primero se instalo y configuro PostgreSQL creando el usuario
necesario para el acceso de openERP a la bases de datos.
Para la instalacion de openERP se utilizaron repositorios de Bazaar para facilitar actualizaciones futuras si fuera necesario. Bazaar es un sistema de control de versiones distribuido patrocinado por Canonical Ltd., disenado para
facilitar la contribucion en proyectos de software libre y opensource. Estos
repositorios contienen los siguientes componentes:
El servidor openERP
El servidor web openERP
Los Addons. Son modulos con las diferentes funcionalidades globales
(aptos para la mayora de empresas) openERP publicados por la comunidad detras de openERP.
Los Extra-Addons. Son modulos de la comunidad esta vez con funcionalidades mas verticales (para tipos de empresa concretos).
Addons para localizacion espanola. Estos modulos adaptan openERP a
la organizacion empresarial espanola (como sistema de contabilidad espanola).
Servidor openVPN
Se monto una red privada virtual utilizando openVPN. Los usuarios solo pueden
acceder si disponen de un certificado TLS de usuario con contrasena (expedidos por una CA propia creada en PubliFringe). Se ha formado a PubliFringe
sobre como crear y revocar certificados para sus comerciales. Existen 2 tipos
163

de usuarios: Uno estandar con acceso u nicamente al servicio web de openERP
y otro administrativo con acceso completo a openERP, al los ficheros compartidos y acceso ssh.
Firewall para permitir el acceso a los servicios exclusivamente a traves de la

red VPN
Utilizando la herramienta iptables para configurar el firewall del servidor. Se

configura con poltica por defecto denegar acceso. A partir de ah se conceden
los permisos mnimos para el correcto funcionamiento del servidor. Se concede acceso a internet (unicamente establecido por el servidor para para instalar actualizaciones de seguridad) y se concede acceso a los servicios u nicamente a traves de la VPN.
Servicio DNS dinamico y router
Se configura un servicio de DNS dinamico con DynDNS (es una compana de

Internet de los Estados Unidos de America dedicada a soluciones de DNS en
direcciones IP dinamicas) en el router para permitir el acceso desde el exterior. Tambien se configuro el router para redirigir hacia el servidor la conexion
VPN.
Sistema de backups y copia en imagen del servidor
Se uso la carpeta compartida como base de copias de seguridad locales. Incluye copias de ficheros que se desean proteger de los ordenadores locales
del personal interno de PubliFringe. Los ordenadores internos de PubliFringe
utilizan un programa de planificacion de tareas (Cobian Backup) para copiar
164
INICIAL SOBRE OPEN ERP.

4.2. F ORMACI ON
periodicamente los datos mas importantes.
Tambien en el servidor mediante el planificador de tareas cron se realizan

copias periodicas de las bases de datos de PostgreSQL.
Otros datos importantes como los archivos de configuracion importantes del

servidor VPN, los addons de openERP utilizados, codigo fuente surgido del
desarrollo, informacion para migrar de un sistema a otro. . . tambien son copiados en el extrable.
Por u ltimo tambien se guarda una copia de una imagen ISO de todo el disco duro del servidor. Esto ayudara a mejorar la velocidad de restauracion del
sistema en caso de fallo global del servidor. Se ha utilizado la herramienta
Clonezilla.
Tambien esta establecido como protocolo copiar este disco externo en un lugar seguro fuera de las oficinas de PubliFringe para no perder la informacion
en caso de fallo global en las oficinas.
4.2.
Formacion inicial sobre openERP.
El equipo de trabajo, formado por el alumno, Peter y Olivia se formaron sobre

las caractersticas de openERP mediante el auto-aprendizaje. Se estudio la documentacion a nivel de usuario y a nivel tecnico (esta documentacion solo el alumno).
Se realizaron varias pruebas con datos de prueba, intentos de migracion de datos,
probar casos reales, primeros cambios de configuracion del sistema. . . Todo para ir
introduciendo al equipo con la estructura y organizacion de openERP. Fue especialmente u til para Peter y Olivia que no tenan experiencia previa con este tipo de
165

sistemas integrales de informacion y era importante que conocieran las posibilidades
de estos sistema para poder empezar a especificar requisitos.
4.3.
Configuracion inicial openERP y migracion de

los primeros datos en el sistema.
Tras realizar algunas pruebas con el sistema openERP con datos de demostracion
en una base de datos de prueba, se prepara la primera instalacion formal del sistema
openERP adaptado a la configuracion que necesita PubliFringe. Esta instalacion realizada en una nueva base de datos contiene:
Configuracion inicial muy basica (Nombre de la empresa, usuarios, configuracion contable inicial. . . ),
Los modulos estables mas basicos.
Datos basicos de PubliFringe migrados del sistema antiguo (datos de clientes,
proveedores. . . ).
Se guardo una copia de seguridad de esta base de datos como referencia para no
empezar de cero en case de que se necesitara volver a empezar.
4.4.
Preparacion de los entornos de trabajo
La base de datos de referencia se clono para conseguir 3 bases de datos inicialmente iguales. Una de ellas fue utilizada como entorno de produccion para PubliFringe (para ser usada en un entorno real). Otras fue usada como entorno de pruebas para las versiones beta de nuevas funcionalidades o adaptaciones. La u ltima fue
utilizada para el desarrollo de nuevas funcionalidades o adaptaciones del sistema.
En los entornos de prueba y desarrollo se sustituyo la informacion real y sensible
(direcciones de correo electronico , telefonos. . . ) por informacion ficticia para evitar
166
CONTINUADA
4.5. D ESARROLLO ITERATIVO DE REQUISITOS Y FORMACI ON
problemas de confidencialidad.
El entorno de produccion inicialmente era muy poco funcional y se segua usando mucho el sistema anterior. Pero a medida que dicho entorno iba integrando
nuevas adaptaciones y nuevas funcionalidades dicho entorno se iba utilizando cada
vez y poco a poco se iba abandonando el sistema de informacion antiguo.
4.5.
Desarrollo iterativo de requisitos y formacion continuada
Como ya se especifico en la propuesta, los requisitos del nuevo sistema no estaba

del todo claros inicialmente. Por eso se propuso este sistema de desarrollo basado en
la metodologa Scrum en la que el desarrollo es iterativo. El ciclo de fases de desarrollo que se detallaran ha continuacion se realizaron repetidamente hasta satisfacer
los objetivos y alcance del proyecto.
4.5.1.
Especificacion y priorizacion de requisitos
Con la formacion inicial en ERP en curso y los entornos de trabajo preparados,

los gerentes Olivia y Peter asesorados por el alumno son capaces de especificar los
primeros requisitos. Estos requisitos se especificaban en lenguaje natural con ejemplos (usables en las pruebas) de manera similar que las historias utilizadas en Scrum.
Estos requisitos se priorizaron en funcion de una estimacion informal del coste
estimado para su realizacion (en tiempo y recursos) y en funcion del impacto que
tiene este requisito respecto a los objetivos del proyecto. As se priorizaban los requisitos que cumplan las necesidades mas basicas para PubliFringe para que as el
entorno de produccion fuera volviendose mas funcional.
167

4.5.2.
Desarrollo de los requisitos
Siguiendo propuestas y restricciones de captulos anteriores se evito en la medida de lo posible el desarrollo a medida. Con eso se buscaba ahorrar costes en tiempo
y recursos de desarrollo (y su correspondiente fase de pruebas). Esto se aplicaba
especialmente en los requisitos relacionados con las partes de menor valor para el
cliente en la cadena de valor de PubliFringe (administracion, facturacion. . . ).
Para el desarrollo o satisfaccion de requisitos, existieron 4 tipos de modificaciones. A continuacion se muestran ordenados por prioridad de uso:
Modificaciones de configuracion. Estas modificaciones no requieren conocimientos tecnicos ya que se cambian mediante las opciones disponibles en la interfaz
del sistema.
Instalando y configurando un modulo existente de la comunidad openERP.
Normalmente tampoco requiere conocimientos tecnicos.
Adaptacion de algun modulo existente (anadiendo campos, botones, modificando funciones, texto. . . ).
Desarrollo a medida de un nuevo modulo.
La comunidad openERP es grande y la mayora de requisitos comunes y basicos
en las empresas disponen de un modulo (Addon) generalmente bastante estable que
lo satisface. La mayora de los primeros requisitos se satisfacieron con modulos
existentes en la comunidad openERP.
4.5.3.
Prueba de los cambios realizados para cumplir los requisitos y formacion sobre los mismos
Cuando un requisito quedaba desarrollado en el entorno de desarrollo, se integraba en el entorno de prueba. En ese entorno los beta testers del equipo probaban
168
CONTINUADA
4.5. D ESARROLLO ITERATIVO DE REQUISITOS Y FORMACI ON
que el nuevo requisito se cumpla y si era u til.
A veces se daba el caso que el requisito no se cumpla o haba errores en las
modificaciones. Es ese caso se correga en el entorno de desarrollo y se volva a integrar en el entorno de prueba.
Si era necesario el equipo de beta testers Peter y Olivia reciban la formacion
necesaria para utilizar las nuevas funcionalidades (y as poder probarlas).
Este paso de pruebas se repite hasta que el requisito se considere apto para el
entorno de produccion.
4.5.4.
Incorporacion de los cambios aprobados al entorno de produccion
Si tras las pruebas se consideraba el requisito apto para entrar en el entorno de

produccion, se integraba en dicho entorno. Aunque la fase de implantacion no estuviera completamente terminada este entorno ya era usado en produccion. A medida
que se enriqueca el entorno de produccion, menos se usaba el antiguo sistema de
informacion.
4.5.5.
Analizar cumplimiento objetivos y alcance del proyecto
A medida que se iban finalizando requisitos y siendo usados en produccion van

surgiendo nuevos requisitos. Estos nuevos requisitos se analizaban y si formaban
parte de los objetivos y alcance del proyecto se especificaban en una nueva iteracion
de desarrollo. Si quedaban fuera del alcance del proyecto se guardaban como proyectos de mejora futuros.
169

4.6.
Detalles tecnicos de la implantacion
En esta seccion se va a explicar la estructura de los componentes desarrollados

para satisfacer los requisitos que fueron surgiendo.
Para empezar se explicaran brevemente las caractersticas tecnicas de openERP
que han permitido su desarrollo.
Es un sistema cliente/servidor que funciona sobre una red IP.
Utiliza el lenguaje de programacion Python.
Utiliza tecnologas orientadas a objetos.
Registra sus datos con una base de datos PostgreSQL relacional.
Sus objetos de negocio se modelan con un sistema ORM 1.5.16.
Ofrece varias tipos de interfaces de usuario: un cliente GTK y un cliente web.
Utiliza ReportLab para la generacion de informe en (PDF).
Utiliza XML para propositos varios: descripcion de datos, vistas, informes,
datos de transporte (XML-RPC 1.5.17).
Figura 4.1: Arquitectura openERP
170

4.6. D ETALLES T E CNICOS DE LA IMPLANTACI ON
En openERP tambien se puede aplicar el patron de diseno MVC 1.5.18 de la
siguiente forma:
Modelo: Las tablas de la base de datos PostgreSQL.
Vista: Las vistas de openERP definidas en ficheros XML.
Controlador: Los objetos de openERP.
Muchos de los requisitos que fueron surgiendo a lo largo de las iteraciones se
pudieron satisfacer con cambios en la configuracion del sistema y/o anadiendo y
configurando nuevos modulos desarrollados por la comunidad openERP.
Para todos los requisitos que se tuvieron que satisfacer mediante adaptaciones de
modulos existentes, el alumno desarrollo un modulo (addon) para contener todas las
adaptaciones especficas de PubliFringe. Utilizando tecnicas de herencia propias de
la programacion orientada a objetos el alumno pudo anadir campos de informacion a
los objetos de negocio existentes en otros modulos, modificando sus funciones, modificando las vistas. . . Tambien utilizo el modulo para importar los datos necesarios
para la correcta configuracion de las adaptaciones. De esta manera se consiguio que
una persona no tecnica pueda aplicar las adaptaciones de PubliFringe en una nueva
base de datos simplemente instalando el modulo.
Las principales caractersticas de este modulo son:
Pequenas modificaciones en las Vistas y en los objetos de negocio.
Creacion de grupos y perfiles de usuario adaptados a PubliFringe (comerciales, contables junior, gerentes. . . ) para la seguridad de openERP. OpenERP propone una serie de grupos o perfiles de usuarios que no satisfacan las
necesidades de PubliFringe. Eso era debido a que estos grupos ofrecas demasiados privilegios y accesos a informacion que los comerciales no deberan
ver.
171

Mejora de los informes generados con openERP. Se adaptaron las facturas,
presupuestos. . . a las necesidades de PubliFringe tanto en la informacion que
ofrecan como en el diseno estetico.
Tambien se desarrollo un modulo completamente a medida para la gestion de
comisiones de los comerciales. En la comunidad de openERP existen modulos que
gestionan comisiones. El motivo del desarrollo a medida en lugar de adoptar alguno
de los modulos existente fue que dichos modulos no se adaptaban a las necesidades
de PubliFringe. No se adaptaban principalmente porque son modulos extranjeros que
no tenan en consideracion la ineficacia de la ley de morosidad en Espana. Ademas
no se opto por modificarlos debido a que tampoco eran estables.
Este modulo de gestion de comisiones crea nuevos objetos de negocio, vistas. . . y
modifica otros existentes para conseguir calcular y mostrar a PubliFringe cuanto
debe a los comerciales en comisiones mensualmente. El modulo de adaptaciones de
PubliFringe tambien otorgara acceso a los comerciales al modulo de comisiones
(aunque solo podra ver su caso, el de otros comerciales no le sera accesible)
172
Captulo 5
Analisis final
En este u ltimo captulo se mostrara la planificacion total del proyecto y con sus
costes en tiempo y recursos. Tambien se analizara el resultado final del proyecto y
se sacaran conclusiones y expectativas de futuro.
La planificacion del proyecto fue ajustandose a medida que se iba disponiendo
de mas informacion a medida que avanzaba el proyecto.
Esta planificacion inicial y los costes estimados iban destinados a satisfacer los
objetivos iniciales de este proyecto:
Implantar una estrategia CRM en la organizacion.
Buscar innovacion o mejorar los procesos de la empresa.
Implantar un sistema de informacion integrado.
Se dejo un tiempo de margen para compensar posibles incidencias o fallos en la
estimacion. Tambien se esperaba anadir costes en otros recursos (ademas del trabajo
del alumno) una vez fuera escogida la solucion tecnologica del proyecto.
A continuacion se mostrara la planificacion inicial de este proyecto:
173

FINAL
Comienzo
Fin
Duracion (horas)
Analisis de objetivos y necesidades de la empresa
Nombre de tarea
03/10/11
04/10/11
Analisis de necesidad del cambio
04/10/11
05/10/11
Estudio de las consideraciones previas
05/10/11
06/10/11
Analisis de los procesos actuales de la empresa
06/10/11
17/10/11
25
Definicion de objetivos y desafos de la solucion a proponer
17/10/11
18/10/11
Investigacion de mercado
18/10/11
31/10/11
35
Seleccion de solucion tecnologica y aprendizaje
31/10/11
14/11/11
40
Planificacion de cambios en la solucion
14/11/11
21/11/11
20
Preparacion del entorno de implantacion
21/11/11
24/11/11
15
Proceso de implantacion
24/11/11
02/02/12
200
Analisis final del proyecto
02/02/12
06/02/12
Margen
06/02/12
29/02/12
71
Total horas
435
Coste por hora
7C
Coste Total
3.045 C
inicial del proyecto

Cuadro 5.1: Planificacion
La planificacion se cumplio sin incidencias relevantes hasta el momento en el

que se escogio la solucion tecnologica del proyecto. En ese momento se estimaron
los siguientes costes adicionales:
Servidor dedicado
Coste
Vida util
Coste anual
Servidor
600,00 C
3 anos
200,00 C
Router/firewall
200,00 C
5 anos
40,00 C
Disco duro externo
100,00 C
5 anos
20,00 C
Mantenimiento
100,00 C
1 ano
100,00 C
Total
360,00 C
Recurso/Servicio

174
En ese momento ya se tena mas claro como satisfacer los objetivos del proyecto.
Estos nuevos costes (con una inversion inicial de unos 1.000 C) ayudaran a lo que
sigue:
Construir una arquitectura TI que soportara el sistema.
Implantar el sistema de informacion openERP con sus funcionalidades que
dan soporte a la estrategia CRM.
Adaptarse o adaptar el nuevo sistema a los procesos de PubliFringe.
A principios del 2012 se realizo un cambio en la planificacion inicial. Este
cambio fue causado por la necesidad de ampliar las funcionalidades del nuevo sistema. El tiempo reservado como margen no era suficiente como para permitir la
implantacion de las nuevas funcionalidades al sistema. Esto se debio a que el tiempo
reservado se fue consumiendo a lo largo de todo el proyecto en parte en tiempo de
auto-aprendizaje, que resulto mas extenso de lo esperado. Tambien se consumio en
otros proyectos (proyectos web de PubliFringe, consultora TI ajena a este proyecto. . . ) ajenos a este proyecto de final de carrera.
Los objetivos de la ampliacion eran:
Desarrollo de un modulo nuevo para openERP (addon) completamente adaptado a PubliFringe con funcionalidades que dan soporte a la gestion de comisiones.
Adaptacion de la seguridad del sistema openERP para permitir el acceso restringido a usuario con los siguientes roles (personalizados para PubliFringe):
Gestor de cuentas.
Contable Junior.
Cambios y mejoras menores en el sistema.
175

FINAL
Comienzo
Fin
Duracion (horas)
Analisis de objetivos y necesidades de la empresa
Nombre de tarea
03/10/11
04/10/11
Analisis de necesidad del cambio
04/10/11
05/10/11
Estudio de las consideraciones previas
05/10/11
06/10/11
Analisis de los procesos actuales de la empresa
06/10/11
17/10/11
25
Definicion de objetivos y desafos de la solucion a proponer
17/10/11
18/10/11
Investigacion de mercado
18/10/11
31/10/11
35
Seleccion de solucion tecnologica y aprendizaje
31/10/11
14/11/11
40
Planificacion de cambios en la solucion
14/11/11
21/11/11
20
Preparacion del entorno de implantacion
21/11/11
24/11/11
15
Proceso de implantacion
24/11/11
22/03/12
325
Analisis final del proyecto
22/03/12
26/02/12
Margen
26/02/12
28/03/12
26
Total horas
515
Coste por hora
7C
Coste Total
3.605 C
extendida del proyecto

Cuadro 5.3: Planificacion
Por todo lo anterior se decidio extender el proyecto un mes mas (80 horas de
trabajo adicionales), quedando la planificacion como sigue a continuacion:
A continuacion se muestran los costes totales del proyecto de final de carrera:
Recursos
Coste recursos
Alumno (515 horas de trabajo)
3.605 C
Infraestructura TI
1.000 C
Trabajadores PubliFringe
No suponen coste adicional

4.605 C
Total
Cuadro 5.4: Costes del proyecto
Hasta este punto se han cumplido, al menos, los objetivos mnimos del proyecto:
Implantar un sistema de informacion integrado.
176
Se ha implantado con e xito el sistema de informacion integrado openERP. El

personal de PubliFringe se ha adaptado a su uso y ha supuesto una mejora dejando atras los problemas encontrados al inicio del proyecto (informacion dispersa, poco sincronizada entre el personal de PubliFringe, datos repetidos. . . ).
Implantar una estrategia CRM en la organizacion.
El sistema openERP incluye funcionalidades que dan soporte a la estrategia

CRM que PubliFringe utilizara para mejorar su relacion con los clientes.
Buscar innovacion o mejorar los procesos de la empresa.
Se ha aprovechado el cambio de sistema de informacion para realizar un analisis de los procesos de PubliFringe para buscar posibles mejoras nuevas maneras de proceder. Gracias a esto se han podido adaptar a los procesos que propone el sistema openERP (los que se consideraron mejores que los usados por
PubliFringe). Tambien se adaptaron los procesos de openERP que podan ser
mejorados segun las necesidades de PubliFringe. Se ha buscado la innovacion
no solo tecnologica (con la implantacion del nuevo sistema) sino a nivel de
empresa. Esto u ltimo a resultado en una evolucion constante en las estrategias
de PubliFringe y en sus procesos a lo largo de toda la duracion del proyecto.
Se ha considerado que el proyecto de final de carrera ha cumplido, al menos,
los objetivos mnimos debido a que el sistema de informacion de PubliFringe queda
abierto a muchas mejoras o ampliaciones mas. Entre otras, algunas expectativas de
futuro de PubliFringe:
Conectar el sistema openERP a la web corporativa de la empresa y a una nueva
tienda de servicios online (e-commerce).
Incluir soporte a la facturacion electronica.
177

FINAL
Extender las funcionalidades del modulo (addon) de gestion de comisiones.
Extender o mejorar la gestion de la seguridad de los usuarios en openERP
(anadiendo nuevos roles o tipos de acceso).
Aplicar una estrategia SRM 1.5.6 y mejorar o ampliar el soporte de openERP
a dicha estrategia. Se detecto, durante la elaboracion de la propuesta (en el
captulo 3, analizando la cadena de valor de PubliFringe), el valor que aporta
la relacion con los proveedores a los clientes de PubliFringe.
Seguir mejorando e innovando de manera continua adaptandose a los cambios
que puedan surgir en PubliFringe, en el mercado, nuevas oportunidades. . .
178
Bibliografa
[1] ((5 pasos a la mejora eficaz de procesos - Septiembre 2011)).
http://teodorabozheva.blogspot.com/2011/02/
5-pasos-la-mejora-eficaz-de-procesos.html
[2] ((Abanq - Octubre 2011)).
http://abanq.org/
[3] ((aDempiere - Octubre 2011)).
http://www.adempiere.com/ADempiere_ERP
[4] ((Check-list de la calidad del sistema de medicion - Septiembre 2011)).
check-list-de-la-calidad-del-sistema-de.html
[5] ((CK-ERP - Octubre 2011)).
http://ck-erp.net/drupal/
[6] ((Claves e xito implantacion CRM - Septiembre 2011)).
http://www.fotosok.com/sistemascrm/implantar-crm.htm
[7] ((Compiere - Octubre 2011)).
http://www.compiere.com/
[8] ((Configuracion Samba - Octubre 2011)).
http://www.linuxparatodos.net/portal/staticpages/index.php?
page=13-como-samba
179
B IBLIOGRAFI A
[9] ((Consejos escritura PFC - Septiembre 2011)).
http://jpgarcia.blogs.upv.es/2009/10/20/
como-escribir-poryectos-fin-de-carrera/
[10] ((Consultora OpenERP - Enero 2012)).
http://www.anajuaristi.com/
[11] ((Documentacion ESXi 5.0 - Enero 2012)).
http://www.vmware.com/support/pubs/
[12] ((Documentacion openERP - Noviembre 2012)).
http://doc.openerp.com/v6.0/
[13] ((Documentacion openVPN - Enero 2012)).
http://openvpn.net/index.php/open-source/documentation/howto.
html
[14] ((Dolibarr - Octubre 2011)).
http://www.dolibarr.es/
[15] ((ERP5 - Octubre 2011)).
http://www.erp5.org/
[16] ((Gestion de la innovacion - Septiembre 2011)).
http://www.monografias.com/trabajos34/
innovacion-y-competitividad/innovacion-y-competitividad.
shtml
[17] ((Gestion de la innovacion tecnologica en el mundo empresarial del siglo XXI
- Septiembre 2011)).
http://www.monografias.com/trabajos37/
innovacion-tecnologica-empresarial/innovacion-tecnologica-empresarial.
shtml
180
B IBLIOGRAFI A
[18] ((Gua practica de definicion de metricas de proceso - Septiembre 2011)).
guia-practica-de-definicion-de-metricas.html
[19] ((Instalacion openERP v6 sobre Ubuntu - Noviembre 2011)).
http://www.malagatic.com/blog/item/27-instalaci%C3%
B3n-openerp-v6-sobre-ubuntu-1004-lts
[20] ((Instalacion Ubuntu con sistema LVM - Octubre 2011)).
http://www.linuxbsdos.com/2011/05/10/
how-to-install-ubuntu-11-04-on-an-encrypted-lvm-file-system/
[21] ((KEME-Contabilidad - Octubre 2011)).
http://keme.sourceforge.net/
[22] ((Las principales diferencias entre Gestion cuantitativa y Medicion y analisis Septiembre 2011)).
que-diferencia-hay-entre-medicion-y.html
[23] ((Libertya - Octubre 2011)).
http://www.libertya.org/
[24] ((Mejora e innovacion de procesos - Septiembre 2011)).
http://www.gestiopolis.com/canales/gerencial/articulos/44/
mejinnoproceso.htm
[25] ((Modelo de Madurez CRM - Septiembre 2011)).
http://fidelimania.com/2011/09/modelo-de-madurez-crm/
[26] ((OpenBravo - Octubre 2011)).
http://www.openbravo.com/es/
[27] ((OpenTaps - Octubre 2011)).
http://www.opentaps.org/
181
B IBLIOGRAFI A
[28] ((Phreebooks - Octubre 2011)).
http://www.phreesoft.com/
[29] ((Preguntas y Respuestas sobre Reingeniera de Procesos - Septiembre 2011)).
http://www.monografias.com/trabajos18/preguntas-reingenieria/
preguntas-reingenieria.shtml
[30] ((Proceso de Innovacion - Septiembre 2011)).
http://www.pymesyautonomos.com/estrategia/
el-proceso-de-la-innovacion
[31] ((Procesos de innovacion - Septiembre 2011)).
http://www.fecyt.es/especiales/papel_informacion/procesos.htm
[32] ((SaltOS - Octubre 2011)).
http://www.saltos.net/portal/es/saltos.htm
[33] ((Seguridad, DMZ y VPN - Noviembre 2011)).
http://www.securityartwork.es/2009/06/23/%C2%
BFpero-que-me-metes-en-la-dmz/
[34] ((SugarCRM - Octubre 2011)).
http://www.sugarcrm.com/crm/
[35] ((Tryton - Octubre 2011)).
http://www.tryton.org/es/
[36] ((Virtualizacion - Diciembre 2011)).
http://www.csospain.es/La-virtualizacion-puede-aportar-mejoras-a-la-seg
seccion-actualidad/noticia-88484
[37] ((vTiger - Octubre 2011)).
http://crmevolutivo.com/
[38] ((WebERP - Octubre 2011)).
http://www.weberp.org/HomePage
182
B IBLIOGRAFI A
[39] ((Wikipedia - Septiembre 2011 / Marzo 2012)).
http://wikipedia.org/
[40] ((xTuple PostBooks - Octubre 2011)).
http://www.xtuple.com/postbooks
[41] ((Como mantener la mejora de los procesos? - Septiembre 2011)).
como-mantener-la-mejora-de-los-procesos.html
[42]
DEL
BARRIO P ERALTA, O RIOL: Estudi i implantacio de CRM (Customer
Relationship Management) a Nexe. Pfc, Llenguatges i Sistemes Informàtics

(LSI), 2009.
[43] M ARQUEZ
, JAVIER C ELMA: Gua para la seleccion de un ERP en la pequena o
microempresa. Pfc, Departamento de Organizacion de Empresas, Universidad
Politecnica de Barcelona, Spain, 2008.
183
Apendice A
Preguntas previas para determinar la

necesidad de un nuevo sistema de
informacion
Existe la necesidad de un sistema de informacion actualizado si:
1. Surgen necesidades de gestion administrativa o de informacion que no cubre

el sistema actual.
2. Se realizan tareas de forma poco racional o con mucho trabajo.
4. Se quiere actuar de forma mas global, en mas ubicacones y con distintas actividades.
5. El hardware de la empresa esta anticuado en prestaciones.
185
A P E NDICE A. P REGUNTAS PREVIAS PARA DETERMINAR LA NECESIDAD DE UN
NUEVO SISTEMA DE INFORMACI ON

6. El sector, el tipo de actividad y la competencia hacen que surja la necesidad
de instalar un nueva sistema de gestion mas eficaz.
7. Se necesita gestionar y estructurar mejor el conocimiento del negocio y aumentar la independencia empresa-empleado.
8. Se dispone de un sistema de informacion desfasado en prestaciones.
distintos puntos del sistema.
10. Los usuarios usan software online, hojas de caculo o pequenas aplicaciones de
bases de datos para hacer su trabajo o mantener la informacion que necesitan
para desempenarlo.
12. Se tienen problemas de gestion de inventario, no se sabe que tienes en el inventario y lo que cuesta.
13. Hay quejas crecientes de los trabajadores respecto a que no pueden trabajar lo
rapido que querran por culpa del sistema.
14. Cada vez es mas dficil cumplir los requerimientos que se piden de formato y
tiempos de entrega cuando se nos pide cierta informacion tanto por parte de
186
los clientes como de los partners.
15. No se esta sacando el suficiente provecho de internet.
16. Se ha pensado o descrito las actuales virtudes y deficiencias de nuestro actual

sistema, y las deficiencias son importantes como para afectar significativamente al rendimiento global de la empresa.
17. La empresa no podra funcionar sin la presencia del gerente.
18. Si un comercial deja la empresa se perdera el negocio.
19. Da la sentacion de no poder controlar la empresa, ya no se conocen todos los

detalles del negocio o no se conocen todos los productos que se venden y sus
precios.
20. Existen oportunidades de negocio que mi empresa querra abordar pero el sistema actual no podra abarcar las nuevas actividades.
21. Se necesita que algunos clientes tengan una entrada a mi sistema y actualmente no la tienen.
22. No se conocen que productos o servicios del negocio dan mas rentabilidad
economica.
23. Se utiliza un alto porcentaje de las funcionalidades del sistema actual, y no

existe posibilidad de ampliarlas ante nuevos requisitos que van surgiendo en
187
A P E NDICE A. P REGUNTAS PREVIAS PARA DETERMINAR LA NECESIDAD DE UN
NUEVO SISTEMA DE INFORMACI ON

la empresa. (el sistema quedara inestable).
188
Apendice B
Consideraciones previas para

empezar con la seleccion de un nuevo
sistema de informacion
Cuestiones que se deben planterar para saber si se esta realmente interesado y
preparado para seleccionar un nuevo sistema de informacion:
1. Se ha calculado el presupuesto que tiene la empresa para adquirir un nuevo

sistema de informacion.
2. Se ha pensado en el tipo de sistema de informacion que podra interesar y los

motivos.
3. Se ha pensado en si existen los medios humanos y materiales para adquirir e

instalar el sistema de forma o ptima.
4. La empresa dispone de personal con conocimientos informaticos que pueda

abordar el proyecto.
189
A P E NDICE B. C ONSIDERACIONES PREVIAS PARA EMPEZAR CON LA

DE UN NUEVO SISTEMA DE INFORMACI ON
SELECCI ON
5. Se tiene claro que el lder del proyecto es el gerente de la empresa, en referencia a la estrategia y los objetivos de e ste.
6. Se ha considerado si se deben efectuar muchos cambios en las funciones y

sistemas de los trabajos actuales.
7. Se ha analizado si el tipo de hardware existente es el adecuado para trabajar

con el sistema de informacion.
8. Se ha medido el impacto que puede tener en la manera de trabajar de los usuarios en un nuevo sistema.
9. Se ha realizado el analisis de la forma en que se va a financiar el proyecto.
10. Se ha valorado el tiempo adicional que necesitan la personas implicadas.
11. Se puede realizar la implantacion con los recursos actuales.
12. Existe personal suficiente para trabajar e introducir los datos en el nuevo sistema, valorando la cantidad de datos y la comprobacion de los mismos.
13. Se ha analizado el impacto que tendra, desde el punto de vista de recursos

humanos, el nuevo sistema en toda su amplitud.
14. Se ha analizado que, segun el tipo de empresa, actividad, facturacion, compras, etc...; es necesario implantar un determinado tipo de sistema.
190
15. Se ha tenido en cuenta la existencia de todos los programas de gestion y bases

de datos que existen en la empresa, para ser transladados al nuevo sistema de
informacion.
16. Se ha pensado el tiempo de formacion y practicas que deberan invertir los

usuarios y como van a disponer de mas tiempo para realizar su tarea habitual,
y al mismo tiempo, ir adaptandose al nuevo sistema.
17. Se ha analizado la cantidad de datos de los programas antiguos que deben ser
correctos para trasladarlos a la nueva aplicacion.
18. Se ha pensado en la forma de realizar el cambio de sistema, evitando procesos

paralelos y trabajos adicionales.
19. Se han definido los objetivos y mejoras a realizar con el nuevo sistema de informacion a nivel de departamento y puesto de trabajo.
20. Se ha analizado el nivel de seguridad de datos que se quiere tener en la empresa, sabiendo que es variable segun la actividad y sector.
21. Se han tenido en cuenta los plazos previos a la instalacion, los plazos de la
misma y la fecha de implantacion final.
22. Se ha evaluado la posibilidad de implantar un sistema de informacion por

modulos, eligiendo los mas importantes y dejando el resto para mas adelante.
191
A P E NDICE B. C ONSIDERACIONES PREVIAS PARA EMPEZAR CON LA

DE UN NUEVO SISTEMA DE INFORMACI ON
SELECCI ON
23. Se ha evaluado el coste de adquirir un nuevo hardware, o bien, actualizar el ya
existente.
24. Se ha valorado el coste del mantenimiento para el nuevo hardware y software

necesarios.
25. Se ha valorado el coste adicional de personal anadido: nuevas incorporaciones,

formacion, practicas y creacion de manuales.
26. Se ha analizado quien posee la mejor gestion de conocimiento de la empresa

para colaborar en la implantacion del nuevo sistema.
192

Implementacion Sistemas

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Implementacion Sistemas

Transféré par

Droits d'auteur :

Formats disponibles

Ttol: Mejora e innovacion de procesos: Implantacion de un nuevo sistema de

informacion en una pyme

Directora: Tamara Alvarez

Autor: Marc Blando Coll

Departamento: Ingeniera de Servicios y Sistemas de Informacion

Alumno: Marc Blando Coll

Director/Ponente: Tamara Alvarez

Me lo contaron y lo olvide. Lo vi y lo entend. Lo hice y lo aprend.

Memorias dedicadas a toda mi familia, a Jennifer, el amor de mi vida y a mi gato

Agradezco a mi ponente y a las personas de la empresa que ha hecho posible este

1.1. Alcance de proyecto . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . .

1.3. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . .

1.4. Presentacion alumno y motivacion . . . . . . . . . . . . . . . . . .

1.5.1. Cadena de valor . . . . . . . . . . . . . . . . . . . . . . . .

1.5.2. Tecnologas de la informacion (TI) . . . . . . . . . . . . . .

1.5.3. Sistema de informacion (SI) . . . . . . . . . . . . . . . . .

1.5.4. Planificacion de recursos empresariales (ERP) . . . . . . . .

1.5.5. Administracion basada en la relacion con los clientes (CRM)

1.5.6. La gestion de las relaciones con los proveedores (SRM) . .

1.5.7. Software propietario . . . . . . . . . . . . . . . . . . . . .

1.5.8. Software libre . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.10. Cloud Computing . . . . . . . . . . . . . . . . . . . . . . .

1.5.11. Proceso de negocio . . . . . . . . . . . . . . . . . . . . . .

1.5.12. Innovacion y mejora de procesos . . . . . . . . . . . . . . .

1.5.13. Reingeniera de procesos . . . . . . . . . . . . . . . . . . .

1.5.14. Metodologa de desarrollo de software tradicional . . . . . .

1.5.15. Metodologas a giles de desarrollo de software . . . . . . . .

1.5.16. Mapeo objeto-relacional . . . . . . . . . . . . . . . . . . .

1.5.18. Patron de diseno Modelo-Vista-Controlador (MVC) . . . .

2.1. Situacion inicial de la empresa . . . . . . . . . . . . . . . . . . . .

2.2. Analisis de la necesidad de un cambio . . . . . . . . . . . . . . . .

2.3. Consideraciones previas al cambio . . . . . . . . . . . . . . . . . .

2.4. Virtudes y defectos del sistema de informacion actual . . . . . . . .

2.5. Procesos actuales de la empresa . . . . . . . . . . . . . . . . . . .

2.5.1. Servicio generico . . . . . . . . . . . . . . . . . . . . . . .

2.5.2. Seleccion de comerciales . . . . . . . . . . . . . . . . . . .

2.5.3. Formacion y supervision de comerciales . . . . . . . . . . .

2.5.4. Recopilar clientes potenciales . . . . . . . . . . . . . . . .

2.5.6. Gestion de agenda . . . . . . . . . . . . . . . . . . . . . .

3. Propuesta de innovacion y mejora

3.1. Problema a revolver . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Estructura de la propuesta . . . . . . . . . . . . . . . . . . . . . . .

3.4. Innovacion tecnologica . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1. Alternativas disponibles . . . . . . . . . . . . . . . . . . .

3.4.2. Seleccionar una alternativa . . . . . . . . . . . . . . . . . .

3.4.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . 138

4.1. Preparacion de la arquitectura que soportara el sistema . . . . . . . 162

A. Preguntas previas para determinar la necesidad de un nuevo sistema de

B. Consideraciones previas para empezar con la seleccion de un nuevo sistema de informacion

1.2. Estructura general de Metrica v3 . . . . . . . . . . . . . . . . . . .

1.3. Proceso scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4. Patron de diseno MVC . . . . . . . . . . . . . . . . . . . . . . . .

2.1. Vision global de un servicio . . . . . . . . . . . . . . . . . . . . .

2.3. Cierre de presupuesto . . . . . . . . . . . . . . . . . . . . . . . . .

2.4. Gestion de presupuestos . . . . . . . . . . . . . . . . . . . . . . .

2.5. Apoyo tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6. Gestion proveedores . . . . . . . . . . . . . . . . . . . . . . . . .

2.7. Gestion de servicio . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8. Gestion de facturas de cliente . . . . . . . . . . . . . . . . . . . . .

2.9. Gestion de comisiones . . . . . . . . . . . . . . . . . . . . . . . .

2.10. Seleccion de comerciales . . . . . . . . . . . . . . . . . . . . . . .

2.11. Publicacion oferta . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.13. Formacion y supervision de comerciales . . . . . . . . . . . . . . .