UNIVERSIDAD CATLICA ANDRS BELLO

VICERRECTORADO ACADMICO
ESTUDIOS DE POSTGRADO
REA DE INGENIERA
Postgrado en Sistemas de Informacin

Trabajo Especial de Grado

DISEO DE UN SISTEMA DE INFORMACIN PARA LA ACTUALIZACIN DE

ARTCULOS REGISTRADOS EN LOS PUNTOS DE VENTA DE EMPRESAS DE
RETAIL. Caso de estudio: Locatel Franquicias C.A.

Presentado por:
Walewska Josefina Brandy Navarro
para optar por el ttulo de
Especialista en Sistemas de Informacin

Asesora:
Mara Esther Remedios

Caracas, Noviembre 2013

NDICE DE CONTENIDO
INDICE DE TABLAS
INDICE DE FIGURAS
 UNIVERSIDAD CATLICA ANDRS BELLO
VICERRECTORADO ACADMICO
ESTUDIOS DE POSTGRADO
REA DE INGENIERA
Postgrado en Sistemas de Informacin

DISEO DE UN SISTEMA DE INFORMACIN PARA LA ACTUALIZACIN DE

ARTCULOS REGISTRADOS EN LOS PUNTOS DE VENTA DE EMPRESAS DE
RETAIL. Caso de estudio: Locatel Franquicias C.A.

Autor: Walewska Josefina Brandy Navarro

Tutor: Mara E. Remedios
Fecha: Julio de 2013
Resumen

La presente investigacin plantea el diseo de un Sistema de Informacin (SI) que

permite la actualizacin de artculos registrados en los puntos de venta de Locatel
Franquicias C.A., a travs de una Interfaz de comunicacin con el Sistema de
Aplicaciones y Productos (SAP) denominada Portable Interfase (PI). Con este
desarrollo se garantiza que la referencia de cada producto sea la ms reciente
apoyando as a las funciones de la Institucin como empresa de retail cuya misin
es ofrecer el surtido ms amplio de productos y servicios de salud, con un alto
contenido de innovacin y diferenciacin. La propuesta abarc las fases de
diagnstico estratgico lo que ayud a identificar las fortalezas y debilidades del
proceso de aplicacin de novedades de artculos, el anlisis de la solucin
propuesta, el diseo del sistema bajo la arquitectura permitida en Locatel y
finalmente se ofrecieron las respectivas recomendaciones para la implementacin.
El diseo de la investigacin realizado fue de campo y documental. Para el
desarrollo de la investigacin se sigui la propuesta ofrecida por el proveedor que
maneja la metodologa de proceso unificado de Rational (RUP), con la utilizacin
de diagramas de Lenguaje unificado de modelado (UML) para la representacin
de los procesos, con la incorporacin de los elementos claves en el diseo de un
Sistema de Informacin Gerencial (SIG).

Palabras Clave: Sistema de Informacin (SI), Fortalezas, Debilidades, Anlisis,

Diseo e Implementacin de Sistemas,
Lneas de investigacin: Ingeniera de Software
 DEDICATORIA

A mis padres por ser mi modelo a seguir, por ensearme que el esfuerzo y
constancia tienen su recompensa, y por recordarme todos los das mis
capacidades para conseguir el xito. Son ustedes los que me motivan a conseguir
cualquier cosa que me proponga, los amo y admiro muchsimo.

A Dios, por acompaarme en cada paso que doy y darme salud para llegar a
donde me lo proponga.
 AGRADECIMIENTO

A Dios por darme la vida, permitirme cumplir esta meta, por permitirme
estar junto a mis seres queridos y velar porque cada paso de mi vida est lleno de
cosas buenas.

A mis padres, por apoyarme incondicionalmente en todas las decisiones

que he tomado, por ayudarme las veces que los he necesitado, y en fin por
acompaarme en mi proyecto de vida.

A la profesora Mara Esther por su valiosa asesora y uso de su tiempo en

guiarme durante el desarrollo de esta investigacin. Gracias por compartir sus
conocimientos e involucrarse conmigo en este proyecto.

A Armando, por acompaarme en esta y tantas otras metas, gracias por tu

paciencia, dedicacin y compresin. Te amo.
 INTRODUCCIN

Hoy en da, en Venezuela existen un conjunto de leyes que exigen la

publicacin de todas las caractersticas de los productos y servicios ofrecidos por
las organizaciones para que los clientes puedan sentirse seguros y claros acerca
de lo que van a adquirir. Por esta razn, las empresas de retail a fin de apoyar sus
labores de inventario, compra y venta de productos, servicios y contrataciones,
cuentan con sistemas de informacin de gran envergadura que les permiten
manejar la informacin de sus clientes, proveedores y artculos ofrecidos.

El conjunto de establecimientos que conforman Locatel Franquicias C.A.

estn encargados de suministrar desde productos de prescripcin, controlados y
de venta, hasta productos altamente especializados de uso hospitalario, y como
empresa de retail, tambin se ha visto en la necesidad de mantener en constante
actualizacin las referencias de sus artculos. Para poder apoyar con esta labor,
se dise un sistema de informacin que permita la actualizacin de artculos en
los puntos de venta de Locatel Franquicias C.A. a travs de una interfaz de
comunicacin, denominada Portable Interfase (PI), con el Sistema de Aplicaciones
y Productos (SAP).

El diseo de la investigacin realizada es de campo y documental. Es

documental porque recopil la informacin pertinente de investigaciones y
documentacin previa para la elaboracin de informes comparativos, que
ayudaron a dilucidar las debilidades y fortalezas de la plataforma actual de Locatel
Franquicias C.A. Por otra parte, el diseo de la investigacin tambin fue de
campo, ya que busc: el anlisis sistemtico de problemas en la realidad, con el
propsito bien sea de describirlos, interpretarlos, entender su naturaleza y factores
constituyentes, explicar sus causas y efectos, o predecir su ocurrencia, haciendo
uso de mtodos caractersticos de cualquiera de los paradigmas o enfoques de
investigacin conocidos o en desarrollo (UPEL, 2006).

1
 En cuanto a la metodologa seleccionada, fue el Proceso Unificado de
Software (RUP) puesto que se cubren gran parte de los aspectos del desarrollo de
software por el detalle que brinda en apoyo del lenguaje unificado de modelado
(UML), logrando agilizar el diseo y desarrollo de la aplicacin asignando a un
desarrollador que dedicado a obtener la perspectiva del cliente a travs de
conversaciones directas.

El desarrollo de la investigacin referente al diseo de un sistema de

informacin que permitiera la actualizacin de artculos en los puntos de ventas de
Locatel Franquicias C.A. a travs de una Interfaz de comunicacin con el Sistema
de Aplicaciones y Productos (SAP) se estructur en los siguientes captulos: El
CAPTULO I contiene el planteamiento del problema, la formulacin del mismo, la
justificacin e importancia as como el alcance y las limitaciones. El CAPTULO II
est relacionado con el marco terico en donde se exponen los antecedentes de la
investigacin, el marco organizacional (historia, misin visin, y organigrama de la
institucin), las bases tericas y las bases ticas y legales. El CAPTULO III donde
se reflejan las bases metodolgicas que sustentan esta investigacin. El
CAPITULO IV donde se reflejan todas las fases que representan los objetivos de
esta investigacin: Anlisis de los actuales procesos del sistema de aplicacin de
novedades de artculos del Punto de venta (Point of Sale/POS) de Locatel
Franquicias C.A. para detectar fortalezas y debilidades del mismo, identificacin
de los Requerimientos Funcionales y No funcionales involucrados en la aplicacin
de novedades de artculos desde el Punto de venta (POS), anlisis de los nuevos
procesos para la aplicacin de novedades de artculos, diseo del sistema
automatizado y elaboracin de las recomendaciones de implementacin
respectivas para la puesta en marcha del sistema de aplicacin de novedades. En
el CAPTULO V muestra las conclusiones y recomendaciones recogidas en esta
investigacin. Finalmente se presentan las referencias bibliogrficas consultadas y
anexos que complementan esta investigacin.

2
 CAPITULO I

Planteamiento del Problema

1. Problema de Investigacin

Segn lvarez (2013), el xito de una empresa de Retail depende de: las
personas que hacen posible la organizacin retail, los procesos que llevan a cabo
esas personas y los resultados que se logran al ejecutar esos procesos
debidamente. La capacidad para responder rpidamente ante los cambios y
optimizar los procesos de negocio, es un factor clave para el crecimiento de las
organizaciones, en especial Locatel Franquicias C.A. que, como empresa de retail,
tiene competidores de gran envergadura en el mundo farmacutico y de hogar. La
agilidad de estos establecimientos que conforman la gran familia de automercados
de salud puede verse cuestionada si se apoya en entornos de IT que no pueden
responder de forma flexible a los cambios que afectan a la actividad de negocio.

Hoy en da, el conjunto de establecimientos que conforman Locatel Franquicias

C.A. estn encargados de suministrar desde productos de prescripcin,
controlados y de venta, hasta productos altamente especializados de uso
hospitalario.

Entre los procesos que pueden afectar las actividades de negocio de Locatel,
se puede mencionar el control del surtido de artculos ofrecidos en cada
establecimiento. Locatel Franquicias C.A. debe garantizar que la presentacin y
referencia de estos artculos para la venta, cuente con la informacin actualizada
de manera transparente, frecuente y organizada; asegurando as que cada artculo
cumple con las demandas de la poblacin y con las leyes establecidas por los
entes gubernamentales del pas, estas condiciones deben cumplirse de acuerdo a
las condiciones de venta cada establecimiento. Un producto rara vez permanece
inalterado durante todo su ciclo de vida.

3
 Es importante saber que tanto en Locatel, como en cualquier establecimiento de
retail, los artculos se manejan a travs de identificadores nicos que aportan
determinada informacin del mismo (tal es el caso de precio, la descripcin, el
porcentaje de impuesto y el porcentaje de descuento).

Para poder ofrecer los artculos para la venta, cada local cuenta con un sistema
de Puntos de ventas que representa el medio de facturacin y salida de los
artculos hacia el consumidor. El Punto de ventas cual est compuesto por un
conjunto de Terminales (Cajas) administradas por un Controlador principal
(denominado CC) y uno secundario (denominado DD).Los Controladores manejan
la lgica principal del proceso de facturacin incluyendo control de ventas de las
cajas, manejo de afiliados y aplicacin de novedades de artculos. Este ltimo
proceso mencionado, consiste en la actualizacin de un archivo que contiene el
compendio de todos los artculos manejados en los establecimientos y que se le
denomina Maestro de Artculos.

Modificar un producto implica modificar la lnea en la cual est integrado; esta

modificacin de la lnea puede venir dada tambin por la eliminacin de algunos
de sus productos integrantes o por adicin de algunos nuevos. El proceso de
actualizacin del Maestro de artculos, se realiza en tres fases diferentes que
involucran tanto esfuerzo humano como procesos automatizados. En la Figura 1
se mostrarn cada una de estas fases y se explicar en detalle en qu consiste
cada una de ellas:

4
 Figura 1. Proceso de actualizacin de maestro de artculos. Situacin actual

Durante la FASE 1, El Departamento de Categora y Precios se encarga de la

actualizacin de cada artculo a travs del Sistemas de Anlisis y Desarrollo del
Programas (SAP) en donde est almacenado el listado global de los artculos para
la venta. Cada artculo posee una referencia compuesta por: Cdigo SAP (Cdigo
nico asignado al artculo en SAP), fecha de ltima modificacin, tipo de
actualizacin, cdigo de barras (cdigo nico que se le asigna al artculo para
poder facturarse por el POS), precio unitario (sin impuesto), moneda para la cual
es permitida la venta, descripcin del artculo, impuesto, descuentos y unidad de
medida.

Una vez que el Departamento de Categora realiza el ajuste de los artculos

deseados en SAP bien sea por creacin, actualizacin o eliminacin; el sistema
SAP crea dos documentos que contienen el listado de los artculos actualizados,
estos documentos se denominan Idocs de novedades. Estos IDOCS pueden ser
del tipo WP_PLU (contienen el listado de cdigos de barra principal) y WP_EAN
(contienen el listado de cdigos de barras secundarias, es decir, barras que

5
dependen de otras principales). Un cdigo de barra principal puede contener
cdigos de barras secundarios que heredan las caractersticas del anterior.

Una vez que los IDOCS de novedades han sido creados, ocurre la FASE 2
en donde los mismos son alojados en una ruta de los servidores de SAP. Existe
un proceso interno programado en los servidores de cada tienda, este se ejecuta
todos los das a las 3:00 am y se encarga de recopilar todos los IDOCS (tanto
WP_PLU como WP_EAN) cuya fecha desde el da de ejecucin hasta siete das
anteriores y concatenarlos generando un gran documento con la recopilacin de
todas las novedades de siete das hasta la fecha. Es importante resaltar que estos
IDOCS de novedades se generan por fecha y ordenando las actualizaciones de
artculos de acuerdo a la fecha y la hora en que se gener la novedad; es decir
que hoy en da pueden existir actualizaciones del mismo artculo registradas en un
IDOC de manera no consecutiva.

Estos IDOCS son enviados posteriormente a todos los controladores a travs

de un proceso automtico (JOB de SQL) que utiliza un protocolo de transferencia
de archivos (Servicio FTP) y se encarga de enviar el comprimido a una ruta
especfica del controlador. Es importante mencionar que este job se ejecuta una
sola vez al da (a las 3:00 am.) y depende nicamente de la estabilidad de
comunicacin entre el servidor de SAP y los diferentes controladores de las
tiendas; esto podra implicar que alguna tienda no aplique la actualizacin de los
artculos y que stos estn disponibles para la venta con una referencia errada o
desactualizada. Hoy en da si llega a existir alguna falla en la ejecucin de alguna
de las fases mencionadas, no existe forma de saber de manera prctica dnde
ocurri la falla ya que el proceso automtico no deja registros del desempeo al
aplicarse. Esto implica que el personal de soporte de Sistemas debe verificar si se
aplicaron o no las novedades a travs de la comparacin manual de una muestra
de los artculos que contiene el IDOC de novedades con el maestro de artculos en
relacin a lo que indica el sistema SAP. Esta verificacin manual no siempre es

6
confiable porque slo se verifica es una muestra de los productos y no se
garantiza que el IDOC completo haya sido aplicado.

Finalmente, ocurre la FASE 3, en donde cada controlador lee el contenido de

los IDOCS de novedades y actualiza el maestro de artculos. Cabe destacar que la
forma en que se actualiza el maestro es a travs de una lectura lineal de los
IDOCS de novedades partiendo desde su cdigo de barras; y sin tomar en cuenta
que pueden existir varias novedades para un mismo artculo, ocasionando en
muchas ocasiones que no se apliquen estas actualizaciones de manera ordenada
y lgica. Esto puede traer como consecuencia que existan barras secundarias que
cambien de barra principal y por el orden de lectura no se aplique la novedad
correctamente, pudiera ocurrir tambin que un artculo cambie de precio en varias
oportunidades del da y por el orden de registro en los IDOCS de novedades el
artculo quede con un precio que no es el ms reciente; este ltimo caso tambin
aplica para los descuentos, impuestos y referencia del mismo.

Por otra parte, hoy en da las novedades generadas en SAP relacionadas

con eliminacin o bloqueo para la venta de cualquier artculo, hoy en da no son
interpretadas por el proceso de aplicacin de novedades, trayendo como
consecuencia que se tengan ciertas inconsistencias entre SAP y los puntos de
ventas, ya que puede existir artculos que hoy en da presenten una condicin que
no est reflejada en los puntos de ventas.

Una vez que se ejecutan exitosamente las tres fases mencionadas

anteriormente, las tiendas estn listas para iniciar su perodo de facturacin con
los artculos actualizados.

7
 2. Formulacin del Problema

Tomando en cuenta los aspectos mencionados anteriormente, surgi la

siguiente interrogante: Cmo puede realizarse la actualizacin de artculos en
Locatel Franquicias C.A. de manera transparente, frecuente y organizada?

Para resolver esta pregunta, fue necesario resolver tambin las siguientes
interrogantes:
- Cmo se lleva a cabo actualmente el proceso de novedades de artculos
en Locatel Franquicias C.A?
- Cules son las fortalezas y debilidades del proceso de aplicacin de
novedades de artculos en el POS?
- Cules son los requerimientos funcionales y no funcionales del nuevo
sistema de informacin para la aplicacin de novedades de artculos?
- Cmo llevar a cabo el nuevo proceso de aplicacin de novedades de
artculos?
- Cules son las especificaciones tcnicas recomendadas para ofrecer las
adecuaciones necesarias en los Puntos de Venta de Locatel Franquicias
C.A.?
- Cmo poner en marcha el proceso de actualizacin de artculos?

8
 3. Objetivos de la Investigacin

Para contestar las interrogantes planteadas en el Problema, se muestran a

continuacin los objetivos de este Trabajo de Grado.

3.1. Objetivo General

Diseo de un Sistema de Informacin que permita la actualizacin de artculos

registrados en los puntos de venta de Locatel Franquicias C.A., a travs de una
Interfaz de comunicacin con el Sistema de Aplicaciones y Productos (SAP)

3.2. Objetivos Especficos

1. Analizar los actuales procesos del sistema de aplicacin de novedades

de artculos del POS de Locatel Franquicias C.A. para detectar
fortalezas y debilidades del mismo.

2. Identificar requerimientos funcionales y no funcionales involucrados en

la aplicacin de novedades de artculos desde el POS.

3. Analizar los nuevos procesos para la aplicacin de novedades de

artculos desde el POS de Locatel Franquicias C.A.

4. Disear el sistema automatizado para la aplicacin de novedades de

artculos desde el POS con las adaptaciones requeridas de acuerdo a
los requerimientos identificados.

5. Elaborar las recomendaciones de implementacin respectivas para la

puesta en marcha del sistema de aplicacin de novedades

9
 4. Justificacin e Importancia de la Investigacin

Ley para la defensa de las Personas en el Acceso a los Bienes y Servicios

(2011), en su artculo 8 seala que toda persona, en relacin a los bienes y
servicios debe tener:

La informacin suficiente, oportuna, clara, veraz y comprensible sobre los

diferentes bienes y servicios, puestos a su disposicin, con especificaciones de
precios, cantidad, peso, caractersticas, calidad, riesgo y dems datos de inters
inherentes a su elaboracin o prestacin, composicin y contraindicaciones que
les permita tomar conciencia para la satisfaccin de sus necesidades.

En toda empresa de retail uno de los aspectos ms importantes es ofrecer

una gama de productos y servicios de calidad y con la mayor transparencia
posible, es por esta razn que Locatel Franquicias C.A. se ha visto siempre en la
necesidad de mantener en constante actualizacin las referencias de sus artculos
de manera que se cumpla con lo establecido por las leyes y mantener as
comunicacin transparente con el cliente.

La necesidad de creacin de un nuevo Sistema de Informacin que permita

la aplicacin de novedades de artculos, se bas en apoyar las funciones de la
Institucin como empresa de retail cuya misin es ofrecer el surtido ms amplio
de productos y servicios de salud, con un alto contenido de innovacin y
diferenciacin.

Si bien es cierto que hoy en da ya la organizacin cuenta con un sistema de

informacin encargado de ejecutar la actualizacin de la referencia de los
artculos; result necesaria la implementacin de otra herramienta automatizada
que funcionara como interfaz de comunicacin entre SAP y POS y que
considerara el orden en que se actualizaban los mismos, que pudiera ejecutarse
varias veces al da y que garantizara que la referencia de cada producto fuera la

10
ms reciente. A travs del desarrollo de esta nueva solucin, se logr tambin
conocer los diferentes procesos de negocio involucrados y facilitar algunos de los
mismos identificando nuevas oportunidades de mejora. Aunado a esto, con la
realizacin de esta investigacin se logr dejar un insumo para todos los
Departamentos involucrados que deseen conocer el proceso de negocio as como
los procesos que se automaticen.

El inicio de este proyecto y su implementacin en Locatel Franquicias C.A.

aportaron los siguientes beneficios:
Optimizacin de los procesos automatizados existentes para la aplicacin
de novedades de artculos
Conocimiento y sensibilizacin a las areas involucradas sobre los
procesos de negocio que comprende la aplicacin de novedades de
artculos.
Transparencia en cuando a la informacin del producto entre SAP como
fuente de creacin y codificacin, como POS como canal de salida al
cliente.
Aplicacin de modificacin de artculos de manera organizada y
frecuente.
Depuracin del maestro de artculos utilizado para la facturacin en los
puntos de venta

En cuanto al aporte que esta investigacin ofreci a la Universidad, es

importante mencionar que este trabajo ofreci material de estudio para futuras
investigaciones relacionadas al desarrollo de Sistemas de Informacin y
metodologa para el diseo, as como investigaciones asociadas al mundo del
retail (facturacin de productos).

11
 5. Alcance y Limitaciones

Este Trabajo de Grado estuvo basado en el diseo de un sistema de

informacin que se encargara de la aplicacin de novedades de artculos en los
Puntos de Venta de Locatel Franquicias a travs de una interfaz de comunicacin
entre los mismos y SAP. Para ello se cubrieron las siguientes etapas: Diagnstico
estratgico de los actuales procesos de negocio, identificacin de sus fortalezas y
debilidades, anlisis de los nuevos procesos involucrados en la actualizacin de
artculos, diseo de los procesos automatizados para la aplicacin de novedades
de artculos desde el POS. Aunado a esto, se aclara que si bien no se contempl
la implementacin del aplicativo, como fase final se ofrecieron las
recomendaciones respectivas para el desarrollo e implementacin del sistema de
aplicacin de novedades de artculos en los puntos de venta de Locatel
Franquicias C.A. Para la realizacin de esta investigacin se cont con la
colaboracin de los departamentos involucrados en el proceso: Categora y
precios, Desarrollos Propios y BD y POS con la intencin de recoger experiencias,
requerimientos, mejores prcticas y aclaratorios del mismo.

En cuanto a las limitaciones para la elaboracin de esta investigacin se

consider el tiempo que puede tomar la inclusin de todas las reas involucradas
en relacin a disponibilidad de los recursos y sensibilizacin al uso de una nueva
aplicacin.

12
 5.1. Resultados Esperados:

En cuanto a lo que se obtuvo en esta investigacin:

a. Diagnstico inicial con listado de fortalezas y debilidades del proceso
actual.
b. Matriz de Requerimientos funcionales y no funcionales (Mtodo Pieces).
c. Anlisis de los nuevos procesos de negocio involucrados en la actualizacin
de artculos en el POS.
d. Documento de Diseo con las especificaciones tcnicas y arquitectura para
el desarrollo del nuevo Sistema (Con diagramas UML que se requieran).
e. Documento con especificaciones de implementacin.

13
 CAPITULO II

Marco Terico

Para poder abordar el problema, a continuacin se darn a conocer las

bases tericas utilizadas para dar una buena conceptualizacin y orientar al lector
en el contexto; asimismo se presentaron los antecedentes que se han publicado y
que estn relacionados al tema a tratar y finalmente se dio a conocer de manera
detallada las caractersticas de la organizacin donde se desarrollar esta
investigacin.

