UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE INGENIERIA INDUSTRIAL

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE INGENIERIA INDUSTRIAL MEJORAMIENTO DE PROCESOS DE PRODUCCION, MANTENCION Y SOPORTE DE PRODUCTOS DE SOFTWARE TESIS PARA OPTAR AL GRADO DE MAGISTER EN INGENIERIA DE NEGOCIOS CON TECNOLOGIAS DE INFORMACION JUAN ENRIQUE ORTUZAR ELTON SANTIAGO DE CHILE MAYO 211

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE INGENIERIA INDUSTRIAL MEJORAMIENTO DE PROCESOS DE PRODUCCION, MANTENCION Y SOPORTE DE PRODUCTOS DE SOFTWARE TESIS PARA OPTAR AL GRADO DE MAGISTER EN INGENIERIA DE NEGOCIOS CON TECNOLIGIAS DE INFORMACION JUAN ENRIQUE ORTUZAR ELTON PROFESOR GUIA: OSCAR BARROS VERA MIEMBROS DE LA COMISION: EDUARDO CONTRERAS VILLABLANCA EZEQUIEL MUÑOZ KRSULOVIC JOSE BENGURIA DONOSO SANTIAGO DE CHILE MAYO 211

Dedicado a mi esposa Macarena y a mis hijos Juan Enrique y Magdalena de Jesús, que tuvieron la generosidad de inspirarme, apoyarme y regalarme el largo tiempo empleado en los estudios y realización de este proyecto. Espero compensarlos algún día. Santiago, Mayo de 211

RESUMEN EJECUTIVO Edi-Trade S.A. es una empresa de servicios y desarrollo de software orientados al comercio exterior y principalmente al rubro de agenciamiento de aduana. Edi-Trade S.A. ha conquistado cerca del 84% del mercado de agenciamiento de aduanas en sus ya más de 18 años de vida. Con el fin de diversificar su cartera de clientes, actualmente concentrada principalmente en las agencias de aduana, Edi-Trade S.A. ha emprendido el proyecto SAUCE (Sistema de Administración Unificado de Comercio Exterior). El objetivo del proyecto SAUCE es desarrollar más y mejores productos y servicios de software para sus clientes y futuros clientes en el mercado del comercio exterior. Con este fin se está desarrollando este trabajo llamado Mejoramiento de Procesos de Producción, Mantención y Soporte de Productos de Software, que en el Marco del Proyecto SAUCE, tiene como objetivo principal mejorar el macroproceso de Cadena de Valor de Desarrollo de Software, implementando el patrón Macro 1 diseñado por el Doctor Oscar Barros. En esta cadena podemos distinguir tres funcionalidades principales: Soporte al Cliente Desarrollo de Proyectos de Software Desarrollo de Requerimientos y Mejoras de Software. Estas funcionalidades están implícitas en el patrón antes mencionado. Según éste, debemos modelar estas funcionalidades en forma transversal para aprovechar las características de ellas y lograr completitud del modelo, máxima cohesión y mínimo acoplamiento. En este proyecto se desarrollará un prototipo de sistema de información de apoyo a la cadena de valor, el cual contará con una variedad de módulos de gestión y de mantención de estados. Para efectos de este informe hemos entrado en el detalle del diseño de los procesos relacionados con asignación de recursos, entre los cuales se destacan la Asignación de Paquetes de Trabajo y Asignación de Incidencias y Problemas. Para la Asignación de Paquetes de Trabajo utilizaremos la técnica de Punto Función para calcular el esfuerzo de los paquetes de trabajo y, por ende, de un proyecto. Luego, se aplicará un algoritmo para la Asignación y Nivelación de Recursos en la Programación de Proyectos con recursos limitados y distintas duraciones posibles para las actividades, utilizando el Método Roy. Para la Asignación de Incidencias y Problemas, se utilizará una técnica basada en Teoría de Colas con Prioridad. Se utilizan las técnicas recién mencionadas debido a que son relativamente fáciles de implementar, y demostrarán que es posible aplicar mecanismos automáticos de asignación de recursos en este negocio. Al utilizarlos de forma correcta (sin que la señalada técnica se acople con el resto del sistema), quedará abierta la puerta para probar con otros algoritmos o con sistemas externos que tengan la capacidad de realizar dichas tareas. A grandes rasgos, los resultados y beneficios del proyecto, son los siguientes: Mejora del grado de cumplimientos de la planificación de producción. Edi-Trade logra mejorar una deficiencia histórica y comienza a recobrara la confianza en los compromisos de fechas de entrega. Identificación y reacción correctiva a tiempo sobre la planificación de la producción. Edi-Trade logra identificar a tiempo los factores que retrasan la planificación comprometida tratando las acciones correctivas a tiempo y no cuando ya es tarde. Mantener informado a los clientes de los avances de sus requerimientos e incidencias. Se mejora la comunicación con los clientes, lo cual los ellos agradecen y es de gran ayuda para aterrizar las percepciones del cliente y de los gerentes de Edi-Trade. Aumento del Resultado Operacional. Se reducen los costos de planificaciones en forma significativa y se evitan costos por conceptos de multas por retrasos.

Contenido 1. PLANTEAMIENTO Y MOTIVACIONES INICIALES DEL PROYECTO... 1 1.1. Antecedentes de la empresa... 1 1.2. Situación actual... 2 1.3. Organización de la empresa... 3 1.4. Tamaño de mercado... 4 1.5. Nuevos clientes... 4 1.6. Evaluación de la empresa... 5 1.7. Modelo de negocios... 6 1.8. Análisis de la empresa... 6 1.8.1. Análisis de las fuerzas de Porter... 6 1.8.2. Análisis FODA... 1 1.8.3. Diagnóstico de la cadena de valor... 15 1.8.4. Estrategia actual de Edi-Trade... 19 1.8.5. Análisis de los actuales procesos... 19 2. MARCO TEÓRICO... 23 2.1. Diseño de procesos basado en patrones de negocio orientado a la gestión, producción y provisión de bienes o servicios... 23 2.1.1. El apoyo de la macro 1.... 24 2.1.2. Lógica de negocios... 26 2.1.3. Diseño de la herramienta computacional... 27 2.1.4. Más Información... 27 2.2. CMMI... 27 2.3. ITIL... 31 2.4. Métrica de Punto Función... 33 3. EL PROYECTO... 35 3.1. Oportunidad... 35 3.1.1. Diagnóstico... 35 3.1.2. El Mercado... 35 3.1.3. Producto Ofrecido... 36

3.1.4. Clientes... 36 3.1.5. Beneficios Cualitativos Preliminares... 37 3.2. Diseño organizacional del proyecto... 37 3.3. Implementación del Proyecto... 39 3.4. Fundamento Teórico Conceptual del Proyecto... 4 3.5. Costos de Inversión y Operación... 45 3.6. Plan de Marketing... 46 3.7. Evaluación Financiera... 46 3.7.1. Flujo de Caja Proyectado a Cinco Años... 48 3.7.2. Análisis de Sensibilidad y Riesgo... 49 4. REDISEÑO DE PROCESOS... 55 4.1. Cadena de valor... 55 4.2. Métricas asociadas... 63 4.3. Arquitectura de macroprocesos... 63 4.4. Análisis de dirección de cambio... 65 4.4.1. Asignación de responsabilidades... 65 4.4.2. Mantención consolidada de estados.... 65 4.4.3. Anticipación... 66 4.4.4. Integración de procesos conexos... 67 4.4.5. Coordinación... 68 4.4.6. Prácticas de trabajo... 69 4.4.7. Apoyo Computacional... 7 4.4.8. Selección de tecnologías de información involucradas... 7 4.5. Modelo del macroproceso Cadena de Valor... 73 4.5.1. Administración de requerimientos e incidencias... 75 4.5.2. Administración relación proveedores de servicios computacionales... 81 4.5.3. Gestión Desarrollo de Soluciones, Incidencias y... 82 4.5.3. Entrega.... 82 4.5.4. Desarrollo, instalaciones, actualizaciones y solución de incidencias... 87 4.5.5. Mantención de estados... 92 4.6. Lógica de Negocios... 93 4.6.1. Descomposición Jerárquica de la Macro 1... 93

4.6.2. Definición de actividades con apoyo computacional.... 96 5. LÓGICA DE NEGOCIOS CONSOLIDADA... 12 5.1. Desarrollo de software... 12 5.2. Soporte al Cliente... 122 5.3. Desarrollo de Requerimientos... 122 5.4. Simulación... 125 5.4.1. Parámetros... 126 5.4.2. Resultados... 13 6. DISEÑO DE LAS APLICACIONES COMPUTACIONALES DE APOYO A LOS PROCESOS.... 143 6.1. Administración de desarrollo e incidencias (1)... 143 6.1.1. Captura de requerimientos (1.1.1)... 143 6.1.2. Análisis comercial de requerimientos (1.1.2)... 145 6.1.3. Detección de incidencias (1.2.1) y captura de incidencias (1.2.2)... 147 6.2. Gestión de desarrollo, incidencias y entrega (3)... 149 6.2.1. Asignación de problemas (3.1.2.2)... 149 6.2.2. Asignación equipo de trabajo (3.1.2.3.1)... 151 6.2.3. Cálculo de plazo y presupuesto (3.1.2.3.2)... 153 6.2.4. Asignación de requerimientos (3.1.2.1)... 155 6.2.5. Control de problemas (3.1.2.1)... 157 6.2.6. Control de paquetes de trabajo (3.1.2.2)... 159 6.2.7. Control de requerimientos (3.1.2.3)... 161 6.2.8. Asignación de incidencias (3.2.1.1)... 163 6.2.9. Publicación de cambios (3.2.1.2.1)... 165 6.2.1. Asignación de difusión de cambios (3.2.1.2.2)... 167 6.3. Desarrollo, instalaciones, actualizaciones y solución de incidencias (4)... 169 6.3.1. Atención incidencia (4.2.1)... 169 7. CONSTRUCCIÓN DE LAS APLICACIONES TI... 171 7.1. Diseño detallado del apoyo computacional para asignación de recursos.... 171 7.1.1. Asignación paquetes de trabajo... 171 7.1.2. Asignación de técnicos... 173 7.2. Diseño lógico del apoyo computacional para ejecución de tareas... 177

7.2.1. Atención de incidencias... 177 7.3. Diagrama de clases de entidad... 179 7.4. Diagrama y paquetes... 18 7.5. Prototipo... 18 7.5.1. Diseño Físico del Prototipo... 181 8. IMPLEMENTACIÓN ORGANIZACIONAL DE LOS PROCESOS DISEÑADOS Y LAS APLICACIONES TI DE APOYO... 192 8.1. Aspectos técnicos.... 192 8.1.1. Contexto de implementación del plan piloto... 192 8.1.2. Alcances del Plan Piloto... 196 8.2. Aspectos de manejo del cambio.... 196 8.3. Generalización de la experiencia... 199 9. Resultados, Conclusiones y Recomendaciones... 27 9.1. Resultados... 27 9.2. Conclusiones... 28 9.3. Recomendaciones... 29 9.3.1. Recomendaciones aplicadas al proyecto... 29 9.3.2. Recomendaciones generales.... 21 1. BIBLIOGRAFÍA... 211 11. ANEXO 1: DISEÑO DE PROCESOS BASADO EN PATRONES DE NEGOCIO ORIENTADO A LA GESTIÓN, PRODUCCIÓN Y PROVISIÓN DE BIENES O SERVICIOS... 213 11.1.1. Apoyo computacional... 224 12. ANEXO 2: CMMI... 226 12.1. Componentes... 231 13. ANEXO 3: ITIL... 235 13.1. Certificación... 237 13.2. Historia y precursores de ITIL... 238 13.3. Visión general de la biblioteca... 24 14. ANEXO 4: MÉTRICA DE PUNTO FUNCIÓN... 243

1. PLANTEAMIENTO Y MOTIVACIONES INICIALES DEL PROYECTO 1.1. Antecedentes de la empresa Gestión y Transmisión Electrónica Sociedad Anónima ó Edi-Trade S.A. se constituyó con fecha 9 de septiembre de 1994. Posteriormente, con fecha 22 de diciembre del mismo año los socios constituyentes repactaron la sociedad. Edi-Trade S.A., desde ahora denominada Edi-Trade, es una empresa del rubro Tecnologías de Información, desde ahora denominado TI. Edi-Trade nació el año 1994 bajo la asociación de una casa de software 3xCom Ltda., el grupo editorial Publitecsa - Proman Normatec, de propiedad de Inversiones y Servicios Gráficos Ltda., y la entidad gremial Cámara Aduanera de Chile A.G.. Esta última convocó a las dos anteriores para formar una empresa cuya finalidad sería desarrollar e implementar un servicio de transmisión electrónica de datos EDI para los Agentes de Aduana, apoyado por un software de gestión aduanero y contable, y servicios de información electrónicas. Esto se cumplió cabalmente, llegando a acaparar hasta el 9% de la transmisión EDI entre los Agentes de Aduana y el Servicio Nacional de Aduana. Desde aquel tiempo los requerimientos del mercado han cambiado, siendo el Software de Gestión Aduanera el producto estrella de la empresa. Así también ha cambiado la estructura societaria, conformada por un grupo de personas relacionadas con la TI, contenido editorial y comercio exterior en un 58% y la Cámara Aduanera de Chile en un 42%. Esto le ha permitido a la empresa tener una visión más amplia del mercado, mirando fuera del nicho inicial del mercado de agentes de aduanas. 1

1.2. Situación actual Actualmente, Edi-Trade tiene en el mercado, un software llamado Sistema Integrado de Gestión Aduanera SIGAD. Dicho software es la segunda versión de un sistema orientado a las agencias de aduana para la confección de declaraciones de importación, exportación y otros regímenes aduaneros, como también para su gestión administrativo contable. En rigor, el sistema SIGAD se divide en dos sub-sistemas: uno aduanero y, el otro administrativo contable, ambos construidos en arquitectura cliente/servidor, desarrollados para plataforma cliente Windows en Borland Delphi 5 y con base de datos Firebird 1. bajo plataforma Linux. A los sistemas antes mencionados se le adicionan módulos en ambiente web llamados: Agencia en línea: permite a los clientes de la agencia de aduana obtener información en línea de sus despachos y cuentas corrientes. COMEX: permite a los clientes de la agencia de aduana ingresar la información de sus órdenes de compra, para hacerles seguimiento y gestión, además de alimentar el sistema SIGAD con información para cada despacho. Este módulo también permite realizar outsourcing de comercio exterior. Al igual que los anteriores, hay otros sistemas que complementan el uso del sistema antes descrito, como por ejemplo: Sistema de transmisión EDI mediante software EDIGATE que accede a VAN privada Edi-Trade: permite a los agentes de aduana enviar y recibir documentos electrónicos en formato EDI, XML o plano al S.N.A., con altos estándares de seguridad. Sistema de facturación electrónica FACTURE: permite la generación, 2

transmisión al SII, intercambio y publicación de documentos tributarios electrónicos DTE. En el último tiempo, Edi-Trade ha ingresado al mercado de la información electrónica, proveyendo sistemas de información en línea que interactúan con su sistema de gestión aduanera SIGAD. Los sistemas mencionados son: Arancel electrónico SAETA: es un sistema que permite consultar la información arancelaria de las distintas mercancías involucradas en un despacho aduanero. Esta información incluye: clasificación arancelaria, advalorem, datos de acuerdos y tratados de libre comercio, más observaciones varias. Movimiento marítimo portuario Mytilus: al igual que el anterior, este sistema interactúa con el sistema SIGAD proveyendo información del las ETAs de todos los barcos que recalan en puertos chilenos con su respectivo seguimiento alrededor del mundo. Todos estos sistemas y servicios han permitido a Edi-Trade posicionarse fuertemente en el mercado de los Agentes de Aduana, ganando cerca del 85% de dicho mercado, fidelizando a sus clientes a través de estos módulos y servicios de valor agregado, produciendo el llamado lock-in. 1.3. Organización de la empresa La empresa se organiza en tres departamentos, más algunas personas para el apoyo administrativo, contando con una planilla permanente de 35 personas. Los departamentos que componen la empresa son: Departamento de sistemas: Encargado del desarrollo y mantención del Sistema de Gestión Aduanera y Contable SIGAD y sus módulos asociados: Agencia en Línea y Comex. 3

Departamento de proyectos: Encargado del desarrollo y mantención de todos los otros productos y servicios, como lo son los sistemas de mensajería e intercambio electrónico de documentos, factura electrónica, sistemas de información en línea y sistemas internos de monitoreo y gestión. Departamento comercial: Encargado de las ventas, mantención de cartera y soporte post venta. 1.4. Tamaño de mercado Desde el inicio de sus actividades en 1994, Edi-Trade ha logrado conquistar el 85% del mercado de los Agentes de Aduana, contando con 188 agentes de aduana usuarios de alguna de las aplicaciones que provee la empresa para la generación y elaboración de destinaciones aduaneras. A lo que se agregan 6 consignantes y consignatarios con licencia para despachar, 1 almacenista y 1 empresa courrier. Cabe destacar que los 188 agentes clientes de Edi-Trade representan el 82,8% del universo de Agentes del sistema y hoy ellos generan dicho 85% del volumen de transacciones mensuales. En consecuencia, hay 43 Agentes de Aduana que no son clientes de Edi-Trade, entre los que se cuentan aquellos que no son potenciales clientes dada su baja cantidad de despachos mensuales. 1.5. Nuevos clientes A principios del año 26 se estableció que debían aumentarse los ingresos vía venta de productos nuevos a los clientes del sistema de gestión y, por otra parte, posicionar los productos en mercados distintos al del agenciamiento aduanero. Los nuevos clientes provendrán de otros nichos de mercado del área de comercio exterior, siendo los más atractivos los importadores y exportadores. También hay otras áreas que se pueden atacar, como por ejemplo, el mercado de las empresas courrier, transportes nacionales y embarcadores. Todas estas forman parte de la operación de comercio exterior, las cuales tienen necesidades de software de gestión, intercambio 4

de información e información normativa y de mercado. Edi-Trade pretende abordar estos nichos de mercado aprovechando la experiencia que posee en el mercado, la cual ha obtenido a lo largo de los años de servicio a los agentes de aduana. Además existe la posibilidad de integrar las cadena de valor de los distintos nichos mediante la transmisión electrónica de datos entre los software de gestión de éstos. 1.6. Evaluación de la empresa A grandes rasgos la empresa se evalúa como exitosa, debido a que ha sabido posicionarse muy bien en su nicho de mercado, llegando a abarcarlo en un 85%. A esto debe sumarse un constante crecimiento en productos y servicios enfocados a su área de mercado, lo que ha transformado a la empresa en un aliado estratégico de sus clientes. Recientes encuestas realizadas por el Departamento Comercial demuestran un excelente grado de conformidad de sus clientes con el producto. Sin embargo, los clientes evalúan en muy mala forma al servicio de soporte post venta que brinda la empresa, principalmente en lo que se refiere a tiempos de respuesta. Esto representa una oportunidad de mejora para abordar en este proyecto ya que este servicio afecta directamente a la calidad del servicio, lo que a su vez, afecta a la competitividad. En cuanto al desarrollo de software de los Departamentos de Sistema y de Proyectos, sus resultados son bien evaluados por buena parte de los clientes, ya que cumple en su gran mayoría con sus necesidades. No obstante hay casos en que se manifiesta cierta disconformidad con la demora del desarrollo de los requerimientos. La evaluación interna de los departamentos anteriormente mencionados también es buena, ya que se cumplen los objetivos. Sin embargo, se tiene presente que el proceso de desarrollo se puede mejorar, haciéndolo más eficiente e incorporando herramientas 5

de gestión y control que permitan llevar un mejor control del rendimiento de programadores e ingenieros, como también controlando mejor los plazos de entrega y tiempos críticos. Estos dos últimos puntos representan otra oportunidad de mejora en el transcurso del proyecto, ya que la eficiencia operacional influye directamente en la competitividad de la empresa. 1.7. Modelo de negocios El modelo de negocios de la empresa consiste en lograr que la experiencia del uso de nuestros sistemas y servicios demuestre eficiencia operacional a los clientes, mediante la integración de nuestras soluciones tecnológicas a sus cadenas de valor. A su vez, gracias a la captación de nuevos clientes también participantes de la cadena de comercio exterior, pero pertenecientes a otros nichos de mercado, que utilicen las soluciones desarrolladas por nosotros, aportarán a la eficiencia operacional esperada. Esto debido a que todos nuestros clientes contarán con la ventaja y facilidad de integrarse verticalmente, constituyendo una red de valor agregado, partiendo del principio de que la información será compartida y podrá circular a través de las diferentes cadena de valor, integradas de forma fluida y precisa. 1.8. Análisis de la empresa 1.8.1. Análisis de las fuerzas de Porter La figura que se muestra a continuación evidencia cómo actúan las cinco fuerzas, descritas por Porter, en el ámbito global de Edi-Trade. Éstas actúan en el ámbito externo y son clave al momento de determinar si el medio es propicio para 6

cumplir con los objetivos planteados y si las estrategias planteadas son las adecuadas. Figura 1.- Fuerzas de Porter Nuevos Nuevos Participantes Participantes Organismos estatales con otro modelo de negocios Proveedores Proveedores Existen sustitutos que hoy en dia son una amenaza Competidores Existe la amenaza de nuevos participantes Competidores Compradores Rivalidad Compradores Rivalidad No existen amenazas significantes por parte de los compradores Sustitutos Sustitutos 1.8.1.1. Nuevos participantes No existe una amenaza considerable de un nuevo participante ya que Edi- Trade es prácticamente la única empresa EDI existente en el mercado, lo que en sí constituye una importante ventaja competitiva al proveer conjuntamente servicios de software y transmisión EDI, dando una solución integral. Disponer de los sistemas EDI puede considerarse una fortaleza al garantizar la no interrupción de negocios en los eventos de fallas en la Internet, sin embargo, debe tenerse en consideración que este es un negocio en franca declinación. Tampoco se visualiza una amenaza de nuevos participantes en el mercado de los software especializados en gestión aduanera y de comercio exterior; la que pudiera ser importante si se considera que, por una parte, el desarrollo de sistemas similares a los provistos por la compañía con un fin meramente comercial se ha dado en el último tiempo y la compañía ha mantenido su posición cuasi-monopólica. Sin 7

