GuiaEnunciadosAlumnos Vrecortada

Gua de Ejercicios Prcticos
Enunciados
(Versin II)
Departamento de Sistemas
Materia: Tecnologa de la Informacin
Cdigo: 275
Ctedra: Guillermo Tricoci
Universidad de Buenos Aires

Facultad de Ciencias Econmicas
Ao 2015
Gua de Ejercicios Prcticos - Enunciados

Catedra: Guillermo Tricoci
Autores
Jorge Clemente - Pablo Corral - Enrique Dondero - Alex Flores David Gambetta - Pablo Gil - Germn Grin - Lucila Guttman Andrs Kouvach - Luis Martnez - Noelia Massone - Brbara
Michalla - Guido Olomudzski - Cecilia Oriolo - Daniel Piorun - Ariana
Rosenthal - Pablo Rota - Daniel Sanguinetti - Juan Martin Strupeni Enrique Szybisz - Adrian Telias - Nair Lgica Tornatore - Guillermo
Tricoci
Agradecimientos
Delfina Crespo - Ezequiel Maravankin - Elina Schneider
- Rosario Yrbas
Revisin de Ejercicios
Pablo Corral Alejandro Golubovic Marcelo Gonzalez Bosque Luis Martinez - Ariana Rosenthal - Guillermo Tricoci
Edicin y Compilacin
Noelia Massone - Guido Olomudzski - Ana Paula Vidal
Pgina 2 de 45

Contenido
Introduccin ........................................................................................................ 4
1.
DAXTOR SA: .............................................................................................. 5
Actividad 3 Anlisis y Diseo Funcional ...................................................... 9

Se pide Anlisis de Procesos: ................................................................ 11
Actividad 9 Modelado de Datos ................................................................. 13
Se Pide Anlisis de Datos: ..................................................................... 15
3. AliMun - Alimentos al Mundo S.A. ............................................................. 16
Actividad 1 Gestin de Proyectos .............................................................. 20
Se pide Analizar proceso de Compras: ................................................... 22
Actividad 3 Evaluacin Econmica de Proyectos ...................................... 23
Se Pide Identificacin de necesidades y costos beneficios ....................... 29
Se Pide Seleccin de Opcin .................................................................... 29
Actividad 4 Seleccin de Software ............................................................. 30
Se Pide Identificacin de necesidades ................................................... 32
Se Pide Seleccin de Software .............................................................. 32
Se Pide Seleccin de Alternativas ......................................................... 35
4. VESEL S.A. ............................................................................................... 36
Actividad 1 Actividades de control del rea de sistemas ........................... 40
Se pide Elaboracin de Matriz de Riesgo e Identificar Controles: .......... 40
Actividad 4 Control de Aplicaciones ........................................................... 41
41
Se Pide Completar Matriz: ..................................................................... 43
Pgina 3 de 45

Introduccin
Esta gua prctica fue realizada con el trabajo conjunto de docentes de las
diferentes ctedras de Tecnologa de la Informacin de la Facultad de Cs.
Econmicas de la U.B.A.
Durante el ao 2014, se ha trabajado para confeccionar la segunda versin que
incluye las actividades de la primera (identificadas con la leyenda "Ao 2007"),
y se agregan nuevas ("Ao 2014") las cuales son, en principio, aplicables a la
ctedra del Prof. Guillermo Tricoci.
Un segundo cambio en esta versin consiste en la separacin de la gua en 3
partes:
a. Enunciados de casos y actividades, cada uno con su ubicacin en el
programa de la materia,
b. Planes de clase y soluciones a las actividades
c. Ejercicios de para exmenes
El presente documento, corresponde a la parte de enunciados de casos y
actividades a utilizar por los alumnos a lo largo del cuatrimestre, pertenecientes
a la Unidad 8 del programa de la materia.
En el mismo se encuentra el desarrollo general de los casos prcticos y, a
continuacin, las actividades relacionadas con cada uno.
Para cada actividad se indica, como referencia, el tema al que corresponden y
su ubicacin dentro del programa de la materia.
Pgina 4 de 45

1. DAXTOR SA:
Autor: Pablo Rota
Los inicios
Todo comenz hace unos 7 aos cuando Juan Roln, experimentado vendedor
de una importante fbrica de papel, y uno sus clientes Abel Gmez encargado
de una librera del micro centro de la ciudad, convierten sus cotidianas charlas
respecto a las dificultades de su negocio en un emprendimiento en comn y
resuelven crear lo que en principio se llam Distribuidora Rogo empresa
dedicada a proveer a libreras de todos la gama de artculos.
Abel Gmez, de 56 aos desde los 19 aos trabaj en este gremio, pas de
cadete a vendedor en una librera de barrio, luego obtuvo un trabajo como
vendedor en uno de las ms tradicionales negocios de artculos de oficina, por
su proverbial buen trato en pocos aos fue responsable de ventas y finalmente
lleg a encargado del saln teniendo entre otras las responsabilidades de
atender a los proveedores donde conoci a su actual socio.
Juan y Abel compartieron la visin de que la mayora de los proveedores del
rubro se agrupaban en dos categoras: grandes empresas que venden
directamente a las libreras a travs de su fuerza de ventas con condiciones de
entrega muy desventajosas para sus clientes o distribuidores en los cuales
siempre haba alguna lnea o producto a buen precio pero que el resto de
artculos o tenan precios muy superiores a los de la competencia o
directamente no tenan existencia.
As fue como gestaron la idea de una distribuidora orientada a brindar el mejor
servicio a los clientes asegurando disponibilidad de toda la lnea de productos y
mrgenes de precio homogneos para toda la lista de productos. La consigna
central fue que nunca una venta no se pudiera concretar por falta de producto.
Idearon incluso un servicio de entregas urgentes para que todo cliente que se
quedase sin mercadera fuese reaprovisionado en forma inmediata utilizando
los servicios de una empresa de mensajera por moto conocida de Abel.
Distribuidora Rogo comenz con una cartera de clientes de 28 libreras de
distinto tamao diseminadas entre la Capital y el gran Buenos Aires las cuales
surgieron entre los anteriores clientes de Juan y algunos contactos de Abel. A
los primeros proveedores los contact Abel y en un principio no tuvieron incluso
inconveniente de comprar algunos productos a otros distribuidores ms
grandes para alcanzar la consigna de tener productos siempre.
El comienzo fue en un depsito de 450 m2 alquilado y contrataron a 5 personas
para tareas generales y de distribucin.
Pgina 5 de 45

La primer dificultad fue la de obtener fondos ms all de sus ahorros y

prstamos personales.
El desarrollo del negocio
A dos aos de iniciada la actividad se incorpor como una actividad colateral el
taller para el copiado de libros contables al detectarse que las libreras
comerciales o no brindaban este servicio o lo derivaban a terceros con los
cuales siempre tenan inconvenientes en el cumplimiento de los plazos de
entrega.
Distribuidora Rogo se estaba ganando fama de ser un proveedor confiable y
con la incorporacin de Toms Snchez, un ex empleado de un taller de
copiado de libros, ms la inversin en la maquinaria necesaria y tres nuevos
empleados se comenz con esta nueva rea de negocios de Distribuidora
Rogo que a partir de ese momento pas a llamarse Daxtor S.A.
Toda la gestin administrativa estaba encargada al Estudio del Dr. Gonzlez y
Asociados clientes directos de la Distribuidora quienes mediante canje de
mercaderas se encargaban de todas las gestiones contables y administrativas.
Tambin para esa poca se compraron las primeras dos unidades de
pequeas pickups para la entrega de mercaderas las cuales fueron asignadas
al incipiente departamento de Despacho a cargo de Roberto Cceres familiar
de Juan Roln y persona considerada muy meticulosa y responsable y que se
encargaba de preparar personalmente cada despacho teniendo especial
cuidado en registrar en prolijos libros todos los pedidos, entregas, receptores
de cada venta, horarios y condiciones de entrega estipulados por cada cliente,
incluso llevaba un registro de todo inconveniente en las entregas por lo cual
ante un reclamo de un cliente era difcil que el mismo no fuera respondido
satisfactoriamente consultando las meticulosas anotaciones de Roberto. De
hecho no eran pocos los clientes que, valorando la precisin y confiabilidad de
Roberto, le hacan directamente a l los pedidos para reponer sus stocks. De
hecho el rea de Despacho fue junto con la de Ventas la que ms se desarroll
en cantidad de personal.
Los vendedores comandados por Juan Roln rpidamente fueron cada vez
abarcando reas geogrficas ms importantes. Cada vendedor atenda a su
cartera de clientes en forma personalizada haba algunos que haban logrados
ventas en el interior del pas las cuales se despachaban por encomienda para
cobrar contra rembolso o por acreditacin bancaria previa asegurando siempre
la forma ms rpida de proveer a sus clientes la cual siempre se mantuvo como
la premisa fundamental del negocio.
Abel Gmez se encarg desde el primer momento en las compras buscando
nuevos proveedores y manteniendo siempre actualizado los precios y
condiciones de los mismos. Es el propio Abel quien llevaba un registro de los
Pgina 6 de 45

proveedores as como la estimacin de compras necesarias a efectos de lograr

concentrar las mismas a la menor cantidad de compras posibles para asegurar
los mejores precios concentrando compras y ahorrando en costos de
transporte.
El negocio hoy
En la actualidad Daxtor S.A. con su poltica de comercializacin y servicio al
cliente ha logrado desarrollarse significativamente.
Cuenta con 15 vendedores. Cada uno de ellos lleva la ficha de la totalidad de
los clientes que atienden y se puede estimar un promedio de 35 clientes por
vendedor, excepto en el caso de Juan Roln que segn su fichero atiende
actualmente a 48 clientes.
Segn los datos de la facturacin en el ao pasado se han realizado un
promedio de 280 ventas mensuales y el monto facturado duplic al alcanzado
tan slo un ao anterior.
Ha tenido mucho xito un modelo de orden de compra abierta implementado
por uno de los vendedores (y rpidamente implementado por el resto) en el
cual algunos clientes importantes pactan precios preferenciales por niveles
compra significativos a realizar en perodos de 3 meses con el compromiso de
Daxtor S.A. de entregar a las 24 horas del pedido el cual es facturado a fin de
mes en base a las compras efectuadas en el mismo a los precios pactados a
principio del trimestre.
Los vendedores adems de una remuneracin bsica mensual cobran un
porcentaje de 5% de comisin por ventas y otro 5 % de comisin por cobranzas
de forma que Daxtor S.A. los compromete en la gestin de la misma para lo
cual cada vendedor mantiene actualizadas las fichas de las ventas y cobranzas
de sus clientes. Una copia de las notas de pedidos que realizan los vendedores
se entrega a Despacho para su preparacin, otra copia se mantiene en el
sector administrativo para remitir al estudio del Dr. Gonzlez y Asoc. para su
facturacin. Una vez realizada la facturacin se devuelve al sector
administrativo para su remisin a los clientes. Los vendedores tambin
entregan al sector administrativo copia de los recibos por cobranzas
entregados a los clientes junto con los valores cobrados los cuales en su
totalidad son depositados en cuentas bancarias.
Los pagos a los proveedores los realiza cualquiera de sus dos socios
nicamente con cheques ya que por norma de seguridad la empresa no
maneja dinero en efectivo. Los pagos menores se realizan mediante el cobro
de un cheque por medio de la Sra. Nora Gilman, ya jubilada y de mxima
confianza de ambos socios y que es la mayor y ms antigua de las empleadas
administrativas, en su ausencia la reemplaza su marido tambin empleado
administrativo de Daxtor S.A.
Pgina 7 de 45

