5602 solucion cpa

Tecnología de la InformaciónGuía de Trabajos Prácticos


Universidad de Buenos AiresFacultad de Ciencias Económicas

CASO CPA


Página 1 de 26


INDICE

ACTIVIDADESActividad 1 – Selección de Software (Guillermo Tricoci – Pablo Corral) 8Actividad 2 – Análisis de Alternativas de Solución (Guillermo Tricoci – Pablo Corral) 8Actividad 3 – Implementación de Software (Guillermo Tricoci – Pablo Corral) 9Actividad 4 – DER Aplicación para aprobación crediticia (Pablo Gil) 10

SOLUCION ACTIVIDADESSolución Actividad 1 – Selección de Software (Guillermo Tricoci – Pablo Corral) 11Solución Actividad 2 – Análisis de Alternativas de Solución (Guillermo Tricoci – Pablo Corral) 13Solución Actividad 3 – Implementación de Software (Guillermo Tricoci – Pablo Corral) 14Solución Actividad 4 – DER Aplicación para aprobación crediticia 26


Página 2 de 26


CPA S.A. - Enunciado del Caso (Guillermo Tricoci – Pablo Corral)

CPA S.A. (Caños Plásticos Argentinos S.A.) es una empresa familiar nacional, productora caños plásticos para la industria de la construcción con 25 años de fuerte presencia en el mercado. En el ejercicio cerrado al 31/12/2006, la facturación ascendía a USD 5.000.000, contaba con una dotación de 80 empleados, 2 Plantas productoras, una en Pilar y otra en San Luis. Su Administración Central se encuentra en Pilar. Posee una importante red de vendedores propios en todo el país y es la tercera a nivel nacional en marketshare. Si bien es una empresa nacional, el 60% de su capital accionario está en manos de la familia Gonzalez (sus dueños fundadores) y el 40% restante en manos de un fondo de inversión norteamericano. La operación de venta fue realizada en plena crisis del 2001 debido a un fuerte endeudamiento que tenía la empresa. A partir de ese momento, y a instancia de los inversores de Estados Unidos, la empresa realiza una fuerte inversión en tecnología de la información, implementando un paquete de gestión integrada (al estilo Oracle Financials) para administrar la gestión de compras, inventarios, pagos, cobranzas, ventas, distribución y contabilidad. Dicha inversión fue completamente desembolsada por los inversores Americanos. Sin embargo, conservaron el sistema de producción, que había sido desarrollado in-house por el hijo mayor de la familia Gonzalez, el Ingeniero en Informática Pedro Gonzalez, quién a su vez se desempeña como gerente de sistemas.

La compañía inversora hizo fuertes intentos, además, de modernizar y profesionalizar la administración de CPA. Sin embargo, contó con fuerte resistencia de los Gonzalez, logrando sólo imponer el gerente de administración y finanzas. Al final del enunciado se detalla el organigrama actual de la compañía: Ana Gonzalez es la hija de Javier Gonzalez y es Licenciada en Recursos Humanos. Leonardo Russo es sobrino de Javier Gonzalez y es Ingeniero Industrial. Mariano Avellaneda es el esposo de Ana y es Licenciado en Administración. Finalmente, Brent Russ es norteamericano y se instaló en Buenos Aires en Diciembre del 2003.

En Enero del 2006 desembarca en Argentina la principal compañía productora de caños plásticos de Brasil. Luego de una fuerte y agresiva campaña comercial y de algunas adquisiciones de empresas locales logró desplazar a CPA del segundo lugar que tenía y ubicarla en el tercero actual. La extrema agresividad desplegada por los recién llegados han puesto en alerta a los norteamericanos, quiénes han comenzado a hacer gestiones para obtener la mayoría accionaría e introducir cambios sustanciales en la empresa y recuperar el puesto perdido. La familia Gonzalez se resiste fuertemente a ceder el control accionario y le ha encargado al gerente comercial que desarrolle un plan agresivo para recuperar las posiciones perdidas.

Luego de un mes de análisis de la estructura de la empresa, el mercado y de las estrategias empleadas por la competencia, Mariano descubre que su proceso de toma de decisiones no siempre cuenta con la información más completa.

Sus clientes tradicionales le cuentan que no se trata de calidad de productos (CPA tenía uno de los mejores departamentos de control de calidad del país), sino que la competencia les satisface sus necesidades de forma más rápida, con tiempos de entregas más cortos, sin que haga falta demasiadas devoluciones de mercadería de baja calidad, qué en muchos casos, hasta se adelantan a sus necesidades. Además, la competencia otorga mejores descuentos en función de volúmenes o a través de distintos paquetes (combos) que fueron armando a medida de cada cliente. La competencia demostraba conocer perfectamente el historial de compras de cada cliente, no importaba que el pedido fuera hecho en Buenos Aires o el interior, ni si el pedido era remitido a la casa central o a cualquiera de los distribuidores autorizados. Era como si toda la red de distribución accediera a una única fuente de información de cada cliente.

Finalmente, los clientes contaron que el manejo de reclamos era impecable, las 24 hs. y con operadores que conocían a la perfección la historia de compras del cliente y con tiempos de resolución de los incidentes no mayor a 48 hs.


Página 3 de 26


La conclusión era que la competencia se había posicionado en el segundo lugar no por tener una mercadería de mayor calidad, sino que había montando un fabuloso sistema de servicios y fidelización de clientes (CRM – Customer Relationship Management).

Ante el informe de Mariano, Javier Gonzalez consulta con Brent. Brent, que es muy afecto a las inversiones en tecnología de la información, le sugiere que implemente el paquete CRM que viene en conjunto con el paquete de gestión integrado que habían instalado. Javier es muy desconfiado de las soluciones enlatadas y le encarga a Pedro que realice una evaluación para determinar la mejor opción.

Luego de un mes de análisis Pedro le acerca a Javier el siguiente informe:

Opción 1: Instalación del componente CRM de paquete de gestión actual

Funcionalidad: Centro de atención de llamadas y reclamos Centro de atención de reclamos por Internet Base de datos centralizada de cliente y pedidos Comercio electrónico Ventas móviles Integración total con el sistema actual, pero con el requerimiento de un hardware