embargo, no debe despreciarse el intento de una empresa dedicada a la provisión de información de comercio exterior de apoyar a un proveedor de sistemas de gestión aduanera mediante alianzas estratégicas, modelo de negocio implementado por la compañía hace algunos años. 1.8.1.2. Proveedores Si bien el mercado proveedor constituye muchas veces un factor tanto o más crítico que el mercado consumidor, como se trata de un servicio, tiene una dependencia extrema de la calidad de la mano de mano de obra. No obstante, el mercado de técnicos computacionales es abundante, por lo que no sugiere una mayor amenaza; apariencia que pudiere estimarse objetable por cuanto algunos proveedores son o pueden ser potenciales competidores, por el conocimiento que logran tener de las aplicaciones de la compañía. amenaza. Por otra parte, no existen insumos importantes que impliquen una Sin embargo, existe una limitante que tiene que ver con el servicio de transmisión electrónica de documentos en sí. Para que pueda existir es necesario que participen tres entidades como se muestra en la siguiente figura: a)cliente b) Proveedor (Edi-Trade) c) Organismos reguladores (Servicio Nacional de Aduana SNA, Servicio de Impuestos Internos SII) El cliente demanda del proveedor los posibles servicios, ya que a un bajo costo reemplaza una considerable cantidad de recursos humanos por tecnología, sin embargo, por mucho que el proveedor esté dispuesto a desarrollar estos servicios, es 8

necesario que el organismo regulador acepte ese medio de comunicación y, a su vez, desarrolle un sistema que sea capaz de recepcionar los formatos de mensajes. Por lo general, el organismo regulador es bastante más lento que el proveedor y eso dificulta o influye en la creación de nuevos productos. 1.8.1.3. Compradores Los compradores son más una fuerza positiva que una negativa. Ellos desean y necesitan de estos servicios para poder ser más competitivos. 1.8.1.4. Productos substitutos Los productos substitutos se consideran una amenaza considerable, debido a que en la actualidad la circunstancia favorecedora de contar con sistemas aduaneros y servicios EDI, como los que ofrece Edi-Trade, ya no se aprecia como un servicio insustituible por parte importante del mercado. Además, hoy los agentes de aduana están dispuestos al cambio tecnológico, aún a un gran costo, por lo que las aplicaciones de gestión aduanera existentes, entre ellas las de la compañía, se están mudando para añadir nuevas tecnologías a fin de adecuarse a los anuncios de los organismos reguladores (SNA y SII). Por otra parte, también existen productos substitutos para otros servicios que presta Edi-Trade, por ejemplo, para la emisión de Documentos Tributarios Electrónicos DTE, los que en razón del precio al que son ofertados, constituyen una amenaza considerable. 1.8.1.5. Competidores Existe la rivalidad de competidores actuales, sin embargo, no es muy 9

grande. Esto le ha permitido a la compañía mantener un sostenido crecimiento en la cantidad de clientes, pero el peligro que implica la sombra de nuevos competidores obliga a levantar nuevas barreras de entrada, como un Comex inteligente, que evite la captura del mercado de Edi-Trade. Los factores que determinan que la entrada de nuevos competidores sea muy poco atractiva son: gran crecimiento de la industria, costos hundidos en investigación y existen intereses estratégicos creados (la Cámara Aduanera es la asociación gremial de los Agentes de Aduanas). Como conclusión de este análisis se puede determinar que la empresa es sobria, afincada y estable, ya que se tiene un crecimiento parejo en el tiempo. No obstante esto, no se está logrando tener una rentabilidad interesante para los dueños, por lo que se necesita dar un salto: mejorar la rentabilidad de forma que lo dueños estén satisfechos. 1.8.2. Análisis FODA empresa. Otro enfoque de análisis es el que compara diversas variables de la Análisis FODA - Fortalezas Oportunidades FORTALEZAS OPORTUNIDADES Alta experiencia del negocio de los agentes de aduana. Mantener y aumentar la participación en el mercado de sistemas aduaneros. Único proveedor con servicios integrales en agenciamiento aduanero y Tecnología EDI de comunicaciones, que permite entregar un sistema de respaldo 1

con la confianza del mercado. Sustentado en aproximadamente 188 agentes que usan nuestros sistemas. único para la transmisión electrónica vinculada con la gestión aduanera y que constituye una opción estratégica para ciertos usuarios. Acceso al conocimiento de las operaciones de comercio exterior de empresas con experiencia en Outsourcing y de los clientes de estos, para el desarrollo de sistemas de comercio exterior. Compromiso y confianza de un importante segmento de clientes en la gestión de la compañía. Acceso a otros mercados vinculados al comercio exterior, distinto del Agenciamiento de aduanas. Aprovechar el nuevo conocimiento para insertar distintas propiedades al sistema de comercio exterior útiles para una importante cantidad de clientes (empresas), el cual una vez aceptado, es difícil cambiar. Recoger de ellos cuales elementos de la empresa los satisfacen plenamente y cuales se pueden mejorar y con ello generar marketing en el mercado meta. Importante portafolio de proyectos por desarrollar, solicitados por algunos clientes y de clara colocación en el universo de la cartera. Crecimiento de la empresa vía la inserción en un nuevo nicho de las empresas importadoras y exportadoras de los distintos rubros y tamaños para generar nuevos ingresos. Bajo costo de mantención de los nuevos proyectos, debido a que se cuenta con personal adecuado para Aumentar la competitividad de la empresa, a través del aprovechamiento óptimo de los recursos humanos y la distribución de 11

estas labores. tareas de mantención de sistemas por área de aplicación especifica. Alto nivel tecnológico de nuestros desarrollos, los cuales exigen y producen importantes reformas en nuestros clientes. Visión de complejidad del ámbito donde la empresa se desarrolla, el que es apañado y permite traspasar el conocimiento a los clientes (asesores de los clientes). Recepción positiva de los clientes al momento de evaluar sistemas similares, ya que este punto de asesoramiento en tecnología y otros aspectos de la implementación de los sistemas, refuerza las capacidades. Se podría llamar a este punto, Credibilidad con Resultados Análisis FODA Debilidades Amenazas DEBILIDADES AMENAZAS Dificultades financieras. Obstáculo para acometer nuevos proyectos. Imposibilidad de sostener los costos de operación, con el evidente riesgo de degradar la prestación de servicios. 12

Preocupación y temor de todo cliente de operar y fortalecer una estructura de mercado monopólica u oligopólica en su área de trabajo crítica. Favorecer a competidores que, por su tamaño, no pueden influir en el precio o se opte por desarrollos internos, especialmente en el área de información a sus clientes (web). Demasiada concentración en un nicho específico: auxiliares de una función pública, sin abarcar otros estamentos del mercado con las mismas herramientas. Sustitución de la industria por una decisión de la autoridad. 13

Poca disponibilidad para la entrega oportuna de los productos, salvo el aduanero. Esto es, no contar con el respaldo humano suficiente para atender el crecimiento y nuevos desarrollos a la velocidad requerida por los clientes, así como mejorar considerablemente la calidad de servicio. Insatisfacción de los clientes. Agrupamiento de los clientes insatisfechos para potenciar otro sistema que existe o se genere, dando pie para la inserción de otras empresas de software en el cliente (ejemplo: Consultis), o permitiendo el fortalecimiento de las ya existentes, al tener todos los recursos humanos sin disponibilidad y no exista cabida para pequeños desarrollos particulares. Estructura societaria que establece que el control político de la compañía sea ejercido por sus propios clientes. Posibles decisiones fundadas en criterios corporativos más que comerciales. Falta de herramientas de trabajo más eficientes para la operación diaria, llámese software, equipos y capacitación en elementos críticos. Pérdida de oportunidades cruciales para atender a tiempo los proyectos. Que la excesiva carga de sistemas a mantener (alta carga operacional), genere respuestas lentas a soluciones de detalles y por lo tanto se debilite la imagen de gestión o de la calidad de nuestros servicios y/o productos. Necesidades y requerimientos de Aunque no responden a decisiones 14

desarrollo muy cambiantes por factores propios de la actividad y cada vez más complejos. internas, influyen indirectamente en la posibilidad de generar la caducidad de los productos e impide cuantificar los desembolsos. 1.8.3. Diagnóstico de la cadena de valor Para realizar el diagnóstico de la cadena de valor se han tomado los años 25 y 26 debido a que se disponía de toda la información, no siendo ésta la situación para el año 27. Además, se han llevado los valores a porcentajes, para simplificar la visión del análisis. En la siguiente figura se puede observar que en el año 26 se movilizó mayor cantidad de dinero durante el año, pero también aumentaron los costos operativos a un 9%, con lo cual el resultado operacional se redujo a un 1%. Con esto se puede concluir que la empresa disminuye peligrosamente su margen operacional, lo que debe ser revertido. 15

Figura 2.- Resultados operacionales 25 v/s 26 Margen 12% Costo 88% 25 Margen 1% Costo 9% RRHH 84% Insumos 14% Tecnología 2% 26 ResultadoOperacional 12% 1% Realizando un análisis más riguroso en los costos del periodo 26, se ha hallado que la mayor proporción de éstos corresponde al pago de los Recursos Humanos (84%), lo cual produjo un segundo análisis más fino, teniendo como foco la cadena de valor, y dentro de ella, las actividades directas y de apoyo. 1.8.3.1. Cadena de valor y recursos humanos en detalle Se han separado las actividades directas y las de apoyo dentro de la cadena de valor de la empresa, para esclarecer cómo se encontraba distribuido el pago de los recursos humanos (84%) dentro de ésta. En la siguiente imagen se visualizan todas las actividades directas y de apoyo implicadas en la cadena de valor de la empresa, aunque las que son foco de atención para este análisis porque están en vinculación directa con los recursos humanos, son: 16

Actividades directas: Servicio Técnico y Soporte a clientes, Desarrollo Nuevos Proyectos, Desarrollo de Mejoras Productos Actuales, Venta, Marketing y Post Venta. Actividades de apoyo: Recursos Humanos, Gestión Superior. Figura 3.- Margen de explotación Margen Costodeactividades directas Serviciotécnicoy SoporteaClientes Desarrollo Nuevos Proyectos Desarrollo DeMejoras Productos actuales Venta, Marketingy Postventa Costos deactividades deapoyo Recursos Humanos Insumos Tecnología Gestión Superior La distribución por cada actividad se puede ver en la siguiente tabla: Distribución de costos por actividades Actividades Directas Proporción Servicio Técnico y Soporte a Clientes 29% 17

Desarrollo de nuevos Proyectos 14% Desarrollo de Mejoras a Productos Actuales 22% Venta, Marketing y Postventa 11% Actividades Indirectas Proporción Recursos Humanos 4% Gestión Superior 21% Después de realizar la distribución del costo de recursos humanos por cada actividad dentro de la cadena de valor, se agregaron los porcentajes en las Actividades Directas y Actividades de Apoyo, donde se visualiza que las primeras utilizan un 76% en la distribución, y las segundas, un 24%. En la figura siguiente se puede observar tal distribución. Figura 4.- Distribución de costos por actividades 29% Act.Directas 76% Act.Apoyo 24% 21% 22% 4% 14% 11% Con esta última información se puede llegar a la conclusión de que, a pesar de que los costos de recursos humanos sean elevados, se requiere de éstos 18

