Está en la página 1de 12

Inicio del proyecto

6.1. Razones que justificaron llevarlo a cabo. ¿Cuál es la problemática o las necesidades de la
empresa o del departamento?

Conocer información real sobre las ventas, ya que la única información disponible en ese
momento era la contabilidad (facturación), y poder analizarla.

6.2. ¿Estaba alineado con los objetivos del negocio? En caso afirmativo, ¿cómo?

Estamos hablando de un caso en que no se analiza la información disponible de cara a la


gestión de la compañía, lo cual aportará ayuda a nivel general para la toma de decisiones.

Esto implica que obviamente el proyecto esté alineado con los objetivos del negocio, puesto
que el análisis de información permitirá, entre otras cosas, detectar puntos fuertes y puntos
débiles de los diferentes aspectos de la empresa, posibilitando de esta manera la mejora y
optimización de aquellos procesos que sean mejorables y que sólo se pueden detectar
mediante el modelo de análisis.

6.3. ¿Cuál era la estimación de la contribución del proyecto (tanto los beneficios financieros,
como los no financieros)?

Como se ha comentado anteriormente, se esperan obtener tanto beneficios financieros como


no financieros, al disponer de la información para la toma de decisiones. En la fase en la que se
encuentra el proyecto son difícilmente cuantificables.

6.4. ¿Se construyó un Business Case para su aprobación? En caso afirmativo, ¿cuáles fueron
los componentes básicos del Business Case?

No se realizó un Business Case.

6.5. ¿Cómo se aprobó el proyecto? ¿Cuáles fueron los criterios que se tuvieron en cuenta? Si
se hicieron cálculos de retorno de la inversión (ROI) o de plazo de recuperación (Payback),
adjuntarlos.

El proyecto fue propuesto directamente por la Dirección General, consciente de la necesidad


de disponer de información para análisis, lo que permitiría mejorar la gestión.

6.6. ¿Quién fue el directivo espónsor del proyecto?

Dirección General.

6.7. ¿Cuáles fueron los requerimientos de negocio? ¿Conocían los usuarios de negocio las
herramientas de Business Intelligence?

Los usuarios no conocían las herramientas de Business Intelligence. Los requerimientos


fueron: análisis financiero, la calidad de servicio de los pedidos, y un cuadro de mando
reducido (o resumen) del financiero.

6.8. ¿Se planteó desarrollar la solución de Business Intelligence?

No, puesto que ya existen soluciones en el mercado.


6.9. ¿Se evaluaron distintas soluciones de Business Intelligence? En caso de que se siguiera
un procedimiento formal, detállelo. ¿Cuál fue la solución escogida?

No se evaluaron distintas soluciones, ya que desde el primer momento el Director General


apostó por implantar QlikView como herramienta con la que realizar el proyecto. La capacidad
de análisis off-line y la baja curva de periodo de aprendizaje fueron factores decisivos para su
elección.

6.10. ¿Se evaluaron distintos implementadores? En caso de que se siguiera un


procedimiento formal, detállelo. ¿Cuál fue el implementador escogido?

La solución la implantó Hound Line, quien mostró las funcionalidades de QlikView a Dirección
General.

7. Planificación

7.1. ¿Cuáles eran los objetivos del proyecto?

El objetivo principal era crear un cuadro de mando que permitiera al departamento financiero
observar de forma ágil y simple la evolución del negocio, así como posicionar a cada uno de los
integrantes del departamento Comercial respecto a su contribución a las ventas.

7.2. ¿Cuál era el alcance del proyecto? ¿Cuáles son las áreas de negocio o departamentos a
los que se dirige? ¿A cuántos usuarios y con qué perfiles?

Áreas implicadas: Económico-financiera, Comercial y Logística.

Nº de usuarios: 15. Perfiles:

Dirección General, Dirección Financiera, Comerciales.

7.3. ¿Qué riesgos se detectaron? ¿Existían planes de contingencia o de mitigación de


riesgos?