La liquidacin de sueldos y de comisiones la realiza el estudio del Dr.

Gonzlez y Asoc. Los pagos correspondientes se hacen en cheque.
Por el copiado de libros Toms Snchez realiza una nota de pedido la cual se
factura como el resto de la operatoria. La cobranza por copiado de libros la
realizan los responsables del sector. En lugar de las comisiones por venta y
cobranza se otorga un 5% sobre el total cobrado por este servicio el cual se
distribuye como un premio a la productividad entre los empleados del sector
segn los criterios que mes a mes establece Toms Snchez.
El depsito original debi mudarse a un galpn de 1200 m2 en dos plantas. En
la planta superior del mismo est el taller de copiado de libros y el sector
administrativo. En la planta inferior se almacena la mercadera en estanteras y
se encuentra el sector que prepara los pedidos para despacharlos.
La preparacin de los despachos la realizan 12 personas en 2 turnos mientras
que el despacho hasta la casa de clientes la realizan 32 personas en dos
turnos en dotaciones de 2 personas por cada una de las 8 unidades que
actualmente dispone la empresa.
Junto con Abel Gmez trabajan en dos turnos un total de 8 personas para
asistir en la compra, recepcin de mercadera y almacenamiento en depsito.
En el sector administrativo trabajan en total 7 personas incluyendo dos
telefonista en dos turnos y una secretaria recepcionista.
Desde hace unos aos algunos empleados utilizan PCs para llevar distintas
planillas de clculo y procesadores de texto para la presentacin de
presupuestos. En total se han identificado a 8 PCs.
Se han detectado que algunos vendedores llevan la ficha de cuenta corriente
de sus clientes en estas planillas, otros por comodidad (pasan la mayor parte
del tiempo visitando clientes) prefieren registros manuales. Tambin hay
algunos clientes que llevan el registro de ventas por orden de compra abierta
as como planillas con informacin comparativa de precios de distintos
proveedores. Tambin se lleva en planillas el registro de la mercadera recibida
en el depsito.
Pgina 8 de 45

Actividad 3 Anlisis y Diseo Funcional

Ubicacin en el Programa
Tema
Autor
4.2.3
Gestin de Cobranzas
Pablo Rota
En Daxtor S.A., empresa dedicada a la distribucin de artculos de librera, a

pesar que los cobradores son los mismos vendedores que bien conocen a cada
uno de los clientes y que perciben una comisin por la misma se han venido
detectando morosidad en la cobranza.
Se ha analizado distintas alternativas, incrementar el porcentaje de cobranza,
asignar premios para la cobranza ms demorada, derivar cobranzas a un
equipo especfico que se ocupe de las cobranzas ms difciles, contratar a un
estudio de abogados y otras propuestas similares pero ninguna que lograra
convencer definitivamente a los dueos de Daxtor S.A.
Finalmente con la asistencia de su estudio contable se ha preparado una
propuesta que incluye la incorporacin de un Jefe de Crditos y Cobranzas, la
asignacin de una persona como responsable de la Tesorera, la definicin de
un procedimiento de cobranza y la implementacin de un sistema informtico.
Propuesta de procedimiento de cobranzas por cobradores en Daxtor S.A.
Elaborado por Estudio Gonzlez y Asoc.
El Jefe de crditos y cobranzas organiza la cobranza de la semana analizando
el control de vencimientos de las facturas pendientes de cobro y los
documentos a cobrar. En base a este anlisis prepara un Listado de Cobranzas
(LC) en el cual se detallan las cobranzas que cada cobrador deber gestionar
durante esa semana.
De hacerse efectivo el cobro, el Cobrador emite un Recibo (Rec). (el Original
para el cliente, el duplicado para la Tesorera de la empresa y el Triplicado
queda en el talonario del cobrador. Los recibos que se utilizan son provisorios
y en ellos se detallan los valores recibidos para ser aplicados a la cuenta
corriente del cliente, en su caso tambin se detallan los documentos recibidos y
las retenciones impositivas efectuadas por los clientes.
Si la gestin de cobranzas no tiene xito el Cobrador deber asentar en ese
listado las circunstancias en la cual no pudo cobrar.
El Cobrador asentar en el Listado de Cobranzas (LC) los nmeros y fechas de
recibos utilizados en cada cobranza. Dicho LC, junto con el duplicado de los
Recibos Provisorios, con los valores recibidos y con las constancias de
retenciones, se rendirn en la Tesorera. All el Tesorero proceder a verificar
que los valores y retenciones entregados por el Cobrador coincidan con lo
Pgina 9 de 45

asentado en el LC y que el total de dichos valores y los comprobantes de

retencin concuerde con el total del duplicado de los Recibos Provisorios.
En Tesorera se emite una Planilla de Rendicin de Cobranzas (PRC) con el
detalle de los valores y retenciones presentados por cada Cobrador la cual se
les entrega a los mismos junto con el LC firmado y sellado por el Tesorero
como constancia por la recepcin de la documentacin rendida.
Tesorera al fin de cada da emite una planilla de Rendicin de Tesorera (RT)
en la cual se registran todos los valores recibidos por la totalidad de las
cobranzas. En la misma se detallan los valores cobrados (efectivo, cheques
valores a depositar, valores en cartera y retenciones impositivas) identificando
el N de recibo por el cual se produjo su ingreso a la empresa.
El Cobrador, con la PRC emitida por el Tesorero y con el LC intervenido por el
mismo, deber rendir su gestin ante el Jefe de Crditos y Cobranzas. El Jefe
de Crditos y Cobranzas, adems de tomar conocimiento de las cobranzas
efectuadas controla la correlatividad de los recibos utilizados y una vez
efectuado ese control firma el PRC y lo enva a Contadura para que realice la
imputacin de los valores cobrados.
Contadura analizando los valores recibidos y el estado de cuentas corrientes
aplica los valores a los comprobantes pendientes. Lo mismo hace con las
retenciones impositivas. A partir de esta imputacin confecciona los Recibos
Definitivos (RD) en los cuales figuran los comprobantes cancelados el cual se
remitir a los clientes por correo.
Por la actualizacin de las cuentas corrientes de los clientes se realizar el
asiento:
Cobranzas
Retenciones impositivas (de corresponder)
a Deudores por Ventas
Con las planillas de Rendicin de Tesorera (RT) enviadas por Tesorera,
Contadura realizar el siguiente asiento:
Valores a Depositar
a Cobranzas
Finalmente Contadura conciliar el saldo de su cuenta Cobranzas y
efectivizar el control de los depsitos contra la cuenta Valores a Depositar.
Propuesta de sistema de cobranzas por cobradores en Daxtor S.A:
Objetivo
Planificar la gestin de cobranzas y controlar la rendicin de la misma.
Listado de acontecimientos
Nro
1
Terminador
Jefe
de
Crditos
y
Descripcin
Anlisis semanal de
gestiones de cobranzas
Entrada
1. Cobranzas a
gestionar
Pgina 10 de 45
Salidas
2. Listado de Cobranzas
(LC)

Cobranzas
(J.C.C.)
Tesorera
a realizar
Rendicin de
cobranzas realizadas
3. Registro de
valores
cobrados
Jefe
de
Crditos
y
Cobranzas
(J.C.C.)
Contadura
Control de cobranzas
realizadas
6. Consulta de
correlatividad
de Recibos
utilizados
7. Imputacin
de cobranzas
Anlisis de imputacin
de cobranza realizada
4. Parte de Rendicin de
Cobranzas.
5. Rendicin diaria de
Tesorera
6. Consulta de
correlatividad de Recibos
utilizados
8. Recibo Definitivo
Considerar el diagrama de contexto y el modelo de comportamiento de la

siguiente pgina
Se pide Anlisis de Procesos:
En base a la informacin disponible realice sus comentarios sobre el sistema
que est evaluando Daxtor S.A. para gestionar sus cobranzas.
Si bien sus observaciones se deben basar en las funcionalidades que tendr la
aplicacin propuesta, tambin puede formular su opinin sobre todos los
aspectos vinculados con esta iniciativa.
Diagrama de contexto
Jefe de
Crditos y
Cobranzas
J.C.C.
1. Cobranzas
a gestionar
6. Consulta de
correlatividad
de Recibos
3. Registro de
valores
cobrados
2. Listado de
Cobranzas
(L.C.)
Cobradores
4. Parte de
rendicin de
cobranzas
Sistema de
cobranzas por
cobradores
Tesorera
5. Rendicin
diaria de
Tesorera (R.T.)
8. Recibos
Definitivos
Clientes
Pgina 11 de 45
7. Imputacin de
cobranzas
Contadura

Modelo de comportamiento
Cobradores
x Clientes
J.C.C.
Cuentas
corrientes
11
1. Cobranzas a
gestionar
10
2. L. C.
Analizar
cobranzas a
gestionar
Cobr
a
12
Tesor
.
4. P. R. C.
Cobranzas a
rendir
3. Registro valores
cobrados
Registrar
cobranzas
13
5. R. T.
15
Controlar
correlativ.
recibos
Cobranzas
16
18
17
Imputar
cobranza
7. Imputacin
Cliente
8. Recibo
Definitivo
Pgina 12 de 45
Contadur.

Actividad 9 Modelado de Datos

Tema
Autores
Correccin
Agradecimientos
3.4
Proceso de Ventas
Germn Grin, Enrique Dondero y Cecilia Oriolo
Pablo Corral y Marcelo G. Bosque
Ezequiel Maravankin, Elina Schneider
Durante los ltimos meses Daxtor ha experimentado un gran crecimiento en su

cartera de clientes, lo que ha generado un impacto negativo no esperado en
sus recursos humanos.
Este crecimiento no fue acompaado por nuevas formas de trabajo de sus
vendedores. Estos ltimos hoy en da se encuentran sobrepasados por el
tiempo que deben dedicar a la gestin y atencin de las nuevas cuentas. El
foco ya no se encuentra depositado en las oportunidades de negocios y en la
generacin de nuevos acuerdos sino que queda reducido meramente a la
gestin de la cantidad de cuentas crecientes que tienen a cargo.
Debido a esta nueva situacin los socios de Daxtor, han decidido analizar la
posibilidad incorporar un software que les permita registrar la informacin de
sus clientes, para optimizar el trabajo del vendedor y para que los mismos
tengan ms tiempo disponible dedicndoselo a la bsqueda y contacto con
nuevos clientes.
Los beneficios que se esperan poder obtener de esta implementacin son los
siguientes:
Mantener un modelo nico de "ficha de cliente": actualmente la ficha del
cliente la maneja cada vendedor, existiendo formatos muy diversos,
tanto en papel como en hojas de clculo.
Asignar y modificar los vendedores responsables de cada cliente:
previendo reasignaciones, la gerencia de ventas necesita poder
modificar quin es el vendedor encargado de cada cliente. Adems, se
est analizando la posibilidad de incorporar la figura de "responsable
sustituto", para los casos de ausencia de un vendedor, por ejemplo, en
vacaciones o enfermedades.
Reportes gerenciales: Juan Roln est muy interesado en poder obtener
listados de sus clientes, agrupndolos por diferentes criterios. Si bien
todava no termin de definir qu reportes quiere exactamente, los dos
que ms le interesan son un listado de clientes por "Zona geogrfica"
(provincia, partido, barrio), y otro de "Clientes con ventas mayores a
entre las fechas"
Pgina 13 de 45

Un consultor fue contratado para que realice una propuesta que permita
cumplir con estas necesidades, para ello ha establecido algunos
procedimientos y ha elaborado los diagramas que se indican a continuacin.
El procedimiento propuesto por el consultor es el siguiente:
a) Siempre que un vendedor entra en contacto con un nuevo cliente, debe
registrarlo en el sistema. Por cada cliente podr registrar ms de una
forma de contacto (varios mails, telfonos, direcciones).
b) La gerencia de ventas deber designar por cada cliente un responsable
(que deber ser quien realiz el contacto) y un responsable sustituto. El
sistema deber informarle a los vendedores sobre esta situacin.
c) Cada vez que un vendedor realice una venta, la informacin deber
registrarse en el sistema de ventas existente, mientras que en el nuevo
sistema slo se deber registrar el nmero de factura y el cliente.
d) Cuando Roln quiera ver los listados por volumen de ventas, el sistema
deber conectarse con su correspondiente mdulo de Ventas para
obtener la informacin necesaria.
A continuacin se presentan los diagramas que present el consultor que
reflejan los procedimientos descriptos:
Diagrama de Entidad Relacin
Observacin de nomenclaturas:
PK: Primary Key Clave Primaria
FK: Foreign Key Clave Fornea
Pgina 14 de 45