En la Figura 2 se presenta el mapa mental de la estructura del Marco Terico:

Figura 2. Mapa Mental: Marco Terico

14
 1. Antecedentes de la Investigacin

Para la elaboracin de esta investigacin se tom en cuenta los siguientes

trabajos previos que aportaron una visin general y completa de las decisiones
especficas consideradas en el mbito de la problemtica adaptada a cada caso
de estudio. Este anlisis result ser una investigacin exploratoria para conocer
diferentes ideas y perspectivas de anlisis previos de situaciones similares que se
tratarn en este documento.

En su investigacin: Anlisis, Diseo y Plan para Implementacin de un

mecanismo que permita el establecimiento de la transmisin de datos en lnea
entre sistemas SAP/R3 y otros sistemas utilizando las herramientas de
comunicacin estndar disponibles en SAP/R3. para obtencin del ttulo de
Especialista en Comunicaciones y Redes de Comunicacin de Datos, Toussaint
(2005), expone que Para implantaciones del Sistema AP/R3 donde conviven
diferentes sistemas se requiere de la transmisin en lnea de datos entre ellos, y
otros sistemas lgicos distintos de SAP/R3, para tal fin SAP/R3 provee de una
herramienta estndar denominada ALE Aplication Link Enable que permite
intercambio controlado de informacin empresarial entre las aplicaciones
SAP/R3 con gestin de datos consistente. La integracin de la aplicacin no se
consigue mediante una base de datos central sino a travs de comunicaciones
sincrnicas y asincrnicas. La base del intercambio de datos de ALE es el
documento intermedio (IDOC), el cual constituye un contenedor general de
datos que puede incluir cualquier dato deseado de una aplicacin R/3. El
establecimiento de un prototipo que permita la comunicacin entre sistemas
SAP/R3 as como el basamento terico y tcnico en el cual se fundamenta este
trabajo especial de grado, constituy un aporte para enriquecer la base de
conocimiento en cuanto a proyectos de consultora de SAP/R3 disponible en la
firma.

15
 Este documento resulta valioso para la investigacin puesta que da a
conocer el desarrollo de sistema de informacin que permite la comunicacin
e integracin del Sistema SAP R3 con otro sistema externo y precisamente
en este proyecto se pretende realizar la aplicacin de novedades de artculos
a travs de una interfaz que consultar y aplicar los IDOCS de novedades
con las actualizaciones a aplicar en el POS

En su investigacin: Metodologa para la implementacin de la integracin de

los sistemas de negocios POS&Touch-SAP Business One en las PYMES.
para obtencin del ttulo de Magister Scientiarum en Ingeniera Industrial,
Mendes (2011), propone una solucin de integracin con el sistema SAP-
Business-One y el sistema de punto de ventas POS&Touch a travs de una
metodologa de trabajo que permita la sincronizacin del manejo de la
informacin y administracin de la misma de manera eficiente y rpida. La
investigacin comprende los lineamientos necesarios para la instalacin de los
sistemas, la integracin de las aplicaciones anteriormente mencionadas y el
establecimiento de las polticas necesarias para la puesta en marcha en
produccin.

Esta investigacin aporta una visin de cmo aplicar una metodologa que
la toma de decisiones durante la integracin de un sistema de puntos de venta
y un sistema ERP.

De Sousa (2006) en su investigacin para la obtencin del ttulo de

Especialista en Sistemas de Informacin cuyo ttulo es: Diseo de una
plataforma que apoye la conformacin de comunidades de prctica para la
gestin del conocimiento. Caso de estudio: Universidad Metropolitana, hizo
uso de la metodologa de desarrollo de software RUP en donde se aplicaron
las dos primeras fases. Dichas fases son cubiertas en su mayora por las tres
primeras disciplinas a saber: Modelado de Negocio, Requerimientos, Anlisis y
Diseo.

16
 La investigacin anteriormente mencionada aporta conocimiento para la
elaboracin de este trabajo puesto que de igual forma se generaron varios
documentos entregables como el documento de identificacin de requisitos, el
documento de anlisis, el documento de diseo de la aplicacin.

Gonzlez (2000) en su investigacin: Implantacin del sistema SAP R/3 en

Pea Colorada para la obtencin del ttulo Maestro en Ciencias, menciona las
ventajas de obtener informacin en tiempo real de algunos procesos en los
departamentos de finanzas, contabilidad, tesorera, RRHH, abastecimientos
para la adecuada y oportuna toma de decisiones haciendo uso del sistema
SAP R/3. La investigacin est estructurada en captulos; el primer captulo da
a conocer los aspectos relevantes de la institucin Pea Colorada, el segundo
captulo menciona las tendencias en los sistemas de informacin, el tercer
captulo y el que brinda conocimiento a este trabajo desarrolla en detalle todas
las funcionalidades y bondades del sistema SAP R/3, dando a conocer sus
mdulo, su metodologa, y otras caractersticas. En su cuarto captulo se
mencionan los beneficios de la implementacin y finalmente existe un ltimo
captulo donde se desarrolla el proyecto.

Este documento cuenta con una seccin donde se explica el modelo de

integracin de SAP R/3 con otras aplicaciones lo que result de gran utilidad
para esta investigacin que precisamente esta basada en la comunicacin de
un sistema externo (Punto de venta) con SAP.

Hernandez (2013), en su investigacin: Desarrollo estratgico de

Proveedores nacionales para una gran empresa de Retail para optar por el
ttulo de Magister en gestin y direccin de empresas. El objetivo principal de
esta investigacin fue desarrollar una estrategia para el proceso de recepcin
para las empresas de retail, que permita mejorar su rendimiento general.

17
 Al igual que esta investigacin, el trabajo mencionado anteriormente
desarrolla su proyecto en una empresa de retail, lo cual gener suficiente
informacin bsica acerca de este tipo de empresas y su correcta
administracin entregando la flexibilidad necesaria para los procesos internos
en los centros de distribucin como tambin una mayor informacin con los
otros sistemas que utilizan las grandes empresas (ERPs, sistemas de
recepcin en tienda, sistemas de precios, sistemas de despacho a domicilio,
etc.), en definitiva con el resto del negocio.

Fuquene, Aguirre y Crdoba (2006) en su artculo: Evolucin de un sistema

de manufactura flexible (fms) a un sistema de manufactura integrada por
computador (CIM) plasma la evolucin de un sistema de manufactura flexible
(FMS) hacia un sistema de manufactura integrada por computador (CIM) a
travs de la integracin de los procesos de planeacin de la produccin
desarrollados en un sistema de planeacin de recursos empresariales (ERP)
con la fabricacin y control de la produccin desarrollados en un FMS, por
medio de una interfaz de capa media, con el fin de automatizar procesos de
envo y recibo de informacin de produccin, para garantizar la transparencia
de los datos y la optimizacin de los procesos. El propsito del artculo es
mostrar una solucin a esta problemtica por medio del desarrollo de un
sistema de capa media que permite el intercambio de datos de dos sistemas
completamente independientes con el objeto de minimizar tiempos en
actividades de transmisin de datos por medio de la automatizacin del
proceso.

Tomal, (2006), en su investigacin: Desarrollo e integracin de los sistemas

de informacin contable a travs de la implantacin del SAP R/3 en una
empresa comercializadora de Gas licuado de petrleos (GLP) en el Ecuador -
Duragas para optar por el ttulo de Master en Administracin de Empresas,
presenta la implementacin de un ERP (Enterprise Resource Planning o
Planeacin de Recursos de la Empresa) SAP R/3 que por sus

18
principales caractersticas es un sistemas integral, modular que contiene
Ventas y Distribucin (SD), Econmico Financiero y Cobranzas (FI-CO-AA-IM-
PS), Abastecimiento e Inventario (MM-PP), Operaciones (PM), logrando
integrar todas las operaciones del negocio de GLP cubriendo o todas las
localidades, para esto es necesario que todas sus plantas y Centros de
distribucin estn conectados on-line, con enlaces dedicados 100%. En su
primer captulo, la autora menciona la necesidad de implementar un sistema
integrado para fortalecer la gestin contable y es precisamente en este
captulo donde puede apreciarse al igual que en esta investigacin los
beneficios de contar con un proceso automatizado que se encargue del
proceso de ventas y su mantenimiento. Luego se presenta el marco terico en
el captulo 2, posteriormente se desarrolla el proyecto y se plantea un captulo
final de anlisis de resultados.

19
 2. Marco Organizacional

A continuacin se dar a conocer la estructura organizacional de Locatel

Franquicias C.A. entre las cuales se mencionarn las partes que integran la
empresa y las relaciones entre dichas partes. La intencin principal es la
diferenciacin de reas, de puestos de trabajo, la formulacin de normas y
procedimientos y las relaciones de autoridad.

2.1. Historia:

En el ao 1981 inicia sus actividades nuestras Empresa Locatel Servicios, en

atencin a un sector de la poblacin que si bien necesitaba utilizar algn equipo
mdico de forma temporal, no posean los recursos o el tiempo de esta necesidad
no lo ameritaba. En la bsqueda de atender estas necesidades es que nuestra
Empresa se dedica a la compra, venta y principalmente alquiler de Equipos
Mdicos.

Debido a la alta demanda y la bsqueda de afianzarnos en el mercado inicia

sus actividades en el ao 1986 Galaxia Mdica, dedicada exclusivamente a la
compra, venta e importacin de los Equipos Mdicos que venda Locatel.

En el ao 1994 inicia sus actividades Farmacia Locatel y nace de la mano de

uno de nuestros directivos el concepto Automercado de Salud con la finalidad de
ofrecer a nuestros clientes ms productos y servicios, ubicado en la PB de nuestra
Master, en nuestra primera tienda en Boleita, la cual hasta la actualidad
permanece.

Ante una demanda creciente en el ao 1998 se apertura nuestro segundo

Automercado de Salud en la Candelaria, en el ao 2000 abrimos en La Marrn y
en el ao 2001 en el Boleita Center.

20
 Por razones estratgicas del negocio, cambiamos al formato de Franquicia en
el ao 2001, y en esa misma poca nos hicimos merecedores del premio
Franquicia de Mayor Crecimiento en el Monto de Inversin En el ao 2002 se
inaugura el Auditorio en memoria de los seores Armando Ruah y Mauricio Levy.

En el ao 2003 inicia sus actividades Fundailusin y es el principal promotor

de nuestro Evento Mes de la Salud, que cierra con un mega evento familiar y un
Maratn, una vez al ao. En el ao 2004 comienza nuestra expansin a nivel
internacional con la apertura de mas Automarcados de Salud en Miami y Bogot y
paralelamente entra en circulacin la Revista +Salud, que es de distribucin
gratuita para todos los empleados.

En 2007 se fusiona Locatel Servicios con Farmacia Locatel. Para 2008 contamos
con cuarenta y cinco (45) tiendas a nivel nacional, con la incorporacin de tiendas
en Rusia y Mxico.

Junio de 2009 se escogi como mes para cambiar de imagen, con un nuevo
logo representado por un aro o anillo, el cual comunica la unin entre los
consumidores y nosotros; una gama de colores, donde el verde est presente en
un 70% y el naranja en un 30%. Verde, nuestro color, el de siempre, que
representa en este logo todos nuestros productos y servicios bsicos orientados al
bienestar y a la salud, presentes en Farmacia. Y el nuevo naranja, introducido
para resaltar las lneas de productos complementarias de nuestro concepto,
Cuidado Personal, Higiene, Belleza, productos para la nutricin entre otros.
Adicionalmente podemos ver que para ambos colores tenemos varias tonalidades
que reflejan lo que siempre nos ha caracterizado Variedad amplia y profunda de
nuestro surtido. El 14 de febrero del 2012 se inaugur un nuevo establecimiento
a nivel internacional: Locatel Bird Galloway en la ciudad de Miami.

21
 2.2. Misin:

Superar las expectativas de nuestros clientes, proveedores, socios y

empleados ofreciendo a toda la poblacin, en un ambiente de armonio y bienestar,
el surtido ms amplio de productos y servicios de salud, con un alto contenido de
innovacin y diferenciacin.

2.3. Visin:
Ser reconocido como la primera opcin de salud y bienestar al detal para toda
la poblacin.

22
 2.4. Organigrama de la Institucin:

Junta Directiva

Direccin de
Relaciones Revista + Salud
Institucionales

Vicepresidencia de
Vicepresidencia
Administracin y
Comercial
Finanzas

Figura 3. Organigrama de Locatel / Junta Directiva (Suministrado por Locatel)

Vicepresidencia
Comercial

Direccin de
Direccin Distribuidora Direccin de Farmacia
Mercadeo

Gerencia de
Gerencia de Operaciones Gerencia de Categora
Distribucin
Gerencia de Compras

Gerencia de ventas Gerencia de Mercadeo

Figura 4. Organigrama de Locatel / Vicepresidencia Comercial (Suministrado por Locatel)

23
Figura 5. Organigrama de Locatel / Vicepresidencia de Administracin y Finanzas (Suministrado por Locatel)

24
 Gerencia de Sistemas

Secretaria

Jefe
Jefe SAP Jefe POS Jefe Redes
Desarrollo

Lder Lder Lder Lder

Lder Administrad Lder BD y
Funcional Funcional Funcional Proyectos Lder POS Lder ABAP
Funcional BI or de Redes Aplicaciones
SAP SD SAP MM SAP FI SAP
Analista Analista Analista Analista Analista
Analista
Funcional Funcional Funcional Analista BI Analista POS Soporte Desarrollo
Desarrollo
SAP SD SAP MM SAP FI Redes ABAP
Analista Analista Analista
Analista
Soporte SAP Soporte SAP Soporte SAP
Soporte POS
SD MM FI

Figura 6. Organigrama de Locatel / Gerencia de Sistemas (Suministrado por Locatel)

25
 3. Bases Tericas

A continuacin se presentar un conjunto de conceptos asociados a los

objetivos de esta investigacin que proporcionarn un mejor entendimiento del
dominio del problema.
Segn Tamayo (2004), las bases tericas nos amplan la descripcin del
problema e integra la teora con la investigacin y sus relaciones mutuas. Es la
teora del problema y tiene como fin apoyar a organizar los elementos contenidos
en la descripcin del problema, de tal forma que puedan ser manejados y
convertidos en acciones concretas.

Aspectos a conocer del proceso que ser objeto de estudio

A continuacin se presentarn un conjunto de conceptos asociados al negocio de

Locatel Franquicias y que servirn de apoyo al entendimiento de esta
investigacin.

3.1. Retail

Segn Diez. (2008), Retail es el trmino ingls para comercio al por menor
o al detalle. Est relacionado con las cadenas de tiendas, franquicias, centrales de
compras.

3.2. Punto de Ventas (POS: Point of Sale)

Segn Diez (2008), es aquel que se usa en el comercio y que por medio de
componentes electromagnticos seala y suma automticamente el importe de
ventas. Es donde se dan cita los distintos productos de los fabricantes y donde el
consumidor viene a comprar esos productos

26
 3.3. Terminales de Puntos de venta (Cajas Registradoras)

Segn Diez, tiene como funcin principal la gestin comercial del punto de
venta, de forma que, a travs de un proceso informtico instalado en un equipo
especfico (compuesto de: pantalla, visor, teclado, cajn e impreso de tickets),
permite realizar cualquier tipo de operacin relativa a la venta de artculos en el
mostrador.

3.4. Cliente

Segn Hernndez (2008), es la persona que teniendo la necesidad de

adquirir un producto, acta en una accin de compra para satisfacer esa
necesidad, bien de manera directa o indirecta, o bien de forma inmediata o
aplazada. Es selectivo para satisfacer su motivacin de compras

3.5. Producto

Segn Diez (2008), representa una fuente de satisfaccin de necesidades,

una adecuada gestin de producto deber girar siempre en torno a las
necesidades del consumidor. El producto representa un bien de consumo por lo
que se destina al uso de consumidores finales y hogares y puede ser utilizado sin
procesar. Los mercados de consumo estn integrados por individuos y grupos
(familias) que adquieren productos y servicios para consumo final

3.6. SAP

El website http://www.sap.com informa que:

El sistema SAP/R3 es un software del tipo ERP (Enterprise Resourse
Planning- Sistema Integrado de Gestin Empresarial) que integra informacin y
automatiza procesos en tiempo real, interconectando las diversas reas de
negocio y optimiza la toma de decisiones en una compaa. Este software fue

27
creado por SAP, una empresa alemana lder mundial en tecnologa de la
informacin para la gestin empresarial. El software SAP R/3 tcnica de tiempo
real en tres dimensiones: Banco de Datos, Aplicaciones e Interfases con
escenarios.
Fundada en 1972 en Walldorf, Alemania, SAP(Sistemas Aplicaciones y
Productos de la Informtica) tiene una importante participacin en el mercado de
aplicaciones empresariales cliente-servidor a nivel mundial. SAP es el distribuidor
nmero uno de software de aplicaciones de negocios estndar y el cuarto
distribuidor independiente de software en el mundo.

3.7. Precio

El precio representa el conjunto de herramientas que utiliza una empresa

para alcanzar sus objetivos de marketing en el mercado elegido.
Segn Diez (2008), desde el punto de vista del comprador, representa la
cantidad de recursos (expresada normalmente en unidades monetarias, aunque
tambin podra consistir en productos y servicios) que es necesario sacrificar o
entregar para adquirir la propiedad o el derecho de uso y disfrute de un producto o
servicio y desde el punto de vista del vendedor, la cantidad de recursos (dinero,
productos o servicios) obtenidos por la venta de un producto o servicio.

3.8. Cdigo de Barras

Segn Hernndez (2004), se trata de una simbologa utilizada para

representar una determinada informacin a travs de una cadena de caracteres.
Es un cdigo basado en la representacin mediante un conjunto de lneas
paralelas verticales de distinto grosor y espaciado que permite reconocer
rpidamente un artculo de forma nica, global y no ambigua as poder realizar
consultas acerca de sus caractersticas asociadas.
La informacin se procesa y almacena en base en un sistema digital binario
donde todo se resume a sucesiones de unos y ceros.

28
Los cdigos de barra estn regulados en Europa por la asociacin EAN
(Asociacin Europea de Numeracin de Artculos). Esta codificacin utiliza dos
tipos de cdigos. El ms amplio es el EAN 13 denominado as porque consta de
13 dgitos. Los dos primeros, corresponden al pas del fabricante, del propietario
de la marca o del distribuidor del pas; los cinco siguientes dgitos son para
designar al fabricante del producto y los otros cinco para el producto en cuestin.
El ltimo dgito es un nmero de control que asegura la lectura ptima exenta de
errores

Por otra parte existen los EAN 8 que slo tienen esta cantidad de dgitos y su
codificacin indica: dos dgitos para el pas, dos para el fabricante, tres para el
producto y el ltimo para el control de lectura

3.9. IDOC

Es una estructura desarrollada para el intercambio de informaciones entre sistemas

SAP o bien la comunicacin del SAP con sistemas ajenos.

3.10. Estructuras del IDOC

El IDOC est formado por Registros de control, Registros de Datos y Registros de

Estado. Detallamos cada uno de ellos a continuacin.

Registro de control:

Contiene toda la informacin administrativa del IDOC, como el sistema

origen y el de destino, el tipo de IDOC del que se trata. Este registro es de
vital importancia ya que a partir de l se permitir saber quien va a ser el
destinatario del IDOC. La estructura de este segmento de control es igual

29
 para todos los IDOCs. Cada IDOC contiene uno y slo un registro de
control.

Registro de datos:

En el registro de datos esta toda la informacin enviada/recibida.

El registro de datos va a estar dividido en distintos segmentos en los cules
van a estar almacenados los datos. Estos segmentos a su vez pueden
contener otros segmentos. Cada IDOC podr tener dentro de los registros
de datos N segmentos donde se almacenan los datos.

Registro de estado:

Es el historial del procesamiento del IDOC en las distintas etapas.

Cada IDOC tendr N registros de estado.

3.11. Etiquetas

Se trata de una leyenda descriptiva adherida al producto o artculo que da

referencia de alguna de las siguientes caractersticas del mismo:
1. Identificar al producto o a la marca
2. Identificar calidad
3. Describir al producto de acuerdo a los siguientes factores
a. Fabricante
b. Dnde y cundo se ha fabricado
c. Contenido y composicin fsica o qumica
d. Formas de utilizacin
e. Condiciones de seguridad y fecha de caducidad

30
 Aspectos a conocer sobre el Diagnstico inicial para la deteccin de
Fortalezas y debilidades:

3.12. Diagnstico

Segn Robbins y Decenzo (2002), El propsito de un diagnstico es

movilizar la accin ante un problema.

Cualquier diagnstico debe suministrar a los ineteresados la informacin y

los anlisis que necesitan para plantear, desde el punto de vista estratgico
cualquier futuro de la empresa a corto y mediano plazo.

3.13. Diagnstico Estratgico

Segn McLeod (2000), la forma en que la organizacin es capaz de gestionar y

explotar, de forma conjunta, coherente y armnica, sus recursos con el fin de
alcanzar determinados objetivos que se consideran buenos para la empresa. Para
realizar este diagnstico se requiere cubrir las siguientes fases:

Fase 1: Identificacin y evaluacin de los recursos de la Empresa

Fase 2: Identificacin y evaluacin de las potencialidades
estratgicas de la empresa.
Fase 3: Comparacin de los recursos y potencialidades con los
propsitos y objetivos definidos en la empresa en funcin de la
generacin de ventajas competitivas sostenibles.
Fase 4: Identificacin de los vacos de planificacin que existan entre
los recursos y potencialidades y los propsitos y objetivos (ventajas
competitivas)
Fase 5: Determinacin de las estrategias que se deben seguir para
solucionar los vacos de planificacin.

31
 Fase 6: Actualizacin constante de la informacin con el fin de
reponer, aumentar y mejorar los recursos y potencialidades de la
empresa.

3.14. Fortalezas

Segn Robbins y Decenzo (2002), Representan recursos internos de la

organizacin o las cosas que sta hace bien. Las fortalezas significan habilidades
o recursos nicos que determinen la ventaja competitiva de la organizacin

3.15. Debilidades

Segn Robbinsy y Decenzo (2002), se refiere a recursos que la organizacin

no tiene o cosas que no hace bien,

3.16. Anlisis de fortalezas y debilidades

Segn Robbins, y Decenzo (2002), este anlisis permite evaluar los recursos
y potencialidades desde un punto de vista dinmico y su realizacin constituye la
base para la aplicacin de los restantes instrumentos y conceptos.

32
 Aspectos a conocer sobre la identificacin de los Requerimientos
funcionales y no funcionales del proceso de aplicacin de novedades de
artculos

3.5. Procesos de Negocio

ISO 9000 define un proceso como: Conjunto de actividades mutuamente

relacionadas o que interactan, las cuales transforman elementos de entradas en
resultados.

De acuerdo a la cita textual, Fernandez (2010):

La definicin dada permite hablar de diferentes niveles de procesos a los que

denominamos procesos de negocio y varan con el tamao de la organizacin:

- Procesos de Alta Direccin