para poder operar eficientemente e innovar, y con ello mantenernos como líderes del mercado, por lo cual estos costos están alineados con la estrategia. 1.8.4. Estrategia actual de Edi-Trade La empresa se encuentra embarcada en la diversificación de productos y expansión a otros nichos de mercado, buscando nuevos clientes implicados en el ámbito del comercio exterior y hallando nuevas fuentes de crecimiento. Como empresa implicada en el ámbito TI, es indispensable evolucionar e innovar en las soluciones que ofrece, y es por este motivo que también se definieron como parte del plan estratégico el cambio del centro del negocio de Sigad 1 a Comex 2, para ampliar el mercado. 1.8.5. Análisis de los actuales procesos En Edi-Trade se pueden identificar tres macroprocesos tipo macro 1 (cadena de valor) los cuales tienen muy poca interacción entre sí: SIGAD) Proceso de Desarrollo y Mantención del Sistemas (gestión aduanero y contable 1 Sistema de Gestión Aduanera. Plataforma Cliente - Servidor 2 Sistema de Comercio Exterior. Sistema modular utilizando una plataforma Web 19

Proceso de desarrollo y mantención de Proyectos varios Proceso de Atención a Clientes. 2

Figura 5.- Distribución de costos por actividades Requerimientos Ideas Requerimientos Ideas Solicitud de Atención Solicitud de Soporte HH Ingeniería y Programación Desarrollo de Sistemas Sistema de Gestión dunera y Contable HH Ingeniería y Programación Desarrollo de Proyectos Productos y servición de intercambio Electrónico de Datos, Proycetos de software y servición de información en línea Nuevas tecnologías HH Técnicos de Soporte y Personal de Ventas Atención al Cliente Servicio de Soporte, Atención al cliente y ventas Instrucciones Arquitectura de empresa actual Concentrar fácilmente los recursos en los productos y servicios que brindan mayor retorno a la empresa. Ha funcionado hasta el momento. Las principales carencias de este modelo de negocio son: No hay una infraestructura tecnológica que permita la óptima integración, gestión y control de los diferentes procesos. 21

No hay gestión y control formal sobre los diferentes procesos. Producto de lo anterior, en varias ocasiones, se postergan más de la cuenta algunos requerimientos, ideas, solicitudes de atención o soporte, debido a que no se priorizan o se quedan en el limbo. Los procesos de desarrollo, sistemas, y desarrollo de proyectos no trabajan en forma integrada, duplicándose los esfuerzos. Los distintos procesos se concentran en alcanzar sus propios objetivos, lo que deja en segundo plano la colaboración a que los otros procesos también alcancen sus objetivos. Tiene capacidad limitada. No se atiene a ningún estándar y al ser carente de una gestión eficiente, es difícil pensar en algún tipo de certificación. En épocas de mayores requerimientos se producen grandes niveles de estrés en los empleados, debido a que se requiere de recursos humanos difícilmente reemplazables y aumentables en forma inmediata. 22

2. MARCO TEÓRICO 2.1. Diseño de procesos basado en patrones de negocio orientado a la gestión, producción y provisión de bienes o servicios Para el rediseño de los procesos y el posterior diseño e implementación de la herramienta computacional de apoyo hemos elegido la técnica de Diseño de Procesos Basado en Patrones de Negocio. Esta es una metodología creada por el Dr. Oscar Barros V. que ha demostrado ser un excelente modelo de completitud, el cual permite minimizar el riesgo y esfuerzo en cuanto a modelamiento de procesos de negocio se refiere. Esto se logra basado en la experiencia de muchas empresas que han sido estudiadas y analizadas por el Dr. Barros para determinar el patrón de procesos de negocio. Dicho patrón será utilizado como base para modelar la arquitectura de procesos de negocio enfocada en el negocio del proyecto. Esto permite realizar un modelo en el cual evitamos pasar por alto los subprocesos, los flujos y relaciones esenciales entre ellos. Por consiguiente, se minimiza el riesgo de un modelo incompleto, un problema bastante clásico en los proyectos de diseño de herramientas de apoyo computacional, en las cuales se depende del conocimiento del negocio que pueda obtenerse de los actores y ejecutores de este. Los modelos del Dr. Barros, llamados Macroprocesos, se clasifican según el área del negocio que cubren: Macro 1: Gestión, Producción y Provisión de Bienes o Servicios. Macro 2: Desarrollo de Nuevos Productos y Servicios Macro 3: Planificación del Negocio Macro 4: Procesos de Apoyo: Financieros, RR.HH., Infraestructura, etc. 23

El caso de este proyecto se utilizará Macro 1: Gestión, Producción y Provisión de Bienes o Servicios, ya que el proyecto se enfoca en rediseñar los procesos de la cadena de valor de Edi-Trade. 2.1.1. El apoyo de la macro 1. La Macro 1 brinda un patrón de cómo se interrelacionan los diferentes subprocesos dentro de la cadena de valor. 24

Figura 6.- Patrón Genérico Macro 1, Gestión, Producción y Provisión de Bienes o Servicio En la figura se puede ver cómo los cinco subprocesos de la cadena de valor se interrelacionan y retroalimentan. En el Anexo 1 se explica en detalle cada subproceso y su descomposición. El diagrama de la figura está hecho en lenguaje IDEF, éste representa un patrón general de la cadena de valor de cualquier negocio. Este diagrama es el punto de partida para modelar la cadena de valor de cualquier negocio. Utilizando este patrón, se asegura que obtendremos un rediseño ordenado inteligentemente según el área del negocio (atención a clientes, atención a proveedores, planificación de producción y entrega, y producción). 25

El modelo del patrón cuenta con un segundo nivel de definición descrito en el Anexo 1 de este informe. Caracterizando los nombres de los subprocesos y flujos, especializamos el patrón al negocio de interés, el cual a su vez, puede ser utilizado como un nuevo patrón especializado de un dominio, en nuestro caso: el desarrollo y mantención de software. De esta forma se amplía la técnica a dominios de negocio especializados. El patrón resultante (desarrollo y mantención de software) constituye el punto de partida para modelar sub-dominios de este, por ejemplo, el sub-dominio: desarrollo y mantención de software de gestión y control para agencias de aduana. Para lograr la especialización del patrón en el dominio que está en desarrollo, se recurre a la experiencia del experto en el negocio. Tradicionalmente, la comunicación ha sido un problema entre el experto del negocio y el experto informático, ya que ambos hablan lenguajes diferentes (lenguaje del negocio y lenguaje informático). Estos diagramas son un excelente lenguaje común para que logren comunicarse efectivamente. 2.1.2. Lógica de negocios El proyecto contempla la mejora de los procesos, por lo tanto, es necesario incorporar experiencia adicional al modelo en re-diseño. Esta experiencia se obtendrá de las mejores prácticas de la industria que se obtienen de estudios especializaos de este dominio, como lo son CMMI e ITIL. El resultado será un modelo de procesos especializado en el dominio, que abarca las mejores prácticas de la empresa y las mejores prácticas de la industria. Las mejores prácticas de la empresa e industria se plasman en el tercer nivel del modelo. El patrón genérico Macro 1, cuenta con dos niveles, siendo el tercer nivel la descomposición de los subprocesos del segundo nivel en tareas. A este nivel se le llama Lógica de Negocio y refleja en detalle el funcionamiento del negocio. Al modelar 26

dicha lógica en lenguaje BPMN, se pueden realizar simulaciones que permiten estudiar la performance del proceso modelado. Al simular los procesos se puede determinar tempranamente las falencias que éste pueda presentar y corregirlos para que el rediseño sea óptimo. 2.1.3. Diseño de la herramienta computacional De la lógica de negocios se modelará un cuarto nivel del modelo, el que se compone de los diagramas del tercer nivel con la adición de la herramienta computacional. De esta forma, el modelo reflejará la lógica de procesos de negocio que deberá ejecutar esta herramienta y los flujos de interacción con las tareas que ejecutarán los diferentes actores. El resultado de este modelo es una orquestación fiel entre procesos de negocio y procesos computacionales. 2.1.4. Más Información Para obtener más información con respecto al Diseño de Procesos Basado en Patrones de Negocio Orientado a la Gestión, Producción y provisión de bienes o Servicios, referirse al Anexo 1 de este informe. 2.2. CMMI CMMI es un framework de la mejores prácticas de la industria en áreas como el desarrollo de productos y adquisiciones. Para efectos de este proyecto, interesa el aporte que realiza en el área de desarrollo de software: grado de madurez ha alcanzado en una empresa. En la implementación de estas prácticas, el mercado establece un punto de comparación estándar que permite determinar a priori la calidad del trabajo que éstas realizan. Hoy en día CMMI es ampliamente utilizado por las 27

software factory como medio de certificación de su calidad productiva. La evaluación de CMMI presenta 5 grados de madurez, los cuales parten del nivel 2. Para alcanzar este nivel, una empresa desarrolladora de software debe implementar siete de las veintidós áreas de procesos definidas por CMMI. Para alcanzar el nivel 3 se requiere implementar once más, dos más para el nivel 4 y otras dos para el nivel 5. La implementación y certificación de CMMI es costosa y requiere de bastante personal para cubrir los procesos definidos por el estándar. Los altos costos que la certificación implica son justificados para las fábricas de software, en donde poseer dicha certificación es requisito para adjudicarse los proyectos y el medio de marketing para la captura de clientes. Edi-Trade es una fábrica de software cuyo objetivo es desarrollar y mantener los productos de software con los cuales presta servicio. Los planes estratégicos actuales 3 no justifican la implementación y certificación de CMMI. Sin embargo, sí justifican la implementación al menos del nivel 2, ya que las áreas de procesos que se pretenden mejorar a través de este proyecto son las mismas o están en estrecha relación con lo propuesto por el estándar. Por lo tanto no es necesario reinventar la pólvora. También es importante considerar, como ya se explicará más en adelante 4, que no existen soluciones infalibles, es decir que la implementación de un estándar no es siempre la forma más adecuada de lograr los objetivos de calidad y mejora de procesos que se desean. El estándar descrito es desarrollado en otras realidades y otras culturas. Lo que se propone en este proyecto, es recoger lo mejor del éste y adaptarlo a la cultura local, sin dejar de lado los actuales procesos que deben ser el marco referencial, o 3 Los planes estratégicos de Edi-Trade están definidos en los proyectos de Adriana Parceisa, que se desarrolla paralelamente a este. 4 Referirse al punto 3.4 de este informe: Fundamento Teórico Práctico del Proyecto. 28

punto de partida, para la definición de los nuevos procesos. Las 22 áreas de proceso abarcados por CMMI son: 1. Análisis de Causas y Resolución (CAR) 2. Gestión de la configuración (CM) 3. Análisis de Decisiones y Resolución (DAR) 4. Gestión Integrada de Proyectos (IPM) 5. Medición y Análisis (MA) 6. Innovación y Despliegue Organizacionales(OID) 7. Definición de procesos organizacionales (OPD) 8. Enfoque Organizacional en Procesos (OPF) 9. Rendimiento de Procesos Organizacionales (OPP) 1. Formación Organizacional (OT) 11. Monitorización y Control de Proyecto (PMC) 12. Planificación de proyecto (PP) 13. Aseguramiento de Calidad de Procesos y Productos (PPQA) 14. Integración de Producto (PI) 15. Gestión Cuantitativa de Proyectos (QPM) 16. Gestión de Requerimientos (REQM) 17. Desarrollo de Requerimientos (RD) 18. Gestión de Riesgos (RSKM) 19. Gestión de Acuerdos con Proveedores (SAM) 2. Solución Técnica (TS) 21. Validación (VAL) 22. Verificación (VER) Cada una de esta áreas se implementa de acuerdo a un nivel de capacidad. El conjunto de la PA (Áreas de Proceso) con su respectivo CN (Nivel de Capacidad) 29

determina el Nivel de Madurez de CMMI. Los niveles de capacidad están definidos de la siguiente forma:. Incompleto: El proceso no se realiza o no se consiguen sus objetivos. 1. Ejecutado: El proceso se ejecuta y se logra su objetivo. 2. Gestionado: Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos. 3. Definido: Aparte de ser un proceso gestionado, se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa. 4. Cuantitativamente gestionado: Junto con ser un proceso definido, se controla utilizando técnicas cuantitativas. 5. Optimizando: el proceso es cuantitativamente gestionado, pero se va más allá: de forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio. Hay una mejora continua. Las áreas que abarcaremos en el proyecto son: 1.Gestión Integrada de Proyectos (IPM) 2.Definición de procesos organizacionales (OPD) 3.Monitorización y Control de Proyecto (PMC) 4.Planificación de proyecto (PP) 5.Aseguramiento de calidad de Procesos y Productos (PPQA) 6.Integración de Producto (PI) 7.Gestión Cuantitativa de Proyectos (QPM) 8.Gestión de Requerimientos (REQM) 9.Desarrollo de Requerimientos (RD) Estas nueve áreas de proceso aportan las mejores prácticas necesarias para 3

cumplir con los objetivos del proyecto, las cuales se implementarán a nivel de capacidad 3. Es demasiado ambicioso implementarlos en un nivel de capacidad mayor. Además, no es una tarea sencilla y, como ya se explicó, los costos en cuanto a recursos son bastante altos. El proyecto ya está propuesto de forma ambiciosa y no se quiere poner en riesgo los objetivos planteados: diseñar e implementar la arquitectura de procesos acorde a las necesidades de la compañía y desarrollar e implementar la herramienta computacional de apoyo. Se pavimentará el camino para una futura implementación formal de CMMI en caso de que el plan estratégico de la empresa así lo determine. Para obtener más información con respecto a CMMI, referirse al Anexo 2 de este informe. 2.3. ITIL Análogamente a CMMI, la Biblioteca de Infraestructura de Tecnologías de Información ( Information Technology Infrastructure Library ), abreviada ITIL, es el framework de las mejores prácticas destinadas a facilitar la entrega de servicios de TI. Mientras que CMMI se especializa en éstas para la producción de un producto TI, ITIL se compone de las mejores prácticas para la prestación de servicios relacionados con TI. En una software factory suelen combinarse estos dos estándares para asegurar la calidad de la producción y prestación de servicios TI. En el caso de Edi-Trade, su realidad no es distinta: la compañía produce y brinda servicios TI. Un ejemplo de esto es la producción y mantenimiento del software SIGAD, para el cual se brinda el servicio de transmisión electrónica de datos, mesa de ayuda y actualización de versiones. Al igual que con CMMI, el objetivo del proyecto no es certificar a la empresa en la implementación de ITIL, sino que adoptar las mejores prácticas, adaptarlas al contexto y cultura de la empresa, mejorando los actuales procesos a través de dichas prácticas. 31

ITIL abarca dos áreas: Prestación de Servicios y Soporte al Servicio; y provee siete guías operativas: 1. Gestión de la infraestructura de TI 2. Gestión de la seguridad 3. Perspectiva de negocio 4. Gestión de aplicaciones 5. Gestión de activos de software 6. Implementación la Gestión de Servicios 7. Implementación de ITIL a pequeña escala La Prestación de Servicios dice relación con lo requiere el servicio para proveer un soporte adecuado a los clientes del negocio. Ésta se compone de: Gestión del Nivel de Servicio Gestión Financiera de Servicios TI Gestión de la Capacidad Gestión de la Continuidad del Servicio de TI Gestión de la Disponibilidad De la Prestación de Servicios, en este proyecto, sólo se abordará la Gestión del Nivel de Servicio y la Gestión de Disponibilidad. Los otros procesos nos alejan del objetivo del proyecto impuesto por la planificación estratégica. Queda abierta la puerta para complementar los procesos de Prestación de Servicios, en un nuevo proyecto, cuando la planificación estratégica de la compañía así lo requiera. Por otro lado, el Soporte al Servicio consiste en asegurar que los usuarios o clientes tengan acceso a los servicios apropiados que soportan las funciones del negocio. El Soporte al Servicio se compone de los siguientes procesos: Centro de Servicio al Usuario 32

Gestión del Incidente Gestión del Problema Gestión de la Configuración Gestión del Cambio Gestión de la Entrega En esta área será necesario entrar en detalle de los seis procesos mencionados. Para los procesos ITIL abordados en el proyecto, se estudiará la propuesta ITIL y se constatará con los procesos de Edi-Trade. Luego, se elaborará una propuesta de mejora a los actuales procesos de la empresa, la cual será revisada en conjunto con los jefes de área involucrados en la ejecución y gestión de los procesos y simulados a través de la herramienta igraf. De esta forma obtendremos la propuesta de mejora definitiva, basándose en las técnicas definidas por el Dr. Barros y descritas en el Anexo 1 de este informe. Para más información acerca de ITIL, se debe consultar el Anexo 3 de este informe. 2.4. Métrica de Punto Función Las métricas de punto función son técnicas utilizadas para medir el tamaño de un software. Estas técnicas permiten tener una base comparativa común para comparar el tamaño de software desarrollados en distintas plataformas y leguajes. La técnica se basa en métodos de recuento de diferentes variables que se ponderan por factores correspondientes a la influencia que estas variables poseen sobre el tamaño del software. Luego, se suman los valores resultantes de la ponderación de cada una de las variables con su respectivo factor. El resultado se pondera por un factor de coerción correspondiente a la plataforma, lenguaje y herramienta de desarrollo. Los factores son determinados en base a un análisis estadístico previo que provee la literatura de la técnica. A este resultado le llamamos el punto función (PF), el cual es una base de 33

medida estándar que al ser ponderado por otro factor determinará el esfuerzo en HH (horas hombre) y en consecuencia los costos ($). Los factores aplicados son de naturaleza estadística, determinados en base a un conjunto de datos obtenidos de software factory de categoría mundial. Al igual que con los estándares anteriormente descritos, los factores de esta técnica debe ser ajustados según la realidad de la empresa. Debido a la naturaleza estadística de la metodología, no es recomendable aplicarla a proyectos de menos de 1 PF. En la aplicación a proyectos menores a dicha medición, se corre el riesgo de obtener resultados poco certeros y si se está estimando costos, tiempo y esfuerzo de un proyecto, la falta de asertividad puede producir graves consecuencias. No obstante se puede utilizar como referencia. El detalle de la fórmula utilizada de este cálculo está descrita en el punto 4.6.2.6.1 Cálculo de Punto Función Plazo y Esfuerzo de este informe. Para obtener más información acerca de la Métrica de Punto Función, ver el Anexo 4 de este informe. 34

3. EL PROYECTO 3.1. Oportunidad 3.1.1. Diagnóstico La estrategia de la compañía consiste básicamente en desarrollar una serie de productos relacionados entre sí que permitan a los diferentes nichos de clientes hacer más eficiente su operación, mediante la interconexión de los software que les provee Edi-Trade con los software que provee a los clientes y proveedores de estos, logrando eficiencia operacional en la cadena de valor de nuestros clientes. Para llevar a cabo dicha estrategia es necesario mejorar la eficiencia operacional de nuestra cadena de valor, ya que en necesario producir más, con mejor calidad a costos razonables. Hoy la brecha entre ingresos y costos no es satisfactoria, por lo que se pretende aumentar los ingresos sin que los costos aumenten en la misma proporción, de esta forma producir una brecha ingreso-costo más atractiva. Por lo tanto, se presenta la oportunidad de realizar un proyecto innovador para mejorar la gestión y el control de la cadena de valor, apoyando tecnológicamente a la asignación de recursos de ésta. 3.1.2. El Mercado El mercado al cual quiere llegar Edi-Trade está compuesto por todo tipo de empresas relacionadas con comercio exterior que no sean agentes de aduana (el nicho de agentes de aduana ya está abordado integralmente). Dentro de estas podemos 35

mencionar a los courrier, los freigth forwarders, embarcadores, puertos, almacenes francos, transportistas, importadores, exportadores, etc. Cada uno de este tipo de clientes tiene necesidades de software de gestión, transmisión electrónica de datos e información y técnica en línea. Estos nichos tienen necesidades particulares de software de gestión y además, tienen necesidad de intercambio electrónico de datos con entidades gubernamentales y otras empresas del ámbito de comercio exterior. Por ejemplo, los Exportadores necesitan gestionar sus operaciones de exportación, confeccionar sus documentos de embarque y transmitir electrónicamente los datos a su agente de aduana y a la naviera. A través del uso de nuestros productos podrá lograr este objetivo. 3.1.3. Producto Ofrecido Este proyecto formalizará los procesos de negocio de la cadena de valor a través de un rediseño de estos, basados en el patrón de diseño de negocios de la cadena de valor llamado Macro 1 del Dr. Oscar Barros. También se incorporará al diseño las mejores prácticas obtenidas de los estándares CMMI para el desarrollo de software, ITIL para la atención a clientes. Adicionalmente, se incorporarán técnicas de cálculo de Punto Función para la estimación del esfuerzo y el método Roy para la asignación de tareas en apoyo a la planificación. Se diseñará, desarrollará e implementará un sistema de información capaz de apoyar dicho diseño. 3.1.4. Clientes Este proyecto tiene como objetivo inmediato a los clientes externos en todo lo 36

que corresponde a gestión de incidencias, gestión de requerimientos y soporte de clientes. Sin embrago, en lo que corresponde al desarrollo de proyectos de software el cliente inmediato es interno: asignación de tareas, gestión y control. No obstante, las mejoras introducidas en el desarrollo de proyectos de software implican que necesariamente el foco del proyecto apunte al cliente externo, ya que se pretende que estos últimos obtengan mejores productos de software en menor tiempo. 3.1.5. Beneficios Cualitativos Preliminares Los beneficios cualitativos que se espera lograr preliminarmente son: Mejora del grado de cumplimientos de la planificación de producción: predecir acertadamente el tiempo que tomará el desarrollo de los proyectos de software. Identificación y reacción correctiva a tiempo sobre la planificación de la producción: identificar en el momento indicado, los factores que afectarán a la planificación de la producción, e introducirlos en esta última para tomar las medidas necesarias. Mantener informado a los clientes de los avances de sus requerimientos e incidencias: mejorar la calidad de la atención al cliente dando solución oportuna a sus requerimientos e incidencias a través de una correcta gestión y un buen canal de información. Entregar Información para la planificación estratégica: generar en forma automática, la información necesaria para alimentar la planificación estratégica. Aumentar el Resultado Operacional: acceder a un mayor número de clientes Comex, producto de la nueva capacidad obtenida vía eficiencia operacional. 3.2. Diseño organizacional del proyecto El equipo de trabajo del proyecto está compuesto por el líder, el equipo de programadores, que desarrollará la herramienta computación, los jefes de los 37

departamentos en los cuales se implementará el proyecto y una persona que reforzará la coordinación entre las partes. El equipo de programadores está constituido por dos programadores analistas y un ingeniero de ejecución, todos ellos pertenecientes al equipo de desarrollo del departamento de proyectos. Éstos serán utilizados cuando sean requeridos y según su disponibilidad, ya que participan en otros proyectos paralelos. El líder del proyecto realizará el diseño e implementación de la mayor parte de la herramienta computacional, por lo cual se ha asignado preliminarmente el uso de 6 hrs. de programadores analistas (equipo de desarrollo) y 32 hrs. de ingeniería (líder del proyecto). En la etapa de operación y puesta en marcha es imprescindible realizar mejoras y corregir errores en la aplicación, por lo que se asignan 32 hrs. de programadores analistas y 15 hrs. de ingeniería. El apoyo al proyecto consiste en la validación de la arquitectura de procesos rediseñada y el apoyo para la puesta en marcha en los departamentos respectivos. El encargado de planificación y control realizará las actividades correspondientes a la gestión del cambio, ya que posee buena llegada y empatía con la gente involucrada. Para esto está contemplado que se dedique seis semanas a la gestión y control de la puesta en marcha, más la gestión del cambio contemplada en el diseño técnico del proyecto. No hay costos de operación asignados, ya que el proyecto reemplazará la actual forma de realizar las tareas, que hoy se realiza a través de herramientas computacionales no especializadas como, por ejemplo, el correo electrónico; el proyecto necesita de una herramienta computacional especializada, lo que implica equivalencia en el esfuerzo de uso y mejora en la eficiencia. Por lo tanto, no hay costos significativos asignados a la operación del sistema. El plan de marketing será diseñado por el líder del proyecto, y como es una idea ya vendida sólo hay que reforzar los motivos de ésta durante el periodo de cambio. 38

Figura 7.- Organización del Proyecto Líder del Proyectos Juan Enrique Ortúzar E. Gerente de Proyectos Coordinador del Proyecto Alejandro Pino Planificación y Control Apoyo del Proyecto Verónica Román Jefa de Soporte Equipo de Desarrollo Programadores Analistas Depto. de Proyectos Apoyo del Proyecto Rodrigo Zúñiga Sub-Gerente de Sistemas 3.3. Implementación del Proyecto El proyecto se implementará en tres etapas: 1. Asignación de Recursos: en esta etapa se pretende automatizar el proceso de asignación de tareas a los desarrolladores, utilizando la herramienta computacional desarrollada para apoyo de esta actividad. 2. Captura y Asignación de Requerimientos de Usuarios: aquí 39

capturaremos los requerimientos de los clientes a través de la mesa de ayuda, éstos se ingresarán en el nuevo sistema y se asignarán con la herramienta de asignación de recursos. Además, se incorporarán funcionalidades de control de tiempos críticos para el desarrollo de requerimientos. 3. Captura y asignación de Incidencias: en esta fase la mesa de ayuda podrá escalar incidencias a los desarrolladores, las cuales serán asignadas automáticamente a éstos. 3.4. Fundamento Teórico Conceptual del Proyecto Por qué Rediseñar los Procesos de Negocio? Para nadie es desconocido que los mercados son dinámicos, y por ende, las empresas deben estar constantemente adecuándose a los nuevos requerimientos de éstos. Un diseño de negocio, que necesariamente implica una arquitectura de procesos y un diseño de procesos detallado con sus respectivas métricas, es una buena base para enfrentarse a estos requerimientos. Por lo tanto, se hace necesario una disciplina como el diseño de negocios, que provee las instancias para ello a través de la gestión del conocimiento de casos similares, uso de mejores prácticas conocidas, implementación de una arquitectura tecnológica acorde con la arquitectura de procesos, simulación, etc. El diseño de negocios, en muchos aspectos, está sujeto a la interpretación del diseñador, cosa que no sucede en otras ramas de la ingeniería tradicionales. Las empresas invierten mucho dinero en una buena arquitectura tecnológica, que muchas veces no explicita u omite aspectos fundamentales de sus procesos o de su gestión, lo que implica a su vez que tenga que ser readecuada o parchada. En consecuencia, se dificulta la puesta en práctica de ésta. Lo anterior nos revela algunas de las razones por las cuales es necesario que a la hora de diseñar procesos utilicemos metodologías estructuradas, que nos permita minimizar el esfuerzo y maximizar la completitud de este. Reutilizando la experiencia 4

de otros proyectos, que ha sido compartida para brindar un punto de partida y una guía para el nuevo diseño. Éste es el fundamento teórico de la ingeniería de negocios, la que se basa en la experiencia de proyectos llevados a la práctica de empresas. El diseño de procesos de negocios se basa en sintetizar el conocimiento empírico y experiencia acerca de procesos de negocios en estructuras que no tienen una formalización que describa adecuadamente sus fundamentos. 5 A mediados de la década del 9, decenas de proyectos implementados por el Departamento de Ingeniería Industrial de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile en empresas nacionales e internacionales, fueron la base para definir los patrones de procesos que conformarían la metodología de la Ingeniería de Negocios 6. Esta disciplina se basa en la definición de patrones de procesos (PPN) llamados Arquitectura de Macroprocesos clasificados según su funcionalidad en: Macro 1: Gestión, Producción y Provisión de Bienes o Servicios. Macro 2: Desarrollo de Nuevos Productos y Servicios Macro 3: Planificación del Negocio Macro 4: Procesos de Apoyo: Financieros, RR.HH., Infraestructura 7. Dicha metodología es validada por posteriores publicaciones de HP, VCOR, APQC 8, las cuales independientemente proponen la implementación de diseño de 5 6 Oscar Barros, Arquitectura y Diseño de Procesos de Negocios. Mar. 27. www.u- cursos.cl Oscar Barros, El Valor Estratégico de la Innovación en los Procesos de Negocios. jul. 26. 7 Para más detalle ver [1] pág. 1 de la bibliografía. 8 Para revisión resumida de dichas publicaciones ver [2] de la bibliografía. 41

procesos de negocios en la empresa a través de macroprocesos que equivalen a los macroprocesos antes mencionados. 9 Como mencionamos anteriormente, muchas empresas invierten muchos recursos en arquitectura tecnológica sin tener una arquitectura de procesos sólida, con las consecuencias antes descritas. Entonces qué es primero?, el huevo o la gallina? (asumiendo que el huevo es la arquitectura tecnológica y la gallina es la arquitectura de procesos). Obviamente para que exista un huevo tiene que haber un gallina que lo ponga, por lo tanto, es de suma importancia contar con una arquitectura de procesos en detalle que llegue hasta los casos de usos e identifique las clases y las secuencias que se trasformarán en el punto de partida para el diseño de una buena arquitectura tecnológica 1 que esté acorde con ella. Es importante recalcar que una arquitectura de procesos sin una buena arquitectura tecnológica que la respalde no sirve de nada. Según Porter, una empresa sólo puede sobrepasar a sus rivales si establece una diferencia que pueda mantener 11. Esto implica que para ser competitivos debemos establecer estrategias sustentables en el tiempo a través de una efectividad operacional que aporte eficiencia y la creación de valor a través de los diferentes procesos, como parte de la estrategia competitiva. Para lograr esto es importante orientarse al cliente hasta establecer su fidelidad mediante el lock-in sistemático 12 : Existen antecedentes empíricos respecto a los resultados que las estrategias planteadas inducen a las empresas: un estudio de empresas de EEUU encontró que la estrategia lock-in sistemático produce un promedio de 4 veces mayor incremento de 9 Oscar Barros, Arquitectura (Ibídem) 1 Los diagramas de casos de uso, de clases y de secuencia son parte de la notación o lenguaje UML (Unifiqued Modeling Language), utilizado ampliamente para el desarrollo de proyectos tecnológicos y de otras ramas de la ingeniería. Par mas detalle ver [3] de la bibliografía. 11 12 Porter, M. E. What is Strategy?, Harvard Business Review, Noviembre-Diciembre 1996. Oscar Barros, Arquitectura (Ibidem) 42

valor de mercado que la estrategia de mejor producto y la estrategia de solución integral para el cliente, un mayor incremento promedio de 1.6 veces 13 Volviendo a mencionar al estudio del Departamento de Ingeniería Industrial de la Facultad de Ciencias Físicas y Matemáticas de Universidad de Chile que estableció y probó los conocimientos plasmados en la Ingeniería de Negocios, podemos agregar que han validado empíricamente el aserto de Porter en cuanto a la conveniencia de establecer una estrategia competitiva conformada por modelos de negocio y procesos bien diseñados y alineados que llevan a la práctica 14. Esto es coincidente con la experiencia internacional, que señala que las empresas líderes en innovación de procesos tienen una clara relación entre su estratégica y arquitectura empresarial, que incluye los modelos de negocio, y los procesos que las materializan 15. En conclusión, a la hora de obtener ventajas competitivas, es importante considerar una buena arquitectura de procesos de negocio, la cual debe estar alineada con los objetivos de la empresa. Es importante mencionar que aunque lo medular de una empresa son sus procesos, éstos no lo son todo. Dentro de la Arquitectura de la Empresa se encuentra la Arquitectura de Procesos, que es foco de nuestra atención. Ya hablamos de la importancia de la Arquitectura de Sistemas y Tecnología que está dentro de la Arquitectura de la Empresa, pero también debemos mencionar que dentro de la Arquitectura de la Empresa se encuentra la Infraestructura de Otros Recursos y la Estructura Organizacional, la cual también tiene que ser diseñada en forma acorde a la Arquitectura de Procesos. Un caso típico es que las empresas se organizan en torno a 13 Hax, A.C y D.L Wilde II. The Delta Project. Palgrave, 21 14 15 Oscar Barros, El Valor (Ibidem) Ibid. 43

una estructura jerárquica a través de la Estructura Organizacional que se determina en base a las funciones dentro de la estructura jerárquica. Por el contrario, el paradigma de la Ingeniería de Negocios propone que la Estructura Organizacional sea determinada a partir de funciones dentro de los procesos que generan valor para la empresa. Retomando las ideas iniciales en que nos referimos por separado a las grandes y a las pequeñas y medianas empresas, nos parece correcto mencionar cómo se ven estas últimas. Los conceptos de Arquitectura de Empresa y Arquitectura de Procesos no son sólo aplicables a las grandes empresas. Por el contrario, la competencia entre las pequeñas y medianas es cada día más reñida y como dice el sabio y conocido refrán empresa que no crece, se muere. Esto implica que dichas empresas deben ser más eficientes y crear más valor para poder ser más competitivas. Aquí es donde los Procesos de Negocios Basados en Patrones tienen mucho que aportar. Ya que muchas de estas empresas no cuentan con los recursos para contratar expertos en el área de la Ingeniería de Negocios, estos modelos de Macroprocesos representan el punto de entrada al mundo de la Ingeniería de Negocios, pues son modelos probados que pueden ser adaptados a la realidad de ellas. Muchas de estas técnicas son aplicadas hoy en día sin que se consideren como parte de un diseño de negocios y muchas veces sin darse cuenta que lo que se está implementando es realmente un diseño de negocios basado en estándares de la industria. Prueba de ello son los famosos sistemas ERP, como SAP, construidos sobre patrones de procesos determinados y normados a través de la experiencia, uso de buenas prácticas, etc. con lo cual estructuran un estándar. Las empresas que implementan estas arquitecturas tecnológicas deben obligatoriamente adaptarse a dichos estándares, y no pueden personalizarlo a su cultura de negocio, lo que suele ser sumamente traumático para la empresa, la cual deberá invertir en desarrollos adicionales para poder cubrir las áreas que su nuevo ERP no tiene la flexibilidad para ajustarse. Ante este problema, el rediseño de proceso de negocio basado en patrones 44

provee un punto de partida y modelo de completitud para establecer la arquitectura de procesos ad-hoc para el negocio específico. En este modelo de procesos se puede incorporar las mejores prácticas de los estándares conocidos, sin necesidad de rigidizar los procesos a una cultura distinta en la cual se establecieron estos estándares. Este modelo de procesos se mapea con una herramienta computacional o se desarrolla una herramienta a la medida. Los buenos paquetes de software permiten desarrollar un capa intermedia de interfaces de usuario, la cuales se podrán adaptar en un 1% al modelo de procesos de negocio, sin necesidad de hacer un desarrollo a la medida partiendo desde cero. Pero nada es tan bueno como parece. Al parecer el diseño de procesos basado en patrones vendría a ser una bala de plata para ser más competitivo. Al replicar un modelo de negocios es de suma importancia analizar el escenario en donde se pretende implementar dicho diseño. Para esto es necesario simular el diseño antes de ser puesto en práctica, para de esta forma, considerar los ajustes que se le deben hacer al modelo. Un ejemplo es el caso EuroDisney s, que por copiar fielmente el modelo de negocios de EEUU creó una larga línea de patrones frustrados 16. 3.5. Costos de Inversión y Operación Los costos del proyecto están distribuidos de la siguiente forma: 1. Costos Diseño y Desarrollo: antes de la puesta en marcha y corresponden al diseño y desarrollo de la herramienta computacional: HH Ingeniería (32horas ) 8.. HH P rogramador (12horas ) 3.645. HH C apac itac ión (1horas ) 25. Dis eño e Impl. del P lan de Mark eting 3. 16 Joan Magretta, Why Business Models Matter, Harvard Business Review, Mayo 22 45

2. Costos de Puesta en Marcha y Operación: durante el primer año de operación y corresponden a la puesta en marcha y ajustes a los procesos y la herramienta computacional: 3.6. Plan de Marketing Este es un proyecto de mejora interna, por lo que el plan de marketing es especial: consiste en seducir y mantener motivados al equipo de gerencia y a los G es tión del C ambio 9. C os tos Operac ión - operarios en los beneficios del proyecto. Para ambos grupos se deben utilizar estrategias de marketing distintas. Al equipo de gerencia hay que seducirlo a través de los beneficios económicos que traerá la mejora de la eficiencia lograda por el proyecto. Para esto lo evaluaremos considerando la posible fuga de clientes basándonos en la historia de la compañía y la retención de los nuevos clientes capturados. El equipo de operarios deberá ser seducido mediante la motivación a realizar su trabajo en forma más eficiente, lo que disminuirá la presión y el estrés de aquellos. 3.7. Evaluación Financiera Este proyecto se está desarrollando paralelamente con otro que pretende hacer lo mismo en el área de planificación estratégica. Estos dos proyectos se complementan mutuamente y entre los dos pretenden obtener los beneficios esperados. Por lo tanto, la evaluación financiera, como el análisis de sensibilidad y riesgos, se realizarán en conjunto. 46

No contamos con información precisa de los mercados a los cuales se venderán los productos y servicios atendidos por las áreas que mejoraremos, tampoco con datos de la repercusión que tendrá una mejor gestión y control de la cadena de valor y planificación estratégica sobre las ventas y la retención de clientes. Además, no contamos con datos que nos permitan simular las ventas de los nuevos productos que se desarrollarán bajo este esquema. Por lo tanto, nuestro análisis apuntará a prevenir la fuga de clientes, justificados en la mala gestión y tiempos de entrega no adecuados. Para esto nos basaremos en la historia de los últimos 5 años de la empresa y la proyectaremos bajo algunos supuestos determinados bajo criterios de expertos hacia las condiciones futuras. 47

3.7.1. Flujo de Caja Proyectado a Cinco Años 48

Basado en el caso de que se fuga un cliente anual, el flujo de ingreso operacional sería el siguiente: 3.7.2. Análisis de Sensibilidad y Riesgo Supuestos considerados: Un cliente que se fugaría producto de la mala calidad del servicio, y que ahora nunca se fugará por estos motivos debido a los cambios introducidos por los dos proyectos en conjunto, es de un 6%. En los últimos 5 años se han fugado 6 clientes producto de una combinación de mala planificación, tiempos de entrega inadecuado, mala gestión y soporte. Cada cliente, en promedio, paga $471. + IVA mensuales por el servicio. La tasa de descuento que se utiliza para evaluar proyectos en la compañía es de un 9,9% y será utilizada en los casos de la evolución en que hay dispersión de los flujos. En los casos en que el riesgo se reconoce en la volatilidad de los flujos, se descontará el riesgo y se utilizará una tasa libre de riesgo de 6%. Condiciones: La evaluación se realiza en periodos anuales en un plazo de 5 años. Un cliente que en condiciones sin proyecto se fugaría por la mala atención, se considera que es un flujo positivo para el proyecto. Casos de Estudio: 49

Caso 1:Durante el plazo de 5 años se logra evitar la fuga de 3 clientes. Se retiene ó 1 cliente por cada periodo, con probabilidad de 4% y 6% respectivamente. Se utiliza una tasa libre de riesgo 6%. Figura 8.- Caso 1.- Análisis de Sensibilidad y Riesgo Año Año 1 Año 2 Año 3 Año 4 Año 5 1 2 3 1 1 2 2 3 P=, 4 2 3 3 3 1 2 3 P=, 6,4,6,4 1,4 1 1 1 1,4,6 1,6 1, 4 1 1 2 2 3 2 2 3 1,4,6,4 1 1,6 3 1 3 2 1 3,6,4,6 3 1 3,6 1 3 1 3 Caso 2:Durante el plazo de 5 años se logra evitar la fuga de 4 clientes. Se retiene ó 1 cliente por cada periodo, con probabilidad de 4% y 6% respectivamente. Se utiliza una tasa libre de riesgo 6%. Figura 9.- Caso 2.- Análisis de Sensibilidad y Riesgo 5

Año Año 1 Año 2 Año 3 Año 4 Año 5 1 1 1 2 1 3 1 4 P=, 4 P=, 6,4 1,6 1,42 1 2 2 3 1 3 1 4 1 3 4 1,6,4 3 1 4,6 4 1 4 51

Caso 3:Durante el plazo de 5 años se logra evitar la fuga de 5 clientes. Se retiene ó 1 cliente por cada periodo, con probabilidad de 4% y 6% respectivamente. Se utiliza una tasa de descuento 9,9%. Figura 1.- Caso 3.- Análisis de Sensibilidad y Riesgo Año Año 1 Año 2 Año 3 Año 4 Año 5 1 2 3 4 5 P=1 P=1 P=1 P=1 P=1 52

Caso 4: Durante el plazo de 5 años se logra evitar la fuga de 6 clientes. Se retienen ó 2 clientes por cada periodo, con probabilidad de 4% y 6% respectivamente. Se utiliza una tasa libre de riesgo 6%. Figura 11.- Caso 4 Análisis de Sensibilidad y Riesgo Año Año 1 Año 2 Año 3 Año 4 Año 5 1 2 4 6 P=, P=, 4 6,6 2,6,4 2,6, 2,6,44,6 4 2,44,6 21,44,6,44,6 61 4 4 6 4 4 6 4 6 6 1 1 1 1 1 1 1 1 1 6 6 6 6 6 6 6 6 6,4,4 1 1 1 53

Caso 5: Durante el plazo de 5 años se logra evitar la fuga de 8 clientes. Se retienen ó 2 clientes por cada periodo, con probabilidad de 4% y 6% respectivamente. Se utiliza una tasa libre de riesgo 6%. Figura 12.- Caso 5.- Análisis de Sensibilidad y Riesgo Año Año 1 Año 2 Año 3 Año 4 Año 5 1 21 41 6 8 P=, 4 P=, 6,4 2,6 21,4 4,6 41 41,46 61 61 1 81 8 8 8 8 1 6,6 54

4. REDISEÑO DE PROCESOS 4.1. Cadena de valor Hoy en día Edi-Trade presenta una estructura de organización operativa que le ha permitido dar solución a la gran mayoría de los requerimientos de sus clientes. Dentro de esta organización podemos destacar tres subprocesos que actualmente son los más relevantes en la cadena de valor: Desarrollo y entrega de soluciones e incidencias presentadas en los productos. productos Gestión de desarrollo y entrega de soluciones e incidencias presentadas en los Administración de requerimientos e incidencias. Actualmente el proceso de Desarrollo y entrega de soluciones e incidencias presentadas en los productos satisface los requerimientos del mercado, siendo a su vez evaluado positivamente por los clientes en su gran mayoría. Sin embargo, se presentan situaciones especiales, en las cuales los tiempos de respuesta se alargan mucho más de lo necesario. La causa principal detectada de estos incidentes ocurre por deficiencias en la comunicación del proceso de administración de requerimientos e incidencias y por la poca formalidad del proceso de gestión de desarrollo y entrega de soluciones e incidencias presentadas en los productos. El subproceso de administración de requerimientos e incidencias no cumple las expectativas de los clientes ni de la empresa, lo que se requiere una rápida mejora. A su vez, se echa de menos un proceso de mantención de estados capaz de coordinar, informar, guardar historia y por sobretodo gatillar alertas a los diferentes subprocesos de la cadena de valor. 55

A continuación, presentamos el modelo actual del proceso de cadena de valor en formato BPMN. Se han destacado en color rojo y discontinuo lo flujos que deben ser atendidos por sus deficiencias o sus inexistencias. En color azul, están los flujos que pueden ser mejorados. Finalmente en negro, los que actualmente no presentan problemas. 56

Figura 13.- Macro 1.- Cadena de valor Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño Requerimientos del Cliente Requerimientos del Mercado Incidencias del Cliente Administración de requerimientos e incidencias Requrimientos de Desarrollo Información al Mercado publicación y mensajes requerimientos de servicios computacionales Información de disponibilidad Administración relación con proveedores de servicios computacionales Información y órdenes a proveedores Necesidades insumos y servicios computacionales Gestión de desarrollo, solución de incidencias y entrega Plan e instrucciones Ideas cambio productos y procesos producción Insumos y otros recursos proveedores Necesidades e información control Desarrollo, Intalaciones, Actulizaciones y solución de incidencias Cambio de Estados Instalación, actualización o solución de la incidencia del sistema del cliente Requerimiento o incidencia del Cliente procesado Información de otros procesos Otros Recursos Estado 2 Estado 3 Estado 4 Mantencón de estado Información a otros procesos Información de estados Estado 1 57

Figura 14.- Subproceso administración de requerimientos e incidencias Requerimientos del Cliente requerimientos delos Sistemas Computacionales Administración de requerimientos Estadoderequerimiento Incidencias del Cliente Administraciónde incidencias Requerimientos deservicios computacionales EstadodeIncidencia Informaciónal Mercado publicacióny mensajes Requerimientos del Mercado Administraciónde productos incidencias delos Sistemas Computacionales Informaciónal Mercado publicacióny mensajes Otros Recursos Estadogeneral sistemas 58

Figura 15.- Subproceso de gestión de desarrollo, solución de incidencias y entregas requerimientos Nuevos Productos y servicios productos y servicios Necesidad de insumos y servicios computacionales Cambio de estados desarrollos Gestión de Desarrollo de Software Planes e instrucciones Técnicas Cambio de estados incidencias incidencias Gestión de Solución de Incidencias Planes e instrucciones Técnicas Necesidad de insumos y servicios computacionales Otros Recursos Infromación de estados de Desarrollo Otros Recursos Información de estados de Incidencias 59

Figura 16.- Subproceso gestión de desarrollo Requerimientos de nuevos productos y servicios Requerimientos de modificaciones a productos ya operativos Gestión y Planificación de Desarrollo de Nuevos Productos y servicios y mantención de los ya existentes Instrucciones Mensaje plan de instrucciones Control de desarrollo necesidad insumo y otros Necesidades de entrega Cambios de estado del desarrollo Decidir entrega del nuevo software o módulo instrucción de entrega Estado de desarrollo y análisis de requerimientos cambio de estado entrega Disponibilidad de software terminado 6

Figura 17.- Subproceso de gestión de incidencias incidencias mensaje requerimentos de cambio Gestión y Planificación de Solución de Incidencias Instrucciones Mensaje plan de instrucciones control de solución y de cambios necesidad insumo y otros Necesidades de entrega Cambios de estado de la solución de incidencias Gestión de difusión instrucción de difusión Estado de solución y análisis de los cambios cambio de estado disfusión Disponibilidad de incidencia solucionada 61

Figura 18.- Desarrollo, instalaciones, actualizaciones y solución de incidencias Nuevos Productos y servicios requerimientos Instrucciones técnicas productos y servicios Instrucciones técnicas Necesidad de información y control Instrucciones técnicas Cambio de estados desarrollos Plan de Instrucciones Desarrollo de Software Requerimiento o incidencia del Cliente procesado Cambio de estados incidencias Plan de Instrucciones Solución de Incidencias Necesidad de información y control Insumos y otros recursos de proveedores incidencia del Cliente procesado Necesidad de información y control Cambio de estados instalaciones y actualizaciones Infromación de estados de Desarrollo Clientes a Proceso Información de estados de Incidencias Instalaciones y Actualizaciones Instalación, actualización o solución de la incidencia del sistema del cliente 62

4.2. Métricas asociadas Las métricas que se pretende utilizar para medir el impacto del proyecto en la empresa son: Margen de utilidades: se espera subir los ingresos en proporción mayor al incremento en los costos, los cuales han crecido en la misma proporción en el último tiempo. Tiempos de respuesta: se pretende mejorar el grado de satisfacción de los actuales clientes mejorando el tiempo del ciclo de solución de requerimientos e incidencias. Tiempos de desarrollo: un objetivo es lograr la excelencia operacional, lo que hace necesario evaluar el tiempo de desarrollo de nuevas capacidades. Estas métricas nos permiten tomar el pulso de los procesos internos de la empresa donde se proponen las mejoras. 4.3. Arquitectura de macroprocesos La empresa se encuentra compuesta de cuatro macroprocesos, los cuales se muestran la figura 19. De estos macroprocesos interesa destacar los de Planificación Estratégica y de Cadena de Valor, ya que son los que se rediseñarán en el marco del proyecto SAUCE. Es importante mencionar que ambos macroprocesos se interconectan entré sí. El de Planificación Estratégica planifica y controla los planes estratégicos a implementar en el de Cadena de Valor, y éste a su vez retroalimenta al primero con las ideas y resultados que surgen al desarrollar software y brindar el servicio de soporte y 63

capacitación. En la figura 19 se puede apreciar la arquitectura de la empresa con los cuatro macroprocesos según el modelo planteado por el Dr. Óscar Barros. En éste se han destacado los que se encuentran en etapa de rediseño. Figura 19.- Arquitectura de empresa. IdeasparanuevosDesarolos Informaciónal Mercado Información Mercado Planificación estratégica Planes Necesidades Ideasyresultadosdelosdeasarolos Desarolo Nuevas Capacidades ProductosdeSoftware Mantencióndesoftware RequerimientoseIncidenciasdeClientes Cadenadevalor ServiciodeSoportey Capacitación HHdeIngenieríayProgramación Resultadosdesdeel mercado ideasyresultadosdedesaroloyantenciónal cliente Recursos Recursos Procesosde al mercado Apoyo 64

4.4. Análisis de dirección de cambio A continuación se realizará un análisis del impacto que tendrá el rediseño de macroproceso de cadena de valor en las variables de diseño asociadas, teorías y conceptos relevantes. Para cada variable se presentará la situación actual en contraste con la situación esperada luego del rediseño e implementación del macroproceso. 4.4.1. Asignación de responsabilidades Situación actual -Recursos Humanos compartidos entre los distintos equipos de trabajo, lo que implica una asignación de responsabilidades descentralizada para algunos recursos y centralizada para otros. - La eficiencia no es del todo satisfactoria: implica esfuerzos adicionales para la coordinación, lo que conlleva necesariamente a mayores costos de administración y de oportunidad. Situación esperada -Descentralización total de Recursos Humanos mediante organización celular. Se pretende conformar equipos de trabajo autosuficientes que administren internamente sus recursos y sus prioridades en base a los planes entregados. - Mayor eficiencia, se bajan los costos de administración y de oportunidad. 4.4.2. Mantención consolidada de estados. Situación actual 65

-Seguimiento de asignación de recursos y estado de avances no consolidado y volátil. Se requiere de esfuerzos adicionales para realizar seguimiento al desarrollo de los proyectos y la atención a clientes. Cada desarrollador y técnico es responsable de cumplir sus responsabilidades asignadas. Se requiere que cada uno de estos realice informes periódicos acerca del avance y cumplimento de tareas asignadas. Estos informes no siempre se realizan, privilegiando el tiempo para la producción. - Información no es compartida. Situación esperada -Seguimiento de asignación de recursos y estados de avance consolidado en un sistema de información que obtenga, dentro de lo posible, la información de los estados desde las herramientas y sistemas que se utilizan en producción. - Información compartida y trazable. Al organizarla en una base de datos en modelo relacional, se podrá hacerse seguimiento a los distintos estados. 4.4.3. Anticipación Situación actual -La planificación de proyectos de desarrollo depende de que la información de los planes sea emitida a las personas que están relacionadas con los proyectos, lo que conlleva a que la información y planificación esté dispersa y no siempre se informa a las personas correctas. También ocurre que las personas correctas no toman con atención la información recibida. Esto implica que muchas situaciones, las cuales se pueden anticipar, terminen siendo atendidas cuando se producen incidencias relacionadas a estas. - La planificación de asignación de recursos para puesta a punto no es del todo satisfactoria. Al igual que en el caso anterior, cuando se planifica la instalación de un 66

software para un nuevo cliente, no siempre se reservan los recursos necesarios para realizar una correcta puesta a punto. La información no es emitida por los canales adecuados que permitan una correcta planificación, lo que produce que los recursos se asignen una vez que los clientes reclamen por los tiempos de respuesta no aceptables en la puesta a punto. - La planificación de recursos para la puesta en marcha no considera todos los factores necesarios para que otros procesos no queden desatendidos, en momentos en que se requieran más recursos. Situación esperada -Correcta planificación de proyectos de desarrollo que permita anticiparse a las necesidades del mercado. - Correcta planificación de recursos para puesta a punto que permita anticiparse a posibles molestias de los clientes. - Correcta planificación de asignación de recursos para las puestas en marcha. Esto permitirá adelantarse a eventuales faltas de recursos para el manejo de contingencias en los procesos de atención a clientes. 4.4.4. Integración de procesos conexos Situación actual -Actualmente el departamento comercial negocia proyectos sin considerar la disponibilidad de recursos en el departamento de proyectos. Lo que implica que el desarrollo de los proyectos se dilate mucho más de lo comprometido por el departamento comercial. - Lo mismo ocurre al momento de coordinar las puestas en marcha de los 67

sistemas. Éstas las realiza el departamento comercial sin considerar contingencias o actividades que puedan tener los departamentos productivos. Esto implica recurrentemente, falta de recursos para atender las puestas a punto y puestas en marcha. Situación esperada -Correcta integración de los procesos productivos y comerciales, de forma tal que la negociación de proyectos esté acorde con la disponibilidad de recursos. - Al igual que en el caso anterior, al integrar correctamente los procesos productivos, de manejo de información relevante y comerciales, se pretende que se planifique correctamente las puestas en marcha con las contingencias que puedan presentarse y afecten a la utilización de recursos. 4.4.5. Coordinación Situación actual -Medición de esfuerzo para nuevos proyectos no es formal y muy poco precisa. - Poca planificación de actividades y seguimiento de éstas. - Se incurre en mucha utilización de horas extras, re-trabajo y contratación de personal por sobrecarga de trabajo por falta de planificación. Producto de ello se genera muchos estrés interno. Situación esperada -Formalización de medición de esfuerzos para el desarrollo de nuevos proyectos a través de técnicas de punto de función. - Planificación de actividades y seguimiento. 68

- Evitar costos de horas extras, re-trabajo y contratación de personal por sobrecarga de trabajo. Reducción después de planificar y disminución del estrés interno. 4.4.6. Prácticas de trabajo Situación actual -Se trabaja de acuerdo a la percepción de las prioridades de cada equipo de trabajo. No se establecen las prioridades en concordancia con otros procesos y macroprocesos. - No hay un sistema integrador de apoyo. No se registran las actividades, lo que implica que no se le puede dar seguimiento a éstas. - Las prácticas de desarrollo de software se han adquirido en base a la experiencia de los líderes de los equipos de trabajo, los cuales las han traspasado a sus subalternos, incorporando buenas y malas prácticas. Esto implica gran riesgo a la hora de abordar grandes proyectos de software. Situación esperada -Se trabajará de acuerdo a la planificación de proyectos y recursos. Se integrará la planificación con otros procesos y macroprocesos. - Se trabajará con un sistema integrador de apoyo, formalizando y registrando prácticas y dando seguimientos a las actividades. Esto se realizará a través de seguimiento computacional, buscando automatizar al máximo la generación de alertas, mensajes y eventos. - Se incorporará el uso de mejores prácticas obtenidas de estándares como ITIL para la atención y soporte de clientes, CMM y RUP para el desarrollo de software. Esto 69

implica un gran cambio cultural para lo que se deberá realizar una gran gestión de cambio. 4.4.7. Apoyo Computacional Situación actual -No hay un sistema integral de apoyo a la gestión y coordinación. Actualmente se realiza a través de e-mail e instrucciones verbales, para lo cual no hay trazabilidad y son muy volátiles. - No hay un sistema de apoyo al desarrollo y seguimiento de proyectos, lo que implica que no hay seguimiento formal y hay mucha amnesia corporativa en los desarrollos pasados. - Los esfuerzos no se miden siempre de la misma forma y estas mediciones son muy subjetivas. Esto implica bajo cumplimiento en los plazos comprometidos en el desarrollo de software. Situación esperada -Implementación de un nuevo sistema integral de apoyo a gestión y coordinación. - Implementación de un nuevo sistema a apoyo al desarrollo y seguimiento de proyectos. - Implementación de un nuevo sistema de punto de función orientado a la medición de esfuerzos. 4.4.8. Selección de tecnologías de información involucradas Debido a que Edi-Trade es una empresa dedicada al desarrollo de software, es 7

de alta factibilidad el desarrollo de los sistemas necesarios para la implementación del rediseño de procesos. Además, no se descarta la futura venta y/o arriendo de los software generados a partir de este proyecto. Por estas razones, es que los software serán desarrollados en un modelo de tres capas para aplicaciones web. Esto se realiza implementando en forma robusta un modelo de datos y las aplicaciones necesarias que satisfagan el modelo de negocios en las capas de datos y aplicaciones. En una tercera capa, llamada la capa de presentación, se implementan las interfaces de usuario que podrán ser modificadas fácilmente para adecuarlas a los requerimientos futuros de Edi-Trade o de posibles clientes de este sistema. 71

Figura 2.- Diagrama de capas de la solución de software CAPA DE PRESENTACIÓN INTERFACES DE USUARIO HTML, JSP, SERVLET, JSF Y WEB SERVICES CAPA DE DATOS ESTRUCTURA DE DATOS QUE SOPORTA EL MODELO DE NEGOCIOS BASE DE DATOS RELACIONAL CAPA DE APLICACIÓN MODELO DE NEGOCIOS EJB Para el desarrollo de las aplicaciones se utilizará JAVA 5 Empresarial con tecnología EJB (Enterprise Java Beans). Las interfaces de usuarios se desarrollaran mediante el uso del framework JSF (Java Server Faces) apoyado con el uso de JSP (Java Server Pages), servlets, HTML Web Services con protocolo SOAP (Simple Object Access Protocol) colaborando con Java Script y librerías AJAX para la construcción de interfaces de usuario con calidad cliente servidor. Como motor de bases de datos se utilizará Firebird. El Servidor de aplicaciones a utilizar se está evaluando, los candidatos son JBOSS y Sun One Aplication Server. Todas estas herramientas y lenguajes son de uso libre y algunos servidores de aplicaciones como JBOSS son open source (código abierto). 72

4.5. Modelo del macroproceso Cadena de Valor A continuación se describirá el primer modelo del macroproceso cadena de valor en BPMN (Figura 21). Este modelo se describe en tres niveles. Es necesario modelar un cuarto nivel en algunos procesos, que se indicarán en la explicación del modelo, que constituyen la lógica del negocio. 73

Figura 21.- Macroproceso Cadena de Valor Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño (Macro 3) Requerimientos del Cliente Requerimientos del Mercado Incidencias del Cliente Administración de requerimientos e incidencias Información al Mercado publicación y mensajes Requerimientos de servicios computacionales Requerimientos de Desarrollo Software e incidencias Información de disponibilidad Información de Estados Administración relación con proveedores de servicios computacionales Información y órdenes a proveedores Necesidades insumos y servicios computacionales Gestión de desarrollo, solución de incidencias y entrega Plan e instrucciones Técnicas Ideas cambio productos y procesos producción Insumos y otros recursos proveedores Desarrollo, Intalaciones, Actulizaciones y solución de incidencias Cambio de Estados Instalación, actualización o solución de la incidencia del sistema del cliente Requerimiento o incidencia del Cliente procesado Necesidades e información control Mantencón de estado Información de otros procesos Otros Recursos Información a otros procesos Información de estados Estado general de sistemas Estado de tarbajos Estado de desarrollo, instalación y soporte de sistemas Estado de tareas 74

4.5.1. Administración de requerimientos e incidencias Este proceso se encarga de la captura de requerimientos e incidencias de los clientes, además de administrar la relación de los nuevos productos con los clientes. Figura 22.- Administración de requerimientos e Incidencias. Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño (Macro 3) Requerimientos del Cliente requerimientos de los Sistemas Computacionales Administración de requerimientos Estado de requerimiento Incidencias del Cliente Administración de incidencias Requerimientos de servicios computacionales Estado de Incidencia Información al Mercado publicación y mensajes Requerimientos del Mercado Administración de productos incidencias de los Sistemas Computacionales Información al Mercado publicación y mensajes Otros Recursos Estado general sistemas 4.5.1.1. Administración de requerimientos Este subproceso está encargado de la administración y gestión de los requerimientos de los sistemas que se encuentran en explotación en los clientes. 75

Figura 23.- Administración de Requerimientos Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño (Macro 3) Requerimientos del Cliente Requerimientos solicitados Captura Requerimientos Cambio de Estados requerimientos y consultas Consultas de Clientes Información y control Gestión de Requerimientos Requerimientos Gestión de Nivel de servicio respuestas a requerimientos y consultas Analisis de Requerimientos Decisión de requerimientos Cambio de estado asignación de requerimientos Otros Recursos Estado de cliente y requerimientos mensaje de requerimientos a desarrollar Otros recursos Estado cliente, requerimiento y disponibilidad de recursos de desarrollo antecedentes de producto o servicio En este subproceso se puede apreciar como son administrados los requerimientos. Se descompone a su vez en tres tareas: 4.5.1.1.1. Captura de Requerimientos Consiste en el registro de los requerimientos solicitados por los clientes. Es posible realizarlo en forma presencial, por medio telefónico o por la página web. 76

4.5.1.1.2. Gestión de Requerimientos Consiste en pre evaluar los requerimientos para que no sean gestionados varias veces, debido a la solicitud de más de una vez por distintos canales, u otro cliente que ya pidió lo mismo. Además, se debe verificar que lo solicitado no se encuentre ya implementado. 4.5.1.1.3. Gestión de Nivel de Servicio Consiste en evaluar si el requerimiento se debe desarrollar, dependiendo de las políticas de nivel de servicio que se brinda al cliente. Además, se debe evaluar el costo económico de desarrollar el requerimiento y si este costo será traspasado al cliente y con qué margen. 77

4.5.1.2. Administración de Incidencias Figura 24.- Administración de Incidencias. Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño (Macro 3) Incidencias del Cliente incidencias ocurridas Captura Incidencias Cambio de Estados incidencias y problemas Consultas de Clientes Información y control Gestión de Problemas Requerimientos Gestión de Configuración respuestas a incidencias y consultas Analisis de incidencias Nivel del Problema Cambio de estado asignación de incidencias Otros Recursos Estado de cliente y incidencias mensaje de incidencias a solucionar Otros recursos Estado cliente, incidencia y recursos para solucionar la incidencia antecedentes del problema Este subproceso que administra las incidencias ocurridas en los clientes, se descompone a su vez en tres tareas: 78

4.5.1.2.1. Captura de Incidencias El registro de las incidencias ocurridas en los clientes. Se puede realizar en forma presencial, por medio telefónico o por la página web. 4.5.1.2.2. Gestión de Problemas Consiste en evaluar si la incidencia corresponde a una causa externa accidental o si corresponde a un problema del sistema en producción. 4.5.1.2.3. Gestión de Configuración Consiste en evaluar si la incidencia corresponde a un problema de configuración del sistema en producción o a un problema en el desarrollo del software. 4.5.1.3. Administración de Productos Este proceso se encarga de vender y gestionar la venta de los productos y servicios ya desarrollados. Nótese que hay flujos que manejan requerimientos; éstos no son del mismo tipo de los que administra el subproceso de Administración de Requerimientos. Aquellos se refieren a requerimientos de desarrollo de nuevas funcionalidades, requerimientos de productos y funcionalidades ya existentes. 79

Figura 25.- Administración de Productos Nuevos Productos y Servicios (de Macro 2) Planes estratégicos y de diseño (Macro 3) Información de mercado instrucciones Marketing y análisis de mercado Cambio de Estados requerimientos Consultas de Clientes Información y control venta y atención al cliente Requerimientos Clientes a proceso decidir satisfacción del requerimiento respuestas a requerimientos y consultas Analisis de requerimientos decisioón de requerimientos Cambio de estado asignación de requerimientos Otros Recursos Estado de cliente y requerimientos mensaje de requerimientos productos y servicios Otros recursos Estado cliente, requerimiento y disponibilidad producto o servicio antecedentes del producto o servicio Este subproceso, a su vez, contiene tres tareas: 4.5.1.3.1. Marketing y análisis de mercado Esta tarea consiste en analizar las necesidades del mercado y generar instrucciones para atender los requerimientos del mercado. 8

4.5.1.3.2. Venta y atención al cliente Consiste en gestionar la venta de productos y servicios ya existentes. A partir de esto, se generan los requerimientos para la instalación de los productos y servicios ofrecidos al cliente. 4.5.1.3.3. Decidir satisfacción de requerimientos En esta parte, se analiza y decide si lo ofrecido o solicitado por el cliente cumple las expectativas de éste. Esta tarea consiste en evaluar si la solución o producto ofrecido cumplirá realmente con las expectativas del cliente para evitar una posible devolución del producto ofrecido debido a expectativas no satisfechas, producto de que el vendedor haya creado expectativas que no corresponden o que el cliente haya solicitado un producto sin conocerlo. 4.5.2. Administración relación proveedores de servicios computacionales Este es el proceso más simple de la cadena de valor. Dadas las características de la empresa, se manejan muy pocos proveedores involucrados en la cadena de valor. Al tener un volumen de flujos bajo, este proceso se atiende con pocos recursos y con baja complejidad. El proceso consiste en coordinar con los proveedores de servicios computacionales de hardware, redes y diseño gráfico para web los trabajos encomendados para Edi-Trade y para los clientes de Edi-Trade. Para esto se debe verificar la disponibilidad del proveedor y hacer seguimientos de las tareas encomendadas. 81

4.5.3. Gestión Desarrollo de Soluciones, Incidencias y Entrega. Este subproceso es el encargado de gestionar la producción de los productos de software y los servicios de soporte al cliente para la solución de incidencias. 82

Figura 26.- Gestión Desarrollo de Soluciones, Incidencias y Entrega. requerimientos Nuevos Productos y servicios Planes productos y servicios Planes Necesidad de insumos y servicios computacionales Cambio de estados desarrollos Gestión de Desarrollo de Software Planes e instrucciones Técnicas Cambio de estados incidencias Gestión de Solución de Incidencias Planes e instrucciones Técnicas Necesidad de insumos y servicios computacionales Otros Recursos Infromación de estados de Desarrollo Otros Recursos Información de estados de Incidencias Como se puede apreciar en la Figura 26 este subproceso se divide, a su vez, en dos subprocesos más que se explican a continuación: 4.5.3.1. Gestión de Desarrollo de Software Este proceso se encarga de la gestión de la producción de nuevos software y adecuación de los ya existentes basados en los requerimientos entregados por los otros procesos ya descritos. 83

Figura 27.- Gestión de desarrollo de software Requerimientos de nuevos productos y servicios Requerimientos de modificaciones a productos ya operativos mensaje requerimentos Planes Gestión y Planificación de Desarrollo de Nuevos Productos y servicios y mantención de los ya existentes Instrucciones Mensaje plan de instrucciones control de desarrollo necesidad insumo y otros Necesidades de entrega Cambios de estado del desarrollo Decidir entrega del nuevo software o módulo instrucción de entrega Otros recursos Estado de desarrollo y análisis de requerimientos cambio de estado entrega Disponibilidad de software terminado Como se aprecia en la Figura 27, el subproceso consta de tres tareas. 4.5.3.1.1. Gestión y planificación de desarrollo de nuevos productos y servicios, mantención de los ya existentes. Esta tarea consiste en la gestión de desarrollo de los nuevos software y la 84

mantención de los ya existentes. 4.5.3.1.2. Control de desarrollo En esta tarea se controla el avance de los desarrollos. 4.5.3.1.3. Decidir entrega del nuevo software o módulo. Esta tarea consta de evaluar el estado de madurez del desarrollo para decidir cuándo puede ser entregado. 4.5.3.2. Gestión de solución de incidencias. Este proceso se encarga de la gestión de resolución de las incidencias reportadas por los otros procesos. 85

Figura 28.- Gestión de solución de incidencias incidencias mensaje requerimentos de cambio Planes Gestión y Planificación de Solución de Incidencias Instrucciones Mensaje plan de instrucciones control de solución y de cambios necesidad insumo y otros Necesidades de entrega Cambios de estado de la solución de incidencias Gestión de difusión instrucción de difusión Otros recursos Estado de solución y análisis de los cambios cambio de estado disfusión Disponibilidad de incidencia solucionada tareas: Como se puede ver en la Figura 28, el subproceso se descompone en tres 86

4.5.3.2.1. Gestión y planificación de solución de incidencias Consiste en gestionar la solución de las incidencias y establecer los cambios necesarios para dar solución a éstas. 4.5.3.2.2. Control de solución y de cambios En esta tarea se planifican y controlan los cambios a implementar y se analiza cómo éstos afectarán a los otros componentes de los distintos sistemas. Además, controla que se den soluciones a tiempo y cambia las prioridades según envejecimiento. 4.5.3.2.3. Gestión de difusión Consiste en gestionar la disfunción de los cambios necesarios para resolver la incidencia y evitar incidencias futuras en sistemas que presentan la misma falencia, pero aún no se ha manifestado. 4.5.4. Desarrollo, instalaciones, actualizaciones y solución de incidencias Este subproceso es el proceso productivo como tal. En éste se desarrollan los nuevos software, se adecuan los ya existentes, se actualizan los sistemas de los clientes y se da solución a las incidencias que se puedan producir con estos. 87

Figura 29.- Desarrollo, instalaciones, actualizaciones y solución de Incidencias Nuevos Productos y servicios requerimientos Planes Instrucciones técnicas productos y servicios Planes Instrucciones técnicas Necesidad de información y control Planes Instrucciones técnicas Cambio de estados desarrollos Clientes a Proceso Desarrollo de Software Requerimiento o incidencia del Cliente procesado Cambio de estados incidencias Clientes a Proceso Solución de Incidencias Necesidad de información y control Insumos y otros recursos de proveedores incidencia del Cliente procesado Necesidad de información y control Otros Recursos Cambio de estados instalaciones y actualizaciones Infromación de estados de Desarrollo Otros Recursos Clientes a Proceso Información de estados de Incidencias Instalaciones y Actualizaciones Instalación, actualización o solución de la incidencia del sistema del cliente Como se puede apreciar en la Figura 29, el proceso se encuentra compuesto por tres subprocesos: 4.5.4.1. Desarrollo de software En este subproceso se desarrollan los nuevos software y se mantienen e incorporan nuevos requerimientos a los ya existentes. Figura 3.- Desarrollo de Software 88

Plan e instrucciones Planes Requerimientos para desarrollar Instrucciones de entrega cambio de estado producción de software cliente a proceso Desarrollo de Requerimientos de software Software o módulo de Software Necesidad de información y control antecendentes de requerimientos Cliente procesado insumos y otros recursos de proveedores Software o módulo de software Entrega estado de desarrollo de requerimientos otros recursos cambio de estado entrega de software disponibilidad de software o módulo La Figura 3 muestra el subproceso de desarrollo de software. Como se puede apreciar, está compuesto por un subproceso y una tarea que describiremos a continuación: 4.5.4.1.1. Desarrollo de requerimientos de software Este subproceso es en donde definitivamente se trasforman los requerimientos en software, pasando por las etapas de análisis, diseño, codificación, pruebas y mantención. Aquí se encuentra implícito el ciclo de vida del desarrollo de software, el cual, dependiendo del proyecto, podrá estar conformado en forma incremental, a modo de prototipo o en cascada para los requerimientos más pequeños y de bajo riesgo. Se hace necesario modelar un cuarto nivel a partir de este proceso, esto se 89

visualiza en la lógica de negocios. 4.5.4.2. Solución de incidencias En este subproceso se da solución a las incidencias que puedan ocurrir en los sistemas que se encuentran en explotación en los clientes. 9

Figura 31.- Solución de incidencias Plan e instrucciones Planes Incidencia Instrucciones de entrega cambio de estado incidencia cliente a proceso Desarrollo de los cambios necesarios para resolver la incidencia Software o módulo de Software Necesidad de información y control antecendentes de incidencia Cliente procesado insumos y otros recursos de proveedores módulo de software Entrega estado de incidencia otros recursos cambio de estado solución de incidencia disponibilidad de módulo Al igual que le subproceso anterior, este se compone de un subproceso y una tarea: 4.5.4.2.1. Desarrollo de los cambios necesarios para resolver la incidencia Este subproceso es el encargado de desarrollar los cambios necesarios para solucionar la incidencia. Al igual que el caso anterior, este subproceso debe ser modelado en un cuarto nivel que se aprecia en la lógica de negocios. 91

4.5.4.2.2. Entrega Una vez que se prueban los cambios necesarios para solucionar la incidencia, se procede a la entrega de la solución. 4.5.4.2.3. Instalación y actualización En este subproceso se realizan las instalaciones de los sistemas y también se actualizan los que están en producción para evitar incidencias. 4.5.5. Mantención de estados En este procedimiento se consolida la información del estado de los distintos procesos y subprocesos, con el fin de alimentar con mensajes, alertas e información a todos ellos. La implementación de este procedimiento constituye uno de los grandes desafíos de este proyecto, ya que éste debe ser lo suficientemente integrado con las herramientas que utilizan el resto de los procesos, de tal forma, de afectar lo menos posible a la eficiencia de los otros. Esto se logrará integrando al máximo la captura de información de estados con los sistemas que se utilizan en los procesos de cadena de valor. Dentro de estos sistemas podemos mencionar: las herramientas de desarrollo, sistemas que provee Edi-Trade a sus clientes, sistema telefónico central, e-mail de los técnicos, ingenieros y clientes, etc. 92

4.6. Lógica de Negocios 4.6.1. Descomposición Jerárquica de la Macro 1 A continuación detallaremos la descomposición jerárquica del macroproceso Cadena de Valor macro 1. Esto nos ayudará a distinguir los subprocesos que requieren apoyo computacional, destacados en color azul. 4.6.1.1. Administración de requerimientos e incidencias (1) 93

4.6.1.2. Gestión de desarrollo, incidencias y entrega (3) 3.1.1 Asignaciónde Desarolos 3.1.2.2 AsignacióndeProblemas 3.1.2.3 AsignacióndeEquipode TrabajoProyectode Software 3.1.2.3.1 AsignacióndeEquipoy PaquetesdeTrabajo 3.1.2.3.2 CálculodePlazoy Presupuesto 3.1.2.1 Asignaciónde Requerimientos 3.1 GestióndeDesarolode Software 3.1.2 PlanificaciónyControl dedesarolo 3.1.2.1 PlanificaciónyControl deproblemas 3.1.2.2 PlanificaciónyControl depaquetesdetrabajo 3.1.2.3 PlanificaciónyControl derequerimientos 3 GestióndeDesarolo, IncidenciasyEntrega 3.1.2 GestióndeEnterga 3.1.2.1 GestióndeEntregade SolucióndeProblemas 3.1.2.2 GestióndeEntregade Software 3.1.2.3 GestióndeEntregade Requerimientos 94

4.6.1.3. Desarrollo, instalaciones, actualizaciones y solución de incidencias (4) 4 Desarrollo, Instalaciones, Actualizacionesy Soluciónde Incidencias 4.1 DesarrollodeSoftware 4.2 Soluciónde Incidencias 4.3 DisfusióndeCámbios einstalación 4.1.1 Desarrollo 4.1.2 EntregaDesarrollo 4.2.1 Atender Incidencia 4.2.2 CierreIncidencia 4.3.1 Configuración 4.3.2 CierredeActividad 95

4.6.2. Definición de actividades con apoyo computacional. A continuación se muestran los procesos con apoyo computacional. En los diagramas hemos definido la pista Sistema Front-end para identificar al sistema Internet que interactúa en el proceso. El motivo de esto es diferenciarse con el Sistema Background, que es el encargado de enviar alertas y que está constantemente en ejecución. 4.6.2.1. Administración de requerimientos e incidencias 4.6.2.1.1. Captura de Requerimientos (1.1.1) Este proceso se encarga de registrar los requerimientos y quién los solicita. 96

Figura 32.- Captura de Requerimientos Cliente Necesidad Desarrollo Solicitar Desarrollo Técnicos de Desarrollo Registro Requerimiento Sistema Front-end Buscar Datos Contacto Existen datos Sí Registrar Información Requerimiento Enviar Mensaje Ticket No Buscar en BD externa Enviar Alerta Ticket Sistema Busqueda de Datos Buscar Datos Jefe de Desarrollo 97

4.6.2.1.2. Análisis comercial de requerimientos (1.1.2) Figura 33.- Análisis Comercial de Requerimientos Jefede Desarrollo Ver Requerimientos no Asignados Seleccionar Requerimiento Analizar Requerimiento Informar Area Comercial Necesita intervención comercial Sí No Pasar a Producción Sistema Front-end Desplegar Requerimientos no Asignados Obtener Datos Requerimiento Enviar ajefe Comercial Encolar Requerimiento Sistema Background Inicio Seguimiento Alertar Está acordado Sí No Alertar Jefe Comercial 4.6.2.1.3. Detección de incidencias (1.2.1) y captura de incidencias (1.2.2) En este proceso se registra la incidencia en la base de datos. Para esto debe considerarse si es que están los datos del cliente en la base de datos; de no estarlos, se debe ir a buscar a una base de datos externa para evitar su digitación. Esta base de datos externa es la del sistema del cliente que está solicitando soporte. Luego de esto, el sistema debe asignar al Departamento de Soporte o al Departamento de Desarrollo en base a si el solicitante de atención es un cliente o un usuario del sistema. Un cliente es una persona que paga por nuestros servicios o una persona que toma la decisión de contratar nuestros servicios; un usuario es una persona que trabaja en una empresa que contrató nuestros servicios y utiliza nuestros sistemas. 98

La información de las personas que solicitan soporte y su respectiva clasificación son obtenidas de una base de datos externa cuya mantención no está involucrada en el proyecto, por lo tanto, el proceso de mantención de las bases de datos externas no aparecerá especificado en este proyecto. 99

Figura 34.- Detección de Incidencias y Captura de Incidencias In c id e n c ia R e p o r ta r In c id e n c ia In fo r m a r á te le fo n ic a m e n te No C lie n te Sí L la m a r P o r T e lé fo n o In fr o m a r P o r p á g in a W e b P á g in a w e b R e g is tr o In c id e n c ia T é c n ic o s d e S o p o r te R e g is tr o In c id e n c ia No In fo r m ó te le fó n ic a m e n te D e s p le g a r T ic k e t E n v ia r M e n s a je T ic k e t Sí D e s p le g a r T ic k e t S is te m a F r o n t- e n d B u s c a r D a to s C o n ta c to No A s ig n a r a S o p o r te E x is te n d a to s No Sí R e g is tr a r In fo r m a c ió n In c id e n c ia in fo r m a u n c lie n te Sí A s ig n a r a D e s a r r o llo B u s c a r e n B D e x te r n a E n v ia r A le r ta T ic k e t E n v ia r A le r ta T ic k e t S is te m a B u s q u e d a d e D a to s B u s c a r D a to s J e fe d e S o p o r te J e fe d e D e s a r r o llo 1

4.6.2.2. Gestión de Desarrollo, Incidencias y Entrega (3) 4.6.2.2.1. Asignación de Problemas (3.1.2.2) Este proceso es el mismo para las incidencias atendidas por el Departamento de Soporte y las que atienden el Departamento de Desarrollo. La gestión de problemas se realiza de forma análoga, ya que consiste en lo mismo, gestionar y asignar una persona responsable de la solución. La única diferencia es que la gestión de problemas sólo la realiza el jefe de desarrollo, pero el proceso es el mismo. Figura 35.- Asignación de Problemas Programador Jefede Desarrollo Ver Problemas Seleccionar Problema Seleccionar Persona Sistema Front-end Obtener Problemasno asignados Obtener Información Ticket Proponer Personas Posibles Registrar Asignacion Enviar Asignacion Sistema Background Inicio Seguimiento 11

4.6.2.2.2. Asignación equipo de trabajo (3.1.2.3.1) En este proceso se ingresan los paquetes de trabajo a desarrollar según el modelo del sistema: el sistema los registra y propone una asignación de acuerdo al equipo de trabajo registrado junto con los paquetes. Luego, el sistema propone la asignación de paquetes basados en el punto función para el cálculo del esfuerzo de los paquetes ingresados y los distribuye entre los desarrolladores, utilizando un algoritmo basado en el método Roy. El usuario modifica y confirma la asignación de paquetes para que queden registrados en el sistema. Figura 36.- Asignación equipo de trabajo Desarrolla dores Crear Proyecto ExisteEquipo No Conformar equipode Trabajo Conformar paquetesde Trabajo Modificar Asignación Propuesta Jefede Dasarrollo Sí Ingresar Equipode Trabajo Sistema Internet Registar Proyecto Registrar equipo detrabajo Ver Asignaciones del Personal Registrar Paquetesde Trabajo Asignación depaquetes Registrar asignación Enviar Avisoa Equipode Trabajo 4.6.2.2.3. Cálculo de plazo y presupuesto (3.1.2.3.2) En este proceso se determina los plazos y presupuestos involucrados, en base a la información ingresada de la conformación de los equipos y paquetes de trabajo. 12

Figura 37.- Cálculo de plazo y presupuesto Desarrolla dores Seleccionar Proyecto Analizar Cálculo Está Conforme Sí Confirmar Plazoy Presupuesto No Jefede Desarrollo Realizar Ajustes a Factores de Cálculo Cambiar Asignación Paquetes de Trabajo Sistema Internet Desplegar Proyectos Cargar Asignaciónde Paquetes de Trabajo Calcular Punto FuncióndePlazoy Presupuesto Registrar Presupuestoy plazo Generar InformePlazoy presupuesto Semodificó asignación Paquetes de Trabajo Sí Registrar Asignación Paquetes de Trabajo Enviar Mensaje Asignación No 13

4.6.2.2.4. Asignación de requerimientos (3.1.2.1) Figura 38.-Asignación de Requerimientos Desarrollador Jefede Desarrollo Ver Requerimientosno Asignados Seleccionar Requerimiento Seleccionar Persona Sistema Front-end Desplegar Requerimientosno Asignados Obtener Datos Requerimiento Proponer Personas Posibles Registrar Asignacion Enviar Asignacion Sistema Background Inicio Seguimiento 14

4.6.2.2.5. Control de problemas (3.1.2.1) Figura 39.- Control de Problemas Desarrolla dor Jefede Desarrollo Ver Problemas Críticos Analizar Problemas HayProblemas quereasignar Sí Ver desarrolladores Reasignar Problema No Sistema Front-end Cargar Problemas Críticos Cargar Asignaciones del Personal Registrar Asignación Enviar Mensaje deasignación Sistema Background Iniciar seguimiento 4.6.2.2.6. Control de paquetes de trabajo (3.1.2.2) El proceso de control, pretende gestionar los paquetes de trabajo que no están cumpliendo el plazo y el presupuesto fijado, y requieren una intervención. A través del sistema se registra la asignación de nuevos recursos para aminorar el desfase en base al criterio del desarrollador a cargo. 15

Figura 4.- Control de Paquetes de Trabajo Desarrolla dor Jefede Desarrollo Ver Proyectos Críticos Ver Paquetesde Trabajo Críticos Analizar Paquetesde Trabajo HayPaquetes detrabajoque Reasignar Sí Ver desarrolladores Reasignar Paquetesde Trabajo No Sistema Front-end Cargar Proyectos Críticos Cargar Paquetesde Trabajo Cargar Asignaciones del Personal Registrar Asignación Enviar Mensaje deasignación Sistema Background Iniciar seguimiento 16

4.6.2.2.7. Control de requerimientos (3.1.2.3) Figura 41.- Control de Requerimientos Desarrolla dor Jefede Desarrollo Ver Requerimientos Críticos Analizar Requerimientos Hay Requerimientos quereasignar Sí Ver desarrolladores Reasignar Requerimientos No Sistema Front-end Cargar Requerimientos Críticos Cargar Asignaciones del Personal Registrar Asignación Enviar Mensaje deasignación Sistema Background Iniciar seguimiento 17

4.6.2.2.8. Asignación de incidencias (3.2.1.1) Figura 42.- Asignación de Incidencias Técnicoo Programador Jefede Soporte o Jefede Desarrollo Ver Incidencias Seleccionar Incidencia Seleccionar Persona Sistema Front-end Obtener Incidenciasno asignadas Obtener Información Ticket Proponer Personas Posibles Registrar Asignacion Enviar Asignacion Sistema Background Inicio Seguimiento 4.6.2.2.9. Publicación de cambios (3.2.1.2.1) En la gestión de cambios se evalúa si los cambios están listos para ser difundidos. Un vez que el jefe de desarrollo estima que los cambios realizados son satisfactorios, el sistema los publica en la bitácora de cambios y envía un mensaje al jefe de soporte, ordenando la difusión y despliegue de ellos. 18

Figura 43.- Publicación de Cambios Jefe Desarrollo Ver Cambios Seleccionar Cambio Evaluar Cambio Cambio Ok Sí No Mejorar Cambio Publicar Cambio Sistema Front-end Mostrar Cambios Cargar Datos Cambio Publicar Cambio Ordenar Difusión Jefe de Soporte 4.6.2.2.1. Asignación de difusión de cambios (3.2.1.2.2) Este proceso tiene como objetivo asignar a los difusores del cambio en el Departamento de Soporte. La asignación es realizada por el sistema a pedido del Jefe de Soporte, quien puede modificar la asignación de éstos, para luego registrar quiénes serán los difusores. El sistema enviará un mensaje al personal de soporte que deberá realizar el cambio. Una vez que el personal de soporte difunde el cambio, debe registrar su acción. 19

Figura 44.- Asignación de Difusión de Cambios Jefe Soporte Ver Cambios nodifundidos Ver Cambios Hay No Cambios sindifundir Sí Seleccionar Cambio Seleccionar Difusores Modificar y Confirmar Difusores Sistema Front-end Desplegar Cambiosno Difundidos Desplegar Difusores Asignar Difusores Registrar Difusión Avisar Difusión Técnicos Soporte 11

4.6.2.3. Desarrollo, instalaciones, actualizaciones y solución de incidencias (4) 4.6.2.3.1. Atención incidencia (4.2.1) Figura 45.- Atención de Incidencias Ayudar a Cliente Ayuda No Configuración Técnico desoporte Ver Tickets Técnico Seleccionar Ticket Atender Ticket Tipo Atención Gestiónde Configuración cliente conforme Sí Producto Problema Informar Problema Informar Necesidadde Producto Registrar Clienteno Conforme Evaluar Conformidad Cierre Incidencia Llenar Encuestade Cierre Sistema Front-end Cargar Ticket Técnico Cargar Datos Ticket Informar ajefe dedesarrollo Informar ajefe Comercial Iniciar Seguimiento Registro enbitácora CierreTicket Desplegar Encuesta Registrar Encuesta Sistema Back- Ground Seguimiento Está cerradoel ticket Sí Alertar a Técnico No Jefe Comercial Jefede Desarrollo 4.6.2.3.2. Cierre de incidencia, evaluar conformidad Estos procesos corresponden a un simple registro en la bitácora de la incidencia. El registro en la bitácora es una mantención de estado, más el ingreso de información adicional para una eventual revisión o consulta de un jefe o del cliente. 111

Figura 46.- Cierre de Incidencia, evaluar conformidad Ayudar a Cliente Soporte Evaluar Conformidad cliente conforme Sí Gestión de Configuración No Registrar Cliente no Conforme Cierre Incidencia Llenar Encuesta de Cierre Registro en Bitácora Registro Bitácora Desplagar Encuesta Registrar Encuesta Sistema Front-end 4.6.2.4. Desarrollo de proyectos de software 4.6.2.4.1. Codificación, entrega, depuración, construcción de manuales, captura de nuevos requerimientos, desarrollo de nuevos requerimientos. Estos procesos corresponden a un registro en la bitácora del proyecto y los sistemas de mantención de estados, más comentarios útiles. 112

Figura 47.- Codificación, entrega, depuración. entrega depuración Desarrollo Construcción Manuales captura nuevos requerimientos desarrollo nuevos requerimientos Sistema Internet registro bitácora 4.6.2.4.2. Desarrollo de mejoras y requerimientos de software. Este proceso pretende controlar los tiempos de cumplimiento y las asignaciones de recursos. Un sistema Back-ground deberá estar siempre en ejecución para que envíe mensajes de alerta al jefe de desarrollo en caso de que el cumplimiento de los plazos se encuentre amenazado. 113

4.6.2.5. Apoyo computacional El apoyo computacional consiste, en su mayoría, en flujos de información desde una interfase de usuario a una base de datos. A este tipo de apoyo lo conocemos como mantención de estados y no cuenta con algoritmos complejos que necesiten ser detallados en esta fase del modelamiento del apoyo. Sin embargo, existen algunas interfaces de usuario y procesos en background que utilizan algoritmos un poco más complejos, los cuales merecen ser detallados en esta etapa previa al modelamiento UML. A continuación se muestran los algoritmos más complejos de apoyo computacional: 4.6.2.5.1. Soporte al cliente Registro incidencia public void registrarincidencia(incidencia incidencia) { if (escliente(incidencia.getsolicitante())) asignaincidenciaadesarrollo(incidencia); else asignaincidenciaasoporte(incidencia); } Gestión de incidencias public void gestionarincidencia(incidencia incidencia, Boolean esproblema, Boolean necesitaayuda) { if (esproblema) asignaincidenciagestiondeproblemas(incidencia); else if (necesitaayda) registrarenbitacoraincidencias(incidencia,necesitaayuda); else { Tecnico tecnico= solicitartecnico(inicencia); Prioridad prioridad= determinarprioridad(incidencia); incidencia.setpropridad(prioridad); asignartecnico(incidencia,tecnico); registrarenbitacora(inciencia,tecnico); } 114

} private Tecnico solicitartecnico(incidencia incidencia) { Tecnico tecnico= gettecnicodesocupado(incidencia.getespecialidad()); if (tecnico == null) { Tecnicos[] tecnicos= gettecnicoposible(incidencia.getespecialidad()); tecnico= proponertecnicoalusuario(inidencia,tecnico); } return tecnico; } private Prioridad determinarprioridad(incidencia incidencia) { if (incidencia.getproducciondetenida()) return new Prioridad(); else if (incidencia.getelementoproducciondetenida()) if (incidencia.getestaenplazolimite()) return new Prioridad(5); else return new Prioridad(1); else if (incidencia.getelementodegestiondetenida()) return new Prioridad(15); else return solictarprioridadalusuario(incidencia); } Sistema de control public void encolarincidencia(incidencia incidencia) { incidencia.setfechahora(new Date()); if (incidencia.getfechacompromiso() == null) incidencia.setfechacompromiso(new Date() + 24 hrs); putcola(incidencia); } public void daemon(cola cola) { for (Incidencia incidencia : cola) { if (incidencia.estacerrada()) delete(incidencia,cola); else if (indencia.getfechacompromiso() - (indencia.getfechacompromiso() - incidencia.getfechahora())/3) > new Date() &&!incidencia.getadvertida()) sendadvertencia(incedencia,incidencia.gettecnico(),supervisor); else if (indencia.getfechacompromiso() > new Date() &&!incidencia.getalarma()) sendalarma(incedencia,incidencia.gettecnico(),supervisor); } Thread.sleep(6 * 6 * 1); } public void crondiario() { if (indencia.getfechacompromiso() > new Date()) sendalarma(incedencia,incidencia.gettecnico(),supervisor); 115

} 4.6.2.6. Desarrollo de software 4.6.2.6.1. Cálculo punto función plazo y esfuerzo La siguiente lógica corresponde al algoritmo que utilizaremos para el cálculo del esfuerzo. Variables EI: Entradas Externas EO: Salidas Externas EQ: Consultas Externas ILF: Archivos Lógicos Internos EIF: Archivos Interfaz Externos DET: Tipo Elemental de Dato RET: Tipo Elemental de Registro FTR: Tipo Archivo Referenciado Complejidad Para un ILF e EIF 1 a 19 DETs 2 a 5 DETs 51 o más DETs 1 RET Baja Baja Media 2 a 3 RETs Baja Media Alta 4 o más RETs Media Alta Alta Complejidad para un EI 1 a 4 DETs 5 a 15 DETs 16 o más DETs a 1 FTR Baja Baja Media 2 FTRs Baja Media Alta 3 o más FTRs Media Alta Alta Complejidad para un EO 1 a 5 DETs 6 a 19 DETs 2 o más DETs a 1 FTR Baja Baja Media 116