Vendedor
Sistema de
Ventas
Clientes Asignados
Vendedores
Existentes
Medio de Contacto
por Cliente
Nuevo
Cliente
SISTEMA
Clientes por Volumen

De Ventas
Clientes por Zona
Geogrfica
Gerencia Ventas
Diagrama de Flujo de Datos
Se Pide Anlisis de Datos:

1) Se le pide a usted que analice los diagramas propuesto por el consultor y
realice las apreciaciones que le parezcan pertinentes teniendo en cuenta el
procedimiento planteado.
2) Con las apreciaciones realizadas reformule los 2 diagramas para que
queden completos.
3) Ahora que ayud a los consultores a realizar correctamente el DER y el
Diagrama de Contexto se le solicita que realice la Lista de Acontecimientos
y el Modelo Preliminar.
Pgina 15 de 45

3. AliMun - Alimentos al Mundo S.A.

Autores: Guillermo Tricoci y Pablo Corral
AliMun (Alimentos al Mundo S.A.) es una empresa de capitales Argentinos

radicada en la ciudad de Mar del Plata. Fue fundada en 1950 por Jos Aragn
y se dedicaba a la industrializacin y comercializacin de conservas de
pescado. Jos, un hombre muy moderno y visionario para su poca, nombro a
la compaa Alimentos al Mundo, ya que el sostena que la Argentina se
volvera a convertir en la fuente de abastecimiento de alimentos para el resto
del mundo.
En el ao 2007, AliMun est dirigida por el hijo de Jos Aragn (ya fallecido),
llamado Jos Aragn II. La compaa creci sustancialmente durante cerca de
60 aos, pudindose decir que se ha cumplido el sueo de Jos Aragn, ya
que la empresa comercializa sus productos en toda la argentina y exporta el
50% de su produccin a 10 pases (entre los que se encuentra China). Posee
sucursales en Uruguay y Chile y cuenta con 3 unidades de negocio:
Conservas de pescado
Harinas, cereales y aceites
Frigorfico
La estrategia de crecimiento, instaurada por Jos Aragn, consiste en la
adquisicin de empresas maduras en las distintas unidades de negocios y su
posterior fusin en la compaa principal, AliMun. Sin embargo, cada nueva
compaa adquirida, a pesar de estar fusionada en una misma entidad legal,
conservaba una administracin independiente. Este modelo de negocios, hoy
continuado por Jos Aragn II, ha sido muy exitoso y ha llevado a la compaa
a una facturacin anual de U$S 50.000.000 en el 2006, a poseer 8 plantas
fabriles y empelar a 4000 personas.
Las plantas fabriles se encuentran distribuidas de la siguiente manera:
Mar del Plata I: Conservas de pescado

Mar del Plata II: Aceites
Pilar: Harinas y cereales
Buenos Aires: Frigorfico
Santa F: Harinas y cereales.
Montevideo I: Harinas y cereales
Montevideo II: Frigorfico
Valparaso: Conservas de pescado
Pgina 16 de 45

Jos Aragn II comienzo a trabajar con su padre en 1980, cuando todava

estaba estudiando Ingeniera Industrial, carrera que nunca lo convenci
demasiado. Jos II siempre estuvo obsesionado con la tecnologa de la
informacin, comprando su primera computadora en 1981. Es por ello que
luego de graduarse de ingeniero industrial, comenz la carrera de ingeniera en
sistemas, gradundose en 1990.
En AliMun, Jos II hizo su carrera desde abajo, comenzando a trabajar como
cadete del sector financiero. A lo largo de los aos, pas por todas las reas
del negocio y por todas sus unidades, siendo l quien dirigi la ltima
adquisicin de AliMun: la planta de conservas de pescado de Chile en 2000.
Luego de vivir 5 aos en Valparaso, Jos vuelve a Mar del Plata a hacerse
cargo de la compaa en 2006, a la muerte de su padre.
Luego de acomodar la sucesin del mando en AliMun, Jos II comienza a
plantear la estrategia a seguir a partir del ao 2008. En carpeta haba varios
proyectos con miras a la expansin en el estratgico mercado chileno: adquirir
Via Congelados, una compaa que produce y comercializa alimentos
elaborados congelados.
La adquisicin de esta Via Congelados no plantea demasiados desafos
comerciales, financiero o de produccin, sino que los planteaba desde el punto
de vista tecnolgico. Via Congelados cuenta con un moderno ERP (el N 1 a
nivel mundial) en el que procesa la informacin de todas las reas de la
compaa: compras, produccin, inventarios, contabilidad, ventas, distribucin y
un moderno tablero de comando.
Si bien Jos II es un apasionado de los sistemas de informacin, AliMun no
contaba con una buena infraestructura tecnolgica. Esto es debido a que su
padre, Jos, era muy tradicional y consideraba que cada empresa adquirida
deba seguir operando con sus actuales sistemas y generar reportes manuales
e impresos para mandar a la casa central en Mar del Plata. Esos informes eran
procesados manualmente en la casa matriz en un sistema especial de
consolidacin contable, de manera de poder generar los libros legales. La
actual plataforma tecnolgica de AliMun consiste en:
Mar del Plata I y II, ERP local para compras, produccin inventarios,
contabilidad, ventas y distribucin.
Pilar, sistema desarrollado in-house de compras y produccin; un
sistema de contabilidad enlatado y un sistema de facturacin
desarrollado por una consultora externa. Ninguno de estos tres sistemas
estn integrados entre s.
Buenos Aires: Sistema contable desarrollado in-house. Facturacin
manual y compras y stock registrado en planillas de clculo.
Santa F: ERP internacional que administra todos sus procesos en
forma integrada
Pgina 17 de 45

Montevideo I: planillas de clculo y un enlatado de contabilidad local.

Montevideo II: planillas de clculo y el mismo enlatado de contabilidad
que Montevideo I, pero desintegrado con l.
Valparaso: ERP internacional (la competencia del ERP de Via
Congelados) que maneja funcionalidad equivalente a la de Via
Congelados.
Ante el crecimiento sostenido de los negocios, Jos II est ms preocupado por
la gestin e integracin de sus distintas reas de negocio que por la adquisicin
en s de Via Congelados. Jos II se dio cuenta que no se poda seguir
administrando la empresa sin una visin global e integradora de todos los
negocios. Adems, Jos II consideraba que la gran redundancia de
informacin, estructuras organizativas y la gran cantidad trabajo manual (y
procesamiento manual de informacin) generaba muchos gastos de
infraestructura que podran complicar los negocios en el mediano plazo. As
mismo, el hecho de contar con administraciones independientes en cada planta
haca incurrir a la compaa en grandes costos operativos, fruto de no
aprovechar las economas de escala en reas, como compras, manejos de
inventarios, balanceo de la produccin, entre otros. Con esta inquietud en
mente, Jos II decidi aprovechar la adquisicin de Via Congelados para
integrar todos sus sistemas de informacin para poder centralizar algunas
decisiones claves que redunden en ahorros importantes de costos, sin por ello
cambiar su estrategia de mantener administraciones separadas por plantas.
Para lograr este objetivo, Jos II le encarg al gerente de sistemas de AliMun
que evalu la implementacin del ERP de Via Congelados en todas las
plantas de AliMun, generando una plataforma integrada.
El estudio realizado por el departamento de sistemas de AliMun se demor 5
meses ms de los 2 meses programados originalmente. Esto se debi a que
las dificultades de integracin y las diferencias de los procesos de negocios de
todas las plantas hicieron muy difcil el relevamiento. Los resultados fueron
impactantes: implementar el ERP en todas las plantas implicara un esfuerzo
de 3 aos de trabajo, reingeniera de procesos de las plantas de Pilar, Buenos
Aires y Montevideo I y II y una inversin de U$S 5.000.000. Adems, dejaba en
claro que se requera realizar un importante esfuerzo de reorganizacin
administrativa para que la unificacin tecnolgica diera los resultados
esperados.
Ante los resultados del estudio, Jos II, que ya haba adquirido Via
Congelados, decidi encarar la integracin por etapas:
Unificacin de compras
Unificacin de pagos y cobranzas
Consolidacin contable
Pgina 18 de 45