El riesgo detectado fue el desconocimiento por parte de Embega de los datos de origen. Para
mitigar este riesgo, se acordó desarrollar únicamente aquellas partes que estuvieran
totalmente especificadas.

7.4. ¿Se establecieron limitaciones al proyecto?

Las indicadas anteriormente.

7.5. ¿Cuáles fueron los supuestos que se tuvieron en cuenta?

No se hicieron supuestos adicionales.

7.6. ¿Se utilizó una metodología específica? Descríbala.

- Análisis de necesidades.

- Análisis de datos disponibles.

- Modelización de los datos.

- Procesos de alimentación.

- Diseño del front-end.


- Aprobación usuarios.

El proyecto se dividió en 3 fases principales: La primera, para definir los datos de origen útiles
y crear con ello una base de datos intermedia. La segunda fue la construcción del modelo en
QlikView y el diseño del primer prototipo de documento que debía permitir un feedback por
parte del usuario, este feedback nos puede llevar a la primera fase y así sucesivamente hasta
llegar a un documento maduro. La tercera y última fue el diseño propiamente dicho de los
distintos documentos QlikView indicados para dar respuesta a los requerimientos iniciales.

Primera Fase: Construcción del Data Mart.

En esta primera fase, Embega facilitó la descripción de los campos y las tablas candidatas a
formar parte del Data Mart final.

El Data Mart que servirá como origen de datos a QlikView se construye sobre SQLServer, como
una base de datos. El proceso de ETL de Geminix (E.R.P.) a SQLServer se implementa
aprovechando las herramientas específicas de SQLServer, las DTS (Data Transformation
Services).

Dividimos el proceso de ETL en tres subfases, la Extracción de Datos de Geminix (E), las
Transformaciones necesarias (T) y las manipulaciones para cargar los datos a las tablas finales
del Data Mart (L).

En esta fase elegimos de Geminix qué campos y de qué tablas queremos extraer los datos
iniciales a tablas temporales en SqlServer.
Transformaciones.

Imagen

En esta fase nos servimos de las tablas temporales antes creadas para, por un lado, generar
una tabla de hechos (FACT) inicial y, por otro, cargar los maestros. La tabla FACT inicial se crea
a partir de los datos de facturas, albaranes y pedidos, aplicando transformaciones a cada paso
para acercarse lo más posible al resultado final esperado: por ejemplo, calculando indicadores
nuevos como combinación lineal de indicadores (campos) de Geminix.

Cargas:

Imagen

Esta es la DTS principal, donde se ejecutan todos los pasos antes descritos (paquete Geminix-
>Embega y Embega Cargas) más las ultimas transformaciones necesarias para acabar creando
el Data Mart final. Según el flujo del diagrama, lo primero que se ejecutará será la extracción
de los datos, a continuación, crearemos la definición de las tablas maestras (para que
posteriormente se inserten los datos), luego se ejecuta el paquete “Embega Cargas” que como
se comentó en el punto anterior crea la FACT y los maestros. Los siguientes pasos calculan
todos los indicadores necesarios en la FACT y intentamos aplicar a ésta una serie de directrices
de Embega para intentar cuadrar las ventas según contabilidad. De forma paralela, se carga
una tabla para la cartera de clientes.

Cargas del PG (Presupuesto General).

Imagen

Por otro lado, el Presupuesto asignado a las diferentes líneas de negocio se mantiene de forma
paralela al resto del proceso de ETL, pero al final se acabarán cruzando todos los datos en el
modelo de QlikView. Los datos de presupuestos se mantienen en Excel. Las previsiones de
presupuestos se cargan anualmente de forma incremental.

Segunda Fase: Modelo QlikView

La construcción del modelo en QlikView se plantea a priori bastante simple, ya que la mayor
parte del trabajo ya ha sido hecho en la construcción del Data Mart.
Las cargas en QlikView las podríamos clasificar de la siguiente forma:

- Carga Directa: El script del QlikView hace una carga directa desde el SQL Server por ODBC de
las tablas Artículos, Clientes, Direcciones de Envío, la Cartera, el PG y la FACT, relacionando
estas tablas como corresponda para mantener la lógica asociativa del software.