2 a 3 FTRs Baja Media Alta 4 o más FTR Media Alta Alta Complejidad para un EQ en el lado Input 1 a 4 DETs 5 a 15 DETs 16 o más DETs a 1 FTR Baja Baja Media 2 FTRs Baja Media Alta 3 o más FTRs Media Alta Alta Complejidad para un EQ en el lado Output 1 a 5 DETs 6 a 19 DETs 2 o más DETs a 1 FTR Baja Baja Media 2 a 3 FTRs Baja Media Alta 4 o más FTRs Media Alta Alta PFB: Punto de Función Bruto Tipo de Función Sim Me Com ple dio plejo N Entradas externas _ * _ * _ * 6 3 4 N Salidas externas _ * _ * _ * 7 4 5 N Consultas externas _ * _ * _ * 6 3 4 N Archivos Lógicos Internos _ * _ * _ * 7 1 15 N Archivos de Interfaz Externa _ * _ * _ * 5 7 1 Punto de Función Bruto (PFB): PF: Punto de Función Fa: Factor de ajuste Gi: Grado de influencia [..5] PF= PFB * Fa Fa=,65 + (,1 * Sum(Gi)) al Tot 4.6.2.6.2. Asignación de paquetes de trabajo Para cada actividad (Aj) necesaria para realizar el proyecto, habrá que especificar qué actividades son precedentes (Pk). Todas las relaciones de precedencia 117