Unificacin de produccin por unidades de negocios:
Conservas de pescado
Harinas, cereales y aceites
Frigorfico
Congelados
Por otro lado, defini que durante el transcurso de la unificacin administrativa,

no se implementara un sistema nico en toda la compaa, sino que integrara
las plataformas existentes. Una vez que el proceso de unificacin termine, se
evaluara la posibilidad de unificacin tecnolgica.
Dado que existe actualmente un software de consolidacin en Mar del Plata, se
utilizar como plataforma sobre la cul construir el sistema de integracin
transitoria. El nuevo modelo mantendr la operacin diaria en cada sistema de
informacin, pero tendr interfaces peridicas con el nuevo sistema de
consolidacin.
Todas las plantas tendrn acceso al nuevo sistema y lo debern utilizar para
realizar las operaciones a medida que las etapas iban avanzando.
Pgina 19 de 45

Actividad 1 Gestin de Proyectos

Tema
Autores
4.3
Anlisis Unificacin del Proceso de Compras
Guillermo Tricoci y Pablo Corral
Con la premisa de iniciar el camino hacia la integracin, unificacin y

centralizacin de funciones comunes, Jos II contrata los servicios de una
consultora de primera lnea para elaborar el proyecto de la primera etapa: el
proceso de compras.
A continuacin se detalla un resumen de procesos de compras por planta:
Mar del Plata I y II, Santa Fe y Valparaiso:
El proceso se divide en tres tipos:
Compras productivas: Se genera un proceso clsico de pedido, recepcin de
mercadera, verificacin de facturas y pago. El input del proceso es el MRP
(corrida de necesidades de abastecimiento en funcin del plan de produccin) y
requera la aprobacin de la gerencia de compras. El inventario est en lnea
con el sistema de produccin, actualizndose a medida que se producen los
consumos de materia prima en cada orden de produccin.
Compras de servicios. Cada rea, en funcin de sus necesidades de servicio,
realiza una requisicin de compras a travs del sistema, que deber ser
aprobada por el jefe o gerente de departamento, en funcin del monto. Se
cuenta con un presupuesto anual por departamento que se verifica
automticamente antes de hacerse la autorizacin. Luego, el circuito sigue con
pedido, recepcin de mercadera, verificacin de facturas y pago.
Compras menores: Se realizan mediante fondo fijo y con la aprobacin del jefe
de departamento.
Todos los documentos estn relacionados entre s, no necesitndose ingresar
los mismos datos dos veces. Las verificaciones y controles internos entre
documentos (recepcin contra pedido y factura contra recepcin y pedido) se
realizan automticamente, pudindose realizar excepciones, previa
autorizacin gerencial. Todas las aprobaciones son automatizadas (firma
electrnica) a travs de workflow (flujo de trabajo). Las facturas slo se pueden
pagar si las verificaciones y controles en las etapas previas del proceso fueron
realizadas exitosamente. Todos los documentos se integran con la contabilidad
en forma automtica y sin posibilidad de intervencin manual. Los datos
maestros de materiales, produccin y proveedores se toman de una base de
datos maestros centralizada para evitar el ingreso de los mismos en cada
transaccin
Pilar:
Pgina 20 de 45

El proceso se divide en tres tipos:

Compras productivas: Se genera un proceso clsico de pedido, recepcin de
mercadera, verificacin de facturas y pago. El input del proceso es el MRP
(corrida de necesidades de abastecimiento en funcin del plan de produccin) y
requera la aprobacin de la gerencia de compras. Durante la recepcin de
mercaderas se generan vales de recepcin que luego contabilidad registra en
su sistema contable. La factura es registrada en contabilidad y verificada
manualmente contra los vales de recepcin.
Compras de servicios. Cada rea, en funcin de sus necesidades de servicio,
realiza una requisicin de compras, que deber ser aprobada por el jefe o
gerente de departamento, en funcin del monto. Se cuenta con un presupuesto
anual por departamento. Luego, el circuito sigue con pedido, recepcin de
mercadera, verificacin de facturas y pago. Todas las semanas se genera un
reporte de pedidos de servicios para enviar a contabilidad. Las facturas se
registran pendientes de verificacin y se comparan con la lista de servicios para
poder ser desbloqueadas. Luego, la factura se enva al sector requirente para
que la firme. Con el visto bueno de cada sector, se habilitan para el pago.
de departamento. Se administran en el sector financiero, quin las lleva en el
sistema de contabilidad.
Si bien las bases de datos maestros estn integradas con los mdulos de
transacciones, los datos de proveedores estn duplicados entre el sistema
contable y el de compras. Existe una interface que los mantiene actualizados
en batch en forma diaria.
Buenos Aires, Montevideo I y II:
Compras productivas: Todos los das el sector de produccin enva por mail
una solicitud de materiales al departamento de compras e inventarios. All se
cotejan el pedido con el stock y, de ser necesario, se emiten los pedidos a los
proveedores correspondientes. Los pedidos se imprimen y se envan a la firma
del gerente general antes de ser enviada a los proveedores. Una vez recibida
la mercadera, compras actualiza la planilla del stock y enva la mercadera a
produccin. Las facturas se reciben en finanzas y se contabilizan bloqueadas.
Se envan a compras para verificar y con la firma del gerente de compras se
desbloquean.
Servicios: Cada sector enva un mail con sus requerimientos al gerente de
compras, quin verifica con el gerente de finanzas el presupuesto y la
disponibilidad de fondos y genera los pedidos. Los pedidos son firmados por el
gerente general antes de ser enviados al proveedor. Las facturas se reciben en
contabilidad. Las contabiliza bloqueadas y las envia a compras. Compras las
compara con los duplicados de los pedidos, las firma y enva a contabilidad
para desbloquear.
Pgina 21 de 45

de departamento. Se administran en el sector financiero, quin las lleva en el
sistema de contabilidad.
Los datos maestros se llevan en planillas de clculo anexas y los datos de los
proveedores se llevan adems en la libreta de contactos del correo electrnico
Se pide Analizar proceso de Compras:
Analice el proceso de compras actual en todas las plantas y elabore:
1. Realice un cuadro comparativo de los sistemas implementados en las
distintas plantas identificando plataforma y funcionalidades
2. Sntesis comparativa de los procesos actuales, relacionando con
plataforma tecnolgica: Se agreg ms detalle para poder desarrollar
este punto
3. Identificacin de puntos en dnde se puedan obtener ventajas de escala
4. Ventajas y desventajas de centralizar las compras bajo una misma
plataforma versus centralizar sobre las plataformas actuales.
5. Identificacin de los principios rectores para un futuro proyecto de
unificacin:
i.
ii.
iii.
iv.
v.
vi.
Estructura organizativa
Estructura de autorizaciones de compras
Tipos de compras y tipos de autorizaciones por compra
Tipos de compras a centralizar/descentralizar
Modelo de datos a integrar
Plataforma tecnolgica
Pgina 22 de 45

Actividad 3 Evaluacin Econmica de Proyectos

Tema
Autores
Revisin
5.3
Business Intelligence
Noelia Massone, Barbara Michalla, German Grin
Guillermo Tricoci y Pablo Corral
Tras la unificacin exitosa de los procesos de compras en todas sus plantas, y

teniendo la informacin de las mismas integrada tanto en lo que respecta a los
proveedores y productos, como a solicitudes y rdenes de compra, Jos II
esperaba poder tener la visin global que necesitaba acerca de los procesos.
Adems, se haban reducido el trabajo manual de procesamiento de
informacin y la redundancia de datos provocada por la falta de integracin de
los sistemas, por lo que la toma de decisiones sera ms gil y de mejor
calidad. Lo aliviaba saber que, gracias a los cambios en el software, los
procesos de compras ya no presentaran problemas, y podra atender otros
temas de la empresa.
Pero, mientras se avanzaba con la integracin del resto de los procesos de
AliMun, Jos empez a notar que no todos los problemas del rea de Compras
se haban solucionado: cada vez que requera a la Gerencia de Compras algn
informe deba esperar la informacin varios das, los acuerdos con los
proveedores no siempre eran ventajosos y, en repetidas ocasiones, las
materias primas no eran suficientes para abastecer la produccin planificada.
Tambin haba recibido quejas de distintos sectores de que frecuentemente los
sistemas transaccionales funcionaban realmente lentos, lo que dificultaba
muchsimo la carga de informacin y retrasaba otras tareas que el personal
deba realizar.
Por otra parte, debido a la importancia de la empresa en la comercializacin de
alimentos, Jos participa en reuniones y eventos de diferentes asociaciones
empresariales, como la CIPA (Cmara de Industriales de Productos
Alimenticios) o la FIPAA (Federacin de Industrias de Productos Alimenticios y
Afines). En estas exposiciones Jos suele necesitar tener disponible
informacin de mltiples sectores y plantas, y en mltiples oportunidades
fueron evidentes las discrepancias respecto a algunos datos. Incluso, Jos
lleg a plantear en alguna oportunidad que le da la impresin que algunos
gerentes "esconden" o "dibujan" la informacin solicitada.
Ante esta situacin, Jos decidi analizar las causas de estos problemas, para
lo cual se reuni con la Gerente de compras, Marisa Alvarado. Ella le plante
que en reiteradas oportunidades no puede contar con la informacin
correcta en el momento necesario. A su personal le requiere mucho tiempo
obtener los datos para realizar los reportes, y esto hace que no siempre se
cuente con la informacin completa, por ejemplo, a la hora de negociar
descuentos o financiacin con los proveedores. En el ltimo ao, en base a una
estimacin de $1.000.000 (a precio de lista) se negoci con los proveedores un
Pgina 23 de 45