o Proceso de Elaboracin, Comunicacin, Implantacin,
Seguimiento y Revisin de Estrategia.
o Proceso de determinacin, difusin, seguimiento y revisin de
objetivos.
o Proceso de Revisin del sistema de gestin por la direccin.
o Proceso Global de Entrega de productos o servicios.
o Proceso de Comunicacin Interna.
- Procesos de Direccin Intermedia
o Ejecucin de los procesos en Cascada.
o Proceso de Gestin y Comunicacin con el Cliente.
o Proceso de Produccin, realizacin del producto o servicio.
o Proceso de Gestin econmica.
o Proceso de Gestin e integracin de Personal.
- Mando Intermedio
o Proceso de contacto con los clientes.

33
 o Proceso de Corte y Soldadura
o Proceso de Manteniemiento
o Proceso de Facturacin y Cobros
- Personal de Base

3.6. Requerimientos

Segn Sommerville (2005),

Los Requerimientos de un sistema son la descripcin de los servicios
proporcionados por el sistema y sus restricciones operativas. Estos requerimientos
reflejan las necesidades de los clientes de un sistema que ayude a resolver algn
problema como el control de un dispositivo, hacer un pedido o encontrar
informacin.
Los requerimientos de sistemas de software se clasifican en funcionales y no
funcionales.

3.7. Requerimientos funcionales

Segn Sommerville (2005),

Son declaraciones de los servicios que debe proporcionar el sistema, de la
manera en que ste debe reaccionar a entradas particulares y de cmo se debe
comportar en situaciones particulares. En algunos casos, los requerimientos
funcionales de los sistemas tambin pueden declarar explcitamente lo que el
sistema no debe hacer.

3.8. Requerimientos No Funcionales

Segn Sommerville (2005),

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen
restricciones de tiempo, sobre el proceso de desarrollo y estndares. Los
requerimientos no funcionales a menudo se aplican al sistema en su totalidad.

34
 3.9. Mtodo Pieces

Wetherbe y Vitalari (1994) desarrollaron un modelo para analizar aplicaciones y

sistemas con el fin de resolver problemas, explotar las oportunidades y satisfacer
directivas establecidas. Dicho marco referencial (PIECES) se emplea para
identificar los requerimientos de acuerdo a las siguientes caractersticas:

Tabla 1. Mtodo Pieces (Wetherbe J. y Vitalari N ,1994)

P Rendimiento
I Informacin
E Economa
C Control
E Eficiencia
S Servicio

Esta tcnica permite asegurar que tanto el analista de sistemas como los
usuarios se involucran en el anlisis de cada una de las categoras esenciales en
relacin con el dominio del problema y que las respuestas contribuyan
significativamente a la definicin de requerimientos del sistema.

35
 Sobre el anlisis del nuevo proceso de aplicacin de novedades de
artculos:

3.10. Sistema de Informacin

Ricard y Valor (1996) definen los Sistemas de Informacin, como el conjunto

formal de procesos que, operando con un conjunto estructurado de datos de
acuerdo con las necesidades de una empresa, recopila, elabora y distribuye (parte
de) la informacin necesaria para la operacin de dicha empresa y para las
actividades de direccin de control correspondientes, apoyando al menos en parte,
la toma de decisiones necesaria para desempear las funciona y procesos de
negocio de la empresa de acuerdo con su estrategia.

Kendall y Kendall (2005) dividen el ciclo de desarrollo de sistemas en siete fases:

1. Identificacin de problemas, oportunidades y objetivos
2. Determinacin de Requerimientos de Informacin
3. Anlisis de Necesidades del Sistema
4. Diseo del sistema recomendado
5. Desarrollo y Documentacin del Software
6. Prueba y Mantenimiento del Sistema
7. Implementacin y Evaluacin del hardware

3.11. Ciclo de Vida de los Sistemas de Informacin

Segn Kendall y Kendall (2005), el ciclo de vida es un enfoque por fases

para el anlisis y el diseo cuya premisa principal consiste en que los sistemas se
desarrollan mejor utilizando un ciclo especfico de actividades del analista y el
usuario. A pesar de que cada fase se explica por separado, nunca se ejecutan de
forma aislada. Es posible que varias actividades ocurran de manera simultnea y
algunas de ellas podran repetirse.

36
El ciclo de vida segn Kendall y Kendall (2005) puede comprender las siguientes
fases aunque no son obligatorias, depender de la naturaleza del proyecto:

1. Identificacin de problemas, oportunidades y objetivos: observacin

objetiva de lo que sucede en un negocio. A continuacin, en conjunto con
otros miembros de la organizacin, el analista determina con precisin
cules son los problemas. Con frecuencia los problemas son detectados
por alguien ms, y sta es la razn de la llamada inicial al analista. Las
oportunidades son situaciones que el analista considera susceptibles de
mejorar utilizando sistemas de informacin computarizados. El
aprovechamiento de las oportunidades podra permitir a la empresa obtener
una ventaja competitiva o establecer un estndar para la industria.
2. Determinacin de los requerimientos de informacin: Entre las herramientas
que se utilizan para determinar los requerimientos de informacin de un
negocio se encuentran mtodos interactivos como las entrevistas, los
muestreos, la investigacin de datos impresos y la aplicacin de
cuestionarios; mtodos que no interfieren con el usuario como la
observacin del comportamiento de los encargados de tomar las decisiones
y sus entornos de oficina, al igual que mtodos de amplio alcance como la
elaboracin de prototipos
3. Anlisis de las necesidades del sistema: herramientas y tcnicas especiales
auxilian al analista en la determinacin de los requerimientos. Una de estas
herramientas es el uso de diagramas de flujo de datos para graficar las
entradas, los procesos y las salidas de las funciones del negocio en una
forma grfica estructurada. A partir de los diagramas de flujo de datos se
desarrolla un diccionario de datos que enlista todos los datos utilizados en
el sistema, as como sus respectivas especificaciones.

4. Diseo del sistema recomendado: En la fase de diseo del ciclo de vida del
desarrollo de sistemas, el analista utiliza la informacin recopilada en las
primeras fases para realizar el diseo lgico del sistema de informacin. El

37
 analista disea procedimientos precisos para la captura de datos que
aseguran que los datos que ingresen al sistema de informacin sean
correctos. Adems, el analista facilita la entrada eficiente de datos al
sistema de informacin mediante tcnicas adecuadas de diseo de
formularios y pantallas.
5. Desarrollo y Documentacin del software: En la quinta fase del ciclo de vida
del desarrollo de sistemas, el analista trabaja de manera conjunta con los
programadores para desarrollar cualquier software original necesario. El
analista se vale de una o ms de estas herramientas para comunicar al
programador lo que se requiere programar, tambin trabaja con los
usuarios para desarrollar documentacin efectiva para el software, como
manuales de procedimientos, ayuda en lnea y sitios Web que incluyan
respuestas a preguntas frecuentes. La documentacin indica a los usuarios
cmo utilizar el software y lo que deben hacer en caso de que surjan
problemas derivados de este uso. Los programadores desempean un rol
clave en esta fase porque disean, codifican y eliminan errores sintcticos
de los programas de cmputo
6. Pruebas y Mantenimiento del Sistema: Antes de poner el sistema en
funcionamiento es necesario probarlo. Es mucho menos costoso encontrar
los problemas antes que el sistema se entregue a los usuarios. Una parte
de las pruebas las realizan los programadores solos, y otra la llevan a cabo
de manera conjunta con los analistas de sistemas. Primero se realiza una
serie de pruebas con datos de muestra para determinar con precisin
cules son los problemas y posteriormente se realiza otra con datos reales
del sistema actual. El mantenimiento del sistema de informacin y su
documentacin empiezan en esta fase y se llevan a cabo de manera
rutinaria durante toda su vida til.
7. Implementacin y evaluacin del sistema: En esta fase se capacita a los
usuarios en el manejo del sistema. Parte de la capacitacin la imparten los
fabricantes, pero la supervisin de sta es responsabilidad del analista de

38
 sistemas. Adems, el analista tiene que planear una conversin gradual del
sistema anterior al actual.

Segn Kendall y Kendall (2005), el ciclo de vida del sistema se representa de

la siguiente forma:

Figura 7. Ciclo de Vida de Sistemas. Kendall y Kendall (2005)

3.12. Metodologa de Desarrollo de software

En la cita textual, Barranco (2001), se especifica que:

Un Sistema de calidad de software propone la utilizacin de procedimientos y

guas tcnicas que establezcan el modo de construccin del software. Una
metodologa de desarrollo de software se fundamenta sobre tres pilares bsicos:
qu hay que hacer y en qu orden, cmo deben realizarse las tareas y con qu
pueden llevarse a cabo. Esto es, qu etapas, actividades y tareas se deben

39
acometer, qu tcnicas deben emplearse para realizar estas actividades y cules
son las herramientas software a utilizar en cada caso. Si la metodologa recoge lo
anteriormente mencionado constituye un entorno de Ingeniera de software.

3.13. RUP (Rational Unified Process)

Segn Fabregas (2011), se presenta el ciclo de desarrollo integrado por las

siguientes fases:

I. Preparacin inicial o conceptualizacin: el objetivo principal de esta fase

es establecer los objetivos del sistema, se delimita el alcance del
sistema y el alcance del proyecto.
II. Preparacin detallada o elaboracin: el objetivo principal de esta fase es
establecer la arquitectura del producto, se estableen los requisitos
funcionales y se analizan los riesgos que pudieran amenazar el logro de
los objetivos del sistema.
III. Construccin: Se desarrolla el producto de software.
IV. Transicin: El objetivo principal de esta fase es instalar el producto una
vez realizadas las pruebas de aceptacin y habiendo efectuado los
ajustes y correcciones que sean requeridos.

3.14. 4+1 Vistas

Un enfoque en la presentacin de un sistema en UML es conocida como 4+1

vistas. Segn Kruchten (1995), esta forma de documentar nuestros modelos divide
lo que sabemos de l en cinco reas:

Vista de Casos de Uso: que contiene requisitos desarrollados en las

restantes vistas.
Vista Lgica: Muestra la estructura esttica del sistema.

40
 Vista Fsica: Muestra el despliegue de la aplicacin en la red de
computadoras.
Vista de Procesos: Muestra los hilos y procesos de ejecucin as como la
comunicacin entre estos.
Vista de Desarrollo: Muestra la estructura en modelos del cdigo del sistema.

3.15. Documento de Requisitos de Software

Segn Sommerville (2005), el Documento de Especificacin de Requisitos

Software:
Es la declaracin oficial de qu deben implementar los desarrolladores del
sistema. Debe incluir tanto los requerimientos del usuario para el sistema, como
una especificacin detallada de los requerimientos del sistema.

El nivel de detalle que se debe incluir en un documento de requerimientos

depende del tipo de sistema que se desarrolle y del proceso de desarrollo
utilizado.
Varias organizaciones como el IEEE, han definido estndares para este
documento, la mayora siguiere la siguiente estructura:

1. Introduccin
2. Descripcin General
3. Listado de Requerimientos

3.16. Anlisis de Sistemas

Kendall y Kendall (2005) indican que:

El anlisis de sistemas consiste en evaluar de manera sistemtica el
funcionamiento de un negocio mediante el examen de la entrada y el
procesamiento de los datos y su consiguiente produccin de informacin, con el
propsito de mejorar los procesos de una organizacin. Muchas mejoras incluyen

41
un mayor apoyo a las funciones de negocio a travs del uso de sistemas de
informacin computarizados.

Un analista de sistemas debe desempear el rol de consultor, experto en soporte

tcnico y agente de cambio.

3.17. Lenguaje Unificado de Modelado (UML)

Segn Weilkiens (2007), UML es un lenguaje y un sistema de notacin

utilizado para especificar, visualizar y documentar modelos del sistema de
software.

42
 Aspectos a conocer sobre el diseo del sistema automatizado para la
aplicacin de novedades de artculos:

3.18. Diagrama de procesos

Este tipo de diagramas permite identificar los procesos de un sistema, sus

entradas, sus salidas y sus formas de almacenamiento de datos en un sistema de
informacin.

Segn Chang (2008), el diagrama de procesos es una herramienta de

planificacin y anlisis utilizada para:
1. Definir y analizar procesos
2. Construir una imagen del proceso etapa por etapa para su anlisis,
discusin o con propsito de comunicacin.
3. Definir, encontrar o estandarizar reas de un proceso susceptibles de ser
mejoradas

3.19. Diagrama de Casos de Uso

Segn Gurin (2012), indica que el diagrama de Casos de uso representa

los objetivos funcionales del usuario del sistema de software. Un objetivo se puede
considerar como una funcionalidad de alto nivel, incluso la realizacin de un
proceso completo. Este diagrama materializa los intercambios informticos entre el
actor y el sistema.

3.20. Diagrama de actividad

Segn Schach (2006). Los diagramas de actividad muestran como se

coordinan varios elementos. Son tiles para modelar negocios en los cuales se
realizan varias actividades en paralelo.

43
 Segn Fowler (2001), los diagramas de actividad se pueden emplear en las
siguientes situaciones:

1. El anlisis de un caso de uso: permite comprender las acciones que

deben ocurrir y cules son las dependencias de comportamiento.
2. En la descomposicin de un flujo de trabajo: ayudan a comprender la
interaccin entre uno o ms casos de uso.
3. En el anlisis de procesos de negocio: ayudan a desglosar por
actividades, las acciones tomadas por todos los miembros involucrados
en la problemtica estudiada.

3.21. Diseo de Sistemas

Segn Oliv y Gmez (2003),

Se trata de aplicar diferentes tcnicas y principios con el propsito de definir
un sistema con el suficiente detalle para permitir su construccin fsica.

- Punto de Partida
o Resultado de la especificacin
Especificacin de datos (Modelo de datos)
Especificacin de procesos (Modelo Funcional y de
Comportamiento)
Especificacin de interaccin con el usuario (Modelo de
Interfaz)
o Tecnologa: Con qu recursos?
Recursos de hardware y software disponibles
Requisitos no funcionales del sistema
- Resultado del diseo: Qu ha de hacer el sistema?
o Estructura interna del software (Arquitectura del Sistema de
Software)
o Diseo de los datos

44
 o Diseo de la Interfaz
o Diseo de los programas
- Proceso del diseo
o Metodologa de diseo
o Adaptacin de soluciones genricas a problemas de diseo.

3.22. Diagrama de componentes

Segn Campderrich (2007), el diagrama de componentes describe la

descomposicin fsica del sistema de software (y eventualmente en su entorno
administrativo) en componentes a afectos de construccin y funcionamiento.
La descomposicin del diagrama de componentes se realiza en trminos de
componentes y de relaciones de los mismos.

Los componentes

Identifican objetos fsicos que hay en tiempo de ejecucin de compilacin o

de desarrollo, y tienen identidad propia y una interfaz bien definida.

Los componentes incluyen cdigo de cualquiera de sus formatos, DLL,

imgenes pero tambin pueden ser documentos manuales cuando se
describen partes no informatizadas de un sistema de informacin

Relaciones entre componentes

En el caso de componentes no informticos, el significado de la relacin es

que un componente utiliza la informacin contenida en el otro. En el caso de
los componentes de software, se distinguen dos tipos de relaciones, en
tiempo de desarrollo y las relaciones de llamadas

45
3.23. Diagrama de despliegue

Segn Campderrich (2007), el diagrama de despliegue permite mostrar la

arquitectura en tiempo de ejecucin del sistema respecto a hardware y a software.

Los Nodos

Los nodos representan objetos fsicos existentes en tiempos de ejecucin,

sirven para modelar recursos que tienen memoria y capacidad de proceso y
pueden ser tanto ordenadores como dispositivos o personas.

Relaciones dentro del diagrama de despliegue

Un componente o un objeto se puede ejecutar si utiliza los recursos de un

nodo o puede estar contenido en este.

3.24. Automatizacin

La Real Academia de las Ciencias Fsicas y Exactas define la automtica como

el conjunto de mtodos y procedimientos para la substitucin del operario en
tareas fsicas y mentales previamente programadas. De esta definicin original se
desprende la definicin de la automatizacin como la aplicacin de la automtica
al control de procesos industriales.

Segn Asensio (2005), la necesidad de automatizacin es elevada si se desea

ofrecer productos de calidad en un entorno competitivo.

46
 Aspectos a conocer sobre las recomendaciones de implementacin del
nuevo proceso de aplicacin de novedades de artculos:

3.25. Implementacin de Sistemas

Se refiere a la adquisicin e integracin de los recursos fsicos y

conceptuales que producen un sistema funcional. Su planificacin consiste en
entregar un bosquejo de los trabajos de implementacin a realizar, los beneficios
esperados y los costos. (McLeod (2000)).

47
4. Listado de Siglas

BD Base de datos. Repositorio de datos para consulta.

Cdigo de Barras Identificador nico e internacional de productos de Retail.
Identificador nico asignado en SAP para uno o varios
Cdigo SAP
cdigos de barra.
Controlador principal de una tienda. Si ambos
CC controladores estn activos, ste asume el control de las
cajas pares.
CU Casos de Uso
Controlador secundario de una tienda. Si ambos
DD controladores estn activos, ste asume el control de las
cajas impares.
Protocolo de transferencia de archivos. Utilizado para el
FTP respaldo de los Idocs de novedades en el controlador
principal.
Documento estndar de SAP que contiene el listado de
IDOC de novedades
artculos a actualizar en el punto de Venta
Maestro de Artculos
Portable Interfase. Aplicacin que se encargar de la
PI
actualizacin de artculos en el POS.
POS Punto de venta. (Point of Sale)
Negocio especializado en la comercializacin masiva de
Retail
productos y servicios a diferentes tipos de clientes.
RF Requerimiento Funcional
RNF Requerimiento No Funcional
RUP Proceso Unificado de Software.
SAP Sistema de Aplicaciones y Productos
Protocolo para la transferencia y manipulacin de archivos
SFTP sobre un flujo de datos fiable. Utilizado para descargar de
SAP los IDOCS de novedades.
SI Sistema de Informacin.
Terminal Caja, Punto de venta.
UML Lenguaje Unificado de Modelado

48
5. Bases ticas y Legales

La elaboracin de esta investigacin se sostuvo sobre bases de honestidad,

honradez y precisin, por lo que se garantiza que las ideas, premisas y solucin
del problema han sido de proporcionados por el autor sobre su base intelectual,
cumpliendo con las normas bsicas de tica establecidas en toda investigacin
cientfica y a la Ingeniera en s en donde se rechaza actuar en cualquier forma
que tienda a menoscabar el honor, la responsabilidad y aquellas virtudes de
honestidad, integridad y veracidad que deben servir de base a un ejercicio cabal
de la profesin.

Por otra parte es importante mencionar que dentro del marco legal, Locatel
se basa en un conjunto de normativas tanto internas como establecidas por los
diferentes entes gubernamentales que sern tomadas en cuenta para la
elaboracin de esta investigacin:

Ley para la defensa de las Personas en el Acceso a los Bienes y

Servicios

En su artculo 8 seala que toda persona, en relacin a los bienes y servicios debe
tener:
La informacin suficiente, oportuna, clara, veraz y comprensible sobre los
diferentes bienes y servicios, puestos a su disposicin, con especificaciones de
precios, cantidad, peso, caractersticas, calidad, riesgo y dems datos de inters
inherentes a su elaboracin o prestacin, composicin y contraindicaciones que
les permita tomar conciencia para la satisfaccin de sus necesidades.

49
 Ley de Costos y precios Justos

En su artculo 18 seala que:

La Superintendencia Nacional de Costos y Precios podr establecer lineamientos
para la planificacin y determinacin de los parmetros de referencia para la
determinacin de precios justos.
Dichos lineamientos pueden tener carcter general, sectorial, particular, o ser
categorizados segn las condiciones vinculantes o similares entre grupos de
sujetos.
Dichos lineamientos debern ser notificados previamente a los sujetos, de manera
personal, si se trata de lineamientos particulares, o mediante publicacin en
Gaceta Oficial de la Repblica Bolivariana de Venezuela, cuando se trate de
lineamientos aplicables a sectores o categoras de sujetos.
Los lineamientos establecidos conforme lo sealado en el presente artculo
servirn a los efectos del clculo del precio justo de los bienes y servicios a
los cuales se refieran, as como para la desagregacin de los respectivos costos o
componentes del precio.

Esta ley fue tomada en cuenta puesto que el incumplimiento de esta ley puede
acarriar consecuencias legales entre el ente gubernamental respectivo y la
franquicia involucrada y la correcta actualizacin de los artculos depender del
buen funcionamiento de un sistema automatizado que minimice dichos riesgos.

10 Mandamientos (www.locatel.com.ve)

o PRIMERO EL CLIENTE: Siempre acogeremos, daremos la bienvenida y

servicios a TODOS los clientes.

o NUNCA DIGA NO: Siempre responderemos de forma positiva y

encontraremos una solucin.

50
o LOS PROVEEDORES TAMBIEN SON NUESTROS CLIENTES:
Recibiremos puntualmente a nuestros proveedores y los trataremos como
si ellos fueran nuestros clientes, esforzndonos en satisfacerlos.

o NUESTROS EMPLEADOS COMPARTEN NUESTROS VALORES:

Creamos una familia con nuestros empleados y logramos su satisfaccin.
Todos compartimos la salud y la filosofa de bienestar y excelencia de
servicio.

o SIN FALLAS DE INVENTARIO: Seguir los procesos de gestin de

inventario, evitar ROTUNDAMENTE las fallas de inventario y mantener
FIFO para manejar las fechas de caducidad.

o TIENDA ORGANIZADA: Siempre, en todo momento, tenemos nuestros

estantes completamente surtidos, limpios, organizados, llenos de luz y
atractivos para nuestros clientes.

o VENTA CRUZADA DE PRODUCTOS Y SERVICIOS: Siempre

proporcionaremos la farmacia y la promocin cruzada de TODOS los
productos de las otras secciones como Equipos Mdicos, Vitamina Y
Suplementos, Salud y Belleza y servicios tales como: Audiologa,
Nutricin, Monitoreo de Presin Arterial y Glucosa, entre otros.
o LNEA EXCLUSIVA DE PRODUCTOS: Siempre proporcionaremos
nuestras lneas exclusivas de productos antes de ninguna otra cosa
(Naturaleza y Vida, Corpore Sano, Invocar, KAZ, Mada, Etc.).
o SEGUIMIENTO DE ORDENES ESPECIALES: Documentaremos y
haremos seguimientos a las ordenes especiales de nuestros clientes
hasta que estn completas y el cliente este satisfecho.
o EL MEJOR SERVICIO EN CADA REA: Proporcionaremos el mejor
servicio y conocimiento posible en cada sector de nuestras tiendas.
Aprenderemos continuamente y no dejamos ningn rea o cliente
desatendidos hasta que su solicitud haya sido solucionada.

51
 CAPITULO III

Marco Metodolgico

Todo desarrollo de un sistema de informacin lleva consigo un conjunto de

pasos a seguir, para con ello no perder ningn componente en la elaboracin del
las fases requeridas en el desarrollo de un sistema til y adecuado para satisfacer
el conjunto de necesidades a resolver.