serán final comienzo. Para cada actividad (Aj) también se deberá especificar todas las posibles duraciones i que puede tener la actividad j (Dij), así como el número de trabajadores necesarios para la duración i de la actividad j por día (Tij). Existirá un número máximo de trabajadores por día en el proyecto (T máx ). Paso 1: Se dibujará el diagrama de red ROY para la duración más corta de todas las actividades. A partir de él se obtendrá el camino crítico y las holguras totales de todas las actividades. Paso 2: Se irán asignando trabajadores a actividades analizando día a día, empezando en t=. Paso 3: En el tiempo (t) analizado, se establecerá qué actividades son candidatas a ser las asignadas de los recursos disponibles. Para ello, únicamente habrá que fijarse en el diagrama de red y una actividad no podrá ser candidata hasta que todas sus actividades precedentes hayan sido asignadas y se hayan finalizado. Paso 4: De entre las actividades candidatas, se elegirá aquella que tenga menor holgura total. Se recuerda que todas las actividades pertenecientes al camino crítico tienen una holgura igual a cero. En caso de igualdad a holgura total, se elegirá aquella actividad cuya duración más corta sea la menor. Si persistiese la igualdad, se elegirá la actividad que necesite el menor número de trabajadores en su duración más corta. Si todavía persistiese la igualdad, se elegirá una cualquiera indiferentemente. Paso 5: Para la actividad elegida, se deberá decidir en qué duración de las posibles se va a realizar, y qué trabajadores por día se van a necesitar. La duración que tendrá esa actividad será la menor de las posibles, comprobando que no se supera el número máximo de trabajadores por día (T máx ). Esto se realizará con ayuda de un gráfico de carga. Se volverá al paso cuatro hasta que para el tiempo (t) analizado ya no sea posible elegir ninguna actividad más debido a falta de trabajadores libres. 118