descuento del 7%. Para esa estimacin se cont con informacin incompleta,
por lo que se omitieron $350.000 al negociar, lo que hubiese permitido
conseguir un descuento mayor (del 15%). Se espera que la produccin de
AliMun para los prximos aos (y, por consiguiente, las compras
asociadas) crezca a un ritmo del 4% anual.
Jos II le pregunt a Marisa, cmo poda perderse tanto tiempo en obtener
reportes, si se haba unificado la informacin de Compras de todas las plantas
en un mismo sistema. Ella le contest: El problema es que los reportes del
sistema actual brindan informacin en detalle de las compras generadas por
cada plantas, pero para las estimaciones requerimos sumar los datos de varios
meses atrs, y agruparlos por tipo de mercadera y por proveedor. La gente de
sistemas nos cre algunos informes en el sistema, pero suelen agregarse
nuevos productos, se cambian los proveedores, o necesitamos hacer clculos
extras en base a esos datos, y estos reportes son muy rgidos, as que
terminamos generando parte de la informacin manualmente o en planillas de
clculo, y es comn que de esta manera se cometan errores. Por mes hay dos
personas durante 2 das, dedicadas exclusivamente a esto, es mucho tiempo.
Otro tema que preocupaba mucho a Jos II eran los pedidos de clientes que no
pudieron cumplirse por falta de materias primas para poder fabricar los
productos solicitados, a pesar de que las plantas poseen capacidad ociosa. De
no haber cancelado estos pedidos, AliMun hubiera ganado $200.000 ms
durante el ltimo ao. Segn lo que le explic Marisa, gran parte de este
problema resida en la dificultad para calcular las estimaciones teniendo en
cuenta distintos escenarios, a la hora de planificar las compras de cada perodo
y negociar con los proveedores (por ejemplo, muchos de estos casos, se dieron
ante aumentos de la demanda imprevistos, o causados por campaas de
marketing de la empresa). Estimar las compras de todos los productos,
teniendo en cuenta las distintas variables involucradas en el proceso (precios,
formas de pago, variedad de proveedores, tiempos de entrega para cada
planta, posibles aumentos de ventas, etc.) requera poder calcular distintos
escenarios, lo cual se tornaba muy complejo de hacer con los reportes
existentes, que eran ms estticos. Para mejorar la planificacin y la respuesta
a los cambios en la demanda, se requera poder armar algn tipo de reporte
dinmico que permitiera analizar el impacto de los cambios en esas variables,
al estilo de un anlisis Qu pasa si.
Luego de la reunin con Marisa, Jos II se reuni con el Gerente de
Tecnologa, Marcelo Agucha, para ver la posibilidad de que se modifiquen ms
rpidamente los reportes que requiere Compras. Nos piden modificaciones
con bastante frecuencia, hacemos algunas, pero no se olvide que estamos
avanzando con la unificacin del resto de los sistemas, que es nuestra
prioridad, y eso lleva mucho tiempo. Entre el desarrollo de los cambios, las
pruebas y las correcciones de los reportes, estamos dedicando ms o menos
30 horas por mes, es lo mximo que podemos., coment Marcelo. En cuanto
a los anlisis de escenarios, le aclar que eso requerira un desarrollo especial,
de varias horas de anlisis y desarrollo.
Pgina 24 de 45

Jos II tambin le consult a Marcelo acerca de la lentitud de los sistemas

transaccionales. Marcelo le explic: Muchos de los reportes que utiliza
Compras, requieren procesar grandes volmenes de informacin porque
utilizan muchos datos histricos (trimestrales, del ltimo ao, etc.), y luego
realizan distintos clculos para agruparlos por diferentes criterios. Esto hace
que los reportes consuman muchos recursos de la base de datos, que es la
misma a la que acceden los sistemas transaccionales, afectando los tiempos
de respuesta. Jos propuso entonces mejorar el hardware del servidor de
base de datos, pero Marcelo le aclar que sera una solucin temporaria,
porque a medida que se siguieran almacenando datos, volveran a encontrarse
con el mismo problema. Quizs sera conveniente que ese tipo de reportes se
realizaran en otra base de datos, dedicada especialmente a eso.
Tras contarle estos problemas a un amigo personal de Jos II, este le sugiri
implementar un sistema de Business Intelligence (BI) para poder explotar mejor
la informacin. l, en su propia empresa haba propuesto un proyecto que
inclua un software de este tipo, y haban logrado aumentar su volumen de
ventas. Tambin le coment que, si lo utilizaban de forma adecuada, podan
mejorar el rendimiento de prcticamente cualquier sector, ya que los directivos
podran contar con informacin ms confiable y actualizada. Jos rpidamente
pens en las posibilidades de mejorar la gestin de compras, e incluso de
obtener mejor informacin de los dems procesos una vez que fueran
integrados.
Si bien en general la idea fue bien recibida en la empresa, desde la Gerencia
Financiera comentaron que podra no ser el momento adecuado, ya que an no
se encontraban integrados otros procesos, como los de pagos y cobranzas, ni
la parte contable, de suma importancia para la gestin de la empresa. Jos II
habl este tema con el Gerente de Tecnologa, y llegaron a la conclusin de
que, si se contrataban los recursos necesarios para llevar adelante el proyecto,
podra iniciarse la implementacin de una aplicacin de BI de forma limitada,
slo para el rea de compras, mientras se avanzaba con el resto del proyecto
de centralizacin. Posteriormente, podran ir incorporando progresivamente la
informacin de otros procesos, siempre teniendo en cuenta que esto requerira
un esfuerzo y costos adicionales.
A Jos II lo entusiasmaba la posibilidad de solucionar estos nuevos problemas,
pero tambin haba ledo que los costos de estas herramientas eran elevados y
no estaba seguro de que fuera realmente conveniente comprar una de ellas.
Por este motivo, le pidi a Marcelo Agucha que lo ayudara a investigar acerca
de las alternativas existentes, casos de aplicacin en empresas del mismo
rubro, costos y beneficios, a fin de poder realizar un anlisis econmico ms
profundo.
Una de las caractersticas que le interesaron a Jos II fue la posibilidad de que
los usuarios pudieran armar sus propios reportes, sin requerir desarrollo por
parte de sistemas, una vez implementada la herramienta. En base a distintos
informes sobre el tema, concluy en que este tipo de soluciones permita
ahorrar, en promedio, alrededor de un 50% del tiempo dedicado por los
usuarios finales a la elaboracin de reportes. Tambin saba que se requerira
Pgina 25 de 45

una nueva base de datos (hardware, y software de administracin)

independiente de los sistemas transaccionales, para centralizar la informacin,
y que deba dedicarse esfuerzo al inicio del proyecto para definir la informacin
que se quera incorporar y disear los procesos de extraccin y carga.
Junto con Marcelo, identificaron dos alternativas de proyecto: en el primer caso
se podra implementar una solucin de BI de tipo Software como Servicio
(Software as a Service - SaaS en Ingls)), que implica ahorros en trminos de
infraestructura pero un aumento en el riesgo de que los datos de AliMun
queden en manos de un tercero, sumado a que el acceso est sujeto a la
disponibilidad del servicio, al pago peridico del servicio y agrega otras
complejidades tcnicas y de seguridad de la informacin; la segunda alternativa
incluye la implementacin de un software de BI tradicional (en las oficnas de la
empresa o on premises en Ingls), en el cual la empresa se hara cargo de la
infraestructura pero sera duea de sus propios datos, generando una base de
conocimiento local y accesible para todas las futuras gestiones.
A partir de la informacin obtenida en diferentes sitios, y luego consultar con
colegas y proveedores, Jos y Marcelo llegaron al siguiente anlisis general de
cada una de las alternativas. En ambos casos, dada la complejidad de la
implementacin, la misma ser realizada por el proveedor, para poder
comenzar a utilizar rpidamente la herramienta. Para cuantificar los costos,
decidieron calcular un promedio de los valores (incluyendo impuestos) que
haban obtenido en la bsqueda.
Solucin de BI SaaS
Licenciamiento: se abona un costo anual de servicio, de $12.000 por
usuario. El mismo incluye utilizacin de mesa de ayuda telefnica y web.
Hardware/software:
o Para aplicacin y base de datos: a cargo del proveedor (incluido
en la licencia), no requiere compra ni mantenimiento.
o No requiere actualizacin de hardware ni software en las
terminales de los usuarios.
Puesta en marcha:
o Consultora y desarrollo (incluye relevamiento, diseo del modelo
y reportes bsicos, desarrollo de ETL, pruebas y correcciones):
Consultor Senior: 220 horas Valor hora: $250
Consultor Junior: 320 horas Valor hora: $180
Desarrollador ETL: 200 horas Valor hora: $250
o Capacitacin: el costo promedio por da completo de curso es de
$2000
Curso reporting bsico (uso general de la herramienta,
creacin y modificacin de mtricas simples y reportes).
Duracin: 2 das
Pgina 26 de 45

Curso reporting avanzado (creacin de mtricas complejas,

tableros de comando). Requiere Reporting bsico.
Duracin: 2 das
Curso Administracin (configuracin de usuarios,
seguridad). Duracin: 1 da
o Personal interno asignado al proyecto:
Analista funcional, con conocimiento de los transaccionales
para colaborar con los consultores y realizar el seguimiento
del proyecto. 200 hs
Personal de infraestructura para trabajar en la
configuracin de acceso a la red de la empresa y a las BD
transaccionales. 30hs
Analistas de compras: participacin de 3 personas en el
relevamiento de necesidades y validacin de los
indicadores y reportes generados. 80hs por persona.
Adems, se requerirn 50 horas anuales de personal de
infraestructura para mantenimiento de los accesos a BD y
correccin de posibles problemas.
La mayora de estas soluciones no cuenta con la posibilidad de anlisis
de escenarios (What If)
Implementacin local de software de BI (On premises)
Licenciamiento:
o Licencia: $250.000. (para 6 usuarios bsicos, 4 avanzados y 1
administrador). Incluye mantenimiento por un ao.
o Mantenimiento anual: 15% sobre el total de la licencia adquirida.
Incluye actualizaciones y soporte tcnico.
Hardware/software adicionales:
o Servidor de base de datos:
Hardware: $40.000
Sistema operativo y utilitarios bsicos (antivirus, etc):
$15.000
Software gestor de base de datos: $185.000
o Servidor de aplicacin: de acuerdo a los requisitos relevados,
podra utilizarse alguno de los servidores actuales de AliMun, por
lo que no implicara gastos adicionales.
o No requiere actualizacin de hardware ni software en las
terminales de los usuarios.
Puesta en marcha:
o Consultora y desarrollo (incluye relevamiento, diseo del modelo
y reportes bsicos, desarrollo de ETL, pruebas y correcciones):
Consultor Senior: 220 horas Valor hora: $250
Pgina 27 de 45

Consultor Junior: 320 horas Valor hora: $180