adicional para albergar una base de datos paralela (que se alimenta on line de la base del paquete de gestión.

Facilidad de operación remota y con varias sucursales Requiere que se instale el software cliente del producto en cada máquina. Facilidad para operar a través de Internet Facilidad para creación de perfiles de usuarios varios con seguridad en la página Web.

Flexibilidad: Configuración sencilla pero que requiere de algo de desarrollo de código para ajustarse a las particularidades locales de Argentina. Escalabilidad: TotalHardware adicional requerido:

Servidor para el nuevo motor de la aplicación y la base de datos Handhelds para ventas móviles con Windows Vista Aumentar la capacidad de disco de las PC actuales Actualizar el sistema operativo a Windows Vista

Integración y facilidad de uso: El sistema requiere de entrenamiento ya que es muy completo pero con múltiples pantallas y funciones.Estimación de proyecto:

Tiempo de análisis: 1 mes Tiempo de diseño: 1 mes Tiempo de construcción: 2 meses Tiempo de pruebas: 1 mes Tiempo de capacitación: 1 mes Tiempo de Migración y puesta en marcha: 1 mes Consultores requeridos: 2 consultores a tiempo completo y un gerente a tiempo parcial Usuarios participantes requeridos: 2 a tiempo completo, 1 gerente de proyecto y 1

usuario a tiempo parcial Duración total: 7

Costo: Licencias: 15 licencias a USD 5000 cada una. $ 232.500 Hardware adicional: USD 100.000. $310.000 Consultores: 2 consultores: $ 70 la hora. 160 hs mensuales x 7 meses. 1 gerente a 40

hs mensuales x 7 meses. $ 176.400 Usuarios participantes: Sueldo mensual de usuario tiempo completo $4000 cada uno.

Sueldo del gerente de proyecto (gerente de sistemas) $10.000. $140.000 Otros gastos asociados: $ 10.000 Costo total: $ 868.900


Página 4 de 26


Opción 2: Desarrollo de un software in-house con interfase al paquete de gestión actual

Funcionalidad: Centro de atención de llamadas y reclamos Centro de atención de reclamos por Internet Base de datos centralizada de cliente y pedidos Comercio electrónico Ventas móviles Integración total con el sistema actual con interfases. Se creará una base de datos

paralela integrada de clientes Facilidad de operación remota y con varias sucursales Facilidad para operar a través de Internet La seguridad es básica.

Flexibilidad: El sistema será desarrollado íntegramente en forma local, pero requiere de importante programación adicional cada vez que se quiera modificar algo. A su vez, es necesario construir interfases con el paquete de gestión actual. Dichas interfaces deberán se modificadas cada vez que se realice mantenimiento en el paquete de gestión actual o se realicen migraciones de versión. Escalabilidad: Requiere de importante programación para realizar mejoras y escalar el producto. La ventaja es que el conocimiento de desarrollo permanece en la compañíaHardware adicional requerido: Se requiere aumentar la capacidad de disco del servidor y las PC. No requiere de cambios de software ni de handheld nuevas.Integración y facilidad de uso: El software será altamente integrado y diseñado exclusivamente de acuerdo a las necesidades de los usuarios. Será muy intuitivo y fácil de manejar.Estimación de proyecto:

Tiempo de análisis: 3 meses Tiempo de diseño: 4 meses Tiempo de construcción: 3 meses Tiempo de pruebas: 1 mes Tiempo de capacitación: 15 días Tiempo de Migración y puesta en marcha: 15 días Programadores requeridos: 2 a tiempo completo Usuarios participantes requeridos: 2 a tiempo completo Programadores internos requeridos: 2 a tiempo completo Gerente de proyectos: 1 a tiempo parcial Duración total: 12 meses

Costo: Licencias: $0 Hardware adicional: USD 5000. $ 15.500 Programadores: 2 $ 35 la hora. 160 hs mensuales x 7 meses. $ 134.400 Usuarios participantes: Sueldo mensual de usuario tiempo completo $4000 cada uno.

$96.000 Programadores internos: Sueldo $ 5500 cada uno. $132.000 Gerente de proyectos: Gerente de Sistemas a tiempo parcial 40 hs mensuales. $30.000 Otros gastos asociados: $ 10.000 Costo total: $ 417.900


Página 5 de 26


Opción 3: Adquisición de un software CRM local con interfase al paquete de gestión actual

Funcionalidad: Centro de atención de llamadas y reclamos Centro de atención de reclamos por Internet Base de datos centralizada de cliente y pedidos Comercio electrónico Ventas móviles Integración total con el sistema actual, con interfases. Se requiere de un hardware

adicional para albergar una base de datos paralela (que se alimenta on line de la base del paquete de gestión.)

Facilidad de operación remota y con varias sucursales Facilidad para operar a través de Internet Facilidad para creación de perfiles de usuarios varios con seguridad en la página Web.

Flexibilidad: El sistema es altamente configurable y está probado localmente. A su vez, es necesario construir interfases con el paquete de gestión actual. Dichas interfaces deberán se modificadas cada vez que se realice mantenimiento en el paquete de gestión actual o se realicen migraciones de versión.Escalabilidad: TotalHardware adicional requerido:

Servidor para el nuevo motor de la aplicación y la base de datos Aumentar la capacidad de disco de las PC actuales

Integración y facilidad de uso: El sistema esta basado fuertemente en Internet y es muy intuitivo y fácil de usarEstimación de proyecto:

Tiempo de análisis: 1 mes Tiempo de diseño: 1 mes Tiempo de construcción: 1 meses Tiempo de pruebas: 15 días Tiempo de capacitación: 15 días Tiempo de Migración y puesta en marcha: 1 mes Consultores requeridos: 2 consultores a tiempo completo y un gerente a tiempo parcial Usuarios participantes requeridos: 2 a tiempo completo, 1 gerente de proyecto y 1

usuario a tiempo parcial Duración total: 5

Costo: Licencias: 15 licencias a $ 20.000 cada una. $ 300.000 Hardware adicional: USD 100.000. $232.500 Consultores: 2 consultores: $ 100 la hora. 160 hs mensuales x 5 meses. 1 gerente

$150 a 40 hs mensuales x 5 meses. $ 190.000 Usuarios participantes: Sueldo mensual de usuario tiempo completo $4000 cada uno.

Sueldo del gerente de proyecto (gerente de sistemas) $10.000. $100.000 Otros gastos asociados: $ 10.000 Costo total: $ 832.500


Página 6 de 26


A continuación se detalla un cuadro comparativo de costos:

Conceptos Opción A Opción B Opción C

Licencias $ 232.500,00 $ - $ 300.000,00

Hardware $ 310.000,00 $ 15.500,00 $ 232.500,00

Consultores/programadores $ 156.800,00 $ 134.400,00 $ 160.000,00

Gerente Consultoría $ 19.600,00 $ - $ 30.000,00

Usuarios Participantes $ 70.000,00 $ 96.000,00 $ 50.000,00

Programadores Internos $ - $ 132.000,00 $ -

Gerente Proyecto Interno $ 70.000,00 $ 30.000,00 $ 50.000,00

Otros Gastos $ 10.000,00 $ 10.000,00 $ 10.000,00

Total $ 868.900,00 $ 417.900,00 $ 832.500,00

Con el informe en la mano, Javier y Brent deberán seleccionar la opción a seguir, considerando que la inversión será costeada en un 50% por la compañía inversora y el 50% restante por CPA.

Modalidad de Trabajo: Cada equipo deberá resolver el caso en conjunto y traer a la clase la resolución propuesta. Durante la clase, los equipos expondrán sus propuestas y se organizará un debate entre todos para obtener una conclusión.

Organigrama actual de CPA S.A.


Página 7 de 26

Javier GonzalezDirector y CEO

Pedro GonzalezCIO

(Gerente de Sistemas)

Ana GonzalezGerente de

Recursos Humanos

Leonardo RussoGerente de Producción

Mariano Avellaneda Gerente Comercial

Brent RussGerente de

Administración y Finanzas


Actividad 1 – Selección de Software (Guillermo Tricoci – Pablo Corral)

Se pide:

1. Analice el caso planteado y determine si la solución propuesta puede dar los resultados esperados (logra recuperar el 2° puesto en el mercado) o si deberían analizarse otras variables además del desarrollo de un componente de software.

2. Suponiendo que la solución planteada por la gerencia al problema de participación en el mercado se resolviese con el desarrollo de un software de CRM, determine:

a. Cuál es la alternativa más conveniente, justificándola (precio, plazos de ejecución, escalabilidad, mantenimiento, etc.). Para este análisis utilice todas las herramientas de la metodología de selección de software.

b. ¿La información analizada por Pedro, es suficiente para decidirse por alguna de las tres alternativas? ¿Qué otros elementos hubiera tenido en cuenta?

c. Se requieren inversiones adicionales en otros áreas / proyectos para lograr los objetivos. ¿De ser así, defina cuales y como calcularía las mismas? Si considera que no se necesitan inversiones adicionales, fundamente está opinión.

Actividad 2 – Análisis de Alternativas de Solución (Guillermo Tricoci – Pablo Corral)

1. Luego de haber seleccionado una de las alternativas, se presenta al resto de los gerentes para su aprobación. Al leer el plan de acción seleccionado, Mariano se opone, argumentando que en realidad, el problema no se resolverá con la construcción de un software.

Se pide:

Analice nuevamente el caso y explique por qué Mariano se opone a la decisión de desarrollar el mencionado software.

2. Luego de haber seleccionado una de las alternativas, se presenta al resto de los gerentes para su aprobación. Al leer el plan de acción seleccionado, Brent se opone, aduciendo que no tiene argumentos suficientes que le indique cuál es el retorno sobre la inversión esperado (ROI).

Se pide:

Analice nuevamente el caso y determine que información adicional requiere Brent para el cálculo del ROI.


Página 8 de 26


Actividad 3 – Implementación de Software (Guillermo Tricoci – Pablo Corral)

1. Seleccione una de las alternativas y desarrolle un plan detallado de implementación, indicando:

Entregables de cada etapa, Información a incluir en cada documento Actividades a realizar en cada fase, Hitos significativos de cada etapa, Riesgos existentes en cada etapa y sus mitigadores Otros componentes presentes en un plan de desarrollo de software.

2. Al comenzar la etapa de pruebas, uno de los usuarios claves identifica 5 nuevas funcionalidades que no estaban contempladas en el plan original. Agregar cada funcionalidad tiene las siguientes implicancias

Tablero de comandoEsta funcionalidad fue considerada deseable por el equipo de proyecto, aunque los usuario claves la consideran clave para el funcionamiento de la nueva estrategia de CRM de la compañía. Incluirla demandaría

o En el caso de la instalación del componente CRM de paquete de gestión actual: 2 días de análisis, 3 de diseño, 3 de desarrollo y 5 de pruebas

o En el caso de desarrollo de un software in-house: 5 días de análisis, 5 de diseño, 10 de desarrollo y 5 de pruebas.

o En el caso de la adquisición de un software CRM local: 2 días de análisis, 5 de diseño, 7 de desarrollo y 5 de pruebas

Actualización de la base de datos de clientes en el sistema actual, completando los datos requeridos por el nuevo sistema y que el anterior no registraba

Al hacer las pruebas integrales, se detectó que los datos de clientes del sistema actual no estaban actualizados. Se plantean dos alternativas:

o Actualizar los datos antes de la migración: 10 días de actualización y 5 días de nuevas pruebas.

o No actualizar los datos y corregirlos una vez que el sistema esté productivo con el riesgo grande de errores que esto implica.

Actualización del historial del cliente para la migración de datos históricos.Luego de las pruebas los usuarios claves se dieron cuenta que no había datos históricos en el sistema, sobre devoluciones y sobre las compras de los clientes. Es por ello que solicitan actualizar estos datos antes de la salida en vivo. Esto implica desarrollar una nueva interfase para cargar datos históricos:

o En el caso de la instalación del componente CRM de paquete de gestión actual: 1 día de análisis, 2 de diseño, 3 de desarrollo y 5 de pruebas



Re configuración de la funcionalidad de cálculo de descuentos.Al realizar las pruebas, se determinó que era necesario re configurar el sistema de descuentos que había en el paquete de gestión actual. El equipo de implementación considera esto como una funcionalidad deseable pero no critica para la implementación. Si se hiciera lugar al pedido, se necesitarían: 2 días de análisis, 3 de diseño, 3 de desarrollo y 5 de pruebas.

Desarrollar una interfase entre el sistema de devoluciones del software de producción y el sistema integrado de control de devoluciones del nuevo sistema CRM.


Página 9 de 26


Al realizar las pruebas, los usuarios claves se dan cuenta que no existían interfases entre el sistema CRM que se estaba instalando y el módulo de devoluciones del software de producción (in-house). Sin esta interfase, las devoluciones registradas en el sistema de producción tendrán que actualizarse manualmente en el sistema CRM. La gerencia comercial considera que con este procedimiento manual se pierde el sentido del software de CRM, por los grandes riesgos de errores y con la posibilidad que el sistema de CRM nunca esté actualizado. Dar a lugar a esta modificación implica:

o En el caso de la instalación del componente CRM de paquete de gestión actual: 4 días de análisis, 5 de diseño, 5 de desarrollo y 5 de pruebas



Se pide: Analice cada una y determine los pasos a seguir con ellas. Re planifique el proyecto para dar lugar a las modificaciones aprobadas. Evalúe el

impacto en tiempos y en costos.

Actividad 4 – DER Aplicación para aprobación crediticia (Pablo Gil)

Habiendo transcurrido 6 meses luego de la exitosa implementación de la aplicación CRM, Brent plantea en una reunión de gerencia la necesidad de desarrollar una aplicación que agilice y mejore el proceso de aprobación crediticia en CPA S.A., debido a que el volumen de ventas y clientes se ha visto considerablemente incrementado, y los límites de crédito y demás condiciones (ej: condición de pago), aún se aprueban manualmente, resguardando toda la documentación en legajos físicos. Brent aclara en la reunión que el sistema integrado no contempla esta opción.

Javier se muestra muy interesado en la propuesta de Brent, y le pide a Pedro que disponga los recursos necesarios para comenzar con el proyecto.

Cuando Brent le presenta a Pedro el requerimiento formal de desarrollo, el mismo incluye las siguientes especificaciones:

El número de cliente que se utilice debe ser el número de cliente del sistema integrado (Javier piensa de forma instantánea que deberá tener un segundo archivo maestro de clientes en la aplicación que se actualice desde la base de datos del sistema integrado).

Los clientes a los cuales se los puede someter a análisis crediticio son aquellos clientes nuevos que soliciten comprar a crédito o aquellos clientes que operan con pago anticipado y también lo solicitan. Para cada análisis, algún integrante del área Comercial debería iniciar un legajo electrónico, y de acuerdo al límite de crédito solicitado se le asignará automáticamente al legajo un código que indique la ruta de aprobación del mismo.

Cada ruta de aprobación se compone de dos niveles aprobadores que varían según el límite de crédito analizado.

Deben contemplarse diferentes condiciones de pago (ej: 15 días fecha factura, 7 días fecha factura, etc), que serán otorgadas en conjunto con el límite de crédito.

Cada legajo debe permitir la posibilidad de resguardar diversos archivos relacionados (ej estados contables del cliente, análisis VERAZ, etc).

Una vez aprobado el legajo el mismo deberá pasar a estado “Cerrado” (se deben considerar estados adicionales) y los datos se actualizarán en la aplicación para el cliente correspondiente, teniendo que ser transmitidos luego al sistema integrado.

Se pide:Realizar el diseño del diagrama de entidad-relación (DER) para la aplicación de análisis crediticio.


Página 10 de 26


Solución CPA S.A.

Solución Actividad 1 – Selección de Software (Guillermo Tricoci – Pablo Corral)

1) Siempre que se plantea la necesidad de utilizar una solución de software es necesario analizar en profundidad el problema plantado y los procesos de negocios que se intentan mejorar con la pieza de software solicitada. La integración del software y de los sistemas de información con el sistema de procesos reales de la organización es fundamental. La información se necesita para tomar decisiones sobre los procesos reales que utilizan las compañías para llevar adelante los objetivos del negocio. En el caso de CPA, se necesita mejorar o, directamente, cambiar la forma en qué se relaciona la organización con sus clientes reales y potenciales. La competencia ha demostrado al Mercado que tiene una mejor forma de satisfacer las necesidades de los clientes y es por ello que se han quedado con el 2° lugar. CPA sólo va a recuperar ese puesto si logra cambiar la forma en que atienden, tanto ellos como sus distribuidores y representantes del interior, a los clientes. Es necesario volver a pensar todos los procesos relacionados con los clientes, desde la forma en que se toman los pedidos, la forma en que se anticipa CPA a las necesidades de los clientes, la forma en que se encuentran soluciones de financiación y de logística que ayudan a los clientes a cumplir más eficientemente con sus objetivos, convirtiendo a CPA en un socio estratégico en lugar de un mero proveedor; la forma en que se procesan los reclamos en caso que se produzcan errores o problemas, la forma en que los clientes perciben que CPA los conoce bien, que los tienen identificados y que no son un cliente más. Lograr esta nueva forma de relacionarse con los clientes requiere cambiar la organización, con sus procesos de negocios y, por supuesto, los sistemas de información que los soportan.