Este proyecto consisti en el desarrollo de un sistema de informacin para

la actualizacin de artculos registrados en el POS de Locatel Franquicias C.A., es
por ello que se recopil la informacin necesaria de los procesos existentes, para
identificar la metodologa de desarrollo, las tcnicas requeridas y las herramientas
empleadas para la construccin del nuevo sistema.

En el presente captulo se expresa, la definicin del tipo de investigacin y la

metodologa de desarrollo de software adoptada. Asimismo, se busca la
especificacin detallada de cada una de las variables involucradas en los objetivos
a desarrollar.

1. Tipo y Diseo de Investigacin

Partiendo de las caractersticas del problema planteado por la organizacin,

el alcance y las herramientas utilizadas, se plante el Diseo de un Sistema de
Informacin para la Actualizacin de Artculos registrados en los puntos de ventas
de Empresas de Retail. Caso: Locatel Franquicia C.A., lo cual entra en la
clasificacin de proyecto factible.
Segn se plantea en el Manual de Trabajos de Grado, Especializacin,
Maestras y Tesis Doctorales de la Universidad Experimental Libertador (UPEL,
2000), se entiende como proyecto factible: la investigacin, elaboracin y

52
desarrollo de una propuesta de un modelo operativo viable para solucionar
problemas, requerimientos o necesidades de una organizacin o grupos sociales.

Aunado a esto, el diseo de la investigacin realizada fue de campo y

documental. Es documental porque recopila la informacin pertinente de
investigaciones y documentacin previa para la elaboracin de informes
comparativos, para que ayuden a dilucidar las debilidades y fortalezas de la
plataforma actual de Locatel Franquicias C.A.

Por otra parte, el diseo de la investigacin tambin es de campo, ya que se

busc: el anlisis sistemtico de problemas en la realidad, con el propsito bien
sea de describirlos, interpretarlos, entender su naturaleza y factores
constituyentes, explicar sus causas y efectos, o predecir su ocurrencia, haciendo
uso de mtodos caractersticos de cualquiera de los paradigmas o enfoques de
investigacin conocidos o en desarrollo (UPEL, 2000). En este sentido, se realiz
la investigacin sobre la prctica, realizando estudio de los resultados obtenidos
con el sistema que actualmente est implementado en el POS de Locatel
Franquicias, para de esta forma identificar oportunidades de mejora.

2. Unidad de Anlisis

En esta seccin se proceder a especificar el ente de medicin de las

variables involucradas en esta investigacin tanto en la recoleccin como en el
procesamiento de la data.

2.1. Poblacin y Muestra

Segn UPEL, 2000, se define poblacin como el universo afectado por el

estudio, el grupo seleccionado, las caractersticas, tamao y metodologa seguida
para la seleccin de la muestra o de los sujetos, la asignacin de las unidades a
grupos o categoras y otros aspectos que se consideren necesarios.

53
 Para este Captulo, la poblacin est referida al conjunto de entidades y
departamentos que hacen posible la publicacin de precios de todos los productos
ofrecidos en dichos establecimientos,

Las unidades a mencionar a continuacin, proporcionaron diferentes puntos

de vista que a su vez sirvieron para identificar necesidades en cada rea.
Asimismo con la participacin de estas personas se obtuvo una visin clara acerca
de las restricciones del dominio que se aplican al sistema.

Estas unidades de apoyo son:

- Departamento de Categora y Precios
- Departamento de Desarrollos Propios y BD
- Departamento POS

De los departamentos mencionados anteriormente, se contar con la participacin

mostrada en la Tabla 2:

Tabla 2. Participantes de cada rea en el proyecto (Suministrado por cada Departamento)

NOMBRE DEL TOTAL DE INVOLUCRADOS ROLES DE INVOLUCRADOS
DEPARTAMENTO PERSONAS
- Gerente
Categora y Precios 8 3 - Lder
- Especialista
Desarrollos propios y - Jefe del Departamento
8 2
BD - Lder
- Jefe del Departamento
POS 4 2
- Lder

54
 3. Instrumentos y Tcnicas para la Recoleccin de Datos

Partiendo de que esta investigacin fue de tipo documental y de campo, se

realiz participacin activa y pasiva durante todo el desarrollo del sistema de
informacin para la actualizacin de artculos en los puntos de venta de Locatel
Franquicias C.A..

Para la identificacin de fortalezas y debilidades, se practic inicialmente una

observacin pasiva en donde recopil las opiniones de los diferentes usuarios e
involucrados en el proceso de actualizacin de artculos actual; durante esta
inspeccin se midi el desempeo de cada una de las reas involucradas con la
intensin de buscar posibilidades de mejora y documentar. Aunado a esto se
procedi a la aplicacin de la entrevista como instrumento para el levantamiento
de informacin, con la intensin de conocer la perspectiva de todos los
involucrados. En esta fase fue clave el juicio de expertos, ya que la opinin de
cada uno de ellos en cuanto a las entradas y salidas del proceso de aplicacin de
novedades de artculos, lo que fue lo que permiti elaborar el anlisis de fortalezas
y debilidades.

Por otra parte, en cuanto a la deteccin de los requerimientos funcionales se

emple el mtodo Pieces y de esta forma se organizarn los mismos de acuerdo
a: requerimientos funcionales de desempeo, requerimientos funcionales de
Informacin, requerimientos funcionales de control, requerimientos funcionales de
eficiencia y requerimientos funcionales del servicio.

En base a lo recogido se procedi a realizar reuniones semanales con los

involucrados y expertos (en este caso los proveedores y los conocedores del
proceso de negocio) para el levantamiento de informacin e identificar as los
requisitos del software. Una de las tcnicas a utilizadas fue la descomposicin que
permiti analizar cada mdulo tanto de SAP como de POS que interviene en el
proceso de novedades de artculos.

55
 4. Fases de la Investigacin

Para el desarrollo de este proyecto se tom como gua la metodologa

empleada en todas las contrataciones con el proveedor de software Soluciones
VLI. La metodologa fue empleada tomando las mejores prcticas del Proceso
Unificado de Software (RUP) puesto que se cubren gran parte de los aspectos del
desarrollo de software por el detalle que brinda el Proceso Unificado de Software
(RUP), y por otra parte se logra agilizar el diseo y desarrollo de la aplicacin
asignando a un desarrollador que se dedique a obtener la perspectiva del cliente a
travs de conversaciones directas.

Segn Somerville (2006), RUP es un modelo en fases que identifica cuatro

fases diferentes en el proceso de software: Inicio, Elaboracin, Construccin y
Transicin

Figura 8. Ciclo de vida RUP. (IBM)

Para la elaboracin de esta investigacin se ejecut en su totalidad la Fase

de Inicio y Elaboracin; las fases de construccin y transicin an cuando no se
ejecutaron en su totalidad; se dejaron los entregables preparados para el
desarrollo e implementacin respectivos en la organizacin.

Partiendo de lo anteriormente mencionado y para obtener una mejor visin

del proyecto completo, a continuacin, en la Figura 9 se muestra cmo cada
objetivo qued enmarcado en las fases del ciclo de vida de RUP:

56
FLUJOS DE TRABAJO DEL PROYECTO INICIO ELABORACIN CONSTRUCCIN TRANSICIN

Objetivo 1: Modelado de situacin actual

Objetivo 2: Identificacin de Requisitos

Objetivo 3: Anlisis del nuevo sistema

Objetivo 4: Diseo del nuevo sistema

Objetivo 5: Recomendaciones de
implementacin

FLUJOS DE TRABAJO DE SOPORTE INICIO ELABORACIN CONSTRUCCIN TRANSICIN

Gestin del proyecto

Figura 9. Flujos de trabajo del proyectos con RUP

57
 Como se puede observar, al utilizar la metodologa de RUP, usamos un
enfoque iterativo e incremental en donde cada iteracin puede incluir el anlisis de
requerimientos y diseo de la aplicacin.

Para obtener un mejor entendimiento de lo que engloba cada fase de esta

investigacin, se us como apoy el modelo de las 4+1 vistas de Kruchten donde
de manera prctica se intenta representar todo el nuevo sistema a desarrollar a
travs de 5 vistas o perspectivas:

1. Vista de Procesos
2. Vista lgica
3. Vista de despliegue
4. Vista Fsica
5. Vista de Escenarios

Figura 10. 4+1 Vistas de Kruchten

58
4.1. Objetivo Especfico 1: Analizar los actuales procesos del sistema de
aplicacin de novedades de artculos del POS de Locatel Franquicias
C.A. para detectar fortalezas y debilidades del mismo.

Durante esta primera fase se realiz un diagnstico inicial que permiti

conocer el actual proceso de novedades de artculos identificando las
fortalezas y debilidades del mismo y detectando oportunidades de mejora
que permitirn hacer adecuaciones en el nuevo sistema de informacin para
cubrir las necesidades de las reas involucradas. Segn Amaya (2005),
deben incluirse factores relacionados con la organizacin, la competencia,
los recursos financieros, la infraestructura, el recurso humano, el recurso
tecnolgico y el proceso gerencial.

4.1.1. Actividades realizadas

o Observacin de procesos para recopilar opiniones de involucrados

en el proceso actual de actualizacin de artculos.
o Verificacin de manual de procedimientos para creacin y
modificacin de artculos en SAP
o Identificacin de Roles y Responsabilidades
o Entrevistas con el Departamento de Categora y Mtodos
o Entrevistas con el Departamento de Desarrollos propios y BD

4.1.2. Entregables

o Diagrama del proceso actual

o Anlisis de fortalezas y debilidades del Proceso de aplicacin de
novedades de artculos

59
 4.2. Objetivo Especfico 2: Identificar Requerimientos Funcionales y No
funcionales involucrados en la aplicacin de novedades de artculos
desde el POS.

Con la ejecucin de esta fase se identificaron todos los requisitos de la nueva

aplicacin (tanto funcionales como no funcionales) y de esta forma definir el
comportamiento del sistema que se va a desarrollar y todas las restricciones que
se consideraron durante el diseo.

Segn Fabregas (2011), el propsito del modelo de requisitos es comprender

en su totalidad el problema y sus implicaciones. De igual forma esta fase sirve de
base para el desarrollo de las instrucciones operacionales y los manuales, ya que
todo lo que el sistema deba hacer se describe desde la perspectiva de los
usuarios.

Tomando en cuenta el enfoque de las 4+1 vistas de Kruchten (2000), esta

fase est incluida en la vista de Procesos y la vista de escenarios como se
muestra en la Figura 11:

Figura 11. 4+1 Vistas de Kruchten/ Identificacin de requerimientos

60
4.2.1. Actividades realizadas

o Se aprovechar el juicio de usuarios expertos involucrados en

las reas del proceso de aplicacin de novedades de artculos
o Clasificacin y organizacin de los requerimientos
o Elaboracin Matriz de Requerimientos (Mtodo Pieces)
o Reuniones semanales con las reas involucradas para refinar
listado de requerimientos

4.2.2. Entregables

o Matriz de Requerimientos (Mtodo Pieces)

Definicin de Requerimientos funcionales
Definicin de Requerimientos No funcionales

61
 4.3. Objetivo Especfico 3: Analizar los nuevos procesos para la
aplicacin de novedades de artculos desde el POS de Locatel
Franquicias C.A.

En esta fase temprana del desarrollo de la aplicacin que permitir la

actualizacin de novedades de artculos desde el POS de Locatel Franquicias
C.A., se procedi a recopilar toda la informacin necesaria acerca de las
caractersticas, funcionalidad y decisiones tomadas para las mejoras de la nueva
solucin. Segn Alarcn (2006), durante el anlisis de sistemas se identifica qu
se tiene que hacer, no se tratan aspectos tecnolgicos, sino que se centra en
aspectos de negocio, ms concretamente en los problemas, necesidades y los
objetivos de los propietarios y de los usuarios de sistema.

En esta fase de elaboracin se estableci un marco de trabajo para el

sistema a desarrollar especificando los casos de uso del sistema y obteniendo un
plan para el desarrollo de estos procesos de software, entendindose por
Procesos de software como las actividades relacionadas con la produccin de un
sistema de software Somerville (2006). Por otra parte, se midi el impacto de los
cambios antes de aceptarlos. Para la elaboracin de los instrumentos entregados
fue necesario el uso de UML ya que nos apoya a representar el dominio del
problema a atacar.

Tomando en cuenta el enfoque de las 4+1 vistas de Kruchten, P (2000) y de

acuerdo a lo mencionado anteriormente, esta fase est incluida en la vista de
Procesos y la vista de escenarios como se muestra en la Figura 12:

62
 Figura 12. 4+1 Vistas de Kruchten/ Anlisis de nuevos procesos

4.3.1. Actividades realizadas

o Entrevistas con el Departamento de Categora y Mtodos

o Entrevistas con el Departamento de Desarrollos propios y BD
o Identificacin de los casos de uso del nuevo sistema de aplicacin
de novedades de artculos en el POS
o Diagramas UML

4.3.2. Entregables

o Documento de especificacin de requisitos

Diagrama de procesos (ejecucin automtica)
Diagrama de procesos (ejecucin manual)
Definicin de actores del sistema
Diagrama de Casos de Uso
Diagrama de actividades

63
 4.4. Objetivo Especfico 4: Disear el sistema automatizado para la
aplicacin de novedades de artculos desde el POS con las
adaptaciones requeridas de acuerdo a los requerimientos
identificados.

En esta fase se definieron todos los controles y procedimientos de respaldo

que protegen a los datos. En apoyo de la fase de anlisis, los entregables
obtenidos en esta fase de diseo, sern insumo para los desarrolladores del
software de la empresa proveedora para iniciar sus labores. La intensin fue,
dejar por escrito todas las especificaciones tcnicas necesarias para comenzar
con el desarrollo del sistema de informacin para la actualizacin de artculos
desde el POS de Casa Matriz.
En esta fase de construccin se busc la transformacin de la especificacin de
cada requerimiento a travs del modelado de la arquitectura para entregar un
documento de diseo con los siguientes artefactos sugeridos por RUP: Diagrama
de Despliegue y el Diagrama de Componentes. Este documento servir como
insumo para los desarrolladores asignados al proyecto.

Es importante mencionar que durante el desarrollo de la aplicacin, se fijarn

metas a corto plazo razonables para que el proveedor pueda liberar paulatina y
evolutivamente el producto. Segn Kendall K (2005), con este mtodo el
desarrollador puede tener control de las siguientes variables: tiempo, costo,
calidad y alcance para poder alcanzar un estado de equilibrio y culminar
exitosamente cualquier proyecto. Estas variables son ajustables si se definen
metas cortas y se tiene buena comunicacin con los interesados.

Tomando en cuenta el enfoque de las 4+1 vistas de Kruchten, P (2000) y de

acuerdo a lo mencionado anteriormente, esta fase est incluida en la vista de
escenarios, la vista lgica, la vista fsica y la vista de despliegue como se muestra
en la Figura 13:

64
 Figura 13. 4+1 Vistas de Kruchten/ Diseo del sistema de informacin

4.4.1. Actividades realizadas

o Reuniones con el desarrolladores para dar a conocer las historias

de usuarios y mostrar el dominio del problema al proveedor
o Documentacin de informacin recopilada de los departamentos
involucrados
o Identificacin y Documentacin de la Arquitectura del nuevo
Sistema de Informacin

4.4.2. Entregables

o Documento de Diseo
Diagrama de Despliegue
Diagrama de Componentes
Modelo de datos

65
 4.5. Objetivo Especfico 5: Elaborar las recomendaciones de
implementacin respectivas para la puesta en marcha del sistema de
aplicacin de novedades.

Durante este proceso se refinaron los detalles para la puesta en marcha en

produccin, se propuso la planificacin de una prueba Piloto que asegure el buen
funcionamiento de los componentes a instalar. Aunado a esto, se planific el
proceso de distribucin de los componentes masivamente y finalmente se
propusieron formas para sensibilizar a los usuarios.

Segn Somerville (2006) durante en esta fase de transicin, se busca mover el

Sistema desde la comunidad de desarrollo a la comunidad del usuario. Por esta
razn se dej documentado todo el funcionamiento del Sistema para que se pueda
sensibilizar posteriormente al usuario y el mismo no tenga problemas a futuro por
desconocimiento de algn componente.

Tomando en cuenta el enfoque de las 4+1 vistas de Kruchten, P (2000) y de

acuerdo a lo mencionado anteriormente, esta fase est incluida en la vista de
Procesos y la vista de escenarios como se muestra en la Figura 14:

Figura 14. 4+1 Vistas de Kruchten/ Recomendaciones de implementacin

66
 4.5.1. Actividades realizadas

o Planificacin de Prueba Piloto en alguna tienda modelo.

o Preparacin de Paquetes de Instalacin
o Sensibilizacin a los usuarios

4.5.2. Entregables

o Recomendaciones para cada departamento antes de la

implantacin
o Planificacin para la certificacin del sistema
o Preparativos para la instalacin de piloto
o Preparativos para la instalacin masiva

5. Operacionalizacin de variables

Referente a la cita textual, Silva L (1997) seala:

El proceso que permite el trnsito que parte del concepto y desemboca en el
recurso cuantitativo (o cualitativo) con se mide (o se clasifica) dicho concepto se
denomina operacionalizacin de variables. Se trata precisamente de llevar la
nocin desde el plano terico al operativo y concierne al acto de medicin de
grado (o la forma) en que el concepto se expresa en unidad de anlisis
especfica.

Para la elaboracin de este proyecto fue necesaria la identificacin de las

variables involucradas en los objetivos especficos a desarrollar. A continuacin se
mostrar cada una de las variables identificadas y especificadas en detalle:

67
Tabla 3. Operacionalizacin de Variables. Objetivo Especfico 1

OBJETIVO 1: Analizar los actuales procesos de aplicacin de novedades de artculos del POS de Locatel Franquicias C.A. para
detectar fortalezas y debilidades del mismo.
VARIABLE DEFINICIN NOMINAL DIMENSIONES INDICADORES
Se refiere a la elaboracin Nmero de procesos y tareas
de un diagnstico inicial Procesos de negocio Nmero de pasos
que permita conocer las actuales Nmero de procesos automatizados
Proceso actual de fortalezas y debilidades Fortalezas del proceso existentes
aplicacin de del actual proceso de actual de aplicacin de Duracin de cada actividad
novedades de aplicacin de novedades novedades de artculos Nmero de actividades que presentan
artculos de artculos e identificar Debilidades del proceso oportunidades de mejora
oportunidades de mejora actual de novedades de Nmero de actividades que generan un bajo
que permitirn hacer artculos grado de eficiencia
mejoras al nuevo sistema Involucrados Nmero de actividades reutilizadas
de informacin.
FUENTES INSTRUMENTOS ENTREGABLES PREGUNTA BASE
Documentacin de
informacin Cmo se lleva a cabo actualmente el
recopilada de los Diagrama del proceso proceso de novedades de artculos en
departamentos Anlisis de fortalezas y actual. Locatel Franquicias C.A?

involucrados. Grupos Debilidades Listado de fortalezas y Cules son las fortalezas y debilidades del
de Opinin, Debilidades. proceso de aplicacin de novedades de
Identificacin de artculos en el POS?
alternativas.

68
Tabla 4. Operacionalizacin de Variables. Objetivo Especfico 2

OBJETIVO 2: Identificar Requerimientos Funcionales y No Funcionales para la aplicacin de novedades de

artculos desde el POS.
VARIABLE DEFINICIN NOMINAL DIMENSIONES INDICADORES
Se refiere al anlisis, a
travs de elaboracin
de documento de
Nmero de Personas a trabajar
Requerimientos especificacin de
Requerimientos Nmero de procesos involucrados
del nuevo requisitos, de todas las
funcionales Listado de necesidades de cada
Sistema de actividades
Requerimientos no persona
Informacin administrativas y
funcionales Listado de caractersticas requeridas
automatizadas del
del artculo
proceso nuevo de
aplicacin de
novedades de artculos.
FUENTES INSTRUMENTOS ENTREGABLES PREGUNTA BASE
Documento de
Anlisis previo,
Cules son los requerimientos
documentacin Matriz de Matriz de
funcionales y no funcionales del nuevo
acadmica, Requerimientos Requerimientos
sistema de informacin para la
bibliografa, (Mtodo PIECES)
aplicacin de novedades de artculos?
fuentes
electrnicas.

69
 Tabla 5. Operacionalizacin de Variables. Objetivo Especfico 3
OBJETIVO 3 : Analizar los nuevos procesos para la aplicacin de novedades de artculos desde el POS de Locatel
Franquicias C.A.
VARIABLE
Proceso de novedades de
artculos nuevo
FUENTES
Documentacin de informacin
recopilada de los departamentos
involucrados (Dpto. Categora,
Departamento de desarrollos
propios y BD, Departamento de
SAP, Departamento POS).
Grupos de Opinin,
Identificacin de alternativas,
Diagramas UML, Cuestionarios
DEFINICIN NOMINAL
Se refiere a la identificacin
de todos los procedimientos
operativos y automatizados
involucrados en el proceso
actual de actualizacin de
artculos desde su
codificacin hasta la salida al
pblico.
INSTRUMENTOS
Diagrama de Procesos
Diagrama de Casos de
Uso
Plantillas de Casos de
Uso
DIMENSIONES INDICADORES
Proceso de Bsqueda de
IDOCS de novedades en
SAP Diagrama de Casos de Uso
Diagrama de actividad
Proceso de Lectura de
Diagramas de procesos
novedades
Proceso de aplicacin de
novedades en el POS
ENTREGABLES PREGUNTA BASE
Diagrama de procesos
propuesto
Cmo llevar a cabo el nuevo
Actores del sistema proceso de aplicacin de
Diagrama de CU. novedades de artculos?
Diagramas de actividad
70
 Tabla 6. Operacionalizacin de Variables. Objetivo Especfico 4

OBJETIVO 4: Disear el sistema automatizado para la aplicacin de novedades de artculos desde el POS con las adaptaciones
requeridas de acuerdo a los requerimientos identificados.
VARIABLE DEFINICIN NOMINAL DIMENSIONES INDICADORES
En apoyo de la fase de
anlisis, los entregables
Diagrama de Componentes de
obtenidos en esta fase de
hardware presentes en la
Novedades de artculos en el diseo, sern insumo para los
Arquitectura del Sistema arquitectura de Locatel
punto de venta. desarrolladores del software
Franquicias C.A.
de la empresa proveedora
Diagrama de Despliegue
para iniciar sus labores de
construccin del software
FUENTES INSTRUMENTOS ENTREGABLES PREGUNTA BASE

Diagrama de Despliegue Cules son las especificaciones

tcnicas recomendadas para
Documento de Diseo previo, Diagrama de
ofrecer las adecuaciones
documentacin acadmica, UML Componentes
necesarias en los Puntos de
bibliografa, fuentes electrnicas. Modelo de datos
Venta de Locatel Franquicias
C.A.?

71
 Tabla 7. Operacionalizacin de Variables. Objetivo Especfico 5