Desarrollador ETL: 200 horas Valor hora: $250
o Capacitacin: el costo promedio por da completo de curso es de
$2000
Curso Reporting bsico (uso general de la herramienta,
creacin y modificacin de mtricas simples y reportes).
Duracin: 2 das
Curso Reporting avanzado (creacin de mtricas
complejas, tableros de comando). Requiere Reporting
bsico. Duracin: 2 das
Curso Arquitecto (diseo del modelo de datos, definicin
de cubos y dimensiones): 2 das
Curso Administracin (configuracin de usuarios,
seguridad). Duracin: 2 das
o Personal interno asignado al proyecto:
Analista funcional, con conocimiento de los transaccionales
para colaborar con los consultores y realizar el seguimiento
del proyecto. 250 hs
Personal de infraestructura para la instalacin del software,
configuracin del nuevo hardware y gestionar acceso
seguro a las BD transaccionales.60hs. 40hs
Analistas de compras: participacin de 3 personas en el
relevamiento de necesidades y validacin de los
indicadores y reportes generados. 80hs por persona.
Adems, se requerirn 150 horas anuales de personal de
infraestructura para mantenimiento de los equipos,
monitoreo, backup, etc.
Todas las aplicaciones relevadas cuentan con la posibilidad de anlisis
de escenarios (What If)
Otros datos recopilados por Jos y Marcelo:
Se dar acceso a la herramienta a 10 usuarios (incluyendo a Jose y a la
Gerente de Compras) para la realizacin o consulta de reportes. De
ellos, 4 usuarios podrn realizar tableros y reportes avanzados.
Adems, se requerir un usuario administrador para la configuracin y
gestin de herramientas. En el caso de la herramienta BI local, este
mismo usuario podr hacer modificaciones en las dimensiones y cubos.
En base a informacin de los ltimos 5 aos, el mercado de BI sufre un
incremento anual en el valor de los servicios, de 15%, en promedio.
Para el anlisis econmico se tomar un horizonte de 5 aos.
Pgina 28 de 45

Para la estimacin de los costos del personal interno, Jose II solicit la

informacin de los valores por hora de cada puesto, incluyendo
retenciones y contribuciones. La informacin proporcionada fue la
siguiente:
o Analista funcional/ Desarrollador: $150
o Personal infraestructura: $130
o Analista de compras: $110
o Anualmente, la empresa incrementa los sueldos en un 20%
promedio.
Se Pide Identificacin de necesidades y costos beneficios
1. A partir del enunciado, identifique cules son las necesidades de la
organizacin que se espera satisfacer.
2. Identifique cules son los costos que podran ser atribuidos al
proyecto.
3. Identifique los potenciales beneficios que podran ser atribuidos al
proyecto. Clasifquelos en Cuantificables y No Cuantificables.
4. Cules de esos beneficios incluira en un anlisis econmico?
Se Pide Seleccin de Opcin
A partir del clculo de los costos y la realizacin de los flujos de fondos
correspondientes:
1. Cul sera la opcin que elegira basndose en el valor inicial de
inversin?
2. Cul sera mejor considerando el costo total de propiedad?
3. Y si se basara en el TVO?
Pgina 29 de 45

Actividad 4 Seleccin de Software

Tema
Autores
4.3
Business Intelligence
Noelia Massone, Barbara Michalla, German Grin
En base a los resultados del anlisis econmico de las alternativas, Jose II

decide avanzar con la opcin de implementar en forma local una herramienta
de BI. Los responsables de llevar adelante el proyecto sern Marcelo Agucha y
Marisa Alvarado.
El primer paso ser seleccionar la herramienta que mejor se ajuste a las
caractersticas y necesidades de AliMun. Para esto debern contactarse con
diferentes proveedores y solicitarles informacin detallada acerca de las
herramientas que comercializan, y un presupuesto de implementacin.
Para definir las caractersticas a evaluar de cada proveedor, Marisa y Marcelo,
se renen con personal de sus sectores, y de otras reas involucradas, les
explican de qu se trata el proyecto y les piden sus opiniones. A continuacin
se resumen algunos comentarios surgidos en las reuniones:
Gerencia de Compras
Los reportes tienen que poder modificarse fcilmente, siempre necesitamos
agregar o sacar columnas, cambiar frmulas o cambiar el formato. Si los
reportes son estticos, o no podemos crear reportes a medida, vamos a seguir
teniendo problemas para obtener rpido la informacin.
A veces, para un mismo reporte, necesitamos cruzar informacin del sistema,
con datos externos, por ejemplo, una planilla de clculo con indicadores del
mercado, o datos del sistema de stock.
Tambin necesitamos que la informacin se pueda ver a distintos niveles, por
ejemplo, ver las compras del mes, por proveedor, y luego poder explotar la
informacin de un proveedor en particular. Necesitamos poder ver los datos
fcilmente sin pedir un nuevo reporte a sistemas, porque lleva tiempo, y es muy
necesario para nosotros poder analizar la informacin para poder tomar
decisiones correctas.
Siempre nos lleva tiempo aprender a usar los sistemas nuevos. Si no es fcil
de usar vamos a tardar ms en sacar la informacin, y las prdidas van a
seguir continuando.
Me parece buena la idea, pero no se mucho de computacin. Aprend a hacer
los informes con planillas de clculo, pero tengo miedo de que con un
programa nuevo sea difcil de hacer y me lleve mucho tiempo.
Uno de nuestros mayores problemas est a la hora de planificar, necesitamos
hacer anlisis de escenarios, hacerlos manualmente es muy engorroso. Si no
podemos resolver esto, la solucin va a ser incompleta.
Pgina 30 de 45

Tiene que permitir hacer reportes con diferentes grficos, tipo tableros.
Nosotros hacemos muchos anlisis con grficos. Adems, ayudan a hacer los
informes ms simples y claros.
Sera bueno poder acceder va web, para poder ver nuestros reportes cuando
vamos a otras plantas, y tambin para compartirlos con otras personas.
Para poder contar con la informacin a tiempo, necesitamos que los jefes de
compras de las plantas, carguen los datos correctamente. Tenemos muchas
idas y vueltas para corregir los datos.
Gerencia de Tecnologa
Una nueva herramienta nos implica nuevos equipos y nuevo software para
administrar, mantener y monitorear, necesitamos que el proveedor nos
garantice un buen de nivel de servicios, para que nos respondan en tiempo y
forma. El tiempo de respuesta es un problema constante con los proveedores y
los usuarios nos reclaman a nosotros porque no pueden realizar su trabajo.
El proveedor tiene que tener experiencia con la herramienta, y en el rubro.
Tuvimos casos de implementaciones con proveedores importantes, pero que
no conocan el rubro, y siempre se demoraron mucho los proyectos porque
tenan que entender el negocio. Algunas veces tuvimos que dedicar ms
recursos propios para trabajar en la implementacin y, adems de que se
vuelve ms caro, actualmente no tenemos personal disponible.
Sera til para nosotros que tengan documentacin completa y clara.
Hay que tener en cuenta que les debe resultar fcil de usar a los usuarios para
que no requieran tanto soporte de nuestro lado. Cuando son difciles de usar
las herramientas, les incomodan a los usuarios en su trabajo diario y nos
requieren ms esfuerzo.
La integracin del resto de los procesos de la empresa nos est llevando
mucho tiempo, si este nuevo proyecto nos lleva muchas horas, se va a retrasar
el resto.
Me parece importante que sea de fcil administracin y mantenimiento, para
que no nos requiera demasiado tiempo.
Tiene que ser compatible con el software de base que conocemos y
utilizamos: Linux CentOS que es el sistema operativo que tenemos en los
servidores de aplicacin, y base de datos MS SQL Server. Las PC de escritorio
tienen Windows Vista y Windows 7. Mantener software de base diferente va a
requerir nuevos recursos slo para este nuevo sistema, y es muy costoso para
la empresa.
Sera bueno que el proveedor tenga varios consultores y que tengan
experiencia, para que puedan ayudarnos si surge algn problema en
particular.
Es valorable que salgan actualizaciones peridicamente, que solucionen
errores o mejoren la funcionalidad, esto muestra que el fabricante contina
trabajando en mejorar el producto.
Seguridad Informtica
Pgina 31 de 45

La seguridad de los accesos es importante. Cmo mnimo requisito, deben

poder crearse roles para restringir el acceso a los reportes slo a usuarios
autorizados. Tambin debe poder diferenciarse entre quienes pueden editar un
informe y quines pueden slo consultarlo.
Tenemos un directorio de usuarios centralizado, que nos permite quitar
fcilmente los accesos a las personas que se van de la empresa o cambian de
rea. Adems, es ms cmodo para los usuarios porque usan siempre la
misma contrasea. Si bien no es obligatorio, es valorable que tenga
compatibilidad con LDAP, que es la tecnologa que usa este directorio.
Gerencia Econmico-Financiera
Las prdidas por pedidos que no pueden cumplirse y por descuentos no
conseguidos con los proveedores son bastante importantes para la empresa,
es necesario reducirlas lo antes posible.
Probablemente requeriremos financiacin, pero si se mantienen los valores
acordes al anlisis econmico que se realiz, la empresa est en condiciones
de afrontar el costo del proyecto.
Direccin
Me interesa que los gerentes y yo podamos acceder a los informes y tableros,
y navegar por ellos desde nuestros celulares o tabletas.
Quiero que podamos reducir las prdidas cuanto antes, no importa que sea la
herramienta ms barata, tiene que ser la que mejor cubre nuestras
necesidades.
Se Pide Identificacin de necesidades
1. En base a las necesidades planteadas por las distintas reas,
identifique aquellas que son relevantes para el proyecto, y
confeccione una lista de caractersticas a evaluar para cada
proveedor. Clasifquelas en funcionales, tcnicas (o no funcionales)
y comerciales.
Se Pide Seleccin de Software
Marcelo Agucha y Marcela Alvarado se contactaron con algunos proveedores,
buscaron informacin sobre ellos y, junto a miembros de sus equipos,
participaron de las respectivas demostraciones de los productos. Luego de un
mes de investigacin, recabaron la siguiente informacin:
Opcin 1 Software propietario, de cdigo cerrado
Posibilidad de creacin de varios tipos de reportes y tableros de

comando. Posee plantillas para facilitar el diseo.
Pgina 32 de 45

Permite navegar la informacin de un reporte en diferentes direcciones