Página 11 de 26


2)

a) Alternativa más conveniente

Matriz de Funcionalidad

ItemPonderaci

ónOpción 1 Opción 2 Opción 3

N P N P N PCentro de atención de llamadas y reclamos 0,15 2 0,3 2 0,3 2 0,3Centro de atención de reclamos por Internet 0,15 2 0,3 2 0,3 2 0,3Base de datos centralizada de cliente y pedidos 0,2 2 0,4 2 0,4 2 0,4Comercio electrónico 0 2 0 2 0 2 0Ventas móviles 0 2 0 2 0 2 0Integración total 0,1 1 0,1 3 0,3 1 0,1Facilidad de operación remota y con varias sucursales 0,15 2 0,3 2 0,3 2 0,3Facilidad para operar a través de Internet 0,1 2 0,2 2 0,2 2 0,2Facilidad para creación de perfiles de usuarios varios con seguridad en la página Web 0,15 3 0,45 1 0,15 2 0,3Total 1 2,05 1,95 1,9

Cada Item se clasifica cómo 1 – Alto, 2 – Medio, 3 – BajoLa ponderación indica el peso que tiene cada ítem 0 - 1N: Valor nominal del itemP: Valor ponderado del item

Matriz de Selección

ItemPonde-ración

Opción 1 Opción 3 Opción 3N P N P N P