Paso 6: Ir al siguiente tiempo (t) en el cual alguna actividad puede empezar a ser realizada. Paso 7: Volver a realizar el diagrama de red ROY, teniendo en cuenta las duraciones establecidas en las actividades elegidas, el tiempo (t) en el que se encuentra y tomando las mínimas duraciones para las actividades no asignadas todavía. Se vuelven a obtener el camino crítico y las holguras totales para las actividades no asignadas. Paso 8: Volver al paso tres hasta que todas las actividades estén programadas, y se tenga una fecha de inicio y fin de cada actividad, así como el gráfico de carga del proyecto. 119

5. LÓGICA DE NEGOCIOS CONSOLIDADA 5.1. Desarrollo de software La lógica de negocios implícita en el proceso de negocio de Desarrollo de Software está basada en un diseño por planificación 17. Se eligió esta metodología ya que se adapta a la realidad de la empresa y de los proyectos en los que ésta se ve involucrada. Sin embrago, esta metodología ha sido modificada para adaptarla a las necesidades de la empresa: le hemos agregado los mecanismos de control necesarios de los tiempos críticos; se han incorporado procesos de construcción de prototipos y verificación de estos con los usuarios, mecanismos de validación de diseño en comité y mecanismos de depuración de entregas; finalmente, hemos agregado un mecanismo que permita iniciar un subproyecto a partir de los nuevos requerimientos que se puedan generar durante el ciclo de vida de la construcción del software. En la Figura 48 se muestra la lógica de negocios que hemos diseñado: 17 HAX, A.C y D.L WILDE II. 21. The Delta Project. Palgrave 12