(drill down, drill across), as como agregar nuevos indicadores y filtros a
un reporte, en tiempo real, por lo que es posible realizar reportes ad-hoc.
Gran variedad de grficos.
Permite exportar los informes en diferentes formatos: archivo de texto,
MS Word, MS Excel, PDF, Adobe Flash, HTML.
Acceso web (compatible con los principales navegadores) y mvil
(Android, iOS, Windows 8)
Permite realizar anlisis de escenarios de manera simple, pero requiere
que el usuario tenga experiencia con la herramienta.
Funcionalidad bsica para datamining. Incluye diversos modelos
predictivos.
Seguridad: distintos niveles de acceso a la informacin (por reas de
informacin, por reportes, etc.) tanto para lectura como para edicin de
reportes. Compatible con LDAP.
La versin actual no permite utilizar distintas fuentes de datos para un
mismo reporte.
El proveedor es partner del fabricante de la herramienta, desde hace 6
aos. Tiene experiencia en latinoamrica, en diversos proyectos, pero
slo 2 de ellos en el rubro de alimentos.
La empresa cuenta con un equipo de 10 consultores en el pas, con
distintos niveles de seniority.
El fabricante actualiza al menos una vez por ao la aplicacin con
mejoras y nuevas funcionalidades. Adems, publican frecuentemente
versiones con correcciones de errores.
De acuerdo a lo visto en las demostraciones, los futuros usuarios
coinciden en que la interfaz resulta muy amigable. Sin embargo, el
mdulo de administracin, posee gran cantidad de opciones de
configuracin, por lo que su uso puede resultar complejo al inicio.
Un colega de Jos II, que utiliza la herramienta en su empresa hace
tiempo, le coment que la curva de aprendizaje es corta.
El sitio web de documentacin de la herramienta posee manuales
actualizados en varios idiomas (incluye espaol), as como un foro que,
segn lo que Marcelo pudo ver, tiene mucha participacin de los
usuarios.
El proveedor garantiza una primera respuesta dentro de las 2 horas para
incidentes crticos en el ambiente de produccin, y 36 hs para el resto de
los casos.
Compatible con el software de base utilizado en AliMun.
La implementacin incluye:
o Definicin del modelo de datos del datawarehouse y creacin de
cubos.
Pgina 33 de 45

o Creacin de los procesos de ETL

o Configuracin del modelo de datos en la herramienta y creacin
de 10 reportes bsicos
o Horas de capacitacin
Tiempo de implementacin: 2 meses
Costo de implementacin (incluye tambin hardware y software
necesarios, y soporte y actualizaciones durante el primer ao): $
800.000
Mantenimiento anual y soporte: $80.000
Opcin 2 Software gratuito, de cdigo abierto
Posibilidad de creacin de varios tipos de reportes y tableros de

comando. Posee plantillas para facilitar el diseo.
Permite navegar la informacin de un reporte en diferentes direcciones
(drill down, drill across), as como agregar nuevos indicadores y filtros a
un reporte, en tiempo real, por lo que es posible realizar reportes ad-hoc.
Poca variedad de grficos.
Permite exportar los informes en diferentes formatos: texto, MS Word,
MS Excel y PDF.
Acceso web (compatible con los principales navegadores) y mvil (slo
Android)
La funcionalidad de anlisis de escenarios es limitada.
Seguridad: distintos niveles de acceso a la informacin (por reas de
informacin, por reportes, etc.) tanto para lectura como para edicin de
reportes. No compatible con LDAP.
Permite conectarse a diferentes fuentes de datos para un mismo reporte.
El proveedor es una consultora de sistemas que implementa la
herramienta desde hace 4 aos. Tiene experiencia en Latinoamrica, y
realiz 3 proyectos en el rubro de alimentos.
La empresa cuenta con un equipo de 5 consultores en el pas, todos con
amplia experiencia.
El fabricante no posee una poltica establecida de periodicidad en las
actualizaciones, y el proveedor desconoce cules sern las prximas
mejoras. Se publican frecuentemente versiones con correcciones de
errores o pequeas mejoras.
De acuerdo a lo visto en las demostraciones, los futuros usuarios
coinciden en que la interfaz resulta muy amigable. El mdulo de
administracin y la aplicacin de actualizaciones, son muy simples.
El sitio web de documentacin de la herramienta posee manuales slo
en ingls. La participacin de usuarios en los foros es poco frecuente.
Pgina 34 de 45

El proveedor garantiza una primera respuesta a los casos, dentro de las

48 hs.
Compatible con el software de base utilizado en AliMun.
La implementacin incluye:
o Definicin del modelo de datos del datawarehouse y creacin de
cubos.
o Creacin de los procesos de ETL
o Configuracin del modelo de datos en la herramienta y creacin
de 10 reportes bsicos
o Horas de capacitacin
Tiempo de implementacin: 1 mes
Si bien la licencia de la herramienta es gratuita, se debe abonar un costo
anual para obtener soporte.
Costo de implementacin (incluye tambin hardware y software
necesarios, y soporte durante el primer ao): $ 600.000
Soporte anual: $50.000
Se Pide Seleccin de Alternativas

a) Elija una alternativa a recomendar a la direccin, utilizando las
herramientas estudiadas de seleccin de software, y tomando como
base los tems definidos en la actividad 2.1 (si lo cree conveniente,
agregue nuevos tems o agrpelos)
b) La alternativa seleccionada, satisface todas las necesidades
planteadas? qu ocurre con aquellas funcionalidades no
solicitadas? Indique cmo resolvera esta brecha, y determine si
correspondera incluirla en el proyecto.
Pgina 35 de 45

4. VESEL S.A.
Autor: Pablo Gil
VESEL S.A. es una empresa argentina dedicada a la fabricacin y venta de

autopartes, que suministra sus productos a distribuidores y mayoristas a nivel
nacional, y que adems exporta parte de su produccin a los pases del
Mercosur. El ltimo ao el porcentaje de ventas al exterior se ha incrementado
hasta llegar al 25 % de la produccin, y debido a las condiciones
macroeconmicas vigentes se planea mantener y elevar dicho porcentaje.
Histricamente, si bien ha ofrecido a sus clientes productos de calidad, VESEL
no se ha caracterizado por ser una organizacin muy abocada al control interno
en ninguna de sus reas (incluida el rea de Sistemas).
En los ltimos aos se han producido algunos cambios en el directorio y en la
gerencia, y una consecuencia de dichos cambios ha sido contratar a una de las
ms importantes firmas de auditora del pas para el presente ejercicio
(anteriormente la auditoria era realizada por un estudio contable de pequea
estructura, siendo el socio principal compaero de la universidad de Marcelo
Menndez, Gerente de Administracin y Finanzas).
Como parte de la revisin de estados contables de VESEL, la firma contratada
tambin auditar al rea de Sistemas y el control interno en sus diferentes
procesos de negocio.
El rea de Sistemas se encuentra dirigida por Andrea Sunches, y est
compuesta por 30 personas las cuales se organizan en los siguientes sectores
o gerencias:
Desarrollo (la programacin de aplicaciones basadas en tecnologa web
se encuentra tercerizada en la empresa Adventure, consultora nacional
dedicada a las tecnologas de la informacin)
Operaciones
Infraestructura y telecomunicaciones
Administracin de Bases de Datos
En VESEL S.A. no existe un plan formal de sistemas, las modificaciones a las
aplicaciones o los nuevos desarrollos se realizan de la siguiente manera:
El rea usuaria presenta un requerimiento va e-mail al rea de
desarrollo.
Pgina 36 de 45

Si el requerimiento presentado requiere modificaciones al sistema

Interparte1 o requiere el desarrollo de una nueva aplicacin, un analista
funcional disea las especificaciones correspondientes y las entrega a
los programadores, quienes al finalizar la construccin (haciendo
participar al sector de administracin de bases de datos si es necesario
crear o modificar archivos) comunican al analista funcional que puede
ejecutarse la prueba de sistema. El analista funcional realiza las pruebas
pertinentes en el ambiente de desarrollo y de no existir errores
implementa los cambios (archivos y programas) en el ambiente de
produccin.
Si el requerimiento presentado requiere modificaciones al sistema WOrder, el procedimiento es similar al descrito, con la diferencia que la
programacin del sistema se encuentra tercerizada. En ocasiones los
desarrolladores de Adventure no cumplen en tiempo y forma con los
pedidos de los analistas funcionales. Cabe mencionar que existe un
contrato entre VESEL y Adventure pero el mismo es general y no
contempla tiempos de entrega ante peticiones de modificacin.
En el centro de cmputos se encuentran los servidores de aplicacin, base de
datos, e-mail y el proxy server. Los administradores de los sistemas operativos
y de bases de datos pertenecen al rea de sistemas. Tambin posee perfil de
administrador del sistema operativo del servidor de Interparte Gustavo Grand,
quien actualmente se desempea como jefe de Contabilidad pero que
anteriormente trabaj en el rea de Infraestructura y Telecomunicaciones.
Se realizan back-up diarios e incrementales en un servidor de back-up y
semanalmente se realiza un back-up total en cinta que es almacenado en el
centro de cmputos. El ltimo ao fue necesario restaurar un archivo de
facturacin y ciertos datos impositivos no pudieron ser recuperados, por lo cual
fue necesario recalcularlos y generarlos nuevamente.
El rea de Operaciones es la encargada de monitorear la ejecucin de los
procesos batch en los sistemas y reprocesarlos en caso de existir algn error.
En varias oportunidades los usuarios del rea de ventas han comunicado al
rea de sistemas que los pedidos de clientes ingresados en W-Order no fueron
reflejados en Interparte o que fueron reflejados por duplicado o triplicado.
Los sistemas de informacin principales administrados por el rea (tambin existen aplicaciones
desarrolladas y mantenidas por las propias reas usuarias) son los siguientes:
Interparte: sistema de gestin integral que incluye todos los mdulos que soportan los
procesos productivos y administrativos. Construido en lenguaje C++ sobre base de datos
SQL Server 2000
W-Order: sistema de gestin de pedidos de clientes. Permite capturar pedidos on-line debido a que cada
cliente se encuentra conectado a la extranet de VESEL. Los clientes conectados poseen un ID de usuario
para el sistema. Una vez que los pedidos son capturados los mismos son transmitidos a Interparte para
su procesamiento.
Pgina 37 de 45

El sistema Interparte consta de los siguientes mdulos:

Compras
Finanzas
RRHH
Contabilidad
Facturacin
Cobranzas
Costos
Activo Fijo
Planificacin de produccin
El ltimo ao se ha recibido un nmero importante de reclamos de clientes
locales que aseguran haber realizado pagos pero que han recibido llamadas de
gestin de cobranzas por parte de analistas de la compaa. Las cobranzas
pueden ingresarse a Interparte a travs de una interface por los principales
sitios webs bancarios o manualmente, ya que algunos clientes efectan pagos
con cheque.
En ciertas operaciones de ventas a crdito se ha sobrepasado el lmite
establecido para el cliente, no quedando bloqueadas en Interparte, aun cuando
el procedimiento crediticio de la compaa as lo indica.
Respecto de los clientes de exportacin, con los cuales se opera
principalmente a travs de cartas de crdito, se han presentado casos de
incobrabilidad porque el cliente no ha cumplido con su obligacin de pago hacia
VESEL S.A.
El procedimiento de compras de la compaa indica que toda orden de compra
emitida debe contar con una requisicin del rea solicitante, previamente
autorizada por un nivel determinado segn el monto de la compra. Sin embargo
existen rdenes de compra que no poseen una requisicin asociada (no es un
campo de ingreso obligatorio en Interparte) y rdenes de compra por montos
elevados que no han sido aprobadas por los niveles correspondientes. Las
facturas de los proveedores son recibidas por el rea de Administracin y son
ingresadas al sistema y liberadas para su pago verificando nicamente que
exista una orden de compra recibida y no cerrada para el proveedor (no existen
en VESEL rdenes de compra abiertas o contratos de abastecimiento).
En el mdulo de Activo Fijo existen bienes que continan amortizndose (ej.
Maquinarias) pero que en la planta de produccin ya han sido desechados y no
se encuentran en uso.
El rea de Contabilidad ha detectado algunas operaciones en ciertas cuentas
que pertenecen a perodos contables no abiertos.
Pgina 38 de 45