Funcionalidad (ver Matriz de Funcionalidad)

0,252,05 0,51 1,95 0,49 1,90 0,48

Flexibilidad 0,05 3 0,15 1 0,05 2 0,1Escalabilidad 0,03 3 0,09 1 0,03 3 0,09Hardware Adicional 0,02 1 0,02 3 0,06 2 0,04Integración 0,10 3 0,3 3 0,3 3 0,3Facilidad de Uso 0,10 2 0,2 3 0,3 3 0,3Tiempo 0,15 2 0,3 1 0,15 3 0,45Costo 0,30 1 0,3 3 0,9 1 0,3Total 1 1,87 2,28 2,06

Cada Item se clasifica cómo 1 – Alto, 2 – Medio, 3 – BajoLa ponderación indica el peso que tiene cada ítem 0 - 1N: Valor nominal del itemP: Valor ponderado del item

Luego de desarrollar la matriz de selección en dónde se detallaron los principales atributos a tener en cuenta para la selección de un proveedor, se ponderaron en función de su importancia, de 0 a 1 y se calificaron como alto (3), medio (2) y bajo (1). Se construyó una matriz adicional de funcionalidad para poder trabajar todos los atributos de funcionalidad en forma más cómoda. La ponderación y la evaluación de posesión se hizo en base a supuestos, ya que no surgen del enunciado. Basados en los resultados de la matriz, se deberá seleccionar la Opción B, con el mayor puntaje.


Página 12 de 26


b) La información con la que se cuenta es buena pero insuficiente. Se deberían tener en cuenta aspectos tales como:

1) Elementos que permita realizar el cálculo del ROI (retorno sobre la inversión), ya que sólo se cuentan con números para calcular los costos, pero no los potenciales beneficios del proyecto. El análisis de los beneficios es muy complicado, ya que es difícil establecer en muchos casos cuál es el beneficio económico de las distintas funcionalidades y del proyecto en su totalidad.

2) Condiciones de venta y pago3) Condiciones de soporte post implementación4) Provisión de material de capacitación5) Datos financieros de los proveedores para evaluar su solvencia6) etc.

c) En conjunto con la inversión en sistemas de información se deberían evaluar inversiones en:

1) Procesos y reingeniería2) Cadena logística y distribución3) Procesos industriales y cadena de abastecimientos4) Desarrollo tecnológico de los distribuidores del interior.5) Desarrollo tecnológico de los clientes para integrar la cadena de distribución.

Solución Actividad 2 – Análisis de Alternativas de Solución (Guillermo Tricoci – Pablo Corral)

1) Mariano había realizado un análisis de situación, pero de forma preliminar. Durante un mes evaluó las principales variables para poder tener un rápido diagnóstico y tener argumentos suficientes para poder encarar un trabajo serio de mejora de procesos. Él está convencido que existen problemas en la forma en que CPA se relaciona con sus clientes, pero necesita un análisis detallado para llegar a una conclusión sobre el diagnóstico y sobre las acciones requeridas para solucionar el problema. Además, es consciente que CRM es una filosofía de la empresa y no una mera herramienta de gestión de clientes. El Software de CRM es necesario, pero sólo en el marco de un proyecto más grande de reingeniería del negocio.

2) Brent necesita información adicional para cuantificar adecuadamente el rendimiento que va a producir la inversión en un activo intangible como lo es el software. Para ello requiere:

a. Evaluar el costo total de la inversión (TCO). En este caso, falta evaluar algunos puntos importantes, como el mantenimiento, el costo de cambios de versión, capacitación y material de entrenamiento, etc.

b. Se desconocen las inversiones adicionales derivadas de la implementación del software, más allá de los costos asociados a la inversión en el software en estudio.

c. Determinar claramente los beneficios o ahorros a obtener de la inversión. El análisis de los beneficios es muy complicado, ya que es difícil establecer en muchos casos cuál es el beneficio económico de las distintas funcionalidades y del proyecto en su totalidad. La intangibilidad de los beneficios del software hace muy difícil la cuantificación y el análisis económico de las inversiones en sistemas de información. Los beneficios podrían obtenerse de aumentos en las ventas, pero es necesario demostrar como aumentarían las ventas en función de las distintas funcionalidades del software. También se pueden producir ahorros, por reducción de personal encargado de tareas manuales que se automatizan. Este último caso no aplicaría para el caso de CPA.

d. Evaluación de los costos de oportunidad de otras inversiones que podrían también tener efectos sobre las ventas y que podrían ayudar a conseguir el 2° lugar del mercado nuevamente (cómo ser campañas de marketing y acción promocional y publicitaria).


Página 13 de 26


Solución Actividad 3 – Implementación de Software (Guillermo Tricoci – Pablo Corral)

1)

Opción 1

1. Entregables de cada etapaa. Análisis:

i. Plan de implementaciónii. Alcance detallado iii. Análisis de Brecha (GAPs)

b. Diseño:i. Diseño Funcionalii. Diseño de Interfacesiii. Programas Adicionales (extensiones)iv. Plan de Pruebasv. Casos de Pruebasvi. Detalle de Datos a Migrar

c. Construccióni. Detalle de Configuración ii. Detalle de Programas

d. Pruebasi. Informe de Pruebas de Sistemaii. Informe de Pruebas de Migración

e. Capacitacióni. Informe de Capacitación

f. Migracióni. Informe de Auditoria de Migración

2. Información a incluir en cada documentoa. Análisis:

i. Plan de implementación: Plan detallado del proyecto que incluye la asignación de los recursos a cada tarea a realizar en cada etapa

ii. Alcance detallado: Detalle de la funcionalidad que es objeto del proyecto. El proyecto se concertará en desarrollar sólo la funcionalidad detallada en el alcance.

iii. Análisis de Brecha (GAPs): Diferencia entre la funcionalidad requerida por los requerimientos de la organización y la funcionalidad que brinda el paquete a implementar. Durante el proyecto se deberá encontrar soluciones a las brechas encontradas, ya sea con procedimientos manuales, adaptación de otras funcionalidades o desarrollo de programas que permitan achicar la brecha.

b. Diseño:i. Diseño Funcional: Diseño conceptual de lo que debe hacer el nuevo

sistema. Se establecen cuáles son los principales parámetros sobre los que trabajar y se diseña la solución que permite cerrar o achicar la brecha encontrada en la etapa de análisis. Se desarrollan además especificaciones funcionales sobre que deben hacer los programas que se deberán construir en forma adicional en la etapa de construcción.

ii. Diseño de Interfaces: Se diseñan las interfaces con todos los programas adyacentes al sistema en desarrollo

iii. Programas Adicionales (extensiones): Se detalla la totalidad de programas a escribirse adicionalmente a la parametrización del paquete de software. De incluir las interfaces, las extensiones y las migraciones automáticas de datos

iv. Plan de Pruebas: Incluir el plan de pruebas a seguirse, incluyendo cada caso a probarse, en qué momento y quién deberá desarrollarlas

v. Casos de Pruebas: Detalle de qué debe probarse en cada circunstancia normal de la operatoria del negocio


Página 14 de 26


vi. Detalle de Datos a Migrar: Identificar que datos deberán migrarse del sistema viejo al nuevo, detallando cuáles datos no existen en el sistema actual pero son requeridos por el nuevo sistema


d. Pruebasi. Informe de Pruebas de Sistema: Informe sobre el resultado de cada

prueba desarrolladaii. Informe de Pruebas de Migración: Informe sobre el resultado de las

pruebas de migración de datose. Capacitación

i. Informe de Capacitación: Informe que permita indicar el grado de avance en la capacitación de las personas que tendrán que usar el nuevo sistema

f. Migracióni. Informe de Auditoria de Migración: Resultado de la migración de datos,

indicando que datos debían migrarse del sistema anterior, y como fueron efectivamente migrados al nuevo sistema. Este informe está orientado a minimizar errores o fraudes

3. Actividades a realizar en cada fasea. Análisis:

i. Análisis de situación actualii. Análisis de requerimientosiii. Determinación de las brechas entre los requerimientos y la

funcionalidad del paqueteiv. Determinación del alcance del proyectov. Preparación del plan detallado de proyecto

b. Diseño:i. Diseño de los procesos futurosii. Diseño de las adaptaciones de funcionalidadiii. Diseño de soluciones para las brechasiv. Diseño de interfacesv. Diseño de programas de mejorasvi. Definición del plan y casos de pruebasvii. Definición de datos a migrar

c. Construcción:i. Configuración/parametrización del sistemaii. Construcción de las aplicaciones incluidas en el alcanceiii. Desarrollo de pruebas unitarias

d. Pruebasi. Desarrollo de las pruebas de integración, aceptación y sistema

e. Capacitación:i. Desarrollo de los manuales de capacitaciónii. Dictado de cursos de capacitacióniii. Desarrollo de plan de salida en vivo (plan de corte)

f. Migracióni. Preparación de los datos para migrarii. Migracióniii. Salida en vivo