- Carga Externas: La tabla de Innovación se carga directamente desde el Excel


‘ProductosInnovación.xls’

- Islas Lógicas: El cálculo de los campos del resultado mensual y el acumulado, las ventas del
mes y su acumulado se hacen ejecutando una consulta en el script que agrupa las ventas o el
resultado según corresponda, dejando la tabla resultante sin ligar con el resto del documento.
Así, estos campos se comportan como valores fijos.

Tercera Fase: Documento final.

En esta fase se construye el aplicativo propiamente dicho, se definen las tablas, los gráficos y la
presentación del documento final. En el caso que nos ocupa se definieron tres documentos,
uno para el análisis financiero, otro para controlar la calidad de servicio de los pedidos y uno
más que actuaría como Cuadro de Mandos reducido (o resumen) del financiero. La definición
básica de los objetos a incluir en los documentos (tablas, gráficos, etc.), la da Embega.
HoundLine intenta responder a todos estos requerimientos, a la vez que cuida que se
aprovechen las capacidades “interactivas” de la herramienta de modo que el Cuadro de
Mando no se convierta en un informe estático.

7.1. ¿Se definió una planificación detallada de las principales actividades y tareas? Explique
los principales componentes de la planificación: recursos, plazos, costes estimados, etc.

En este caso y debido al pequeño tamaño del proyecto no se realizó planificación detallada.

7.2. ¿Cuántos componentes y de qué perfiles formaban el equipo de trabajo?

- 1 responsable por parte del cliente (Dirección Financiera).

- 1 responsable por parte del implantador.

- 1 Analista.

– 1 Programador

- 1 Informático del cliente conocedor de los orígenes de datos.

- Los usuarios del sistema en desarrollo.

7.1. ¿Se establecieron procedimientos de comunicación y aprobación de cambios?

No, debido al reducido tamaño del equipo de trabajo.

8. Diseño

8.1. ¿Cuáles son las fuentes de datos origen? ¿Se han tenido que modificar las aplicaciones
orígenes de datos?

El origen de los datos era directamente “Geminix” su ERP, por lo que, al no disponer de ningún
modelo analítico ni de ninguna agrupación del ERP, se decidió crear una base de datos
intermedia en SQLServer que reuniera únicamente la información requerida. Esta sería la
fuente de datos a explotar por QlikView. Se complementó con algunos datos en Excel,
concretamente los presupuestos, y se tuvieron que añadir algunos campos al ERP.

8.2. ¿Cuáles son los modelos de negocio cubiertos?

Ventas y logística.

8.3. ¿Cuáles son los modelos de datos?

Imagen

8.4. ¿Cuáles son los principales K.P.I. (Key Performance Indicators) utilizados?

Los principales KPi son de ventas, costes y márgenes.

Imagen

9. Ejecución

9.1. ¿Se comunicó el comienzo del proyecto a los componentes de la organización?

Sí, puesto que se requería la implicación de los usuarios.

9.2. ¿Con qué periodicidad se hacía el seguimiento de la planificación?

En caso de que no se hubiera planificado, ¿qué alternativa se escogió para realizar el


seguimiento del proyecto? El seguimiento se realizaba semanalmente, mediante reuniones de
seguimiento.

9.3. ¿Durante la ejecución del proyecto se ha desencadenado algún riesgo?En caso


afirmativo, ¿estaba planificado?, ¿existía plan de contingencia o mitigación?, ¿cómo se
resolvió?

El principal problema venía de la definición de “Ventas” por parte de Dirección Financiera, que
varió a lo largo del proyecto. Finalmente se adoptó la última definición sin más cambios.

9.4. ¿Existieron problemas con la calidad de los datos?

En caso afirmativo, ¿cuáles fueron? Hubo que realizar limpieza de muchos datos que estaban
erróneamente introducidos, como fechas de transacciones, descripciones y algunas
inconsistencias en la base de datos origen.