En este contexto la nueva firma de auditoria contratada debe realizar su

evaluacin.
Pgina 39 de 45

Actividad 1 Actividades de control del rea de sistemas

Tema
Autor
6.2
Riesgos rea de Sistemas
Pablo Gil
Se pide Elaboracin de Matriz de Riesgo e Identificar Controles:

1. Como parte del nuevo equipo de auditoria de VESEL S.A., debe detectar
los principales riesgos a los que est expuesta el rea de sistemas de la
organizacin y determinar qu controles actualmente se estn
realizando para mitigar dichos riesgos.
2. Identifique los controles cuyo diseo no es adecuado o aquellos casos
en los que es necesario implementar controles adicionales y describa
cmo deberan ser dichos controles.
Pgina 40 de 45

Actividad 4 Control de Aplicaciones

Tema
Autores
Correccin
Agradecimientos
6.2.2
Procesos de Cobranzas
Germn Grin, Enrique Dondero y Cecilia Oriolo
Pablo Corral y Marcelo Gonzalez Bosque
Ezequiel Maravankin y Elina Schneider
Finalizadas las auditoras al rea de sistemas, VESEL le encarga al equipo

auditor hacer foco sobre el Mdulo de Cobranzas del Sistema Interparte.
El mdulo de cobranzas hace uso de datos que fueron ingresados al Sistema
Interparte por medio de otros mdulos. Para poder gestionar una cobranza se
requiere que la factura est asignada a un cliente vlido en el sistema. Se han
presentado quejas por parte de usuarios, que al ingresar el nmero
correspondiente de un cliente (para crear una determinada factura), el sistema
ha dado como resultado cliente inexistente, o no ha trado los datos del mismo
cuando los usuarios reconocan que el cliente exista y posea facturas
registradas.
Cada cliente debe estar sujeto a una pre-aprobacin de sus condiciones de
pago. Dependiendo su capacidad de crdito, el Sistema permite o no, la
posibilidad de que el cliente pague en efectivo, cuenta corriente o cheque
diferido. Por el momento no se permiten transacciones con los clientes con
tarjeta de crdito, aunque el mdulo de cobranzas est preparado para
realizarlas. En una prueba de aplicacin, ha sido posible registrar un pago con
tarjeta de crdito.
En otra prueba de aplicacin, tambin fue posible cargar una forma de pago no
vlida para un cliente. Es decir, el cliente estaba pre-aprobado para efectuar
pagos en efectivo o cuenta corriente pero en la prueba pudo registrarse un
cheque con pago diferido. Lo mismo ha sucedido con clientes que poseen
condicin de pago slo efectivo, a los cules se les ha podido asociar pagos en
cuenta corriente.
Se verific la existencia en el sistema actual de ingreso de pagos en cuenta
corriente con fechas posteriores al registro de la transaccin, para lo cual, se
identifican inconsistencias entre las fechas de ingreso del pago y la fecha de
dicha autorizacin. Tambin se manifiestan inconsistencias en los valores de
los pagos, ya que se han encontrado pagos con valor negativo ingresados al
sistema. Adems, se pueden detectar errores en el ingreso de pagos con
decimales o en moneda extranjera.
No todas las personas que conforman el rea de cobranzas tienen perfil para
operar en el mdulo de esta rea. El movimiento del personal y la falta de
Pgina 41 de 45

actualizacin de los perfiles, llev a que las personas incorporadas

recientemente a Vesel, deban utilizar el perfil de sus compaeros para poder
realizar sus tareas. Asimismo han existido casos en los cules usuarios han
podido ingresar al mdulo con contraseas anteriores (que difieren de la
actual).
Lo anteriormente detallado indica que la situacin del mdulo de cobranzas
para el resguardo y disponibilidad de la informacin no es muy distinta al resto
del sistema. Respecto a los Back up a realizar, adems de los back up diarios,
los procedimientos indican que debe ser realizado un back up anual
correspondiente al cierre contable de cada perodo. Sin embargo, miembros del
Departamento de Cobranza han necesitado restaurar informacin contable de
ejercicios pasados para obtener los cierres correspondientes a Previsiones
para Deudores Incobrables, y slo han podido obtener los datos
correspondientes al ltimo ejercicio.
En un perodo anterior se contrat a un auditor para que realice la matriz de
controles de la aplicacin ver anexo -; ahora se le pide a nuevo equipo de
auditora que finalice esa construccin de matriz de controles. Esa matriz est
compuesta por los objetivos de control, el tratamiento actual del sistema, el
tratamiento que debera hacer el sistema, las pruebas necesarias, los
inconvenientes de las mismas, los cambios propuestos para el sistema y los
criterios de cada uno de estos tems.
Pgina 42 de 45

Se Pide Completar Matriz:

A continuacin se presenta la matriz de controles de aplicacin, la cual, se encuentra
incompleta. Se le solicita a Ud. completar la matriz segn corresponda.
N
Objetivo de
Control
Detalle del
control
Tratamiento
en el Sistema
ACTUAL
Existencia y
calidad de las
validaciones
Control de
Procesamiento
Cambio
propuesto para
el sistema
CriterioDimensin
Consistencia en la
Base de Datos de
clientes
Revisin y
correccin del
software, en el
procesamiento de
formas de pago
en el cliente, para
la
correspondencia
con las
condiciones del
mismo.
Integridad
Ingresar
cdigo de
cliente
inexistente.
Ingresar
pagos con
nmeros
decimales.
El sistema
acepta y
rechaza
transacciones
segn su valor.
Utilizar las
credenciales
actuales
(usuario y
contrasea) de
cada usuario
para habilitar o
no su acceso al
sistema.
4
Restriccin
hacia personas
que necesiten el
acceso
Restriccin de
Acceso
Inconvenientes
del control
actual
El sistema
verifica e
informa la
condicin de
pago del cliente
imposibilitando
el ingreso de un
pago que no se
corresponda
con las
condiciones
ingresadas en el
sistema.
Control de
Entrada de
transacciones
ingresadas
Pruebas a
Realizar
Ingresar
cdigo de
cliente
existente.
Se informa que
el sistema
requiere un
cliente valido.
Tratamiento
deseado
Nuevos
usuarios no
pueden operar
en el mdulo
por falta de
perfil,
utilizando el
usuario de
otros.
Usuarios han
podido ingresar
con contraseas
no actualizadas.
El sistema no
habilita las
funcionalidades no reconoce el
perfil.
Pgina 43 de 45
Accesibilidad Confidencialidad

Backup del
software de
aplicacin y de
archivos
maestros
Contar con
respaldo y
recuperacin
de
informacin
anterior a la
vigente en el
sistema
Poder acceder
al back up de
cada periodo
contable y que
el sistema
informe el
estado del
mismo.
Pgina 44 de 45
Realizacin de
Back up
peridicos
(mensuales y
anuales) Alerta
por sistema si los
mismos no se
realizan.

a) nidos.
Pgina 45 de 45

GuiaEnunciadosAlumnos Vrecortada

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

GuiaEnunciadosAlumnos Vrecortada

Încărcat de

Drepturi de autor:

Formate disponibile

Gua de Ejercicios Prcticos

Ctedra: Guillermo Tricoci

Universidad de Buenos Aires

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

DAXTOR SA: .............................................................................................. 5

Actividad 3 Anlisis y Diseo Funcional ...................................................... 9

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

La primer dificultad fue la de obtener fondos ms all de sus ahorros y

Gua de Ejercicios Prcticos - Enunciados

proveedores as como la estimacin de compras necesarias a efectos de lograr

Gua de Ejercicios Prcticos - Enunciados

La liquidacin de sueldos y de comisiones la realiza el estudio del Dr.

Gua de Ejercicios Prcticos - Enunciados

Actividad 3 Anlisis y Diseo Funcional

En Daxtor S.A., empresa dedicada a la distribucin de artculos de librera, a

Gua de Ejercicios Prcticos - Enunciados

asentado en el LC y que el total de dichos valores y los comprobantes de

Gua de Ejercicios Prcticos - Enunciados

Considerar el diagrama de contexto y el modelo de comportamiento de la

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

Actividad 9 Modelado de Datos

Durante los ltimos meses Daxtor ha experimentado un gran crecimiento en su

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

Clientes por Volumen

Diagrama de Flujo de Datos

Se Pide Anlisis de Datos:

Gua de Ejercicios Prcticos - Enunciados

3. AliMun - Alimentos al Mundo S.A.

AliMun (Alimentos al Mundo S.A.) es una empresa de capitales Argentinos

Mar del Plata I: Conservas de pescado

Gua de Ejercicios Prcticos - Enunciados

Jos Aragn II comienzo a trabajar con su padre en 1980, cuando todava

Gua de Ejercicios Prcticos - Enunciados

Montevideo I: planillas de clculo y un enlatado de contabilidad local.

Gua de Ejercicios Prcticos - Enunciados

Unificacin de produccin por unidades de negocios:

Por otro lado, defini que durante el transcurso de la unificacin administrativa,

Gua de Ejercicios Prcticos - Enunciados

Actividad 1 Gestin de Proyectos

Con la premisa de iniciar el camino hacia la integracin, unificacin y

Gua de Ejercicios Prcticos - Enunciados

El proceso se divide en tres tipos:

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

Actividad 3 Evaluacin Econmica de Proyectos

Tras la unificacin exitosa de los procesos de compras en todas sus plantas, y

Gua de Ejercicios Prcticos - Enunciados

Gua de Ejercicios Prcticos - Enunciados

Jos II tambin le consult a Marcelo acerca de la lentitud de los sistemas

Gua de Ejercicios Prcticos - Enunciados

una nueva base de datos (hardware, y software de administracin)

Gua de Ejercicios Prcticos - Enunciados

Curso reporting avanzado (creacin de mtricas complejas,

Gua de Ejercicios Prcticos - Enunciados

Consultor Junior: 320 horas Valor hora: $180

Gua de Ejercicios Prcticos - Enunciados

Para la estimacin de los costos del personal interno, Jose II solicit la

Gua de Ejercicios Prcticos - Enunciados