4. Hitos significativos de cada etapaa. Análisis: Aprobación del alcance del proyectob. Diseño: Aprobación de los diseños funcionales y técnicosc. Construcción: Pruebas unitarias okd. Pruebas: Pruebas de aceptación oke. Capacitación: Evaluación de la capacitaciónf. Migración: Salida en vivo

5. Riesgos existentes en cada etapa y sus mitigadores


Página 15 de 26


Riesgo Impacto Prob Categoría Estrategia AccionesMala definición de requerimientos

3 0,4 1,2 EVITAR Realizar una definición de requerimientos analizando las necesidades y motivaciones de CPA para implementar un soft de CRM.

Mala estimación de costos

3 0,3 0,9 TRANSFERIR Contratar una consultora con alto conocimiento de gestión de proyectos y con experiencia en este tipo de implementacionesContratar un gerente de proyectos profesional

Desconocimiento del negocio por parte de los analistas

2 0,4 0,8 MITIGAR Realizar adecuados talleres de análisis para poner a los analistas en contextoNombra usuarios claves expertos de la organización y asignarlos tiempo completo al proyecto, desligandolos de sus tareas habituales

Alta rotación de los miembros del equipo

2 0,4 0,8 TRANSFERIR Establecer por contrato que la consultora deberá proveer de recursos de igual calidad en caso que se produzcan cambios durante el proyecto

Indefinición del alcance del proyecto

3 0,2 0,6 MITIGAR Logra una buenda definición de requerimientosBuscar la aprobación formal del alcance, por escrito, para minimizar los cambios de alcance. Aún así, es probable que el alcance no sea del todo claro y de origen a disputas

Mala estimación de tiempos


Dificultades de migración de datos

2 0,3 0,6 MITIGAR Dedicar horas de análisis, diseño y construcción para la migración de datosDecicar horas y usuarios especialistas para la limpieza y preparación de los datos a migrar

Baja participación de usuarios claves

2 0,2 0,4 EVITAR Logra el involucramiento de la cúpula de la administración para logra que los usuarios se involucren en serio en el proyecto

Cambios constantes de alcance

2 0,2 0,4 MITIGAR Obtener aprobación de alcanceDesarrollar un buen procedimiento para administrar los requerimientos de cambios, estableciendo pautas para su manejo

Desconocimiento de la herramienta a implementar

2 0,2 0,4 TRANSFERIR Contratar a la mejor consultora de la herramienta y logra que se responsabilice por contrato para proveer consultores con alta


Página 16 de 26


Riesgo Impacto Prob Categoría Estrategia Accionesexperiencia

Malas pruebas de usuarios

3 0,1 0,3 EVITAR Definir claros casos de pruebas

Dificultades de mantenimiento de sistemas legacy

1 0,3 0,3 MITIGAR Dedicar un equipo de profesionales para mantener el sistema legacy de manera de garantizar la calidad de las interfaces con el sistema en construcciónRealizar nuevos acuerdos de manetenimiento con los proveedores del sistema legacy

Dificultades de integración de softwares

1 0,2 0,2 MITIGAR Dedicar horas de análisis, diseño y construcción para la integración de software

6. Otros componentes presentes en un plan de desarrollo de software.a. Plan de Proyecto

Gantt Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8Análisis Diseño Construcción Pruebas Capacitación Migración

Ocupación Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 TotalConsultor A 160 160 160 160 160 160 160 1120Consultor B 160 160 160 160 160 160 160 1120Gerente Consultría 40 40 40 40 40 40 40 280Usuario A 160 160 40 40 160 160 160 880Usuario B 160 160 40 40 160 160 160 880Usuario C 80 80 0 0 80 80 80 400Gerente 160 160 160 160 160 160 160 1120Total 920 920 600 600 920 920 920 5800

b. Plan de Control de Cambios: Determina el procedimiento de administración y aceptación del los cambios que se proponen luego de que la etapa correspondiente fuera aprobada.

c. Plan de Mantenimiento: Establece los procedimientos que se seguirán para mantener el sistema operativo una vez que el proyecto salga en vivo y cómo ir realizándole mejoras a lo largo del ciclo de vida

d. Plan de Corte: Establece la secuencia de pasos, tiempos y personar responsables para desactivar el sistema viejo y activar el sistema nuevo.


Página 17 de 26


Opción 2

1. Entregables de cada etapaa. Análisis:

i. Plan de implementaciónii. Alcance detallado iii. Análisis de Brecha (GAPs)

b. Diseño:i. Diseño Funcionalii. Diseño de Interfacesiii. Programas Adicionales (extensiones)iv. Plan de Pruebasv. Casos de Pruebasvi. Detalle de Datos a Migrar


d. Pruebasi. Informe de Pruebas de Sistemaii. Informe de Pruebas de Migración

e. Capacitacióni. Informe de Capacitación

f. Migracióni. Informe de Auditoria de Migración

2. Información a incluir en cada documentoa. Análisis:

i. Plan de implementación: Plan detallado del proyecto que incluye la asignación de los recursos a cada tarea a realizar en cada etapa

ii. Alcance detallado: Detalle de la funcionalidad que es objeto del proyecto. El proyecto se concertará en desarrollar sólo la funcionalidad detallada en el alcance.

iii. Análisis de Brecha (GAPs): Diferencia entre la funcionalidad requerida por los requerimientos de la organización y la funcionalidad que brinda el paquete a implementar. Durante el proyecto se deberá encontrar soluciones a las brechas encontradas, ya sea con procedimientos manuales, adaptación de otras funcionalidades o desarrollo de programas que permitan achicar la brecha.

b. Diseño:i. Diseño Funcional: Diseño conceptual de lo que debe hacer el nuevo

sistema. Se establecen cuáles son los principales parámetros sobre los que trabajar y se diseña la solución que permite cerrar o achicar la brecha encontrada en la etapa de análisis. Se desarrollan además especificaciones funcionales sobre que deben hacer los programas que se deberán construir en forma adicional en la etapa de construcción.

ii. Diseño de Interfaces: Se diseñan las interfaces con todos los programas adyacentes al sistema en desarrollo

iii. Programas Adicionales (extensiones): Se detalla la totalidad de programas a escribirse adicionalmente a la parametrización del paquete de software. De incluir las interfaces, las extensiones y las migraciones automáticas de datos

iv. Plan de Pruebas: Incluir el plan de pruebas a seguirse, incluyendo cada caso a probarse, en qué momento y quién deberá desarrollarlas

v. Casos de Pruebas: Detalle de qué debe probarse en cada circunstancia normal de la operatoria del negocio

vi. Detalle de Datos a Migrar: Identificar que datos deberán migrarse del sistema viejo al nuevo, detallando cuáles datos no existen en el sistema actual pero son requeridos por el nuevo sistema

c. Construcción


Página 18 de 26


i. Detalle de Configuración ii. Detalle de Programas