9.5. Mostrar un ejemplo del modelo de datos, dimensiones y pantallas de la solución.

Imagen
9.6. ¿Cuál ha sido el hardware instalado?

Se ha utilizado el servidor de SQL Server del que ya disponían, con 4 Gb de RAM para dar
soporte a los documentos QlikView.

9.7. ¿Cuáles han sido los productos y las licencias de software que se han adquirido (BBDD,
ETL, BI, SO, etc.)?

Indicar, en caso necesario, principales funcionalidades si se han adquirido distintos tipos de


licencias. 15 licencias QlikView, una de ellas de desarrollador y las demás de analista.

9.8. ¿Se han validado los resultados obtenidos con las fuentes de información?

Se han validado en la medida de lo posible, ya que en algunos casos no se ha podido realizar


este tipo de validación por el desconocimiento de los datos origen.

9.9. ¿Cuál es el tamaño de la base de datos?

Entre 300.000 y 500.000 registros en total.

9.10. ¿Se han llevado a cabo planes de formación para los usuarios?

En caso afirmativo, detállelos. Se realizaron tres jornadas de formación de la herramienta a los


usuarios.

9.11. ¿Se produjeron cambios durante el proyecto? ¿Cuáles fueron las razones que los
provocaron?

No se realizaron cambios en cuanto al diseño, pero sí en lo referente a las fórmulas a aplicar a


los datos en origen, por desconocimiento de los campos y las relaciones en algunos casos del
ERP por parte del cliente.

10. Finalización

10.1. ¿Se comunicó la finalización del proyecto a los componentes de la organización?

Sí.

10.2. ¿Se han alcanzado los objetivos propuestos? ¿Cómo? En caso negativo, ¿cuáles son las
principales razones que no han permitido alcanzar los objetivos?

Los objetivos acordados se alcanzaron, si bien por parte del cliente costó concretar su
definición de “Ventas”.

10.3. ¿Se han producido desviaciones en el plazo?

Se produjeron pequeñas desviaciones causadas por los mencionados cambios de fórmulas a


aplicar.

10.4. ¿Se han producido desviaciones en los costes? ¿Cuáles han sido los costes del
proyecto?

No se han producido desviaciones en los costes del proyecto, que han sido del orden de los
45.000€ (incluyendo licencias).
10.5. ¿Se han producido otras desviaciones en el proyecto?

En caso afirmativo, explicitarlas. No se han producido desviaciones más allá de las ya


comentadas.

10.6. ¿Se ha documentado el proyecto? En caso afirmativo, ¿qué documentos se han


elaborado?

Se ha realizado la siguiente documentación:

- Análisis funcional

- Modelos físico y lógico.

- Procesos ETL, incluyendo mapeos de los datos y transformaciones.

- Manual de usuario explicativo de los objetos disponibles en los documentos finales.

10.7. ¿Había una solución alternativa a la que se desarrolló? En caso afirmativo, ¿cuál era?,
¿por qué se desestimó?

Cualquier herramienta de Business Intelligence hubiera servido. Se eligió QlikView debido a la


predisposición de Dirección General, además de su menor coste de desarrollo.

10.8. ¿Disponen los usuarios de help desk para consultas?

No, no se ha considerado necesario debido a la facilidad de uso de la herramienta.

10.9. ¿Cuáles han sido las acciones post implementación?

Seguimiento de la implementación.

10.10. ¿Se ha establecido un plan de mejora del proyecto?

Se está estableciendo en estos momentos.

10.11. ¿Se ha destinado un presupuesto al mantenimiento del proyecto?

De momento no, aunque se hará.

10.12. ¿Cuál ha sido la valoración por parte de los usuarios?

La valoración ha sido positiva hasta el punto que ahora desean seguir ampliando las áreas
analizadas con QlikView.

11. Aprendizaje organizativo

11.1. Si volviera a realizar el proyecto, ¿qué cambiaría?

La gestión de los cambios en las especificaciones

11.2. ¿Cuáles han sido los principales problemas que se han encontrado en el desarrollo del
proyecto?