OBJETIVO 5: Elaborar las recomendaciones de implementacin respectivas para la puesta en marcha del sistema de
aplicacin de novedades.
VARIABLE DEFINICIN NOMINAL DIMENSIONES INDICADORES
Se refiere a la elaboracin de Plataforma tecnolgica para la
un listado de recomendaciones puesta en marcha en
Planificacin de la
para la implementacin en el produccin (Diagrama de
Recomendaciones para la implementacin
conjunto de tiendas que Despliegue)
implementacin Piloto
conforman Locatel Franquicias Nmero de Tiendas a Instalar
Rollout
C.A. en un intento de Nmero de componentes a
minimizar impactos negativos. instalar
FUENTES INSTRUMENTOS ENTREGABLES PREGUNTA BASE
Plan para Piloto
Cmo poner en marcha el
Manual de implementacin Plan para Rollout
Documentacin proceso de actualizacin de
Manual de Usuario Plan de pruebas
artculos?

72
 6. Aspectos Administrativos del Proyecto

La elaboracin de este proyecto llev consigo un esfuerzo de tiempo y

recursos econmicos a especificar a continuacin. En esta seccin se mostrar en
detalle el tiempo invertido en cada fase del proyecto, sus entregables y el
presupuesto invertido en el mismo.

6.1. Estructura Desagregada de Trabajo (EDT)

En la Figura 15 se presenta las actividades y resultados obtenidas por cada fase

de la investigacin:

Figura 15. Estructura desagregada de Trabajo.

73
6.2. Cronograma de la Investigacin

Tabla 8. Cronograma de Trabajo

74
 6.3. Presupuesto de la investigacin

A continuacin, en la Tabla 9 se muestra la inversin que representa la

elaboracin de esta investigacin as como los recursos empleados

Tabla 9. Presupuesto de la Investigacin

CUENTA MONTO (BS)

Resmas de papel 400

1
2 Impresin de Documentos 2000

3 Encuadernacin de documento 1000

4 Fotocopias 100

5 Viticos de Transporte 200

6 Unidades de Crdito 8100

TOTAL 11800

75
 CAPITULO IV

DESARROLLO DE LA PROPUESTA

Todo desarrollo de un sistema de informacin, posee fases en donde se

definen los procesos, las funcionalidades, la estructura, arquitectura y secuencia
de actividades que el desarrollador plasmar en el producto final; es por ello que
se ha incluido este captulo en la investigacin, ya que propone artefactos que se
basan en tratar de cubrir las necesidades y especificaciones de los involucrados.

Este captulo suministrar una visin panormica y a su vez especfica del

contenido y estructura del sistema a desarrollar. Para ello se recurre al mtodo de
observacin y recopilacin de la data a travs de la interaccin directa con los
involucrados.

FASE I: Analizar los actuales procesos del sistema de aplicacin de novedades de

artculos del POS de Locatel Franquicias C.A. para detectar fortalezas y
debilidades del mismo.

Para identificar las fortalezas y debilidades del proceso de aplicacin de

novedades fue necesario realizar el levantamiento de informacin con las reas
involucradas y conocer desde cada punto de vista aspectos que requieran
atencin. Como se muestra en la Figura 16, en esta fase se plantearn los
siguientes aspectos:

Figura 16. Aspectos Fase I.

76
 1.1. Identificacin de Roles y Responsabilidades para la obtencin de
puntos de vista

Segn Sommerville (2007), los puntos de vista proporcionan diferentes tipos

de requerimientos. Los puntos de vista de los involucrados proporcionan
requerimientos detallados del proceso actual y ayudan a descubrir oportunidades
de mejora. Asimismo proporcionan restricciones del dominio que se aplican al
sistema.
La identificacin inicial de los puntos de vista que son relevantes a un
sistema a veces puede ser difcil, as que para este levantamiento de informacin
se tomaron en cuenta los siguientes aspectos:
1. Los puntos de vista de la ingeniera que reflejan los requerimientos de
las personas que tienen que desarrollar, administrar y mantener el
sistema.
2. Los sistemas que deben interactuar directamente con el sistema a
especificar.
3. Las regulaciones y estndares que se aplican al sistema.
4. Las fuentes de los requerimientos no funcionales y de negocio del
sistema.

En la Figura 17 se presenta los puntos de vista de las personas

involucradas en este proyecto.

77
Figura 17. Diagrama de Puntos de vista de los involucrados

78
 Se escogieron estas personas, por la relacin que tienen algunas de sus
labores en este proyecto, a continuacin, en la tabla 10 se muestra el rol de cada
una de ellas para mejor entendimiento:

Tabla 10. Roles y Responsabilidades de los involucrados del proyectos

DEPARTAMENTO PUNTO DE VENTA (POS)

Rol Nombre Responsabilidades
o Dirigir, controlar y supervisar el uso adecuado del
Jefe POS Rosana Gmez software y hardware institucional, respetando las
normativas establecidas
o Establecer, asegurar y evaluar medidas para el
mejoramiento administrativo de los servicios
brindados a las unidades administrativas en materia
de tecnologa de la informacin.
o Asegurar la implementacin de procesos de calidad
en todo el ciclo de vida en el desarrollo productos
de software.
Lder POS Walewska Brandy
o Planificar y coordinar a nivel operativo el equipo
tcnico perteneciente a las diferentes reas
implicadas en el proyecto.
o Realizar la planificacin detallada de las diferentes
partes de un proyecto conforme el ciclo de vida.
o Generar la documentacin especfica segn las
polticas y normas establecidas.
o Definir los mdulos a desarrollar.
Analista POS Waldmir Mendes o Estudiar y establecer las pruebas a realizar para
detectar las anomalas de la aplicacin.
o Velar por el cumplimiento y satisfaccin de las
necesidades del cliente
Lder de
Juan C. Gmez o Gestin de adquisiciones
proyecto VLI
o Gestionar el recurso humano a involucrar en el
proyecto.
Analista POS Diana Delgado o Definir los mdulos a desarrollar.
VLI o Establecer relaciones entre funcionalidades de
software y requisitos funcionales solicitados por el
cliente

79
 DEPARTAMENTO DE DESARROLLO Y BD
Rol Nombre Responsabilidades
Jefe de Jos M. Vasquez o Interpretar el anlisis y la arquitectura de los
desarrollos requerimientos del software.
propios y BD o Generar el cdigo de las aplicaciones, interfaces,
servicios y componentes lgicas del software.
o Asegurar que el cdigo realizado cumple con las
especificaciones funcionales y de arquitectura.
Coordinador de Marco Hung o Realizar la instalacin, configuracin y
BD mantenimiento preventivo y correctivo del software
de base de los equipos centrales del Centro de
Tecnologa de la Informacin.
o Monitorear, de acuerdo a lo planificado, la
performance de las base de datos, a fin de analizar
los ajustes que pudieran ser requeridos para
mantener el nivel esperado de servicio
o Planificar, ejecutar y controlar la migracin del
software de base en funcin de las soluciones
tecnolgicas acordadas.
o Instalar y mantener las herramientas de
administracin de sistemas.
o Documentar las modificaciones que fueron
efectuadas sobre el software de base de los
sistemas centrales

DEPARTAMENTO DE CATEGORA Y PRECIOS

Rol Nombre Responsabilidades
Lder de o Disear herramientas, normas y procedimientos
Xiomara
Categora y para automatizacin y control de los procesos
Bustamante
precios operativos que soportan la gestin del rea
(Codificacin, precios, planogramas).
o Realizar el proceso de codificacin de artculos.
(jerarquizacin)
o Proponer estrategias de fijacin de precios basadas
Analista de en el anlisis del entorno competitivo y rentabilidad
Categora y Carolina Hung del negocio.
precios o Ejecutar las actualizaciones de precio de venta de
todos los artculos comercializados por el grupo
Locatel basados en las polticas de precio y
negociaciones regulares con los proveedores.

A continuacin se muestra de manera resumida los aspectos recopilados de

cada entrevista. Estos aspectos que permitieron la posterior identificacin de
fortalezas y debilidades.

80
 1.2. Resultado del Levantamiento de Informacin

Las entrevistas fueron realizadas con base a un guin previamente

desarrollado, involucrando temas claves con fines prcticos para efectos de esta
tesis. Cabe destacar que en su mayora son preguntas abiertas y adaptadas a la
situacin de cada entrevistado.
Se inicia por describir la entrevista del personal de Categora y Precios
quienes comenzaron por aclarar que su participacin en el proceso de aplicacin
de novedades de artculos est asociada a la creacin y modificacin de los
mismos desde el sistema SAP. Estos artculos pueden ser: Miscelneos,
Farmacia, Nutricin y Dermocosmticos. Explican que existe una jerarqua
preestablecida y puede descargarse en SAP Arts.
Indican tambin que tanto codificacin como cambio de precio se ejecutan
diariamente, si se trata de modificacin de otra referencia del artculo como
descripcin no es tan frecuente. Los cambios pueden ser solicitado por el
Departamento de Compras, o simplemente una tienda puede notificar que le lleg
un artculo nuevo. Sin embargo aclaran que, en el caso de los artculos regulados
es Categora quien lleva el control.
Luego para entender un poco cmo se manejan los artculos que sern
facturados por el POS, la Lder del rea aclara que los productos pueden tener
varias unidades de medida en SAP puesto que desde esta herramienta se
manejan las entradas y salidas del mismo, estas unidades de medida pueden ser:
Unidad, Caja o Bulto. Tanto Unidad como Caja pueden ser facturados por el POS,
sin embargo Bulto no debe ser vendido por lo tanto no debe tener asignado precio
de venta.
Independientemente de la novedad que tenga el producto, slo bajar al
Punto de venta, si el mismo posee en SAP precio de facturacin.
Luego y para entender su responsabilidad en esta cadena de labores,
explican cul es el procedimiento para crear un artculo nuevo:
1. El Dpto. Compras entrega la ficha de Producto al Dpto de Categora y
precios. Se verifica que el artculo no exista en SAP ni por barra ni por
descripcin.

81
 2. En base a la Ficha del producto que se harecibido, el Dpto. de Categora
ingresa los datos correspondientes del producto en ZART.
3. SAP genera el cdigo SAP y la informacin del producto que sern
enviados al Dpto. de Compras.
4. El Dpto. de Compras crea el Registro Info e indica el precio inicial a
asignarle al producto.
5. El Dpto. de Categora asigna precio de venta al POS (este precio es
calculado automticamente por SAP).

Informan adems que el tiempo que toma la creacin de un artculo es entre

2 das a 1 semana mximo dependiendo del tiempo de comunicacin entre
departamentos.
Aunado a esto, mencionan que para la creacin del artculo en SAP, utilizan
una transaccin denominada ZART y para la asignacin de precio utilizan una
transaccin denominada VKP5. Los precios de artculos de Lealtad y la revista son
asignados desde la Transaccin: VKP12.

En relacin a la modificacin de artculos, el procedimiento es similar a la

creacin solo que NO es modificable la unidad de medida y en SAP utilizan las
mismas transacciones ZART Y VKP5. El tiempo que toma la modificacin de un
artculo puede variar entre 2 das a 1 semana mximo dependiendo del tiempo de
comunicacin entre departamentos.

Luego resaltan que tambin cuentan con un procedimiento para impedir la

venta de un artculo por cualquier causa justificada; para ello, se bloquea en SAP
por aprovisionamiento y luego se le informa al personal de Desarrollos propios y
BD y al Departamento de POS para que la barra sea bloqueada manualmente.

Cuando un artculo tiene una fecha de vigencia en especfico, el mismo es

modificado manualmente en la transaccin VKP5 de acuerdo a lo establecido por
la competencia en su encarte. Como actualmente el POS no maneja fechas de

82
vigencia, es necesario que baje una novedad del artculo al Punto de venta el da
de vencimiento a las 11:00 pm.
En el caso de la reasignacin de barras, informan que se le asigna una
barra IK al producto que tena la barra y esta barra es reasignada al producto
nuevo. Tambin mencionan que puede ocurrir que los proveedores reutilicen las
barras y por eso un artculo nuevo puede usar una barra que ya fue usada por
otro. Es por esta razn que puede darse el caso que queden en stock artculos
viejos con la barra que ahora tendr el nuevo. El Dpto de Categora le asigna la
barra IK al viejo y la barra existente queda asignada al nuevo producto. Cuando
esto ocurre indican (en forma de autocrtica) que el Punto de ventas no tiene forma
de detectar que existe una dualidad de barras y confirman que deberan indicar
que se realizar este procedimiento al El Dpto POS para eliminar la dualidad de
barras.

Finalmente el Departamento de Categora, anuncia sus solicitudes de

mejora y son (En el apartado A-1 de la seccin de Anexos se muestra el formato
de la entrevista aplicada):
- Se requiere de novedades de emergencia que bajen a tiempo. (Forzar
novedades el mismo da en los Puntos de venta).
- Depuracin del Maestro de artculo.
- Novedades para el bloqueo de artculos en SAP para que bajen al POS.

En la entrevista realizada al departamento de Desarrollos Propios y BD, se

logr conocer en detalle el procedimiento ejecutado para que las novedades de
artculos generadas en SAP, sean reconocidas por los puntos de venta y aplicadas
(En el apartado A-2 de la seccin de Anexos se muestra el formato de la entrevista
aplicada).
Bsicamente, el proceso se inicia en SAP con la ejecucin de la transaccin:
JOB_NOVEDADES_VZLA para la generacin de los Idocs de novedades. Este
corre todos los das a las 11:00pm y se encarga de buscar modificaciones de
artculos en SAP y agruparlas en el documento de novedades denominado IDOC

83
que queda alojado en una ruta especfica del servidor. El proceso es automtico y
nativo de SAP, adems se ejecuta por organizacin de ventas (Aclaran que Una
organizacin de ventas es una sociedad que comprende un conjunto de tiendas).
Adems de este proceso, explican que existe una transaccin denominada
WPMA que sirve para generar puntualmente un IDOC de acuerdo al momento
deseado y se aplica por centro, luego se ejecuta un JOB de SQL con los
siguientes pasos
- Paso 1.Descargar los IDOCS desde SAP: en este paso se hace una
conexin va FTP para ubicar los IDOCS WP_PLU y WP_EAN de los
ltimos 10 das por centro.
Una vez ubica los IDOCS con el rango de fecha correspondiente a los
ltimos 10 das, los convierte en formato de texto y los concatena.
Finalmente los enva a travs de una conexin ftp a cada controlador de
la tienda
- Paso 2. Aplicacin en el POS: en este paso se ejecuta una
comunicacin telnet con los controladores de cada tienda y se hace la
peticin de lectura y aplique de cambios a los artculos indicados en los
IDOCS.
Bsicamente este proceso se encarga de leer los IDOCS de novedades
y registrar en el maestro de artculos las modificaciones para cada
producto. Finalmente se registra en un archivo denominado
HISTNOVE.dat la modificacin, el tipo y la fecha de aplicacin.
- Paso 3. Generacin de EAMITEMR.txt desde el POS: en este paso se
genera un maestro de artculos en formato de texto.
- Paso 4. Descarga del EAMITEMR.txt: en este paso se descarga el
maestro de artculos en formato de texto en una BD con la intensin de
dejar un historial por da de las modificaciones realizadas.
- Paso 5. Publicar en Catlogo de artculos: teniendo registrada la
informacin del maestro de artculos, en este paso se compara la
informacin registrada el da en curso y el da anterior para detectar
cules fueron las modificaciones realizadas y poder nutrir la aplicacin

84
 de catlogo de artculos utilizada por las tiendas para obtener
informacin del producto y su disponibilidad por tienda.
- Paso 6. Respaldar EAMITEMR.txt: en este paso queda respaldado en
una ruta del servidor el maestro de artculos en formato de texto.

Luego de haber explicado este proceso, reflexionan que si existe algn