d. Pruebasi. Informe de Pruebas de Sistema: Informe sobre el resultado de cada

prueba desarrolladaii. Informe de Pruebas de Migración: Informe sobre el resultado de las

pruebas de migración de datose. Capacitación

i. Informe de Capacitación: Informe que permita indicar el grado de avance en la capacitación de las personas que tendrán que usar el nuevo sistema

f. Migracióni. Informe de Auditoria de Migración: Resultado de la migración de datos,

indicando que datos debían migrarse del sistema anterior, y como fueron efectivamente migrados al nuevo sistema. Este informe está orientado a minimizar errores o fraudes

3. Actividades a realizar en cada fasea. Análisis:

ii. Análisis de situación actualiii. Análisis de requerimientosiv. Determinación de las brechas entre los requerimientos y la

funcionalidad del paquetev. Determinación del alcance del proyectovi. Preparación del plan detallado de proyecto

b. Diseño:i. Diseño de los procesos futurosii. Diseño de las adaptaciones de funcionalidadiii. Diseño de soluciones para las brechasiv. Diseño de interfacesv. Diseño de programas de mejorasvi. Definición del plan y casos de pruebasvii. Definición de datos a migrar

c. Construcción:i. Configuración/parametrización del sistemaii. Construcción de las aplicaciones incluidas en el alcanceiii. Desarrollo de pruebas unitarias

d. Pruebasi. Desarrollo de las pruebas de integración, aceptación y sistema

e. Capacitación:i. Desarrollo de los manuales de capacitaciónii. Dictado de cursos de capacitacióniii. Desarrollo de plan de salida en vivo (plan de corte)

f. Migracióni. Preparación de los datos para migrarii. Migracióniii. Salida en vivo

4. Hitos significativos de cada etapaa. Análisis: Aprobación del alcance del proyectob. Diseño: Aprobación de los diseños funcionales y técnicosc. Construcción: Pruebas unitarias okd. Pruebas: Pruebas de aceptación oke. Capacitación: Evaluación de la capacitaciónf. Migración: Salida en vivo


Página 19 de 26


5. Riesgos existentes en cada etapa y sus mitigadores

Riesgo Impacto Prob Categoría Estrategia AccionesMala definición de requerimientos

3 0,4 1,2 EVITAR Realizar una definición de requerimientos analizando las necesidades y motivaciones de CPA para implementar un soft de CRM.

Mala estimación de costos


Indefinición del alcance del proyecto

3 0,2 0,6 MITIGAR Logra una buenda definición de requerimientosBuscar la aprobación formal del alcance, por escrito, para minimizar los cambios de alcance. Aún así, es probable que el alcance no sea del todo claro y de origen a disputas

Mala estimación de tiempos


Baja participación de usuarios claves

2 0,2 0,4 EVITAR Logra el involucramiento de la cúpula de la administración para logra que los usuarios se involucren en serio en el proyecto

Cambios constantes de alcance

2 0,2 0,4 MITIGAR Obtener aprobación de alcanceDesarrollar un buen procedimiento para administrar los requerimientos de cambios, estableciendo pautas para su manejo

Malas pruebas de usuarios

3 0,1 0,3 EVITAR Definir claros casos de pruebas

Desconocimiento de los lenguajes de programación

2 0,1 0,2 MITIGAR Entrenar y capacitar a los programadores de la compañía en la herramienta de programación


Página 20 de 26


6. Otros componentes presentes en un plan de desarrollo de software.a. Plan de Proyecto

Mes

1Mes

2Mes

3Mes

4Mes

5Mes

6Mes

7Mes

8Mes

9Mes 10

Mes 11 Mes 12

Análisis Diseño Construcción Pruebas

Capacitación Migración

OcupaciónMes

1Mes

2Mes

3Mes

4Mes

5Mes

6Mes

7Mes

8Mes

9Mes 10

Mes 11

Mes 12 Total

Programador E A 160 160 160 160 160 160 160 160 160 160 160 160 1120Programador E B 160 160 160 160 160 160 160 160 160 160 160 160 1120Gerente proyectos 80 80 80 80 80 80 80 80 80 80 80 80 560Usuario A 160 160 160 160 160 160 160 40 40 40 160 160 1160Usuario B 160 160 160 160 160 160 160 40 40 40 160 160 1120Programador I A 160 160 160 160 160 160 160 160 160 160 160 160 1120Programador I B 160 160 160 160 160 160 160 160 160 160 160 160 1120Total 1040 1040 1040 1040 1040 1040 1040 800 800 800 1040 1040 7320

b. Plan de Control de Cambios: Determina el procedimiento de administración y aceptación del los cambios que se proponen luego de que la etapa correspondiente fuera aprobada.

c. Plan de Mantenimiento: Establece los procedimientos que se seguirán para mantener el sistema operativo una vez que el proyecto salga en vivo y cómo ir realizándole mejoras a lo largo del ciclo de vida

d. Plan de Corte: Establece la secuencia de pasos, tiempos y personar responsables para desactivar el sistema viejo y activar el sistema nuevo.

Opciòn 3

1) Entregables de cada etapa: Idem Opciòn 12) Información a incluir en cada documento: Idem Opciòn 13) Actividades a realizar en cada fase: Idem Opciòn 14) Hitos significativos de cada etapa: Idem Opciòn 15) Riesgos existentes en cada etapa y sus mitigadores: Idem Opciòn 1


Página 21 de 26


6) Otros componentes presentes en un plan de desarrollo de software.a. Plan de Proyecto

Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6Análisis Diseño Construcción Pruebas Capacitación Migración

Ocupación Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 TotalConsultor A 160 160 160 160 160 800Consultor B 160 160 160 160 160 800Gerente Consultría 40 40 40 40 40 200Usuario A 160 160 40 160 160 680Usuario B 160 160 40 160 160 680Usuario C 80 80 0 80 80 320Gerente 160 160 160 160 160 800Total 920 920 600 920 920 4280

b. Plan de Control de Cambios: Idem Opcion 1c. Plan de Mantenimiento: Idem Opcion 1d. Plan de Corte Idem Opcion 1

2)

Tablero de comandoEl tablero de comando es una buena funcionalidad, estratégica, pero incluirla en esta etapa del proyecto implica demasiados riesgos con pocos beneficios de corto plazo. Se planteará como una segunda etapa.

Actualización de la base de datos de clientes en el sistema actual, completando los datos requeridos por el nuevo sistema y que el anterior no registraba

Los datos maestros son claves a la hora de iniciar un nuevo sistema. Siempre es deseable contar con los datos limpios y completos al iniciar la vida de un nuevo sistema. Dado que son actividades que se pueden realizar en paralelo y que no afectan el camino crítico, se pueden agregar mientras duren la fase de capacitación.

Actualización del historial del cliente para la migración de datos históricos.