Lo mencionado anteriormente.

11.3. Explicar cuáles han sido los factores críticos de éxito o de fracaso del proyecto. Los
principales factores críticos del éxito han sido:

- El lideraje del proyecto por parte de Dirección General.


- La participación de todos los usuarios y técnicos del cliente implicados en la definición del
proyecto.

11.4. Explicitar cuáles han sido las lecciones aprendidas del proyecto.

Realizar una distinta aproximación a la problemática relatada en el punto 1.

12. Persona de contacto de la empresa: Santiago Mendirichaga.

13. Persona de contacto del implementador: Andrés Bloch.

1. Empresa: SAGE SP

2. Proyecto: Sage SP emprendió un proyecto de data warehousing y reporting corporativo,


estableciendo la calidad de los datos como una de las prioridades clave.

3. Implementador: Equipo interno dedicado y consultores PowerData.

4. Descripción breve del proyecto: La confianza en los datos es un requisito clave para el éxito
de un proyecto de Business Intelligence.

SAGE SP maneja una gran cantidad de datos de la relación con sus clientes, que debe gestionar
eficazmente para mantenerse líder en un segmento de mercado tan competitivo como el de
software para la pequeña y mediana empresa.

En octubre de 2004, Sage SP tomó la decisión de emprender un proyecto de Business


Intelligence con la implantación de una data warehouse corporativo y un sistema de reporting
para la alta dirección. La implementación de un sistema CRM y uno de gestión de campañas se
dejó para una segunda fase. El éxito de estas iniciativas dependía, en gran medida, de una
herramienta clave que comprueba que los datos utilizados son los correctos, asegurando la
calidad de los mismos.

Imagen

Los objetivos del proyecto eran:

• Generar información necesaria para la toma de decisiones estratégicas, de fácil acceso y en


tiempo real.

• Asegurar la integridad de los datos para un mejor conocimiento del cliente y, por lo tanto, la
prestación de un servicio más personalizado. Orientados a la excelencia del servicio.

• Asegurar el cumplimiento con la normativa vigente en cuanto a protección de datos.

Este proyecto ha sido llevado a cabo por el departamento de Gestión de la Información,


perteneciente a la dirección Financiera Corporativa de Sage España.

5. Descripción de la compañía:
Sage SP, fundada en 1981, es la empresa líder en soluciones de gestión para la pequeña y
mediana empresa en España. En 2003 pasó a formar parte del Grupo Sage, el líder mundial en
software de gestión, con más de 5 millones de clientes en todo el mundo y presente en 17
países. Sage SP cuenta en la actualidad con más de 250.000 clientes registrados y 2,5 millones
de productos vendidos, entre los que se encuentra SP ContaPlus, el programa de gestión más
utilizado por las pymes españolas. Más de 600 profesionales integran la plantilla de la
compañía, expertos altamente cualificados capaces de ayudar y dotar de valor añadido a los
negocios de sus clientes en su camino de integración en la Sociedad de la Información.

6. Inicio del proyecto

6.1. Razones que justifi caron llevarlo a cabo. ¿Cuál es la problemática o las necesidades de
la empresa o del departamento?

Sage SP tiene actualmente una estrategia totalmente orientada al cliente, siendo éste el
mayor valor de la compañía. El cliente está en el corazón de las decisiones estratégicas. Para
potenciar al máximo esta estrategia, la alta dirección necesitaba un reporting que facilitara
descubrir tanto cuáles eran las necesidades del cliente, como las ventas y además que se
adecuara con la realidad. Todo ello era necesario para poder tomar decisiones conformes con
la evolución de su negocio.

Anteriormente la empresa estaba orientada hacia el producto y a los servicios que prestaban,
por lo que se debía conseguir un cambio global. Este cambio afectaba a los sistemas de
información, las mentalidades, los procesos de negocio y, además, debía respetar las nuevas
leyes de protección de datos.

6.2. ¿Estaba alineado con los objetivos del negocio?

En caso afirmativo, ¿cómo? SAGE SP ha entrado en una etapa de descentralización de la