Figura 48.- Lógica de negocios para desarrollo de proyectos de software I n i c i o P r o y e c t o C a p t u r a d e r e q u e r i m i e n t o s A n á l i s i s d e R e q u e r i m i e n t o s C o n s t r u c i ó n d e I n t e r f a c e s p r i n c i p a l e s N o P r e s e n t a c i ó n d e I n t e r f a c e s a l c l i e n t e c l i e n t e c o n f o r m e C ie r r e d e U R D Sí D i e s ñ o G l o b a l R e v i s i ó n d e D i s e ñ o c o n t r a r e q u e r i m i e n t o s E v a l c u c i ó n d e l e q u i p o d e r e q u e r i m i e n t o s N o e q u i p o c o n f o r m e C o n f o r m a c i ó n d e P a q u e t e s d e T r a b a j o Sí D e f i n i c i ó n d e P l a z o y p r e s u p u e s t o c o d i f i c a c i ó n, d e p u r a c i ó n y p r u e b a s d e p a q u e t e s d e A l t a p r i o r i d a d i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 1 Sí d e p u r a c i ó n c o d i f i c a c i ó n, d e p u r a c i ó n y p r u e b a s d e p a q u e t e s d e M e d i a - A l t a p r i o r i d a d i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 2 e r r o r Sí d e f u n c i o n a m i e n t o E n t r e g a c o d i f i c a c i ó n, d e p u r a c i ó n y p r u e b a s d e p a q u e t e s d e M e d i a p r i o r i d a d i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 3 Sí c o d i f i c a c i ó n, d e p u r a c i ó n y p r u e b a s d e p a q u e t e s d e M e d i a - B a j a p r i o r i d a d i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 4 Sí c o d i f i c a c i ó n, d e p u r a c i ó n y p r u e b a s d e p a q u e t e s d e B a j a p r i o r i d a d i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 5 Sí Sí h a y n u e v o s r e q u e r i m i e n t o s N o C o n s t r u c c i ó n M a n u a l e s i n y e c t a r r e c u r s o s N o e s t a a t i e m p o C o n t r o l 6 E n t e r g a f i n a l Sí 121

5.2. Soporte al Cliente Para el diseño de la lógica de negocios del proceso de negocio de soporte al cliente, hemos tomado como base el modelo ITIL. A este modelo le hemos agregado mecanismos de alertas y lo hemos detallado a más bajo nivel para poder simular el proceso. En este procedimiento, los tiempos de espera son críticos, por lo que hemos decido simularlo. Los resultados de la simulación de verán en el punto Simulación. En la Figura 49 se aprecia la lógica de negocios mencionada. 5.3. Desarrollo de Requerimientos Este proceso se encarga de la mejora continua de los proyectos ya entregados. Es por esto que se debe manejar en forma paralela y asignar recursos especiales a los procesos de negocios de desarrollo de proyectos de software y soporte al cliente. Para definir esta lógica de negocios, hemos mezclado lo que se refiere a desarrollo de software con las buenas prácticas ITIL. En la Figura 5 se muestra la lógica de negocios detallada de este proceso. 122

Figura 49.- Lógica de negocios soporte al cliente Gestion de Incidencias Gestión de Problemas Desarrollo de Mejoras Pruebas Desarrollo Es problema No Sí No Pruebas Exitosas Sí No Cliente Conforme Instalación de Mejoras Sí Necesita ayuda Sí Cierre Incidencia No Gestión de Cambios Ayudar a Cliente Sí Ingreso Incidencias informa un cliente Incidencia Resuelta No Incidencia EdiTrade Soporte Gestión de Disfusión Sí Necesita ayuda Sí Es Problema No Gestión de Incidencias Cierre Incidencia Ayudar a Cliente No Sí Gestión de Configuración Evaluar Conformidad cliente conforme No Genera Alerta No Sistema Control De desarrollo No Está Ok Sí Seguimiento Está Ok Sí Está Lista No Sí No Está Listo Sí Genera Alerta Jefe de Desarrollo Alerta Jefe Soporte Alerta 123

Figura 5.- Lógica de negocios de desarrollo de requerimientos Requerimiento Gestión de Requerimientos Desarrollo Requerimientos No Cliente Conforme Sí Cierre Desarrollo Pruebas Desarrollo terminado Desarrollo No Pruebas Exitosas Sí Instalación de Nuevas Funcionalidades se incorpora a versión oficial No Gestión de Cambios Sí EdiTrade Soporte Gestión de Disfusión Genera Alerta Sistema Control De desarrollo No Está Ok Sí No Está Listo Sí Jefe de Desarrollo Alerta 124

5.4. Simulación Se ha escogido el proceso de Soporte al Cliente para ser simulado, ya que en éste el tiempo de servicio es crítico para prolongar la relación con el cliente en el tiempo. A partir de la información recopilada del actual funcionamiento de este proceso de negocios que se encuentra en rediseño, establecimos los parámetros que presentaremos a continuación. Se establecieron tiempos de ejecución y calentamiento suficientes para poder evaluar el modelo. Cabe destacar que en base a los resultados de la simulación se mejoraron algunos puntos en el proceso que permitieron mejorar considerablemente el tiempo de respuesta en concordancia con los costos. También se costeó la asignación de recursos por área para lograr un mejor equilibrio entre costos y tiempo de respuesta. 125

5.4.1. Parámetros 5.4.1.1. Configuración de Ejecución 126

5.4.1.2. Generadores 127

5.4.1.3. Recursos 128

5.4.1.4. Definición de horario 129

5.4.2. Resultados 5.4.2.1. Tiempo Tiempo transcurrido (Semanas) 7,14 1 Estadísticas de transacción (Horas) º 31 N Pro Prom. Pr m. Ciclo Trabajo om. Esp 1 7,6 8,42,77 5 Prom. Esp rec Prom. Bloqueo, 5,42 Pro m. Inact 2,2 3 Pro m. Serv 6,19 13

Estadísticas de transacción (Horas) P Pro N rom. m. º Ciclo Trabajo Edi- 2,,3 Trade/Desarrollo 6 36 1 Edi-Trade/Ingreso 1 4,, Incidencias 31 56 Edi-Trade/Jefe de N N/ Desarrollo /D D Edi-Trade/Jefe 2 1, Soporte 45 1,81 Edi-Trade/Sistema 2 4, <, 45 91 1 Edi-Trade/Soporte 8 4,,9 66 52 8 Estadísticas de transacción (Horas) N Pro Prom. Pr º m. Ciclo Trabajo om. Esp B 1 7,6 8,42,77 PD1 31 5 P rom. Esp Pr om. Esp rec,,4 4,,56 N N/ /D D 1, 1,81 4,,91 3,,54 Prom. Esp rec Prom. Bloqueo, 5,42 Pro m. Bloqueo, 4,5 6 N/D 11,8 1 1,7 4,1 5 P rom. Inact, 4, N /D, 3, 17 3, 39 Pro m. Inact 2,2 3 Pr om. Serv, 31 4, 56 N/ D 11,81 1, 74 1, 13 Pro m. Serv Estadísticas de actividad (Horas) (25 de 44 filas) P P P P P P P N rom. rom. rom. rom. rom. rom. rom. º TT Trabaj Esp Bloque Ciclo Esp Inact Serv o rec o Edi-Trade/Soporte - Gestión de 2 Incidencias 64,51,8,43,,,43,8 Edi-Trade/Ingreso Incidencias - 1 Incidencia 29,,,,,,, Edi-Trade/Ingreso Incidencias - 1 informa un cliente 29,,,,,,, Edi-Trade/Soporte - Es Problema 1 32,,,,,,, Edi-Trade/Ingreso Incidencias - 1 4 4 4 4 Incidencia Resuelta 31,56,,56,,56,,56 Edi-Trade/Sistema - 1 13,,,,,,, Edi-Trade/Soporte - Necesita ayuda 8 26,,,,,,, Edi-Trade/Sistema - Está Ok 6 131 6,19

Edi-Trade/Sistema - Seguimiento Edi-Trade/Soporte - Ayudar a Cliente Edi-Trade/Sistema - Está Lista Edi-Trade/Desarrollo Gestión de Problemas Edi-Trade/Sistema - Edi-Trade/Sistema - Control De desarrollo Edi-Trade/Sistema - Está Ok Edi-Trade/Sistema - Está Listo Edi-Trade/Desarrollo - Instalación de Mejoras Edi-Trade/Sistema - Genera Alerta Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Desarrollo Gestión de Incidencias Edi-Trade/Desarrollo - Es problema Edi-Trade/Soporte - Edi-Trade/Soporte - Cliente Conforme Edi-Trade/Soporte - Evaluar Conformidad 71,,,,,,, 6 < < < 71,1,1,,,,,1 6 1 62,3,34,96,,,96,34 5 37,,,,,,, 5 16,43,8,35,,,35,8 4 3 3 1 2 1 33,46,,46,,42,5,42 4 < < < 4,1,1,,,,,1 4 4,,,,,,, 3 23,,,,,,, 2 1 1 1 84,59,58,1,,,1,58 2 < < < 66,1,1,,,,,1 2 1 1 6 1 6 59 8,13, 8,13,, 2,13, 2 58,,,,,,, 2 < < 58,6,5,1,,,1,5 2 58,,,,,,, 2 1 1 1 58,57,,57,,5,7,5 2 58,,,,,,, 2 1 1 1 58,65,33,32,,,32,33 132

5.4.2.2. Costos Estadísticas de transacción N Pro Prom. Prom. º m. Coste MO Coste Eq. Coste 1 226,, 31 2,45 Prom. Otro Coste 2262,4 5 Prom. Est. Coste 2262,4 5 Prom. HE Coste, Estadísticas de transacción To To N Tot t MO t Eq. º Coste Coste Coste 1 233 31 2585,,, Tot Otro Coste 233 2585, Tot Est. Coste 233 2585, T ot HE Coste Tot VA Coste, 233 2585, Tot SVA Coste, Tot VAC Coste, 133

Estadísticas de transacción Edi- Trade/Desarrollo Edi- Trade/Ingreso Incidencias Edi-Trade/Jefe de Desarrollo Edi-Trade/Jefe Soporte Edi- Trade/Sistema Edi- Trade/Soporte º 6 31 45 45 66 N Tot Coste 5 2 934, 1 2 2,,,, 18 8 23245, ot MO Cost e,,,,,, T T ot Tot Eq. Otro Cost Coste e 5, 934,,,,,,,,, 18, 23245, Tot Est. Coste 5 934,,,,, 18 23245, ot HE Cost e,,,,,, T Tot VA Coste 5 934,,,,, 18 23245, ot SVA Cost e,,,,,, T ot VAC Cost e T,,,,,, Estadísticas de recursos Trabajador Edi- Trade/Desarrollo Edi- Trade/Ingreso Incidencias Edi-Trade/Jefe de Desarrollo Edi-Trade/Jefe Soporte Edi- Trade/Sistema Edi- Trade/Soporte N úmero 4 1 1 1 4 6 Pr T omt Uso ot Coste 4,2,,,,, 1 19,15,,,,, Tot Est. Coste,,,,,, Tot HE Coste,,,,,, Tot Coste actividad,,,,,, Tot Coste uso,,,,,, 134

Estadísticas de recursos T N Pr ot úmero omt Uso Coste Tr 1 16,, abajador 7 22 Estadísticas de recursos Trabajador T N Pr Tot ot úmero omt Uso Est. Coste Coste 1 16,,, 7 22 Tot Est. Coste, Tot HE Coste, Tot HE Coste, Tot Coste actividad Tot Coste actividad,, Tot Coste uso Tot Coste uso,, Estadísticas de actividad T N Tot ot MO º TT Coste Coste 934 B 1 416, PD1 8312, T ot Eq. Coste, Tot Otro Coste Tot Est. Coste 934 934 416, 416, T ot HE Coste, Tot VA Coste 934 416, T ot SVA Coste, To t VAC Coste, 135

Estadísticas de actividad (25 de 44 filas) Edi-Trade/Desarrollo - Desarrollo de Mejoras Edi-Trade/Soporte - Gestión de Configuración Edi-Trade/Desarrollo - Pruebas Edi-Trade/Soporte - Ayudar a Cliente Edi-Trade/Desarrollo - Instalación de Mejoras Edi-Trade/Desarrollo - Ayudar a Cliente Edi-Trade/Soporte - Gestión de Incidencias Edi-Trade/Soporte - Evaluar Conformidad Edi-Trade/Desarrollo - Gestión de Cambios Edi-Trade/Desarrollo - Gestión de Problemas Edi-Trade/Desarrollo - Gestión de Incidencias Edi-Trade/Desarrollo - Cierre Incidencia Edi-Trade/Soporte - Cierre Incidencia Edi-Trade/Sistema - Edi-Trade/Sistema - Genera Alerta Edi-Trade/Sistema - Edi-Trade/Sistema - Está Listo Edi-Trade/Sistema - Seguimiento Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Sistema - Está OK Edi-Trade/Sistema - Edi-Trade/Sistema - Está Lista Edi-Trade/Sistema - Edi-Trade/Sistema - Genera Alerta Tot Coste 528 51, 838 5, 714 15, 542 84, 532 5, 429, 221 88, 221 88, 178 1, 167 7, 1 62, 676, 442 9,,,,,,,,,,,,, ot MO Coste T ot Eq. Coste T Tot Otro Coste 528,, 51, 838,, 5, 714,, 15, 542,, 84, 532,, 5, 429,,, 221,, 88, 221,, 88, 178,, 1, 167,, 7, 1,, 62, 676,,, 442,, 9,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, Tot Est. Coste 528 51, 838 5, 714 15, 542 84, 532 5, 429, 221 88, 221 88, 178 1, 167 7, 1 62, 676, 442 9,,,,,,,,,,,,, ot HE Coste,,,,,,,,,,,,,,,,,,,,,,,,, T Tot VA Coste ot SVA Coste 528 51,, 838 5,, 714 15,, 542 84,, 532 5,, 429,, 221 88,, 221 88,, 178 1,, 167 7,, 1 62,, 676,, 442 9,,,,,,,,,,,,,,,,,,,,,,,,,, T ot VAC Coste T º TT N 2, 23 2, 58 2, 7 6, 62 2, 84 1, 65 2, 64 2, 58 1, 37 5, 16 2, 58 1, 4 2, 6 8, 1, 62 2, 58 3, 23 6, 71 2, 59 4, 33 6, 71 1, 7 5, 37 1, 13 2, 66 136

5.4.2.3. Recursos Promedio ponderado en el tiempo uso de recursos Tra bajador 1 6,22 137

Estadísticas de recursos (Días) Tra bajador N úmero 1 7 P romt Uso 1 6,22 Pro m. Actividad 5,2 3 Estadísticas de recursos (Días) Trabajador Edi- Trade/Desarrollo Edi-Trade/Ingreso Incidencias Edi-Trade/Jefe de Desarrollo Edi-Trade/Jefe Soporte N úmero Edi-Trade/Sistema 4 Edi-Trade/Soporte 6 4 1 1 1 Pr om. Disponib romt Uso P 4,2,,,,1 1 9,15 27, 4 P rom. Inact Pr om. Activida d 8 4,15 12,97,,, <,1 6, 18 rom. TFS P 3,58 Pr om. Disponi b Estadísticas de actividad (minutos) (25 de 44 filas) Edi-Trade/Desarrollo - Edi-Trade/Desarrollo - Desarrollo de Mejoras Edi-Trade/Ingreso Incidencias - Incidencia Edi-Trade/Ingreso Incidencias - Informa un Cliente Edi-Trade/Ingreso Incidencias - Incidencia Resuelta Edi-Trade/Sistema - Control De desarrollo Edi-Trade/Sistema - Está OK Edi-Trade/Sistema - Pr om. Esp rec, 6 <,1,,,,,, rom. HE P, rom. Esp rec P, P romt Uso se 1 6,22 P rom. Coste, 138 T ot Coste, P P P P P P T rom. romt rom. rom. rom. rom. ot Esp Uso Cost Inact TFS HE Coste rec se e 1 8 3 4 9,3 4,15,58,,,2,, 3 8 3 2,27 4,15,58,,,,, 3 8 3 2,27 4,15,58,,,,, 3 8 3 2,27 4,15,58,,,,, 3 8 3 2,27 4,15,58,,,1,, 2 8 3 1 6,9 4,15,58,, 9,15,, áx Esp rec 8,26 2,1,,,,,, M T Pro ot Nº mt Nº esp esp rec rec 2 1 3 2 6, 7,,,,,,,1 8 M áx Nº esp rec M áx Cap º TT 2 1 1 2 1 1 1 4 1 1 1 N 1 39 2 23 1 29 1 29 1 31 4 4 4 4 6 5

Edi-Trade/Sistema - Edi-Trade/Sistema - Está Listo Edi-Trade/Sistema - Edi-Trade/Sistema - Genera Alerta Edi-Trade/Sistema - Edi-Trade/Sistema - Seguimiento Edi-Trade/Sistema - Edi-Trade/Sistema - Está OK Edi-Trade/Sistema - Edi-Trade/Sistema - Está Lista Edi-Trade/Sistema - Edi-Trade/Sistema - Genera Alerta Edi-Trade/Sistema - Edi-Trade/Jefe Soporte - Alerta Edi-Trade/Soporte - Gestión de Incidencias Edi-Trade/Soporte - Gestión de Configuración Edi-Trade/Soporte - Es Problema,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 45 4 3 4 3 5 5 2 5 1 1 1, 9,,,,3 1,,3,,3 9,,,,1 9,,,, 3 1 1 1 1 1 1 3 1 1 1 1 1 1 1 1 1 1 1 2 3 1 3 1 2 59 3 23 2 58 1 62 8 6 71 4 33 6 71 1 7 5 37 1 13 2 66 1 32 2 51 2 64 2 58 1 32 5.4.2.4. Colas Total transacciones que han tenido que esperar Tra 4 bajador 46 Estadísticas de recursos (Horas) N úmero Tot Nº esp Prom T Nº esp Tra 1 44 bajador 7 6 Máx Nº esp Prom. Esp no Prom. Esp rec,57 9 18,71, N º ocu 1 599 Estadísticas de recursos (Horas) N Tot Prom Máx Prom. Prom. N 139

Tra bajador úmero Nº esp T Nº esp Nº esp Esp no Esp rec º ocu 1 44 1,57 9 18,71, 7 6 599 Estadísticas de actividad (25 de 44 filas) ot Espera T P romt Espera áx Espera M ot Nº T en act T P romt Nº T en act Edi-Trade/Sistema - 1 1 4 6 7 1 75,69 464,69 33 Edi-Trade/Ingreso Incidencias - Incidencia 7 2 1 2 1 7 7 1 Resuelta 29,16 137,16 31 Edi-Trade/Sistema - 4 1 2 1 2 4 4 1 3,63 58,63 59 Edi-Trade/Jefe Soporte - Alerta 3 1 4 1 1 2 9 1 8,44 69,44 51 Edi-Trade/Soporte - 2 2 2 3 3 1 78,14 58,14 58 Edi-Trade/Desarrollo - Desarrollo de Mejoras 2 1 3 1 2 3 4 2 54,9 27,41 23 Edi-Trade/Sistema - 1 2 1 1 2 1 63,53 16,53 7 Edi-Trade/Desarrollo - 1 1 1 2 2 1 63,8 42,8 39 Edi-Trade/Sistema - 1 2 1 1 2 1 58,28 67,28 32 Edi-Trade/Soporte - Gestión de Difusión 1 1 3 4,79 37,79 3 1 Edi-Trade/Sistema - 1 8 8 1 1 1 24,48 1,48 Edi-Trade/Soporte - Gestión de Configuración 1 2 2 3 3 3 11,43 58,59 58 Edi-Trade/Sistema - 9 6 6 1 1 1 1,31 5,31 5 Edi-Trade/Jefe de Desarrollo Alerta 8 8 2 1,58 1,58 2 1 Edi-Trade/Soporte - Ayudar a Cliente 5 6 6 2 3 3 1,22 61,29 62 Edi-Trade/Soporte - Gestión de Incidencias 4 2 2 2 4 3,15 64,18 64 Edi-Trade/Desarrollo Pruebas 3 2 2 2 2 2 4,2 23,24 7 Edi-Trade/Desarrollo - Instalación de Mejoras 2 3 2 2 3 2 9,13 8,16 84 Edi-Trade/Soporte - Evaluar Conformidad 2 2 2 1 3 3 3,12 58,15 58 Edi-Trade/Desarrollo - Gestión de Cambios 1 1 1 1 2 1 1,2 42,3 37 Edi-Trade/Soporte - Cierre Incidencia 8 2 2 1 2 2,7 6,8 6 Edi-Trade/Desarrollo - Ayudar a Cliente 7 1 1 1 1 1, 65,2 65 Edi-Trade/Desarrollo - Gestión de Problemas 3 1 5 3 2 5 áx Nº T en act M áx Cap M 14 º TT N