Siguiendo el mismo criterio que en el caso de los datos maestros incompletos, se puede paralelizar el desarrollo de la nueva interfase de datos históricos con la fase de capacitación. Esto no afectaría el camino crítico.

Re configuración de la funcionalidad de cálculo de descuentos.

Esta modificación no agrega valor en esta etapa del proyecto y se desarrollará como una segunda fase.

Desarrollar una interfase entre el sistema de devoluciones del software de producción y el sistema integrado de control de devoluciones del nuevo sistema CRM.


Página 22 de 26


Claramente esta funcionalidad es crítica y no se tuvo en cuenta en su momento. El riesgo de una interfase manual es alto y no contar con esta impacta en el resultado final del proyecto. Hay cierto riesgo al incluir esta interfase y requiere de recursos adicionales para no afectar el camino crítico.

Replanificación Opción 1

Gantt Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8AnálisisDiseñoConstrucciónPruebasLimpieza de datos maestrosMigración datos Históricos

AnálisisDiseñoConstrucciónPruebas

Interfase devolucionesAnálisisDiseñoConstrucciónPruebas

CapacitaciónMigración

Ocupación Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 TotalConsultor A 160 160 160 160 160 160 160 1120Consultor B 160 160 160 160 160 160 160 1120Consultor C 0 0 0 0 0 40 0 40Consultor C 0 0 0 0 0 120 0 120Gerente Consultría 40 40 40 40 40 40 40 280Usuario A 160 160 40 40 160 160 160 880Usuario B 160 160 40 40 160 160 160 880Usuario C 80 80 0 0 80 80 80 400Usuario C 0 0 0 0 0 40 0 40Usuario C 0 0 0 0 0 40 0 40Usuario D 0 0 0 0 0 80 0 80Gerente 160 160 160 160 160 160 160 1120Total 920 920 600 600 920 1240 920 6120

El camino crítico de las mejoras está definido por la interfase de devoluciones que es de un mes. Se procederá a realizarlo en paralelo con la capacitación y con las modificaciones a las migraciones de datos. Esto requerirá el agregado de un consultor adicional, de utilizar al usuario C a tiempo completo y agregar un nuevo usuario a tiempo parcial. Con esta estrategia no será necesario cambiar la fecha de salida en vivo. Los costos adicionales producidos por el agregado de las nuevas funcionalidades son de:

Costos Horas $/hs Total $Consultor C 160 $ 70,00 $11.200Usuario C 80 $ 25,00 $2.000Usuario D 80 $ 25,00 $2.000Total 320 $15.200



Página 23 de 26


Gantt Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12 Mes 13AnálisisDiseñoConstrucciónPruebasLimpieza de datos maestrosMigración datos Históricos




Ocupación Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12 Mes 13 TotalProgramador E A 160 160 160 160 160 160 160 160 160 160 160 0 160 1920Programador E B 160 160 160 160 160 160 160 160 160 160 160 0 160 1920Gerente proyectos 80 80 80 80 80 80 80 80 80 80 80 0 80 960Gerente proyectos 0 0 0 0 0 0 0 0 0 0 0 80 0 80Usuario A 160 160 160 160 160 160 160 40 40 40 160 0 160 1560Usuario A 0 0 0 0 0 0 0 0 0 0 0 40 0 40Usuario A 0 0 0 0 0 0 0 0 0 0 0 40 0 40Usuario A 0 0 0 0 0 0 0 0 0 0 0 80 0 80Usuario B 160 160 160 160 160 160 160 40 40 40 160 0 160 1560Usuario C 0 0 0 0 0 0 0 0 0 0 0 0 40 40Programador I A 160 160 160 160 160 160 160 160 160 160 160 0 160 1920Programador I A 0 0 0 0 0 0 0 0 0 0 0 40 0 40Programador I A 0 0 0 0 0 0 0 0 0 0 0 120 0 120Programador I B 160 160 160 160 160 160 160 160 160 160 160 0 160 1920Programador I B 0 0 0 0 0 0 0 0 0 0 0 40 0 40Programador I B 0 0 0 0 0 0 0 0 0 0 0 120 0 120Total 1040 1040 1040 1040 1040 1040 1040 800 800 800 1040 560 1080 12360

Dado que el tiempo entre las pruebas y salida en vivo en el proyecto original era de un mes y que el camino crítico de las nuevas funcionalidades a agregar es de un mes y medio, no queda más remedio que postergar la salida en vivo. Esto genera un sobre costo importante, sobre todo de las horas parciales del gerente de proyectos. Se deberá suspender la participación de los programadores externos y se utilizará el trabajo de los programadores internos para desarrollar las nuevas aplicaciones, dado que son de menor costo. Esto requiere una negociación con los dos programadores externos. Los costos adicionales producidos por el agregado de las nuevas funcionalidades son de:

Costos Horas $/hs Total $Gerente de proyectos 80 187,5 $15.000Usuario A 160 25 $4.000Usuario C 40 25 $1.000Programador I A 160 34 $5.500Programador I B 160 34 $5.500Total 600 $31.000



Página 24 de 26


Tablero de Comando Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6AnálisisDiseñoConstrucciónPruebasLimpieza de datos maestrosMigración datos Históricos




Ocupación Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 TotalConsultor A 160 160 160 160 160 800Consultor B 160 160 160 160 160 800Consultor C 0 0 0 56 0 56Consultor D 0 0 0 80 72 152Gerente Consultría 40 40 40 40 40 200Usuario A 160 160 40 160 160 680Usuario B 160 160 40 160 160 680Usuario C 80 80 0 80 80 320Usuario C 0 0 0 80 0 80Usuario C 0 0 0 40 40Usuario C 0 0 0 40 40Usuario C 40 40Usuario C 40 40Gerente 160 160 160 160 160 800Total 920 920 600 1136 1152 4728

En este caso, si bien la funcionalidad adicional tiene un camino crítico de un mes y es posible agregarla antes de la fecha de salida en vivo adicional, es necesaria una importante actividad de replanificación de las tareas de capacitación y migración. Se reduce la migración en 10 días, pero se agregan horas adicionales de un nuevo usuario (el C) ya que no es posible reducirla tanto tiempo. Por otro lado, se pone en paralelo con la capacitación lo que requiere también del apoyo del usuario C. serán necesarios dos consultores adicionales para poder llevar adelante la nueva funcionalidad, ya que los dos consultores iniciales (A y B) ya están con actividades para esas etapas que le consumen todo su capacidad mensual. Los costos adicionales producidos por el agregado de las nuevas funcionalidades son de:

Costos Horas $/hs Total $Consultor C 56 100 $5.600Consultor D 152 100 $15.200Usuario C 240 25 $6.000Total 448 $26.800


Página 25 de 26


Solución Actividad 4 – DER Aplicación para aprobación crediticia


Página 26 de 26

5602 solucion cpa

Documents