error con el proceso de aplicacin de novedades (que corresponde al paso 2, no
tienen forma de enterarse, as que tampoco tienen certeza de que los artculos
estn actualizados diariamente, el monitoreo es manual y es realizado por ellos
mismos. Aunado a esto la descarga de los IDOCS de SAP a los controladores de
las tiendas es lo que ms toma tiempo y podra mejorarse. El proceso de
comparacin del maestro del da de ejecucin con el del da anterior no es el ideal.
Finalmente comparten sus opciones de posibilidad de mejora:
1. Desde SAP pudiera ejecutarse el proceso de concatenacin de los
IDOCS y alojarlos en la ruta comprimidos para facilitar la descarga a los
controladores.
2. Deben crearse los mecanismos para registrar el desempeo e informar
errores
3. El nuevo proceso a implementar puede registrar en una tabla las
novedades de los artculos para evitar la comparacin de los maestros
de artculos por fecha
4. El proceso nuevo puede registrar el maestro de artculo completo en una
tabla
5. El nuevo proceso a implementar puede comunicarse con el catlogo de
artculos para informar los cambios aplicados.
6. El aplique debera darse por cdigo SAP.

En la entrevista realizada a la Jefa del Departamento de POS, se logr

entender el manejo de los IDOCS de novedades en relacin al aplique en los
Puntos de Venta. Inicialmente el proceso comienza con la lectura del WP_PLU
que contiene el listado de cdigos SAP y sus barras principales. Este documento

85
contiene la referencia completa del artculo (Descripcin larga, Impuesto,
Descuento, Precio).

Durante la reunin con el Lder y la analista POS de la empresa Soluciones

VLI, se logr entender la lectura de los IDOCS de novedades, bsicamente para
aplicar cualquier cambio, se realiza una lectura lineal por cdigo de barras del
IDOC WP_PLU; por cada cdigo de barra se consulta al maestro de artculos se
compara toda la referencia del producto con lo que indica el IDOC para detectar
alguna diferencia, si se consigue algn cambio, el proceso actual guarda este
cambio en una cola la novedad y continua leyendo el IDOC de novedades. Una
vez que se han detectado todas las novedades del IDOC se procede a registrar en
el maestro de artculos las mismas.

Para entender el manejo del los IDOCS WP_EAN es importante saber que
estos manejan la herencia de las barras. Este documento contiene nicamente el
listado de las barras principales con sus barras secundarias (si poseen). La Jefe
del Departamento de POS confirma que este documento es el que debe pautar la
herencia de las barras y que si una barra principal tiene una novedad registrada en
el IDOC WP_PLU, lo lgico es que tambin este registrada en el IDOC WP_EAN
si posee barras secundarias. Primero se lee completo el WP_PLU y
posteriormente se lee completo el WP_EAN.

Proceso de aplicacin de novedades actual

Gracias a la informacin recopilada con la aplicacin de diferentes entrevistas se

procedi con la elaboracin de un Diagrama de actividad asociado al proceso de
negocio relacionado con la aplicacin de novedades en los Puntos de venta donde
actualmente se siguen los siguientes pasos:

1. Generar Cambios a un artculo.

2. Generar IDOCS de novedades de artculos.
3. Almacenar IDOCS en una ruta especfica en SAP.

86
 4. Descargar Va FTP IDOCS con las novedades de artculos.
5. Concatenar IDOCS con barras principales.
6. Enviar va FTP IDOCS al controlador de cada tienda.
7. Solicitar aplique de novedades a los artculos.
8. Ubicar IDOCS en el controlador.
9. Leer IDOCS de novedades.
10. Actualizar maestro de artculos.
11. Registrar cambios en el archivo HISTNOVE.DAT.
12. Notificar culminacin de aplique.
13. Respaldar maestro de artculos.
14. Publicar modificaciones en el maestro de artculos.

1.3. Diagrama de Proceso actual

Basado en los aspectos recopilados se identificaron los siguientes procesos

planteados en un Diagrama que involucra tanto los procesos de negocio como las
tareas automatizadas de la aplicacin de novedades de artculos. Ver Figura 18.

87
Figura 18. Diagrama de Procesos actual

88
 1.4. Identificacin de Fortalezas y Debilidades

A continuacin se muestra tabla que permitir reconocer aquellas, actividades,

tareas o situaciones en general que hacen que el proceso cumpla con sus metas
de forma exitosa, y ayudan mejorar la gestin o los objetivos del negocio.
Asimismo se identificarn aquellos atributos internos que pueden resultar un
obstculo para lo anteriormente planteado.

Tabla 11. Fortalezas del proceso actual

FORTALEZAS
1. Existe ya un proceso de aplicacin de novedades automatizado que sirve de modelo
inicial

2. Posibilidad de mejorar el proceso actual luego de la recoleccin de necesidades de

cada rea

3. Gracias al proceso de aplicacin de novedades de artculos actual es posible la

impresin de etiquetas con la referencia de los artculos

4. Gracias al proceso de novedades actual es posible publicar la referencia del artculo en

el Catlogo Web.

5. El proceso permite el manejo de jerarqua de cdigos de barras donde las barras

secundarias heredan la referencia completa del artculo

89
Tabla 12. Debilidades del proceso actual
DEBILIDADES
1. No existe documentacin de los procesos

2. La aplicacin de novedades de artculos a pesar de ser un proceso aplicado en los

Puntos de Ventas es manejado por el personal de desarrollo

3. Carencia de mecanismos para reportar incidencias en el sistema

4. Falta de un sistema automatizado que cubra todos los pasos de la aplicacin de

novedades en el POS

5. Desconocimiento de los pasos a seguir para la aplicacin de novedades por parte de

las reas involucradas

6. Falta de control con respecto a la aplicacin o no de las novedades en cada artculo

del IDOC
7. Fallas en la escritura del archivo historial de novedades lo que ocasiona impresin de
etiquetas de artculos con referencias erradas

8. Procedimiento de lectura y aplicacin en el POS no es intuitivo

9. Desconfianza de la vigencia de la referencia de a cada artculo

10. Se desconoce el desempeo de la aplicacin, no hay logs de desempeo

11. No existe el manejo de artculos bloqueados en el POS, a pesar de que en el IDOC

de novedades se registran los bloqueos, stos no son interpretados por el POS

90
FASE II: Identificar los requerimientos funcionales y no funcionales involucrados
en la aplicacin de novedades de artculos desde el POS.

Con la ejecucin de esta fase se pretende identificar todos los requisitos de la

nueva aplicacin (tanto funcionales como no funcionales) y de esta forma definir el
comportamiento del sistema que se va a desarrollar y todas las restricciones que
se debern considerar durante el diseo.

Segn Cavero J, (2005), la ingeniera de requisitos es la rama de la ingeniera

del software que se ocupa de la primera etapa del proceso de desarrollo del
software: la comprensin y la formalizacin de las necesidades que debe
satisfacer un sistema informtico.

Como se muestra en la Figura 19, en esta fase se plantearn los siguientes

aspectos:

Figura 19. Aspectos Fase II.

91
 2.1. Identificacin de Requerimientos Funcionales

A continuacin se definir un grupo de requerimientos funcionales asociados

al hardware que deben ser cumplidos a cabalidad para la puesta en marcha del
proyecto.
Cada requerimiento se identifica de la siguiente forma:

Tabla 13. Requerimientos funcionales. RF001.

Cdigo: RF001
Nombre La interfaz de comunicacin POS/ SAP ser Portable Interface
Descripcin: Partiendo de los componentes instalados hoy en da en los controladores y
que conforman al Portable Interface utilizado actualmente slo como interfaz
de salida. Se desea actualizar dichos componentes e incluir la interfaz de
entrada para la aplicacin de novedades de artculos en el POS
Tipo de
Funcional y de Servicio
Requerimiento:
Solicitado por: Departamento POS
Tabla 14. Requerimientos funcionales. RF002.
Cdigo: RF002
Nombre Debe llamarse automticamente todos los das a una hora configurable
Descripcin: El proceso de aplicacin de novedades debe ejecutarse todos los das a las
3:00 am de forma automtica, esta hora debe ser configurable.
Tipo de
Funcional y de Control
Requerimiento:
Solicitado por: Departamento POS
Tabla 15. Requerimientos funcionales. . RF003.
Cdigo: RF003
Nombre Permitir conexin va SFTP
Descripcin: La interfaz debe conectarse con SAP a travs de un servicio de conexin
segura SFTP con parmetros de conexin especficos
Tipo de
Funcional, de Servicio y de Control
Requerimiento:
Solicitado por: Departamento POS y Desarrollo

92
Tabla 16. Requerimientos funcionales. . RF004.
Cdigo: RF004
Nombre Los IDOCS se descargarn de SAP en formato comprimido (.zip)
Descripcin: Los IDOCSa aplicar en el controlador se descargarn de SAP en formato
comprimido (.zip) con el nombre de A001AAAAMMDD.zip correspondiente a
centro y fecha
Tipo de
Funcional, de Informacin y Economa
Requerimiento:
Solicitado por: Departamento POS y Desarrollo

Tabla 17. Requerimientos funcionales. RF005.

Cdigo: RF005
Nombre Los IDOCS deben descomprimirse en una ruta de controlador (adx_udt1)
Descripcin: Una vez que termina la bsqueda de A001AAAAMMDD.zip, se ejecuta el
proceso de descompresin de los IDOCS, en la ruta C:\adx_udt1\
Tipo de
Funcional y de Servicio
Requerimiento:
Solicitado por: Departamento POS

Tabla 18. Requerimientos funcionales. RF006.

Cdigo: RF006
Nombre Slo se descargar el IDOC WP_PLU con barras principales y secundarias
Descripcin: Los IDOCS ledos por el POS sern del tipo WP_PLU y contendrn tanto
barras principales como barras secundarias.
Tipo de
Funcional y de Eficiencia
Requerimiento:
Solicitado por: Departamento Desarrollo

Tabla 19. Requerimientos funcionales. RF007.

Cdigo: RF007
Nombre Los IDOCS a ser ledos deben ser de formato .txt
Descripcin: Los IDOCS a aplicar en el CC deben estar en formato de texto
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS

Tabla 20. Requerimientos funcionales. RF008.

Cdigo: RF008
Nombre Los IDOCS deben ser renombrados a WP_PLU02.txt
Descripcin: En la ruta adx_udt1 del controlador deben estar almacenados los IDOCS con
la descripcin corta de la siguiente manera WP_PLU01.TXT
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS

93
Tabla 21. Requerimientos funcionales. RF009.
Cdigo: RF009
Nombre El proceso debe leer secuencialmente el IDOC de novedades
Descripcin: El IDOC WP_PLU debe ser ledo con el PI de manera secuencial de acuerdo
al orden en que ya vienen registradas las barras.
Tipo de
Funcional, de Informacin y Control
Requerimiento:
Solicitado por: Departamento POS y Desarrollo
Tabla 22. Requerimientos funcionales. RF010.
Cdigo: RF010
Nombre El proceso debe registrar en el maestro de artculos los cambios encontrados
Descripcin: Todos los artculo encontrados en el IDOC deben ser ledos y registrados en
el EAMITEMR.dat o maestro de artculos
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS

Tabla 23. Requerimientos funcionales. RF011.

Cdigo: RF011
Nombre El PI debe identificar en el IDOC el cdigo SAP, barras asociadas y tipo de
novedad
Descripcin: Para registrar en el maestro de artculos el PI debe identificar el cdigo SAP
en el IDOC, sus barras asociadas y el tipo de novedad
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS

Tabla 24. Requerimientos funcionales. RF012.

Cdigo: RF012
Nombre Para escribir la novedad de un artculo es necesario bloquear por Cdigo
SAP sus barras asociadas primero.
Descripcin: Para escribir en el maestro de artculos se debe ubicar por el cdigo SAP,
todas las barras asociadas y borrarlas. luego escribir el sap con barras
completo de acuerdo a lo ledo en el IDOC
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento Desarrollo
Tabla 25. Requerimientos funcionales. RF013.
Cdigo: RF013
Nombre Los IDOCS con fecha cabecera superior a la fecha del cc no se aplicarn
Descripcin: Los IDOCS con fecha cabecera superior a la fecha del cc no se aplicarn
Tipo de
Funcional, de Informacin y de Control
Requerimiento:
Solicitado por: Departamento POS, Desarrollo y Categora

94
Tabla 26. Requerimientos funcionales. RF014.
Cdigo: RF014
Nombre Los tipos de modificaciones ledas sern cambio de precio, artculo nuevo y
otro cambio
Descripcin: Las modificaciones permitidas en el maestro de artculo sern:
- Cambio de precio: si se trata de cambio de precio, cambio de
descuento o cambio de impuesto. El indicador ser P
- Artculo Nuevo: introduccin de un nuevo producto al mercado. El
indicador ser N
- Otro Cambio: Cambio de descripcin El indicador ser O
- Sin novedad: cuando el artculo viene en el IDOC pero no se
detectan diferencias en el maestro. El indicador ser X
Tipo de Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS

Tabla 27. Requerimientos funcionales. RF015.

Cdigo: RF015
Nombre Registrar de artculos nuevos
Descripcin: El sistema deber asignar un artculo como nuevo si:
- El cdigo SAP y la Unidad no existen previamente en el maestro de
artculo
- El Cdigo SAP existe pero la unidad de medida es diferente a la que
indica el maestro
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS y Desarrollo
Tabla 28. Requerimientos funcionales. RF016.
Cdigo: RF016
Nombre Registrar de artculos con cambios de precio
Descripcin: El sistema deber asignar un artculo con cambio de precio si el cdigo SAP
y la unidad de medida es igual a la que indica el maestro y se detecta
cambio de precio, cambio en el impuesto o cambio en los descuentos.
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS y Desarrollo

Tabla 29. Requerimientos funcionales. RF017.

Cdigo: RF017
Nombre Registrar de artculos con otro cambio
Descripcin: El sistema deber asignar un artculo con otro si el cdigo SAP y la unidad
de medida es igual a la que indica el maestro y se detecta cambio en la
descripcin del artculo
Tipo de
Funcional y de Informacin
Requerimiento:
Solicitado por: Departamento POS y Desarrollo

95
Tabla 30. Requerimientos funcionales. RF018.
Cdigo: RF018
Nombre El sistema debe registrar en una tabla de BD los eventos fallidos durante la
aplicacin de novedades.
Descripcin: El sistema debe almacenar en una tabla de BD las fallas detectadas durante
la aplicacin de novedades de artculos del maestro EAMITEMR.dat
Tipo de
Funcional, de Control, de Informacin y de Eficiencia
Requerimiento:
Solicitado por: Departamento de Desarrollo

Tabla 31. Requerimientos funcionales. RF019.

Cdigo: RF019
Nombre El sistema debe almacenar en una tabla de BD las novedades aplicadas a
los artculos del maestro EAMITEMR.dat
Descripcin: El sistema debe almacenar en una tabla de BD las novedades aplicadas a
los artculos del maestro EAMITEMR.dat
Tipo de
Funcional, de Control y de Informacin
Requerimiento:
Solicitado por: Departamento de Desarrollo

Tabla 32. Requerimientos funcionales. RF020.

Cdigo: RF020
Nombre El sistema debe registrar informacin especfica en la tabla de novedades
Descripcin: Se debe almacenar en la tabla de novedad la siguiente informacin:
- Fecha novedad: Fecha de cabecera del IDOC
- Cdigo SAP
- Unidad de medida
- Cdigo de Barra del artculo
- Tipo de Cambio
- Precio Unitario
- Impuesto
- Descuento
Tipo de
Funcional, de Control y de Informacin
Requerimiento:
Solicitado por: Departamento de Desarrollo

Tabla 33. Requerimientos funcionales. RF021.

Cdigo: RF021
Nombre El sistema debe enviar correo electrnico en caso de fallas
Descripcin: El sistema deber enviar correo electrnico cuando falle la escritura en la
tabla de eventos o en la tabla de novedad.
Tipo de
Funcional y de Control
Requerimiento:
Solicitado por: Departamento de POS y Desarrollo

96
Tabla 34. Requerimientos funcionales. RF022.
Cdigo: RF022
Nombre El PI debe poder ejecutarse manualmente
Descripcin: El sistema debe permitir la ejecucin manual del PI para la aplicacin de
novedades a cualquier hora del da, segn una fecha deseada.
Tipo de
Funcional y de Control
Requerimiento:
Solicitado por: Departamento POS, Desarrollo, Categora
Tabla 35. Requerimientos funcionales. RF023.
Cdigo: RF023
Nombre El proceso debe dejar por escrito un log de desempeo
Descripcin: Una vez que culmine la ejecucin del proceso de aplicacin de novedades
debe quedar por escrito y por artculo el desempeo de los componentes
involucrados.
Tipo de
Funcional y de Control
Requerimiento:
Solicitado por: Departamento POS

2.2. Identificacin de Requerimientos No Funcionales

A continuacin se definirn un grupo de requerimientos no funcionales

asociados al hardware que deben ser cumplidos a cabalidad para la puesta en
marcha del proyecto.
Cabe destacar que para el proveedor seleccionado por el tiempo de
confianza prestndonos servicios, no hay cabida a escoger otras opciones de
software.
Cada requerimiento se identifica de la siguiente forma:

97
Tabla 36. Requerimientos no funcionales. RNF001.
Cdigo: RNF001
Nombre El proceso no debe tardar ms de un minuto por ejecucin
Descripcin: El proceso de lectura de los IDOCS y aplique de novedades en el POS no
puede tardar ms de un minuto en ejecucin.
Tipo de
No funcional y de desempeo
Requerimiento:
Solicitado por: Departamento POS
Tabla 37. Requerimientos no funcionales. RNF002.
Cdigo: RNF002
Nombre El log de desempeo debe sobrescribirse diariamente
Descripcin: El logs del desempeo del PI para la aplicacin de novedades debe
sobrescribirse diariamente.
Tipo de
No funcional y de Economa
Requerimiento:
Solicitado por: Departamento POS

Tabla 38. Requerimientos no funcionales. RNF003.

Cdigo: RNF003
Nombre El proceso debe ser compatible con la versin de Sistema Operativo
instalada en produccin en los controladores
Descripcin: Actualmente tanto controladores como cajas se rigen por el Sistema
Operativo Supermarket Aplication (SMA) V.590R101, para la instalacin de
la interfaz de comunicacin para el aplique de novedades de artculos, la
misma debe ser compatible con dicho Sistema Operativo
Tipo de
No funcional y de Servicio
Requerimiento:
Solicitado por: Departamento POS
Tabla 39. Requerimientos no funcionales. RNF004.
Cdigo: RNF004
Nombre El PI debe ser capaz de establecer comunicacin con el sistema SAP
Descripcin: La interfaz de comunicacin, debe permitir comunicacin estable con el
sistema SAP.
Tipo de
No funcional y de Servicio
Requerimiento:
Solicitado por: Departamento POS

Tabla 40. Requerimientos no funcionales. RNF005.

Cdigo: RNF005
Nombre Para el envo de las transacciones cada tienda debe contar con un servidor
de BD
Descripcin: Se requiere de la instalacin de un servidor de BD SQL para el registro de
las modificaciones detectadas y aplicadas a los artculos.
Tipo de
No funcional y de desempeo
Requerimiento:
Solicitado por: Departamento POS

98
Tabla 41. Requerimientos no funcionales. RNF006.
Cdigo: RNF006
Nombre Para el envo de las transacciones a SAP los servidor deben tener instalados
el servicio sftp
Descripcin: La interfaz de comunicacin, debe permitir una comunicacin va sftp
estable.
Tipo de
No funcional y de Desempeo
Requerimiento:
Solicitado por: Departamento POS
Tabla 42. Requerimientos no funcionales. RNF007.
Cdigo: RNF007
Nombre El sistema no debe detener la ejecucin si no puede actualizar algn artculo
Descripcin: Si el sistema detecta algn error durante la ejecucin del proceso de
actualizacin de artculos, no debe terminar, debe escribir en la BD los
eventos y continuar ejecutndose
Tipo de Funcional y de desempeo
Requerimiento:
Solicitado por: Departamento POS y Desarrollo

99
 2.3. Matriz de Requerimientos

Haciendo uso del mtodo PIECES para reconocimiento de los

requerimientos, a continuacin se listarn los Funcionales y no Funcionales y se
clasificarn de acuerdo a la estructura mencionada. Esta tcnica permite asegurar
que tanto el analista de sistemas como los usuarios se involucran en el anlisis de
cada una de las siguientes categoras esenciales en relacin con el dominio del
problema. Ver Tabla 43.

Tabla 43. Mtodo Pieces.

CATEGORA REQUERIMIENTO
- RNF001: El proceso no debe tardar ms de un minuto por
ejecucin.
- RNF005: Para el envo de las transacciones cada tienda
P debe contar con un servidor de BD.
(Performance/ - RNF006: Para el envo de las transacciones a SAP los
Desempeo) servidor deben tener instalados el servicio sftp
- RNF007: El sistema no debe detener la ejecucin si no
puede actualizar algn artculo
RF004: Los IDOCS se descargarn de SAP en formato
comprimido (.zip)
RF007: Los IDOCS a ser ledos deben ser de formato .txt
RF008: Los IDOCS deben ser renombrados a
WP_PLU02.txt
RF009: El proceso debe leer secuencialmente el IDOC de
novedades
I RF010: El proceso debe registrar en el maestro de
(Information/ artculos los cambios encontrados
Informacin) RF011: El PI debe identificar en el IDOC el cdigo SAP,
barras asociadas y tipo de novedad.
RF012: Para escribir la novedad de un artculo es
necesario borrar por Cdigo SAP sus barras asociadas
primero.
RF013: Los IDOCS con fecha cabecera superior a la
fecha del cc no se aplicarn
RF014: Los tipos de modificaciones ledas sern cambio

100
 de precio, artculo nuevo y otro cambio.
RF015: Registrar de artculos nuevos
RF016: Registrar de artculos con cambios de precio
RF017: Registrar de artculos con otro cambio
RF018: El sistema debe registrar en una tabla de BD los
eventos fallidos durante la aplicacin de novedades
RF019: El sistema debe almacenar en una tabla de BD
las novedades aplicadas a los artculos del maestro
EAMITEMR.dat
RF020: El sistema debe registrar informacin especfica
en la tabla de novedades
E RF006: Slo se descargar el IDOC WP_PLU con barras
principales y secundarias.
(Eficience/
Eficiencia) RF018: El sistema debe registrar en una tabla de BD los
eventos fallidos durante la aplicacin de novedades
RF002: Debe llamarse automticamente todos los das a
las 3 am
RF003: La interfaz debe conectarse con SAP a travs de
un servicio SFTP con parmetros de conexin especficos
RF009: El proceso debe leer secuencialmente el IDOC de
novedades
RF013: Los IDOCS con fecha cabecera superior a la
fecha del cc no se aplicarn
C RF018: El sistema debe registrar en una tabla de BD los
(Control) eventos fallidos durante la aplicacin de novedades
RF019: El sistema debe almacenar en una tabla de BD
las novedades aplicadas a los artculos del maestro
EAMITEMR.dat
RF021: El sistema debe enviar correo electrnico en caso
de fallas
RF022: El PI debe poder ejecutarse manualmente
RF023: El proceso debe dejar por escrito un log de
desempeo

E RF004: Los IDOCS se descargarn de SAP en formato

comprimido (.zip)
(Economy/ RNF002: El log de desempeo debe sobrescribirse
Economa) diariamente.

RF001: La interfaz de comunicacin POS/ SAP ser

Portable Interface
S RF003: La interfaz debe conectarse con SAP a travs de
un servicio SFTP con parmetros de conexin especficos
(Services/Servicios)
RF005: Los IDOCS deben descomprimirse en una ruta de
controlador (adx_udt1)
RNF003: El proceso debe ser compatible con la versin

101
 de Sistema Operativo instalada en produccin en cada
controlador.
RNF004: El PI debe ser capaz de establecer
comunicacin con el sistema SAP

FASE III: Analizar los nuevos procesos para la aplicacin de novedades de

artculos desde el POS de Locatel Franquicias C.A.

Segn el IEEE Piattini (1996), la fase de anlisis se refiere al estudio de las

necesidades de los usuarios para llegar a una definicin de los requisitos del

102
sistema, hardware o software, as como el proceso de estudio y refinamiento de
dichos requisitos.

Se puede concluir que partiendo de las necesidades del cliente, se detectan

requisitos de software que finalmente podran convertirse en funcionalidades del
sistema:

Necesidades del Requisitos de Funcionalidades

cliente Software del Sistema

Figura 20. Trazabilidad de necesidades de usuario

En esta fase se pretende determinar los objetivos y lmites de la propuesta

a desarrollar, caracterizar su estructura y funcionamiento basados en el listado de
requerimientos recogidos anteriormente.

Como se muestra en la Figura 21, en esta fase se plantearn los siguientes

aspectos:

Figura 21. Aspectos Fase III.

3.1. Diagrama de Procesos Propuesto

Segn Jacobson (1998), el proceso de desarrollo de software es aquel en

que las necesidades del usuario son traducidas en requerimientos de software,
estos requerimientos transformados en diseo y el diseo implementado en

103
cdigo, el cdigo es probado, documentado y certificado para su uso operativo.
Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar
un cierto objetivo"

Para desarrollar software es necesario:

1. Entender la naturaleza del software
2. Utilizar un proceso de desarrollo bien definido y probado (adaptado a las
caractersticas del software a desarrollar)
3. Gestionar el desarrollo de software como un proyecto de ingeniera

En la Figura 22 se presenta el diagrama de actividades que representa los

procesos nuevos a fin de entender dnde se ubican los requerimientos solicitados
anteriormente

104
Figura 22. Diagrama de Procesos propuesto

105
 3.2. Procesos Identificados

De acuerdo al diagrama presentado anteriormente, se pueden identificar los

siguientes procesos y subprocesos en la nueva aplicacin para novedades de
artculos:
1. Generar Cambios
a. Generar cambios a un artculo
2. Comprimir IDOCS
a. Generar IDOCS (WP_PLU) de artculos por centro
b. Almacenar IDOCS comprimidos en una ruta especfica
3. Descargar IDOCS
a. Conectarse va FTP a ruta de IDOCS
b. Descomprimir IDOCS de novedades
c. Almacenar IDOCS en ruta del CC
4. Aplicar novedades de artculos
a. Actualizar maestro de artculos
b. Registrar novedades en BD
c. Registrar eventos (errores) en BD

106
 3.3. Actores del Sistema

A continuacin, en la tabla 44 se detallan los roles de las personas y

sistemas que interactuarn con el Sistema. Los actores modelan cualquier entidad
externa que necesite intercambiar informacin con el sistema.

Tabla 44. Actores del Sistema.

Nombre del Actor Descripcin
Servicio encargado de activar de acuerdo a un
Servicio QUARTZ tiempo establecido (parametrizable) el proceso de
aplicacin de novedades de artculos desde el
controlador CC
Persona encargada de generar reportes de ventas y
operaciones para monitoreo en tienda, generar y
visualizar los libros de venta para su respectiva
Analistas POS verificacin, generar y visualizar los reportes de
venta y de inventarios para futuros ingresos y
egresos de mercanca, verificar reportes de
inventario para solicitudes y venta de artculos de
farmacia

107
 3.4. Funcionalidades del Sistema

En la Figura 23 se representa a travs del siguiente diagrama de Casos de

Uso, el conjunto de tareas que deben poder llevarse a cabo con el apoyo del
sistema que se propone en esta investigacin:

Figura 23. Diagrama de Casos de Uso.

A continuacin se presenta la tabla con el detalle de los casos de uso

mencionados en los diagramas anteriores:
Tabla 45. Casos de Uso del Sistema. CU001.
CU001. APLICAR NOVEDADES
Cdigo: CU001
Descripcin: Este caso de uso permite ejecutar todas las funciones involucradas
en el proceso de aplicacin de novedades de artculo

Tabla 46. Casos de Uso del Sistema. CU002.

CU002. DESCARGAR IDOCS
Cdigo: CU002
Descripcin: Este caso de uso permite obtener los IDOCS de novedades a
travs de la conexin del CC a una ruta del servidor de SAP donde
se encuentran alojados los IDOCS comprimidos. Una vez
descargados los mismos deben ser descomprimidos y
almacenados en una ruta del controlador CC

108
Tabla 47. Casos de Uso del Sistema. CU003.
CU003. ACTUALIZAR EAMITEMR.DAT
Cdigo: CU003
Descripcin: Este caso de uso permite la lectura secuencial de los IDOCS de
novedades y la actualizacin del maestro de artculos segn las
novedades encontradas en el documento.

Tabla 48. Casos de Uso del Sistema. CU004.

CU004. REGISTRAR NOVEDADES
Cdigo: CU004
Descripcin: Este caso de uso permite llevar un control a travs del registro en
una tabla de BD, las novedades detectadas y aplicadas.

Tabla 49. Casos de Uso del Sistema. CU005.

CU005. REGISTRAR ERRORES
Cdigo: CU005
Descripcin: Este caso de uso permite llevar un control a travs del registro en
una tabla de BD los eventos con errores detectados durante la
ejecucin del proceso de aplicacin de novedades de artculos.

109
 3.5. Diagramas de Actividad

Para representar de manera grfica cada caso de uso o funcionalidad del

sistema, en la Figura 24 se presentan los diagramas de actividad que pretende
mostrar el conjunto de acciones que el sistema debe ejecutar:

1. Aplicar novedades de artculos

Figura 24. Diagrama de Actividad. CU001.

Una vez que se genera la novedad desde el sistema SAP, existe un trabajo
automatizado nocturno que se encarga de generar los IDOCS WP_PLU con las
actualizaciones del da. Con el nuevo proceso, este documento manejar la
herencia de las barras, por lo que ya no ser necesario la generacin del IDOC
WP_EAN con los cdigos de barra secundarios ya que la estructura del WP_PLU
las contendr (En el apartado B de la seccin de Anexos se muestra el nuevo
formato del IDOC). Al ejecutarse el PI, a travs de una conexin FTP se
descargarn los documentos hacia una ruta especfica del controlador en donde
los mismos sern descomprimidos y utilizados para la actualizacin del maestro
de artculos. Estas actualizaciones posteriormente sern registradas en una BD
que permitir la publicacin de las referencias y posterior uso de las mismas en
otros procesos.

110
 2. Descargar Idocs

Figura 25. Diagrama de Actividad. CU002.

La descarga de los IDOCS de novedades de artculos consiste en la

conexin va sftp a SAP desde el controlador con el PI para posteriormente
descomprimir los mismos, respaldarlos en una ruta del controlador en formato de
texto y renombrarlos. Una vez que los mismos estn alojados en el controlador se
procede con la actualizacin del maestro de artculos.

111
 3. Actualizar EAMITEMR.dat

Figura 26. Diagrama de Actividad. CU003.

Una vez que se descargan los IDOCS con las novedades del da, el PI debe
leer secuencialmente los mismos, identificando cada producto a travs de su
cdigo SAP y su unidad de medida. Todas las barras asociadas al cdigo SAP
leido, deben ser bloqueadas antes de la modificacin; posteriormente se lee la
nueva referencia del artculo en el IDOC y todas las barras son actualizadas. Para
cada barra actualizada debe ejecutarse el proceso de escritura en una BD de
dichas modificaciones.

112
4. Registrar novedades

Figura 27. Diagrama de Actividad. CU004.

113
 Cada vez que se actualiza una barra en el maestro de artculos, es necesario
que este evento quede registrado en una tabla de una BD que permitir
posteriormente publicar las novedades para procesos externos como la impresin
de etiquetas y actualizacin del catlogo de artculos.
El proceso de registro de novedades en una BD ser de la siguiente forma: si
el cdigo SAP-Unidad ledo en el IDOC, no existe en el maestro de artculos, se
manejar con el indicador N para identificarlo como producto nuevo. Este mismo
caso aplica para artculos que tengan un cdigo SAP que s existe pero con
diferente unidad de medida a la del maestro de artculos.
Si tanto el cdigo SAP como la unidad de medida del artculo existen en el
maestro, debe compararse la referencia que tienen en relacin a la que presenta
el IDOC. Si se trata de un cambio de precio, debe manejarse el indicador P; si se
trata de un cambio de descripcin, deber manejarse el indicador O que significa
que el artculo ha sufrido Otro cambio.
Por otra parte al realizar la comparacin de la referencia del artculo tanto en el
maestro como en el IDOC, no se detectan novedades; el PI deber registrar en BD
la novedad con el indicador X para referenciar que no hubo cambios.

114
 5. Registrar errores

Figura 28. Diagrama de Actividad. CU005.

Si se detecta algn error durante la ejecucin del PI, el mismo deber

registrarse en una tabla de eventos en una BD. Esta informacin ser consultada
de manera manual y automtica a la hora de reprocesos. (En el apartado C de la
seccin de Anexos se muestra la tabla con los mensajes de error a almacenar)

115
 3.6. Matriz de Requisitos vs. Casos de Uso

Como mencion al principio de esta fase, para realizar el anlisis de una

solucin propuesta, primero se capturan las necesidades del cliente, luego se
hace un documento requisitos que ha sido validada por los involucrados y
finalmente se hace un modelo de casos de uso.
A continuacin se muestra el listado de requisitos de software asociados a su
respectivo caso de uso. Ver tabla 50.

Tabla 50. Requerimientos vs. Casos de Uso.

CDIGO CU CDIGO REQUERIMIENTO
RF001
RF002
CU001: Aplicar novedades RF021
RF022
RF023

RF003
RF004
CU002: Descargar IDOCS RF005
RF006
RF008
RF007
RF009
RF010
RF011
RF012
CU003: Actualizar EAMITEMR.dat
RF013
RF014
RF015
RF016
RF017
RF019
CU004: Registrar novedad
RF020
CU005: Registrar errores RF018

116
FASE IV: Disear el sistema automatizado para la aplicacin de novedades de
artculos desde el POS con las adaptaciones requeridas de acuerdo a los
requerimientos identificados

Para el desglose de esta fase se tomaron en cuenta los siguientes aspectos,

considerados desde la concepcin de la nueva solucin:

1. La organizacin e infraestructura como redes y hardware es

responsabilidad de cada establecimiento o franquicia tenerla funcional para
la correspondiente implementacin y parametrizacin.

2. Motivado a las relaciones establecidas con el proveedor de software en

oportunidades anteriores, no se tom en consideracin la evaluacin de
diferentes opciones de software con otros proveedores.

3. Todos los mdulos a implementar sern adquiridos por un proveedor canal

de IBM, por lo que se espera que la funcionalidad sea completamente
compatible con el sistema operativo y las funcionalidades previamente
instaladas en Locatel Franquicias por el mismo proveedor.

Como se muestra en la Figura 29, en esta fase se plantearn los siguientes

aspectos:

Figura 29. Aspectos Fase IV.

117
 4.1. Plataforma tecnolgica para el proceso y puesta en produccin

En relacin a la plataforma necesaria para la puesta en marcha a

produccin, en la Figura 29, se presenta la siguiente plataforma tecnolgica con
las siguientes especificaciones:

Figura 30. Diagrama de Despliegue.

En la siguiente tabla se describen las especificaciones tcnicas de cada equipo

mencionado

118
Tabla 51. Especificaciones tcnicas de Hardware.
NODO IMAGEN MODELO ESPECIFICACIONES TCNICAS

Contiene Hasta dos procesadores Intel Xeon

de la serie 5600 a 3,46 GHz de seis cores (3,60
GHz en la versin de cuatro cores) con
Servidor de
X3650 M3 tecnologa QuickPath Interconnect (QPI) y
Windows velocidad de acceso a memoria de hasta 1333
MHz

SurePOS 700 funciona como un controlador

para los sistemas de puntos de venta con
procesadores para sistemas operativos de 64-
bits, con velocidad de hasta 3GHz.
Segn el modelo elegido, esta potente solucin
Controladores (CC SurePOS 700
suministra al sector del comercio minorista
y DD) velocidad, disponibilidad y fiabilidad gracias a
su disco duro SATA, adems de ofrecer
soporte para tecnologa RAID (Redundant
Array of Independent Disks) y hasta 2GB de
memoria DDRII.

119
 SurePOS 700 tambin funciona como un
terminal puntos de venta, ya que estos

IBM SurePOS 700

modelos estn preconfigurados de manera que
puedan utilizarse con todas las cajas de IBM
puestos que tienen incorporada una funcin de
deteccin automtica.

El IBM 4694 es un terminal de puntos de venta

Terminales/ Cajas que cuenta con la capacidad de proceso

necesaria como para ejecutar las
aplicaciones en el mercado, incluyendo
fidelizacin de clientes, marketing electrnico y
ventas y servicio basados en la Web.
IBM 4694
Procesador 2 VIA C3 de 866 MHz2 Memoria
de vdeo de 4 MB (UMA)
Estndar de 64 (347) o 128 MB
Unidad de disco duro4 de 20 GB opcional
(estndar en P47 hasta 512 MB disponibles3)
10/100 Ethernet

120
 4.2. Arquitectura de la solucin

En la Figura 31 se presenta la arquitectura de la solucin planteada, en ella

se podr apreciar los componentes de software, hardware y comunicacin
requeridos para la puesta en marcha a produccin. Es importante resaltar que
para este proyecto no se tom en consideracin la evaluacin de otras opciones
de hardware, puesto que el aplicativo seleccionado trabaja perfectamente con
los componentes a mostrar:

Figura 31. Diagrama de Componentes.

Es importante resaltar que la aplicacin (PI) debe alinearse con las

funcionalidades del sistema implementado para las terminales y controladores,
denominado Supermarket Aplication

121
 4.2.1. Componentes involucrados

Portable Interface

De acuerdo al portal del proveedor http://www.lineadatascan.com, PI es un

framework para el desarrollo y despliegue de aplicaciones java altamente modular
y configurable.

Diseado para ser escalable y responder a las necesidades cambiantes y

exigentes de las empresas que necesitan transferir, trasformar y procesar
informacin importante del negocio de manera oportuna y confiable. Es portable a
varias plataformas permitiendo as un crecimiento balanceado de acuerdo a las
necesidades de la empresa.
Su finalidad es proveer una infraestructura a base de plugins para el desarrollo
e integracin de soluciones, enfocadas al manejo, transporte, y transformacin de
informacin hacia y desde los diferentes sistemas de informacin, que pueda tener
la empresa.

Arquitectura

La arquitectura del PI est conformada por:

o Core: Componente principal, encargado de gestionar el ciclo de vida de

cada componente del framework.
o Shells: Componentes que permiten comunicarse con el framework y
ejecutar comandos. Actualmente se tienen Shells para ejecucin va
consola, TCP.
o Comandos: Son los componentes encargados de realizar la lgica de
negocio.
Teniendo en cuenta estos tipos de componentes es posible implementar
diferentes tipos de arquitecturas, funcionalidades y modos de ejecucin, como por
ejemplo
Interaccin

122
 Actualmente el framework cuenta con 2 shell's estndar:
o SocketShell: Trabaja en base a peticiones por socket, se debe enviar la
instruccin a ejecutar a un socket definido por el cliente.
o ConsoleShells: Trabaja en base a peticiones en lnea de comandos; se
ejecuta la tarea a travs de una instruccin ingresada manualmente o a
travs de un men.

IDOCS de novedades

El IDoc WP_PLU transporta los Artculos estndares. Estos objetos son usados
en la interfaz de salida del POS para transferir los datos relacionados con los
artculos que estn en venta en las respectivas tiendas. Estos Artculos estn o
estaban listados en cada una de las tiendas respectivamente. Los datos
transferidos incluyen toda la informacin requerida en el punto de venta, como los
impuestos, descripcin, precio, EAN/UPCs, y la fecha en que suben al pos como
una fecha de validacin.

Los siguientes sub - objetos estn dentro de los IDocs de Novedades de

Artculos:
Data Maestra (Cdigo SKU, Ventas por unidad, categora)
Texto de Artculos (Descripcin)
Condiciones de los Artculos (por ejemplo, precios de venta y de promocin)
Descuentos
Cdigo de Impuestos.
Los artculos estn definidos en el POS usando EAN/UPC. Muchos
artculos tienen diferentes EAN/UPCs y precios por diferentes ventas unitarias. De
hecho, una venta sencilla unitaria puede tener EAN/UPCs diferentes. Si esto no es
garantizado solo el EAN/UPC principal podr ser escaneado en el POS, entonces
la barra secundaria puede ser transferida en otro registro del WP_PLU.

123
 Maestro de Artculos (EAMITEMR.dat)

El maestro de artculos es un archivo administrado por los controladores de kas

tiendas y contiene informacin acerca de todos los artculos que compra o fabrica,
almacena y vende la misma. Es la fuente central de la empresa para poner a
disposicin datos especficos de artculos. Esta informacin se almacena en
registros maestros de artculo individuales a travs de un cdigo identificador que
puede estar compuesto por su Cdigo SAP y su cdigo de barras.

Componente de Lectura del IDOC

La aplicacin de los IDOCS mencionados tiene como finalidad aplicar las

novedades, y el proceso consiste en la bsqueda de novedades registradas en el
archivo EAMITEMR.DAT, para ser actualizadas en una tabla de novedades
posteriormente.

Novedad de un artculo

Se refiere a cualquier modificacin realizada en un artculo y que es leda

desde un IDOC de novedades

Componente de escritura del artculo

Consiste en la actualizacin del maestro de artculo con la nueva referencia del

producto de acuerdo a la novedad indicada en el IDOC. Para ello este
componente deber apoyarse del cdigo SAP del artculo as como de sus barras
asociadas.

Directorio de Salida

Consiste en una ruta ubicada en el servidor de SAP en donde estarn alojados

los IDOCS en formato comprimido. El Portable Interfase se encargar de visitar

124
dicha ruta a travs de parmetros de conexin especficos y ubicar los IDOCS de
la fecha a ser aplicados

Directorio de entrada

Consiste en una ruta ubicada en los Controladores de las tiendas, que a travs
de parmetros especficos, servir para respaldar los IDOCS comprimidos a ser
aplicados por medio del Portable Interfase

Tabla de eventos

Se trata de un repositorio de datos que contendr los eventos con errores

detectados durante la ejecucin del proceso de aplicacin de novedades de
artculos. Estos eventos sern consultados posteriormente para procesos de
soporte y de reproceso de IDOCS en caso de ser necesario.

Tabla de novedades

Esta funcionalidad es vital para un proceso satlite de etiquetas, esto se basa

en el llenado de una tabla en Base de Datos que poseen las novedades aplicadas
por artculos.

El proceso se basa en la escritura de la tabla en donde se expresan los datos

necesarios para identificar si un determinado bajadas desde SAP hacia el POS.

125
FASE V: Elaborar las recomendaciones de implementacin respectivas para la
puesta en marcha del sistema de aplicacin de novedades.

Tomando en cuenta los requisitos y los entregables de las fases anteriores, en

esta fase se plantean un conjunto de recomendaciones que forman parte de las
responsabilidades de las reas involucradas e interesadas en la salida a
produccin del producto.

Como se muestra en la Figura 32, en esta fase se plantearn los siguientes

aspectos:

Figura 32. Aspectos Fase IV.

126
 5.1. Listado de Requisitos para los Departamentos involucrados

A continuacin se presentan los requisitos mnimos a ser cumplidos por cada

Departamento antes de la instalacin de la solucin propuesta en las tiendas de
Locatel Franquicias.

Requerimientos asociados al Departamento de Desarrollos propios y BD

1. Crear tabla de novedades con las siguientes especificaciones:

- FECHA: Fecha de aplicacin de Novedad (ubicada en la cabecera

del IDOC)
- CODIGO SAP: Cdigo SAP del Artculo Actualizado.
- UNIDAD DE MEDIDA: Unidad de medida del artculo (Unidad, Caja,
Bulto)
- NOVEDAD: Indica el Tipo de Novedad siguiendo la mtrica:
- O = Otro Cambio
- N = Artculo Nuevo.
- P = Cambio de Precio
- ESTADO: Indica si a etiqueta del artculo se imprimi o no
- DESCRIPCION LARGA: Se escribe en este campo la descripcin
larga del artculo que viaja desde SAP al POS.
2. Crear tabla de eventos del sistema con las siguientes especificaciones:

- F_IDOC: Fecha de aplicacin de Novedad (ubicada en la cabecera

del IDOC)
- F_IDOC: Fecha de aplicacin de Novedad (ubicada en la cabecera
del IDOC)
- EVENTO: Error detectado por la aplicacin.
3. Realizar las configuraciones necesarias para que el Idoc no est
concatenado con los ltimos 7 das. Slo se manejar un da.

127
4. La estructura del IDOC WP_PLU cambiar para incluir extensiones con las
barras adicionales.

Requerimientos asociados al Departamento POS

1. Se recomienda elaborar las especificaciones de los casos de prueba

listados mas adelante
2. En el POS se manejarn modificaciones de inclusin, bloqueo, modificacin
de artculos.

3. El tiempo de instalacin por tienda no debe ser mayor a 4 horas.

4. Durante la instalacin se solicita el acompaamiento del analista funcional

de VLI.

5. Se deben realizar los respectivos manuales y entrenamiento a los usuarios

para facilitar la ejecucin manual del proceso.

6. Se depurar el maestro de artculos antes de instalar en produccin. Para

ello se requiere la descarga de un maestro directo desde el Sistema SAP.

7. Al menos un ambiente de Laboratorio debe estar preparado durante toda la

para replicar los problemas en caso de requerirse.

8. Requerimientos asociados al Departamento de Categora y Precios

9. Las eliminaciones no estarn registradas en los IDOCS de novedades.

10. La modificacin de artculos debe contener: precio, descripcin, descuento,

IVA.

128
 5.2. Planificacin de la Certificacin de la Solucin Propuesta

Para la certificacin del proceso se requiere la ejecucin de un set de

pruebas que garantice que cada versin que sale a nuestras tiendas posea
todas sus herramientas en perfecto estado, as como tambin la contingencia
adecuada en caso de que alguno de los controladores falle.

Una vez concluido el desarrollo de la interfaz (PI) y completada la

elaboracin del prototipo funcional del mismo, se debe ejecutar el siguiente plan
de. Para la planificacin de las mismas, se proponen las siguientes fases:

Identificacin de los Escenarios

De acuerdo a los Casos de so Identificados, a continuacin se presentan los

posibles escenarios alternos que podran ocurrir durante la ejecucin del PI y que
deben considerarse dentro de las pruebas de certificacin del componente.

Tabla 52. Escenarios de Prueba

CASO DE
ID ESCENARIO
USO
E01 Error en Descarga de IDOCS
CU002 E02 Error en Registro de eventos
E03 Error en Registro de novedades
CU003 E04 Falla Conexin con SAP va SFTP
CU004 E05 Error en escritura del EAMITEMR.dat
E06 Conexin Fallida con la BD de Novedades
CU005
E07 Conexin Fallida con la BD de Errores

129
 Identificacin de los Casos de Prueba

Tomando en cuenta los escenarios de prueba mencionados en la seccin

anterior, en la Tabla 53 se listan los casos de prueba identificados.

Tabla 53. Casos de Prueba

ID
ID DESCRIPCIN RESULTADOS ESPERADOS
ESCENARIO
Parmetros de conexin a Mensaje de error:
E04 CP1
SFTP de SAP incorrectos Conexin con SAP fallida
Servidor de SAP Mensaje de error:
E01 CP2
inaccesible Conexin con SAP fallida
Parmetros de conexin a Mensaje de error:
E05 CP3 FTP del controlador Conexin FTP con controlador
incorrectos fallida
Mensaje de error:
No existen IDOCS por
E05 CP4 No existen novedades por
descargar
aplicar
Mensaje de error:
E05 CP5 EAMITEMR.dat daado
Proceso Fallido
Parmetros de conexin a
Mensaje de error:
E02, E07 CP6 BD de eventos
Conexin con BD fallida
incorrectos
Parmetros de conexin a
Mensaje de error:
E03, E06 CP7 BD de novedades
Conexin con BD fallida
incorrectos

En caso que sea necesario realizar una actividad diferente a las estipuladas en
esta propuesta para devolver la funcionalidad al software, se deber utilizar el
Procedimiento de Control de Cambios.

130
 5.3. Preparativos para instalacin de Piloto

Para la distribucin del sistema se requiere de la instalacin de un piloto previo

en una tienda modelo, con duracin de 1 mes de manera que se garantice la
estabilidad de la aplicacin.

Para la instalacin del piloto se requiere contar previamente con las siguientes
premisas:

1. Permitir el acceso al proveedor al sitio donde se ejecutar el servicio, en los

horarios previamente acordados.
2. Permitir los accesos remotos a analista funcional de VLI: VPN o conexin
remota similar a los sistemas donde se ejecutar el servicio y servidores de
prueba necesarios.
3. Deben configurarse previamente usuarios y permisos a los ambientes de
pruebas requeridos para la certificacin del aplicativo. Usuarios y permisos
restringidos a los ambientes de pruebas para el soporte durante la garanta
del producto.

En el apartado D de la seccin de Anexos se muestra el formato de acta de

piloto que deber ser firmada y sellada por Locatel para dar inicio a la instalacin
del piloto. Es importante acotar que se dar por aceptada la solucin desarrollada
por el proveedor, una vez que se compruebe durante el piloto el normal estado de
funcionamiento, ejecutando las actividades descritas en cada uno de los servicios
ofrecidos.

131
 5.4. Preparativos para instalacin masiva

Para la instalacin del Portable Interface (PI), se espera que el impacto sea
el menor posible en las tiendas y que no altere la facturacin diaria, inclusive las
instalaciones y actualizaciones debern hacerse en horarios diferentes al perodo
contable para evitar as afectar la operatividad. Para las nuevas inclusiones se
entrenar a los usuarios y de esta forma mitigar problemas operativos en tienda.

La intensin del proyecto es evitar el trabajo de verificacin que hoy en da se

realiza de manera manual y puede ocasionar reportes de diferencias en tiendas no
reales.

El proceso de instalacin masiva deber realizarse bajo un plan de

instalacin por fechas en donde cada tienda se atienda por separado y se
compruebe que tanto a nivel de controladores como cajas, no se ve afectada la
facturacin ni las actividades diarias de la tienda.

132
 CAPITULO V
Conclusiones y Recomendaciones

A continuacin se presentan las conclusiones y recomendaciones basadas

en los aspectos expuestos del captulo de desarrollo.

Conclusiones

Con la elaboracin de este proyecto, se logr estudiar a fondo los procesos

de negocio as como los automatizados, involucrados en la aplicacin de
novedades de artculos; esto result de gran importancia para la identificacin de
sus fortalezas y debilidades.

En esta primera fase fue posible obtener un acercamiento con todos los
involucrados y se logr documentar los diferentes puntos de vista de donde se
identificaron necesidades que posteriormente se convirtieron en requisitos de
software.

Cada requerimiento fue incluido en el nuevo proceso de aplicacin de

novedades lo que permiti la identificacin de las funcionalidades del Portable
Interfase que ser la aplicacin encargada de la actualizacin del maestro de
artculos utilizado para la facturacin en los Puntos de venta. Posteriormente se
mostr de qu trata cada funcionalidad y las actividades involucradas en la fase de
anlisis.

Para la instalacin de los componentes que conforman al Portable Interfase

se diseo la arquitectura necesaria con la que Locatel ya cuenta y est
perfectamente preparado. Se especificaron los componentes tanto de software
como de hardware necesarios y se mostraron sus caractersticas tcnicas.

Una vez realizado el anlisis y diseo del Portable Interfase (PI) se

detectaron un conjunto de requisitos ajenos al dominio del departamento de POS y

133
cuyo cumplimiento resulta necesario para la puesta en marcha de esta solucin.
Por esta razn se list un conjunto de recomendaciones previas a la
implementacin y a estas se les asignaron sus respectivos responsables.
Asimismo se cre un plan para la certificacin que acompaado con la ejecucin
de las pruebas de software servir de preparativo para la puesta en produccin.

Es importante mencionar que este proyecto result factible puesto que se

cuenta con la disponibilidad de los recursos, la documentacin de algunos
procesos y la aprobacin de la gerencia de informtica para incluir ste dentro de
la cartera de proyectos.

Recomendaciones

Acompaar este proyecto con una buena coordinacin, para ello se

recomienda planificar en detalle los 5 grandes grupos de procesos ofrecidos por el
PMI (2008), que son:
Iniciacin
Planificacin
Ejecucin
Seguimiento y Control
Cierre

Darle continuidad al proyecto partiendo de que se tiene un adelanto

importante en la fase de anlisis y diseo con esta investigacin que servira de
aporte e insumo al proveedor para iniciar los respectivos desarrollos. Estas fases
forman parte del proceso de iniciacin del proyecto.

Asignar los recursos humanos y estimar el tiempo requerido de cada sub-

proceso para dimensionar el proyecto completo y tener proyecciones en cuanto al
tiempo que tomar el desarrollo, los riesgos involucrados, los costos y cundo
podr ser implementado el mismo.

134
 Sensibilizar a los involucrados en este proyecto (no slo de Locatel sino del
proveedor seleccionado) acerca de la metodologa RUP que ha sido escogida
porque ofrece un conjunto de normas acerca del desarrollo que no slo son
usadas como mejores prcticas para construir el software, sino que adems
permiten identificar problemas en los procesos de negocio existentes en la
organizacin. Finalmente, la metodologa exige la elaboracin de una serie de
instrumentos como entregables que sern de gran utilidad al momento de formar
al personal que manejar y brindar soporte a la aplicacin, as como la
transferencia de conocimientos a lo largo del ciclo de vida del sistema.

Ofrecer a todos los interesados de este proyecto, una presentacin formal

de los avances que se tienen con esta investigacin y las ventajas de la misma
para poder asignarle la prioridad respectiva al proyecto. Es importante que los
interesados conozcan los avances obtenidos puestos que estos participan
activamente y pueden solicitar modificaciones tanto al plan del proyecto como a
los entregables.

Aplicar el plan de pruebas, as como elaborar y ejecutar los casos de

pruebas que servirn para que cada rea involucrada certifique que la aplicacin
sirvi de aporte a sus procesos de negocio dentro de la aplicacin de novedades
de artculos

Segn el PMI (2008), el xito se mide por la calidad del producto y del
proyecto, la puntualidad, el cumplimiento con el presupuesto y el grado de
satisfaccin del cliente.

135
 REFERENCIAS BIBLIOGRFICAS

Alarcn, V. (2006). Desarrollo de Sistemas de Informacin. Barcelona,

Espaa. Edicions UPC.

Alvarez, M. (2013). Cuadro de Mando Retail. Barcelona, Espaa: Profit

Editorial.

Amaya, J. (2006). Gerencia, Planeacin y Estrategia: Fundamentos, Modelo

y Software de Planeacin. Colombia. Editorial Cucaramanga.

Asensio, P., Arbos R. (2005). Automatizacin de procesos mediante la gua

GEMMA. (1era Edicin). Barcelona, Espaa: Edicions UPC.

Barranco J. (2001). Metodologa del anlisis estructurado de Sistemas.

Madrid, Espaa: Alcobendas.

Cavero J., Vela B., Marcos E., (2005). Aspectos Filosficos, Psicolgicos y
Metodolgicos de la Informtica.

Colegio de Ingenieros de Venezuela (1996). Cdigo de tica Profesional.

Chang R. (2007), Las herramientas para la mejora continua de la calidad.

Argentina: Ediciones Granica.

Diez, E. y Daz, M. (2008). Gestin de Precios. (5ta Edicin). Madrid,

Espaa: Esic Editorial.

Fabregas, L (2011). Gerencia de Proyectos de Tecnologa de Informacin.

(1era Edicin). Venezuela: Libros de El Nacional.

136
 Falgueras B. (2003). Ingeniera de Software. (1era Edicin). Barcelona,
Espaa: Editorial UOC.

Fernndez, J. (2010). Gestin por Procesos. (4ta Edicin). Madrid, Espaa:

Esic Editorial.

French, S., Maule, J., Papamichail, N. (2009) Decision Behaviour, Analysis

and Support. (1era Edicin). New York, EEUU: Cambridge.

Fowler, M. (2001). UML gota a gota. 1era Edicin. Mexico. Adisson Wesley
Longman

Fuquene Carlos, Aguirre Santiago y Crdoba Bibiona (2006). Evolucin de

un sistema de manufactura flexible (fms) a un sistema de manufactura
integrada por computador (cim) [Versin Electrnica], EBSCO. Recuperado
el 30 de junio del 2013,de:
http://web.ebscohost.com/ehost/pdfviewer/pdfviewer?sid=7a500af8-84ff-
4108-b786-e2233a760c4b%40sessionmgr198&vid=5&hid=113

Gonzlez, P. (2000). Implementacin de SAP R/3 en Pea Colarada. Tesis

de Mestra no publicada. Universidad de Colima. Mxico.

Gurin, B. (2012). Gestin de proyectos informticos. Desarrollo, Anlisis y

Control. Espaa: Ediciones ENI.

Hernndez, P. (2008). Gestin del Punto de ventas. Madrid, Espaa:

Editorial Vrtice

Hernndez, L. (2012). Desarrollo estratgico de Proveedores nacionales

para una gran empresa de Retail. Tesis de Maestra en Gestin y Direccin
de Empresas. Chile.

137
 Kendall K Y Kendall, J. (2005). Anlisis y Diseo de Sistemas. (6ta Edicin).
Mxico: Pearson Educacin.

Ley para la defensa de las Personas en el Acceso a los Bienes y Servicios

(2010, Marzo). Gaceta Oficial de la Repblica Bolivariana de Venezuela
Nmero 39.358, Febrero 1, 2010.

LineaDataScan (s.f.). Recuperado el 27 de octubre del 2013, de

http://www.lineadatascan.com/productos/lineadatascan/frameworks/PI.aspx

Locatel (s.f.). Recuperado el 20 de noviembre del 2013, de

http://www.localtel.com.ve

McLeod, R. (2000). Sistemas de Informacin Genercial. (7ma Edicin).

Mxico: Pearson Educacin.

Mendes, W. (2011). Metodologa para la implementacin de la Integracin

de los Sistemas de Negocios POS&Touch-SAP Business One en las
Pymes. Maestra en Ingeniera Industrial. Universidad Nacional
Experimental Politcnica Antonio Jos de Sucre.

Namakforoosh, M. (2005). Metodologa de la Investigacin. (2da Edicin).

Mexico: Editorial Limusa.

Oliv R. Y Gmez S. (2003). Diseo de Sistemas de Software en UML.

(1era Edicin). Barcelona, Espaa. Edicions UPC.

Real Academia Espaola (2001). Diccionario de la lengua espaola (22nd.

Ed). Madrid, Espaa.

Robbins, S. y Decenzo D. (2002). Fundamentos de la Administracin. (3era

Edicin). Mxico: Pearson Educacin.

138
 Schach, S. (2006). Ingeniera de software clsica y orientada a objetos. 6ta
Edicin. Mexico. Mc. Graw Hill.

Silva, L. (1997). Cultura estadstica e Investigacin cientfica en el campo de

la salud: una mirada crtica. Madrid, Espaa. Ediciones: Daz Santos S.A.

Sommerville, I. (2006). Ingeniera del Software. (7ma. Edicin). Madrid,

Espaa: Pearson Educacin.

Tamayo M. (2004). El Proceso de la Investigacin Cientfica. (4ta Edicin).

Mxico: Editorial Limusa, S.A./Noriega.

Tomal, E., (2006). Desarrollo e integracin de los sistemas de informacin

contable a travs de la implantacin del SAP R/3 en una empresa
comercializadora de Gas licuado de petrleos (GLP) en el Ecuador
Duragas. Tesis de Maestra en Administracin de Empresas. Ecuador.

Toussaint, H. (2005). Anlisis, Diseo y Plan para Implementacin de un

mecanismo que permita el establecimiento de la transmisin de datos en
lnea entre sistemas SAP/R3 y otros sistemas utilizando las herramientas de
comunicacin estndar disponibles en SAP/R3. Especializacin en
Comunicaciones y Redes de Comunicacin de datos. Universidad Central
de Venezuela.

Weilkiens, T., Oestereich B. (2007). UML 2: Certification Guide. EEUU:

Elsevier Inc.

Wetherbe, J. y Vitalari, N. (1994), Systems Analysis and Design: Traditional

Best Practices. (4ta Edicin). Minnesota

139
ANEXOS
 ANEXO A
FORMATO DE ENTREVISTAS APLICADAS

1
ANEXO A-1

ENTREVISTA APLICADA AL DEPARTAMENTO DE CATEGORA Y PRECIOS

PARTICIPANTES

NOMBRE CARGO
Xiomara Bustamante Lder de Categora
Carolina Hung Especialista
Categora
Rosana Gmez Jefe POS
Walewska Brandy Lder POS
Waldmir Mendes Analista POS

OBJETIVO

El objetivo principal de esta entrevista es conocer los procedimientos

ejecutados de manera automtica y manual por parte del Departamento de
Categora y Precios durante la aplicacin de novedades de artculos que son
vendidos desde los puntos de venta de Locatel Franquicia C.A.

Con este documento se pretende realizar una exploracin inicial de las

funciones del Departamento durante el proceso de actualizacin de artculos y
detectar posibilidades de mejora.

2
 PREGUNTAS

2. Cules son las funciones del Departamento en relacin al proceso de novedades de

artculos?
3. Cmo est organizado el departamento de Categora y Precios?
4. Cules son los procesos involucrados en relacin al proceso actual de aplicacin de
novedades de artculos?
5. Cules son los tipos de artculos que se manejan en el proceso de aplicacin de
novedades?
6. Con qu frecuencia se aplican novedades en el POS?
7. Cmo se determina que debe haber una novedad?
8. Cules son las unidades de medida que manejan los artculos vendidos en el POS?
9. Cul es el procedimiento para crear un artculo nuevo?
a. Cul es el nombre de la transaccin en SAP?
b. Cunto tiempo dura este procedimiento por artculo?
10. Cul es el procedimiento para modificar un artculo?
a. Cul es el nombre de la transaccin en SAP?
b. Cunto tiempo dura este procedimiento por artculo?
11. Cul es el procedimiento para eliminar un artculo en SAP?
12. Cul es el procedimiento para bloquear un artculo en SAP?
13. Cmo se maneja la vigencia de un artculo?
14. Qu caractersticas del artculo pueden cambiar por un perodo de tiempo especfico
(vigencia)?
15. Cules son los tipos de barras manejados?
16. Cmo se maneja la herencia de estas barras?
17. Cmo se maneja el proceso de reasignacin de cdigos de barras?
18. Por qu realizan este procedimiento?
19. Cul es su percepcin del actual proceso de aplicacin de novedades? Qu mejoras
incluira en este proceso?

3
ANEXO A-2

ENTREVISTA APLICADA AL DEPARTAMENTO DE DESARROLLO Y BD

PARTICIPANTES

NOMBRE CARGO
Jos Manuel Vasquez Jefe De Desarrollos y
BD
Marco Hung Coordinador de BD
Rosana Gmez Jefe POS
Walewska Brandy Lder POS
Waldmir Mendes Analista POS

OBJETIVO

El objetivo principal de esta entrevista es conocer los procedimientos

ejecutados de manera automtica y manual por parte del Departamento de
Desarrollos y BD durante la aplicacin de novedades de artculos que son
vendidos desde los puntos de venta de Locatel Franquicia C.A.

Con este documento se pretende realizar una exploracin inicial de las

funciones del Departamento durante el proceso de actualizacin de artculos y
detectar posibilidades de mejora.

4
 PREGUNTAS

1. Cmo se ejecuta el proceso de aplicacin de novedades desde SAP?

2. Qu es una organizacin de ventas?
3. Este proceso de SAP se puede ejecutar manualmente?
4. Cmo se procesan estos IDOCS en POS?
4.1. Cmo se identifican estos IDOCS?
4.2. En qu consiste esta peticin?
5. Quin es el responsable del monitoreo diario?
6. Cules son los errores detectados?
7. Qu mejoras realizara al proceso de aplicacin de novedades?
8. Qu datos del Histnove.dat se utilizan para la impresin de etiquetas?
Qu informacin adicional necesitan registrar en el histnove.dat?

5
 ANEXO B
NUEVA ESTRUCTURA DEL IDOC DE NOVEDADES

6
 En la siguiente figura se presenta la cabecera del IDOC WP_PLU con la
especificacin de cada campo:

El IDoc WP_PLU transporta los Artculos estndares. Estos objetos son

usados en la interfaz de salida del POS para transferir los datos relacionados con
los artculos que estn en venta en las respectivas tiendas. Estos Artculos estn o
estaban listados en cada una de las tiendas respectivamente. Los datos
transferidos incluyen toda la informacin requerida en el punto de venta, como los
impuestos, descripcin, precio, EAN/UPCs, y la fecha en que suben al pos como
una fecha de validacin.
Los siguientes sub - objetos estn dentro de los IDocs de Novedades de Artculos:

Data Maestra (Cdigo SKU, Ventas por unidad, categora)

Texto de Artculos (Descripcin)
Condiciones de los Artculos (por ejemplo, precios de venta y de promocin)
Descuentos
Cdigo de Impuestos.

7
 Estructura del IDOC WP_PLU

- E1WPA01: Interfaz entre SAP y el POS, Entrada + Salida de artculos

Segmento de ID Maestro
Estatus: Requerido, Nmero Mnimo: 1, Nmero Mximo: 9999999
o E1WPA02: Interfaz entre SAP y el POS, Carga + Descarga de data
maestra de artculos
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 1
o E1WPA03: Interfaz entre SAP y el POS, Entrada + Salida de
artculos maestros, Textos
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99
o E1WPA04: Interfaz entre SAP y el POS, Salida de artculos
maestros, condiciones de artculos
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99

- E1WPA05: Interfaz entre SAP y el POS, salida de artculos maestros,

valores de condicin
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99

- E1WPA11: Interfaz entre SAP y el POS, Salida de artculos maestros,

condiciones de artculos
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99
o E1WPA09: Interfaz entre SAP y el POS, Salida de artculos
maestros, condiciones de artculos
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99

- E1WPA10: Interfaz entre SAP y el POS, Salida de artculos maestros,

buenas ventas gratis.
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99
o E1WPA07: Interfaz entre SAP y el POS, Entrada + Salida, Artculo
Maestro, Impuestos.
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99
o E1WPA08: Interfaz entre SAP y el POS, Entrada + Salida, Artculo
Maestro, adicin de artculos. NO
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 99
o E1WXX01: Segmento para adecuaciones del cliente, usado de ser
Requerido
Estatus: Opcional, Nmero Mnimo: 1, Nmero Mximo: 999

A esta estructura se aadirn los siguientes segmentos dependiendo de la

cantidad de subbarras que contenga una barra principal. Es importante resaltar
que estas adiciones siguen siendo parte de la estructura estndar del IDOC que
ofrece SAP.

8
- E1WXX01: Segmentos para adecuaciones del cliente para ser usado de ser
requerido.
Definicin del Segmento E2WXX01 Vlido desde la versin 30A, Tamao
del Segmento: 0055
o FLDGRP: Campo Grupo
Tipo de Dato Interno: CHAR Tamao Interno: 000005 Caracteres
Posicin en el Segmento: 001, Offset: 0063. Largo Externo:
000005
o FLDNAME: Campo Nombre
Tipo de Dato Interno: CHAR Tamao Interno: 000010 Caracteres
Posicin en el Segmento: 002, Offset: 0068. Largo Externo:
000010
o FLDVAL: Campo Valor
Tipo de Dato Interno: CHAR Tamao Interno: 000040 Caracteres
Posicin en el Segmento: 003, Offset: 0078. Largo Externo:
000040

9
 ANEXO C
MENSAJES A ALMACENAR EN LA TABLA DE EVENTOS

10
Tabla 54. Mensajes de Error a almacenar en la Tabla de eventos
Proceso Caso Mensaje Sugerido
Error al intentar conectarse al servidor sftp:
IP Errada
Error al intentar conectarse al servidor sftp:
Error de Conexin
Usuario errado
Error al intentar conectarse al servidor sftp:
Conexin al Contrasea errada
servidor sftp Se conect correctamente al host:
Conexin exitosa
xxx.xx.x.x
Transferencia Transferencia de archivo xxxxxxxx.zip
exitosa exitosa
Transferencia Error realizando la transferencia del archivo
Fallida xxxxxx.zip.
Bsqueda del
No consigue el .zip El archivo idocsxxxx.zip no existe
Comprimido
Descompresin Se descomprimi exitosamente el archivo
Descomprimir exitosa xxxxxxxxx.zip
archivo Descompresin Error al descomprimir el archivo xxxxxxx.zip
fallida
Registros grabados exitosamente: 69.
Registros no grabados: 1. Los registros que
presentaren problemas fueron: xxxxxxxx
Reporte una vez
Aplicacin de Discriminar correos la siguiente forma:
finalizado el
novedades - Si hubo algn error mostrar mensaje
proceso
con el asunto Proceso Fallido.
- Si no hubo errores mostrar mensaje
con el asunto Proceso Exitoso.

11
 ANEXO D
ACTA DE PILOTO

12
 OBJETIVO

En esta seccin se evaluar los resultados de un piloto organizado en

una de nuestras tiendas, en donde se probar la versin analizada
directamente en produccin.

El piloto tendr una duracin mnima de una semana, y estar en continuo

monitoreo por parte de nuestro personal y el personal de sistemas de la
tienda que se seleccione.

RESULTADO DEL PILOTO

DATOS DEL PILOTO

TIENDA SELECCIONADA POR EL PILOTO: _ _

FECHA INICIO DEL PILOTO: _ FECHA FIN DEL PILOTO: _

RESPONSABLE DE MONITOREO CASA MATRIZ: _

RESPONSABLE DE MONITOREO TIENDA:

COMPORTAMIENTO DE LA ACTUALIZACIN.

OBSERVACIONES:

_ _ _

_ _ _

_ _ _

NMERO DE CASOS DE SOPORTE REPORTADOS: _

NMERO DE LOS TICKETS DE LOS CASOS DE SOPORTE ABIERTOS:

__

__

13
 ANEXO E
NARRATIVAS DE CASOS DE USO

14
ANEXO E-1
Tabla 55. Narrativa CU002

Caso de Uso CU002. Descargar IDOCS

Actores N/A (Se activa como un extend del CU: Aplicar novedades)
Este caso de uso permite obtener los IDOCS de novedades a travs de la conexin
del CC a una ruta del servidor de SAP donde se encuentran alojados los IDOCS
comprimidos. Una vez descargados los mismos deben ser descomprimidos y
Propsito almacenados en una ruta del controlador CC

Curso Normal de Eventos

Accin de Actores Respuesta del sistema
1. Conecta a SAP a travs de unos parmetros de
conexin especficos.
2. Copia IDOCS de novedades
3. Descomprime IDOCS
4. Renombrar IDOCS
5. Almacenar IDOCS de noevdades

Cursos
Alternativos
1. Se ejecuta hasta el paso 1 del Curso normal de
eventos
2. Se detecta conexin fallida
Linea 1: 3. Se ejecuta el CU: Registrar errores

15
Tabla 56. Narrativa CU003

Caso de Uso CU003. Actualizar EAMITEMR.dat

Actores N/A (Se activa como un extend del CU: Aplicar novedades)
Este caso de uso permite la lectura secuencial de los IDOCS de novedades y la
actualizacin del maestro de artculos segn las novedades encontradas en el
Propsito documento.

Curso Normal de Eventos

Accin de Actores Respuesta del sistema
1. Se activa el CU Descargar IDOCS
2. Lee secuencialmente el IDOC
3. Identifica producto a actualizar en el IDOC
4. Identificar barras asociadas a ese producto
5. Bloquea las barras identificadas en el maestro
6. Lee referencia del artculo
7. Registra nueva referencia del artculo en el maestro
8. Retorna al paso 3

Cursos
Alternativos
1. Se ejecuta hasta el paso 7 del Curso normal de
eventos
2. No existen ms artculos
Linea 1: 3. Fin del proceso

16
Tabla 57. Narrativa CU004

Caso de Uso CU004. Registrar Novedades

Actores N/A (Se activa como un extend del CU: Aplicar novedades)
Este caso de uso permite llevar un control a travs del registro en una tabla de
Propsito BD, las novedades detectadas y aplicadas.

Curso Normal de Eventos

Accin de Actores Respuesta del sistema
1. Se activa el CU Actualizar EAMITEMR.dat.
2. Se conecta a la BD.
3. Se lee secuencialmente el IDOC.
4. Se detecta que el artculo no existe en SAP.
5. Se registra artculo nuevo.

Cursos
Alternativos
1. Se ejecuta hasta el paso 3 del flujo de eventos
bsico
2. Se detecta que el existe el cdigo SAP pero con
otra unidad de medida
Linea 1: 3. Se registra artculo nuevo
1. Se ejecuta hasta el paso 3 del flujo de eventos
bsico
2. Se detecta que el existe el producto con igual
unidad de medida
3. Se compara la barra del IDOC con el maestro
4. Se detecta que no hubo novedad
Linea 2: 5. Se registra el artculo con otro indicador
1. Se ejecuta hasta el paso 3 del flujo de eventos
alterno 2.
2. Se detecta que hubo novedad
3. Se detecta que la novedad fue cambio de precio
4. Se registra el artculo con indicador de cambio de
precio
Linea 3:
1. Se ejecuta hasta el paso 2 del flujo de eventos
alterno 3.
2. Se detecta que hubo novedad
3. Se detecta que la novedad fue otro cambio
4. Se registra el artculo con indicador de otro cambio
Linea 4:

17
Tabla 58. Narrativa CU005
Caso de
Uso CU005. Registrar Errores
Actores N/A (Se activa como un extend del CU: Aplicar novedades)
Este caso de uso permite llevar un control a travs del registro en una tabla de BD los
eventos con errores detectados durante la ejecucin del proceso de aplicacin de
Propsito novedades de artculos.

Curso Normal de Eventos

Accin de Actores Respuesta del sistema
1. Se activa el CU Actualizar Descargar IDOCS.
2. Se conecta a la BD.
3. Registra el evento en la BD

18
 ANEXO F
CARTAS DE APROBACIN PARA LA ELABORACIN DE LA TESIS

19
Universidad Catlica Andrs Bello
Direccin General de Estudios de Postgrado
Postgrado en Sistemas de Informacin
Presente.-

CARTA DE APROBACIN

Por la presente me permito comunicar que he sido la asesora del Trabajo Especial
de Grado de la estudiante Walewska Josefina Brandy Navarro cdula de identidad
nro. 17.758.666, quien opta por el ttulo de Especialista en Sistemas de
Informacin, intitulado DISEO DE UN SISTEMA DE INFORMACIN PARA LA
ACTUALIZACIN DE ARTCULOS REGISTRADOS EN LOS PUNTOS DE
VENTA DE EMPRESAS DE RETAIL. Caso de estudio: Locatel Franquicias C.A.

Asimismo, hago constar que como tutor estoy conforme con el contenido
presentado, por lo que cuenta con mi aprobacin para ser inscrito como Trabajo
Especial de Grado.

Sin otro particular al cual hacer referencia, se despide cordialmente,

En la ciudad de Caracas a los veinte das del mes de Noviembre 2013

-------------------------------------
Mg. Mara Esther Remedios
CI:5.530.488

20
 APROBACIN DE LA EMPRESA

Caracas, Noviembre del ao 2013

Sres.
UNIVERSIDAD CATLICA ANDRS BELLO
Postgrado en Sistemas de Informacin
Caracas

Nos dirigimos a ustedes para informarles que hemos autorizado a la Ing.

Walewska Josefina Brandy Navarro, C.I.: 17.758.666, quin labora en esta
organizacin, a hacer uso de la informacin proveniente de esta institucin, para
documentar y soportar los elementos de los distintos anlisis estrictamente
acadmicos que conllevarn a la realizacin del Trabajo Especial de Grado
titulado Diseo de un sistema de informacin para la actualizacin de artculos
registrados en los puntos de venta de empresas de retail. Caso de estudio: Locatel
Franquicias C.A como requisito para optar al ttulo de Especialista en Sistemas
de Informacin, exigidos por la Direccin General de los Estudios de Postgrado de
la Universidad Catlica Andrs Bello.

Sin ms a que hacer referencia, atentamente,

___________________________________
Carlos Lpez Ch.
Gerente Dpto. Sistemas

21