Edi-Trade/Desarrollo - Gestión de Incidencias 2 Edi-Trade/Sistema - Genera Alerta,3 16,4 16 2 2 1 1 1, 58,1 58 2 2 2 1, 69, 66 Estadísticas de actividad (Horas) (25 de 44 filas) Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Soporte - Ayudar a Cliente Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Sistema - Edi-Trade/Desarrollo - Edi-Trade/Soporte - Edi-Trade/Soporte - Gestión de Incidencias ot Nº esp rec Edi-Trade/Soporte - Gestión de Difusión 8 Edi-Trade/Desarrollo - Ayudar a Cliente 7 Edi-Trade/Soporte - Evaluar Conformidad 5 Edi-Trade/Desarrollo - Desarrollo de Mejoras Edi-Trade/Soporte - Gestión de Configuración Edi-Trade/Jefe Soporte Alerta Edi-Trade/Jefe de Desarrollo Alerta Edi-Trade/Sistema - Genera Alerta Edi-Trade/Sistema - Edi-Trade/Sistema - Está Lista Edi-Trade/Soporte - Es Problema Edi-Trade/Sistema - Está OK 45 5 1 3 3 6 5 1 T P romt Nº esp rec 1 5 5 4 4 2 2 2 2 1 3 1 1,9,39,22,3,31,18,19,7,1,,4,,,,,,,,,,, Tot Nº bloqueos 25 8 1 8 1 32 81 65 13 3 14 2 25 8 3 13 2 18 25 1 11 3 8 81 Pr omt Nº bloqueos,5 4,1 4,,3 8,1 7,1 4, 9, 1, 4,1 5,7 4,,1 2 1, 9,4 3 1,4 4,5 8,,,,, rom. Esp rec P,,,,,,, <,1,, N /D,, <,1,, N /D,,,,, Pr om. Bloqueo 6, 3, 79, 1, 42 6, 6, 1, 92, 23, 5, N/ D,,, 75, 11,56 N/ D,,,,, rom. Inact P 1 2,13 1,35,96 2,5 1 1,15 7,91 4,19 1,52 1,7,43 N /D,4 1,32 5,65 4,82, N /D,,,,, 141 º TT N 2 59 1 7 6 62 4 33 8 6 5 1 32 1 39 2 58 2 64 1 65 2 58 2 23 2 58 2 51 2 66 1 13 5 37 1 32 6 71

Edi-Trade/Sistema Seguimiento,,,,, 6 71 Edi-Trade/Soporte - Cliente Conforme,,,,, 2 58 Edi-Trade/Sistema - Genera Alerta,,,,, 1 62 142

6. DISEÑO DE LAS APLICACIONES COMPUTACIONALES DE APOYO A LOS PROCESOS. Dada la lógica de negocios e identificadas las tareas dentro de los procesos en que interviene el sistema computacional, se establecen los casos de uso del sistema computacional. Con éstos podemos diseñar la secuencia que deberá tener cada uno, con los cual se estará en condiciones de implementar la aplicación computacional. El lenguaje de diseño utilizado es la notación UML. 6.1. Administración de desarrollo e incidencias (1) 6.1.1. Captura de requerimientos (1.1.1) 6.1.1.1. Caso de uso 143

6.1.1.2. Diagrama de secuencia 144

6.1.2. Análisis comercial de requerimientos (1.1.2) 6.1.2.1. Caso de uso 145

6.1.2.2. Diagrama de secuencia 146

6.1.3. Detección de incidencias (1.2.1) y captura de incidencias (1.2.2) 6.1.3.1. Caso de uso 147

6.1.3.2. Diagrama de secuencia 148

6.2. Gestión de desarrollo, incidencias y entrega (3) 6.2.1. Asignación de problemas (3.1.2.2) 6.2.1.1. Caso de uso 149

6.2.1.2. Diagrama de secuencia 15

6.2.2. Asignación equipo de trabajo (3.1.2.3.1) 6.2.2.1. Caso de uso 151

6.2.2.2. Diagrama de secuencia 152

6.2.3. Cálculo de plazo y presupuesto (3.1.2.3.2) 6.2.3.1. Caso de uso 153

6.2.3.2. Diagrama de secuencia 154

6.2.4. Asignación de requerimientos (3.1.2.1) 6.2.4.1. Caso de uso 155

6.2.4.2. Diagrama de secuencia 156

6.2.5. Control de problemas (3.1.2.1) 6.2.5.1. Caso de Uso 157

6.2.5.2. Diagrama de secuencia 158

6.2.6. Control de paquetes de trabajo (3.1.2.2) 6.2.6.1. Caso de uso 159

6.2.6.2. Diagrama de secuencia 16

6.2.7. Control de requerimientos (3.1.2.3) 6.2.7.1. Caso de uso 161

6.2.7.2. Diagrama de secuencia 162

6.2.8. Asignación de incidencias (3.2.1.1) 6.2.8.1. Caso de uso 163

6.2.8.2. Diagrama de secuencia 164

6.2.9. Publicación de cambios (3.2.1.2.1) 6.2.9.1. Caso de uso 165

6.2.9.2. Diagrama de secuencia 166

6.2.1. Asignación de difusión de cambios (3.2.1.2.2) 6.2.1.1. Caso de uso 167

6.2.1.2. Diagrama de secuencia 168

6.3. Desarrollo, instalaciones, actualizaciones y solución de incidencias (4) 6.3.1. Atención incidencia (4.2.1) 6.3.1.1. Caso de uso 169

6.3.1.2. Diagrama de secuencia 17

7. CONSTRUCCIÓN DE LAS APLICACIONES TI 7.1. Diseño detallado del apoyo computacional para asignación de recursos. 7.1.1. Asignación paquetes de trabajo Dentro del caso de uso Asignación Equipo de Trabajo (6.2.2.1.), está incluido uno llamado Asignación de Paquetes de Trabajo. Éste tiene como funcionalidad la distribución de los paquetes de trabajo entre el personal del equipo que conforma el proyecto. Cada paquete de cuenta con tres atributos esenciales para su asignación: Especialidad: paquete. Dependencia: paquetes. Determina qué personas son aptas para el desarrollo del Determina el orden en el cual deben ser desarrollados los Punto Función: Es un atributo calculado en base al algoritmo de punto función y determina el esfuerzo necesario para desarrollar el paquete de trabajo. Este valor, ponderado por un factor de corrección correspondiente a cada persona, determina el número de horas empeladas para el desarrollo. 171

7.1.1.1. Diagrama de clases 7.1.1.2. Diagrama de realización 172

7.1.2. Asignación de técnicos Dentro del caso de uso Asignación de Incidencias (Proceso 3.2.1.1 de la cadena 173

de valor), está incluido uno llamado Asignación de Técnicos. Éste tiene como funcionalidad la distribución de las Incidencias entre el personal técnico de soporte al cliente. El sistema asigna una incidencia al técnico desocupado según la especialidad a la cual se le hayan asignado menos incidencias. De no haber ningún técnico disponible, las incidencias son puestas en una cola a la espera del primer técnico de la especialidad que se desocupe. Antes de ir a la cola el Jefe de Soporte tiene la facultad de asignarle una prioridad especial y además puede asignársela a un técnico en particular. 174

7.1.2.1. Diagrama de clases 175

7.1.2.2. Diagrama de realización 176

7.2. Diseño lógico del apoyo computacional para ejecución de tareas El sistema de Apoyo Computacional a la cadena de valor tiene muchos casos de uso asociados a la mantención de estados y a la gestión y control manual. Para complementar el diseño lógico de los casos de uso de asignación de recursos y pensando en construir un prototipo funcional, incluiremos el diseño detallado del más complejo que no involucra asignación de recursos. El caso de uso elegido es el de Atención de Incidencias (correspondiente al proceso 4.1. de la cadena de valor Macro 1). 7.2.1. Atención de incidencias Este caso es usado cuando un técnico toma un ticket asignado o de la cola y procede a atenderlo. En base al criterio del técnico, se canaliza el ticket a las distintas instancias o le da solución el mismo. 177

7.2.1.1. Diagrama de clases 178

7.3. Diagrama de clases de entidad 179

7.4. Diagrama y paquetes 7.5. Prototipo Se ha construido un prototipo utilizando la tecnología AndroMDA para generar una aplicación web Java Empresarial que permita demostrar la factibilidad en el desarrollo del sistema. La tecnología AndroMDA se basa en la generación de código a partir del diseño físico de la aplicación en lenguaje UML. El código generado por AndroMDA se complementa con el de programación manual para introducir a la aplicación computacional la lógica de negocio. AndroMDA se combina con otras herramientas y tiene varias posibilidades a la hora de generar código. Hemos integrado la herramienta con Rational Arquitect y Eclipse para poder desarrollar el prototipo. Se ha elegido la generación de código en Java con tecnología EJB y capa de persistencia Hibernate, lo cual conformará una aplicación Java Empresarial que correremos en servidor de aplicaciones JBoss con base de datos MySql. 18

7.5.1. Diseño Físico del Prototipo 7.5.1.1. Casos de Uso Busca Proyecto: Es el caso de uso que permite seleccionar un proyecto para el cálculo de su esfuerzo. Busca Usuarios: Es el caso de uso que permite buscar un usuario (no implementado). Busca Persona: Es el caso de uso que permite buscar una persona. 181

7.5.1.2. Diagrama de Clases de Dominio Persona: Es la entidad que representa a la persona que ejecuta o es responsable de un proyecto. 182

Usuario: Son los datos del usuario para logearse en el sistema (no implementado). Proyecto: Contiene la información de un proyecto de software PaqueteDeTrabajo: Corresponde a la unidad de trabajo asignable a un desarrollador, contiene la información necesaria para calcular el esfuerzo necesario para su desarrollo. ArchivoInterfazExterno, ArchivoLogicoInterno, ConsultaExternaOutput, ConsultaExternaInput, SalidaExterna, EntradaInterna: Estas son clases que contienen la estructura de datos necesaria para almacenar la información referente a la complejidad del paquete de trabajo. 7.5.1.3. Diagrama de clases Value Object Este diagrama muestra las clases que contendrán los datos de las clases de dominio dentro de la aplicación. Aunque no todas se utilizan, se crea una clase VO por cada clase de tipo Entity, con el fin de que estén disponibles cuando sea necesario. 7.5.1.4. Diagrama de clases servicios Este diagrama describe las clases que controlan las interacciones entre las interfaces de usuario y las clases de servicio. Las clases de servicios utilizan objetos de tipo entidad y a través de la ejecución de los métodos de éstas se da forma a la lógica del modelo de la aplicación. Podemos visualizar tres clases de servicio, en el contexto de este prototipo, la más importante es la Clase ServicioProyecto, la cual, además de buscar un proyecto determinado, invocará al método del proyecto que calcula el esfuerzo de éste. 183

7.5.1.5. Diagrama de máquina de estados Estos diagramas describen la lógica de la interfaz y usuario para cada caso de uso. Nos concentraremos en el diagrama BuscaProyectos ya que es el que ejecuta el algoritmo cálculo de esfuerzo. Los otros sólo buscan y filtran las tablas de la base de datos. Estado IniciaBuscaProyectos muestra la página de inicio en la cual aparecen los campos de filtrado de la tabla de proyectos. Luego se pasa al estado de busquedadeproyectos, en el cual se filtra la tabla de proyectos y se retorna al estado inicial. Después de la búsqueda se puede pinchar un proyecto específico para que se muestre el detalle. Cuando ocurre esto último se pasa el estado iniciadetalleproyecto, el cual carga los datos del Proyecto y calcula el esfuerzo del proyecto. Por último, el estado despliegeproyecto muestra los datos del proyecto. 184

7.5.1.6. Pantallas del prototipo Búsqueda de proyectos despliega todos los proyectos en forma inicial y permite filtrar los distintos campos 185

Se despliega un proyecto con el cálculo del punto función asociado. 186

187

Mantenedor de Personas. 188

Mantenedor de Proyectos 189

Mantenedor de Paquetes de Trabajo. En esta pantalla se indican los datos necesarios para el cálculo del esfuerzo. Como estos datos son estructuras de datos especiales, el paquete de trabajo puede poseer varios objetos de los tipos de clases que definen la estructura de datos. 19

Esta es una de las pantallas en donde se ingresan los datos referentes a la complejidad. 191

8. IMPLEMENTACIÓN ORGANIZACIONAL DE LOS PROCESOS DISEÑADOS Y LAS APLICACIONES TI DE APOYO 8.1. Aspectos técnicos. 8.1.1. Contexto de implementación del plan piloto Este proyecto trata del rediseño de la cadena de valor basado en Macro 1 en los siguientes ámbitos: Gestión y Atención de Incidencias Gestión y Atención de Requerimientos Gestión y Desarrollo de Proyectos El objetivo del plan piloto es lograr la asignación de tareas de desarrollo y mantención de software en forma óptima y lograr una buena gestión sobre las tareas Gestión y Atención de Incidencias Gestión y Atención de Requerimientos Gestión y Desarrollo de Proyectos Asignación, Control y Gestión de Paquetes de Trabajo 192

asignadas, que permita la re asignación de éstas en cualquier momento. El sistema cuenta con un módulo para la asignación y gestión de paquetes de trabajo. Éste es utilizado en tres ámbitos del sistema. Para efectos del plan piloto sólo integraremos dicho módulo con el ámbito de Gestión y Desarrollo de Proyectos. Dado el ámbito de implementación del plan Piloto, éste afectará a los siguientes procesos: Gestión y Desarrollo, Solución de Incidencias y Entrega Desarrollo, Instalaciones, Actualizaciones y Solución de Incidencias. 193

Figura 51.- Procesos que afectará el plan piloto NuevosProductosy Servicios(deMacro2) Planesestrat gicosy dedise o Requerimientosdel Cliente Requerimientosdel Mercado Incidenciasdel Cliente Administraci nde requerimientos eincidencias Requrimientos dedesarrollo Informaci nal Mercado publicaci nymensajes requerimientos deservicioscomputacionales Informaci ndedisponibilidad Administraci n relaci ncon proveedores deservicios computacionales Informaci ny rdenesaproveedores Necesidadesinsumosyservicios computacionales Gesti ndedesarrollo, soluci nde incidencias yentrega Plane instrucciones Ideascambioproductosy procesosproducci n Insumosyotrosrecursosproveedores Necesidadese informaci ncontrol Desarrollo, Intalaciones, Actulizacionesy soluci nde incidencias CambiodeEstados Instalaci n, actualizaci no soluci ndelaincidencia del sistemadel cliente Requerimientooincidenciadel Clienteprocesado Informaci ndeotrosprocesos OtrosRecursos Estado2 Estado3 Estado4 Mantenc nde estado Informaci na otrosprocesos Informaci ndeestados Estado1 194

Descomponiendo jerárquicamente los procesos antes señalados, podemos identificar los subprocesos que implementaremos en el plan piloto. Como muestra el diagrama XX, dentro del proceso de Gestión y desarrollo Solución de Incidencias y Entrega, implementaremos los subprocesos de: 3.1.2.1 3.1.2.2 3.1.2.3 Planificación y Control de Problemas Planificación y Control de Paquetes de Trabajo Planificación y Control de Requerimientos Figura 52.- Sub procesos implementados en el plan piloto 3 Gesti ndedesarrollo, IncidenciasyEntrega 3.1 Gesti ndedesarrollode Software 3.1.1 Asignaci nde Desarrollos 3.1.2 Planificaci nycontrol dedesarrollo 3.1.2 Gesti ndeenterga 3.1.2.2 Asignaci ndeproblemas 3.1.2.3 Asignaci ndeequipode TrabajoProyectode Software 3.1.2.1 Asignaci nde Requerimientos 3.1.2.1 Planificaci nycontrol deproblemas 3.1.2.2 Planificaci nycontrol depaquetesdetrabajo 3.1.2.3 Planificaci nycontrol derequerimientos 3.1.2.1 Gesti ndeentregade Soluci ndeproblemas 3.1.2.2 Gesti ndeentregade Software 3.1.2.3 Gesti ndeentregade Requerimientos 3.1.2.3.1 Asignaci ndeequipoy PaquetesdeTrabajo 3.1.2.3.2 C lculodeplazoy Presupuesto En el proceso de Desarrollo, Instalaciones, Actualizaciones y Solución de Incidencias, implementaremos el subproceso de 4.1.1. Desarrollo. Figura 53.- Sub procesos implementados en al plan piloto 195

4 Desarrollo, Instalaciones, Actualizacionesy Soluci nde Incidencias 4.1 DesarrollodeSoftware 4.2 Soluci nde Incidencias 4.3 Disfusi ndec mbios einstalaci n 4.1.1 Desarrollo 4.1.2 EntregaDesarrollo 4.2.1 Atender Incidencia 4.2.2 CierreIncidencia 4.3.1 Configuraci n 4.3.2 CierredeActividad 8.1.2. Alcances del Plan Piloto El plan piloto tiene los siguientes alcances: Implementación de Punto Función para cálculo de esfuerzo. Implementación de Método Roy para asignación de tareas. Implementación de modelo de programación l Implementación de interfaces necesarias para la interacción con el sistema de apoyo computacional definidas en el modelo. 8.2. Aspectos de manejo del cambio. La implementación total del proyecto implicará un gran cambio cultural en la empresa. Para una implantación exitosa, es necesario realizar gestión de cambio sobre el equipo humano que se verá afectado por este cambio. 196

Los equipos identificados que se verán afectados por éste son: Equipo de Soporte al Cliente Equipo de Desarrollo y/o Mantención de Sistemas Como estrategia para implantar exitosamente el proyecto, se gestionará cada equipo con una técnica distinta, que se ajuste a las características e idiosincrasia de estos. Con el equipo de Soporte al Cliente es necesario crear la necesidad y hacerle marketing al proyecto, mediante charlas, newsletters y reuniones inductivas. En base a éstas se podrá detectar y explotar las oportunidades para realizar el cambio. En este proceso utilizaremos el Modelo en 5 Etapas de Stewart: 1. Diagnosticar 2. Identificar la resistencia 3. Asignar la responsabilidad 4. Desarrollar y poner en marcha estrategias 5. Supervisar La necesidad que se deberá transmitir al equipo de soporte se puede delinear de la siguiente manera: Para adaptarnos a los cambios que se han producido en el entorno. Para ser más competitivos. Para subsistir y desarrollarnos. Para satisfacer mejor las necesidades de nuestros clientes. Para que nuestro personal se sienta mejor. Para poder utilizar con más eficiencia la nueva tecnología. 197

Para aprovechar nuevas oportunidades o neutralizar las amenazas que podemos identificar en el entorno. Para superar a nuestros competidores. Para estar a tono con los tiempos. Para no quedarnos atrás. Para sentirnos menos presionados y agobiados en el trabajo. Para trabajar en nuevos mercados. Para vencer la desventaja competitiva. como: A su vez, dentro del plan de marketing se deberá utilizar frases de alto impacto "Si buscas resultados diferentes, no sigas haciendo lo mismo" Albert Einstein El equipo de desarrollo y mantención de software es un equipo pequeño, bien cohesionado y con gran capacidad de adaptación. Eso ha quedado demostrado en otros procesos de cambio que ha sufrido el equipo. Por lo tanto, se requieren menos recursos para la gestionar el cambio y lograr implantar el proyecto. Como estrategia para realizar el cambio debemos considerar la motivación, que se logra planteando objetivos y metas claras. Como técnica para la gestión del cambio, utilizaremos el Modelo de 3 Etapas de Lewin: Descongelamiento Cambio Recongelamiento El objetivo planteado para este equipo es Mejora de la Eficiencia a través de una Mejor Planificación, lo cual se logrará persiguiendo la clara meta de Cumplir los 198

Tiempos de Entrega. Las necesidad de implantar el proyecto se le presenta al equipo de la siguiente forma: Para satisfacer mejor las necesidades de nuestros clientes. Cumplimiento de metas. Para que nuestro personal se sienta mejor. Satisfacción Personal. Para no quedarnos atrás. Evitar Cambios más Bruscos. Para sentirnos menos presionados y agobiados en el trabajo. Ambiente de Trabajo. Para trabajar en nuevos mercados. Mayores ingresos implica mejores sueldos. También a un lineamiento estratégico general que deberá aplicarse a ambos equipos, el cual lo podemos delinear de la siguiente manera: BLOG, Página web Objetivos e Hitos Comunicación y Feedback. Reuniones Informativas Liderazgo. Reuniones Generales Participación. Involucrarse con personas - Sintonizar Emocionalmente. Medición de Cumplimiento de Objetivos Retribuciones. Evento de Implantación del Sistema Despedirse de lo Viejo. 8.3. Generalización de la experiencia A través de la generalización de la experiencia se pretende explicar el patrón de diseño, tanto del proceso como computacionalmente, y que éstos pueden ser reutilizados para otros proyectos. Dado el siguiente contexto en el cual se implantará el proyecto: Gestión y Atención de Incidencias 199

Gestión y Atención de Requerimientos Gestión y Desarrollo de Proyectos Podemos definir el siguiente dominio: Soporte al Cliente TI Consultoría, Desarrollo y/o Mantención de Sistemas TI 2

8.3.1.1. Dicho dominio se conforma de la siguiente forma: Soporte al Cliente Soporte al Cliente TI Cadena de Valor Macro 1 Dominio EdiTrade Desarrollo, consultoría y/o mantención Sistemas TI 21

Los objetos del sistema que se pueden personalizar para adaptarse a una situación específica son los siguientes: Asignación de Tareas Cálculo de Esfuerzo Workflow Interfaces de usuario Esto objetos varían según el dominio al cual se aplica el sistema. Por lo tanto, el sistema deberá estar construido de forma tal que permita el reemplazo de dichas clases reemplazando paquetes de clases de especialización de dominio Las clases reemplazables se deben definir mediante una jerarquización abstracta que le permita al sistema cargar y ejecutar la clase específica, sin tener que modificar el código fuente. 22

Figura 54.- Diagrama de Clases Framework Asignación de Tareas 23