estrategia, necesitando mayor fiabilidad y automatización en su sistema de indicadores para
conseguir información precisa allí donde sea más efectiva.

6.3. ¿Cuál era la estimación de la contribución del proyecto? (tanto los beneficios
financieros, como los no financieros)

Un mayor conocimiento y enriquecimiento de los datos de cliente permitiría ofrecerles el


servicio más indicado a sus necesidades. Se esperaba aumentar en un 50% la efectividad de las
campañas de marketing.

6.4. ¿Se construyó un Business Case para su aprobación? En caso afirmativo, ¿Cuáles fueron
los componentes básicos del Business Case?

Se elaboraron unas directrices bajo las cuales quedó definido el proyecto. Estas definiciones
sirvieron para el desarrollo de las pruebas de concepto.

6.5. ¿Cómo se aprobó el proyecto? ¿Cuáles fueron los criterios que se tuvieron en cuenta?

Si se hicieron cálculos de retorno de la inversión (ROI) o de plazo de recuperación (Payback),


adjuntarlos. El proyecto fue aprobado por el Consejo de Dirección teniendo en cuenta los
objetivos que se habían fijado y los planes de ejecución. Se hicieron cálculos de amortización y
de retorno de la inversión en las campañas de marketing.

Los objetivos que se definieron fueron:


• Mejorar la segmentación partiendo de datos más precisos.

• Aumentar el número de impactos y disminuir las devoluciones al garantizar que los datos de
contacto son válidos (direcciones postales, direcciones de correo electrónico, números de
teléfono y fax).

• Evitar la duplicidad de impactos sobre el mismo contacto.

• El enriquecimiento de datos para aportar información adicional y mejorar la calidad del


mensaje enviado al contacto.

• La visión única del cliente, posible mediante la eliminación de registros duplicados,


mejorando el conocimiento del cliente y cumpliendo con lo preceptuado en la Ley Orgánica de
Protección de Datos (ver apartado siguiente).

6.7. ¿Quién fue el directivo espónsor del proyecto?

Fueron dos: Alvaro Ramírez, CEO y Consejero Delegado de Sage España, y Juan Pablo Herrera,
CFO de Sage España.

6.8. ¿Cuáles fueron los requerimientos de negocio? ¿Conocían los usuarios de negocio las
herramientas de Business Intelligence?

Los usuarios de negocio conocían Excel, por lo que solicitaban información al departamento de
Sistemas que después elaboraban. Ahora los usuarios de negocio trabajan con la herramienta
Microstrategy, lo cual les proporciona mucha más libertad ante el departamento de Sistemas,
ya que pueden generar los informes que necesitan ellos mismos y obtener datos actualizados y
en los cuales se pueda confiar.

6.9. ¿Se planteó desarrollar la solución de Business Intelligence?

No se planteó desarrollar ninguna herramienta, ya que en el mercado existían soluciones, a


partir de las cuales se hizo una selección.

6.10. ¿Se evaluaron distintas soluciones de Business Intelligence?

En caso de que se siguiera un procedimiento formal, detállelo. ¿Cuál fue la solución escogida?
Se evaluaron varias de las herramientas disponibles en el mercado. El primer criterio de
selección fue un criterio económico, a continuación, se tuvieron en cuenta aspectos técnicos
evaluando las posibilidades de explotación e integración. Después se hicieron pruebas de
concepto con aquellas soluciones más afines a nuestra organización y estructura de sistemas
de datos.

La solución escogida fue Microstrategy.

Imágenes

6.11. ¿Se evaluaron distintos implementadores? En caso de que se siguiera un procedimiento


formal, detállelo. ¿Cuál fue el implementador escogido?
Se decidió invertir en herramientas accesibles tecnológicamente para que en un corto periodo
de tiempo pudiéramos ser autónomos y poder adaptar el sistema a nuestras necesidades. Esta
fue una de las premisas del proyecto, ya que los procesos de negocio en Sage SP cambian
frecuentemente.

También podría gustarte