“P R O Y E C T O S E N S O F T T E K” -...

“P R O Y E C T O S E N S O F T T E K”

I N G E N I E R O E N I N F O R M Á T I C A

S A N D R A S Á N C H E Z P É R E Z

2010.

MEMORIA DE EXPERIENCIA PROFESIONAL

Índice

Resumen i Introducción ii Capitulo I. Antecedentes de la Empresa

1.1 Softtek 1 1.2 Visión 1 1.3 Organigrama de la Empresa 2 1.4 Organigrama del área 4 1.5 Presencia Global 6 1.6 Servicios 7 1.7 Mercado 7 1.8 Premios y Distinciones 8

Capitulo II. Programa de generación de Puntos 2.1 Introducción 9 2.2 Plataforma 9 2.3 Capacitación Extra 9 2.4 Condiciones Generales del programa de puntos 10

Capitulo III. Procesos de Mejora 3.1 Introducción 18 3.2 Plataforma 19 3.3 Capacitación Extra 20 3.4 Overview de PPM 21 3.5 Soporte a Aplicación de PPM 23 3.6 Digitalización de Procesos 33 3.7 Proyecto Six Sigma 45

Conclusiones 76 Bibliografía 77 Anexo A 78

Resumen

El principal propósito de este informe es evidenciar la experiencia profesional que se obtuvo en el transcurso de tres años y medio de laborar en Softtek.

Los proyectos que forman parte de este informe van enfocados a temas de informática, razón por la cual tienen el objetivo de crear soluciones de valor para la industria, en este caso en particular: para los clientes de Softtek.

Los proyectos cuentan con dos características distintivas:

1. Enfoque prospectivo, donde se genera una visión futura de la industria en donde se identifican y seleccionan los factores críticos para lograr desarrollos que aporten valor a la industria (Clientes).

2. Análisis de la tecnología, donde se identifican y seleccionan los factores técnicos que permitan la creación de nuevos desarrollos en cualquier tipo de industria.

i

Introducción

El informe abarca tres capítulos, de los cuales el primer capitulo trata acerca de la empresa Softtek, el segundo y tercer capítulo trata de los proyectos en los que se participo.

El primer capitulo muestran los antecedentes de “Softtek”, que es la empresa en la que se ha desarrollado la experiencia profesional la cual es la base de este informe.

El segundo capitulo trata del subproyecto que se llamaba “Programa de generación de Puntos”, este subproyecto pertenecía al proyecto de PMARE02 del sector financiero, en el que se desarrollaban aplicaciones para Bancos. En este proyecto se realizo el desarrollo de un programa que otorgaba puntos para los clientes del banco que obtuvieran una tarjeta de crédito del Banco X, este programa de puntos fue diseñado por Javier Zamora y desarrollado por Sandra Sánchez. La finalidad del programa de puntos era para aquellas personas utilizaran de forma continua su tarjeta de crédito, se les otorgaran puntos que podían ser canjeados por artículos o dinero en efectivo. El Banco X promovía el siguiente slogan: “Entre mas compres, mas ganas”, con la finalidad de que mas personas sacaran una tarjeta de crédito.

El tercer capitulo trata del subproyecto que se llama Kintana4, este subproyecto pertenece al área del PIC5. En este proyecto se realizaban actividades tales como el Soporte a la aplicación de Kintana a nivel mundial (crear o modificar usuarios, cambiar datos, etc.), el desarrollo de procesos de mejora para GDC México 6(crear o modificar procesos organizaciones, reportes, etc.) y por último el desarrollo de un proyecto de Six Sigma para incrementar las métricas de On Time Response y On Time Analysis.

4 Kintana: Aplicación utilizada por Softtek para la administración de requerimientos.

5 PIC: Process Improvement and Compliance

6 GDC México: Centro Global de Entrega de México

ii

1

Capitulo I. Antecedentes de la Empresa

1.1 Softtek En diciembre de 1982, Softtek fue fundada en México como una pequeña compañía de servicios de TI. En 1997 Softtek introdujo el modelo de servicios Near Shore® con la creación del Centro Global de Entrega en Monterrey, México, el primero en su tipo en toda Latinoamérica.

Aunque la compañía ha crecido enormemente desde su origen, promovida por una cultura corporativa única, esta tendencia se aceleró luego de que la actual Presidente y CEO Blanca Treviño tomara posición como CEO en el año 2000.

En el 2003, Softtek adquirió el Centro Global de Desarrollo de GE en México y expandió su portafolio de aplicaciones y servicios al combinar las capacidades de los dos jugadores más fuertes de Near Shore® en México.

Después de 25 años, Softtek se transformó en un proveedor global de soluciones de TI y procesos de negocio con más de 6,000 colaboradores a través de 30 oficinas en Norteamérica, Latinoamérica, Europa y Asia.

En agosto del 2007 Softtek adquirió I.T. UNITED, empresa ubicada en China, expandiendo sus capacidades al mercado asiático. Softtek utiliza la metodología de su marca registrada Near Shore® para trabajar con clientes, conocer sus necesidades a nivel local, regional y global a través de trabajo on-site y Centros Globales de Entrega.

1.2 Visión4

Trascender como proveedor global líder en Soluciones de TI y Procesos de Negocio, generando relaciones mutuamente benéficas, de largo plazo y cimentadas en una base de confianza ganada.

Construiremos nuestro futuro siendo una empresa sólida y socialmente responsable, con un historial rentable. Proporcionamos servicios innovadores y de alta calidad, impulsados por la pasión de nuestra cultura centrada en el elemento humano.

4 http://www.softtek.com/sp/acerca_vision.php

2

1.3 Organigrama de la Empresa

Organigrama 1. Estructura Principal de Softtek

1.3.1 Funciones

Presidente y CEO. Bajo su liderazgo Softtek se ha convertido en el proveedor independiente de servicios de TI más grande de Latinoamérica y ha sido reconocida por analistas de la industria como el único proveedor de servicios Offshore de TI fuera de la India en presentar seria competencia para el mercado estadounidense.

CEO Softtek Servicios Near Shore®. Emprendedor y generador de apoyo en el inicio de operaciones en diversos mercados. A principios de los noventa, fundó y desarrolló las unidades de negocio de Tecnología Orientada a Objetos y la de Business Intelligence, marcando con ello la entrada de Softtek a las aplicaciones comerciales fuera de mainframe y midrange5.

5 Midrange es un equipo más potente que un ordenador común, pero más pequeño que un equipo

Mainframe; son llamados ordenadores de media gama. Están diseñados para ser Host en entornos multi-usuario.

3

CEO Softtek México y Centroamérica. Consolidador de la oferta de servicios y el posicionamiento de Softtek en Softtek México y Centroamérica. Entre sus aportaciones a Softtek se cuentan logros en el sector de consultoría; el arranque de la práctica de Oracle Applications y la creación del área de Product Management para Estados Unidos.

CEO Softtek Sudamérica y Caribe. Consolidador de la oferta de servicios y el posicionamiento de Softtek en Softtek en Sudamérica y El Caribe. Dirigente de la expansión de la compañía a nuevos horizontes como Argentina, Colombia, Venezuela, Chile y Puerto Rico, sedes donde posicionó a la organización en poco tiempo.

CEO Softtek Europa. Consolidador de la oferta de servicios y el posicionamiento de Softtek en Softtek Europa.

Director Regional Sudamérica Hispana. Responsable de las operaciones de Argentina, Chile, Colombia y Venezuela.

Chief Financial Officer. Responsable de crear y mantener un equipo de administración y finanzas capaz de responder a los retos globales de una organización tan dinámica. Con la creación de esta área corporativa, se establecieron las políticas de finanzas, procesos de contabilidad y la evaluación de proyectos estratégicos, donde coordina los procesos de adquisiciones y de análisis estratégico.

Chief Operating Officer. Responsable por la operación de diferentes unidades de entrega de servicios, la administración de las capacidades de la compañía, el acatamiento de los Acuerdos de Niveles de Servicio (SLA por sus siglas en inglés) y por las diferentes certificaciones de calidad.

Chief Shared Services Officer. Responsable por suministrar los recursos necesarios para la operación de la compañía.

Vicepresidente de Capital Humano. Consolidador de la esencia de Softtek, promotor de un proceso de evolución que busca reafirmar este importante elemento considerado como uno de los grandes diferenciadores de Softtek: su cultura.

Vicepresidente de Marketing y Comunicaciones. Responsable del manejo de la comunicación corporativa a nivel global, lo cual abarca: Estados Unidos, Latinoamérica, Europa y Asia. En conjunto con su equipo define la propuesta de valor y las estrategias de posicionamiento para los mercados globales de ITO y BPO a través de la estrategia de Softtek Global Nearshore.

4

1.4 Organigrama del área

Organigrama 2. Estructura del área

1.4.1 Funciones

Global Account Director: Se encarga de establecer los Acuerdos de Nivel de Servicio y el establecimiento de métricas que permitan medir los resultados operativos de la cuenta.

Regional Operational Leader: Se encarga de coordinar todos los proyectos de la cuenta utilizando sus habilidades avanzadas y conocimientos diversificados, es responsable del planeamiento y desarrollo de un plan detallado de trabajo, asignando el trabajo a los recursos y generando reportes de progreso al Global Operational Leader utilizando un buen proceso de comunicación/integración, para asegurar el flujo eficaz de la información entre el cliente, el usuario y el personal asignado.

BRM: Se encarga de identificar y contactar clientes con el fin de realizar un levantamiento de sus necesidades para realizarles una propuesta de valor.

Consultor PPM: Se encarga de apoyar a los BRM, durante el proceso de venta de una aplicación basada en PPM, el apoyo puede ser aplicado a propuestas, prototipos y cursos de capacitación orientados al cliente.

Función: Consultor PPM que da soporte a Ventas.

5

Operational Leader (OL): Se encarga de la coordina varios proyectos de una naturaleza compleja, supervisa al personal de uno o varios proyectos a su cargo, asignando responsabilidades individuales, identificando los recursos apropiados y requeridos, desarrollando un plan de trabajo, optimizando los recursos, participando en las retroalimentaciones, cambios de nivel económico, evaluaciones, recomendando entrenamientos especializados, asignando, para asegurar la terminacion oportuna del proyecto y disminuir el índice de rotación de personal.

Desarrollo Humano: Proporciona y garantiza que todos las personas dentro de la organización tengan los conocimientos y habilidades necesarios para desempeñar su trabajo, con el fin de mantenerlos actualizados, incrementar sus competencias y elevar la productividad y calidad en el servicio que ofrecemos a nuestros clientes.

Capital Humano: Se encarga de promover los recursos humanos, asegurando que estos sean desarrollados, capacitados, asegurando un plan de compensación competitivo en el mercado de IT, generando la cultura y comunicación propicias para un clima organizacional óptimo.

Sourcing: Se encarga de controlar y administrar los requerimientos de recursos en todos los sectores de la organización, asignar equipos de trabajo efectivos para los proyectos y elaborar los planes de carrera para la gente (formación).

Cultura México: Se encarga de fomentar y crear una comunicación idónea para la interacción efectiva en la cuenta.

Staff Costa Rica: Se encarga de administrar los recursos humanos y los procesos que implican su información.

6

1.5 Presencia Global

Fig.1 Presencia Global.

Softtek cuenta con más de 30 oficinas alrededor del mundo (Ver Fig. 1), 8 de las cuales son consideradas como Centros Globales de Entrega (Ver Fig. 2) porque cuentan con:

• Una infraestructura de comunicaciones sólida.

• Planes de recuperación de desastres y de continuidad de negocio.

• Práctica madura de reclutamiento y centro de entrenamiento.

• Máxima seguridad y conformidad administrativa.

• Segmentos físicos y lógicos aislados con capacidad para albergar múltiples clientes.

• Diseñados para albergar crecimiento en volumen y capacidades.

• Fuerte rigor en procesos (Six Sigma, CMM, ISO).

Argentina: México: China:

La Plata Aguascalientes Beijing

Baja

México D.F.

Monterrey

Brasil: España:

São Paulo La Coruña

Ubicación de los Centros Nearshore Globales de Entrega de nuestra red:

Fig. 2 Centros Globales de Entrega.

7

1.6 Servicios

Los servicios de Softtek ayudan a las organizaciones a responder rápidamente a las necesidades de su negocio, e inclusive a definir nuevas condiciones de mercado. Los cuatro servicios proporcionados por Softtek con los siguientes:

• Servicios relacionados a aplicaciones

• Outsourcing de procesos de negocio

• Productos de software y servicios relacionados

• Servicios administrados de soporte de infraestructura de TI

El portafolio completo de soluciones (Ver Fig. 3) comprende:

Fig. 3 Servicios desglosados.

1.7 Mercado

• Softtek es el proveedor de servicios preferido por varias organizaciones Fortune 500.

• Corporaciones líderes en el mercado donde operamos.

8

1.8 Premios y Distinciones

Softtek tiene 27 años como proveedor de servicios de TI, a lo largo de estos años ha sido merecedor de varios premios y distinciones, algunos de ellos son mencionados a continuación:

• Programa Corporativo Six Sigma.

• Certificación ISO 9001:2000 (para Servicios de Desarrollo de Aplicaciones y Soporte y Mantenimiento de Aplicaciones en Brasil, y Servicios de Procurement en Aguascalientes, México).

• Certificación ISO 9001:2000 en “Diseño, desarrollo, soporte y mejora de soluciones informáticas” en Argentina.

• 10 “SAP Award of Excellence” en la categoría “Best Regional Partner”.

• Best Solution Delivery Award 2004 por parte de Gartner.

• Encabeza la lista de Emerging Outsourcing Players de la revista BusinessWeek.

• Tres años consecutivos ganador de la categoría “Top Company to Watch South of the Border” de la lista GS100 por Global Services.

• Considerado uno de los mejores lugares para trabajar en Argentina, Brasil y México.

• La única compañía latinoamericana incluida en el Magic Quadrant for Offshore Application Services 2006 & 2007 de Gartner.

• Reconocida como “Strong Performer for SAP Implementation Services”6.

6 Reporte “The Forrester Wave: SAP Implementation Providers, Q4 2007”

9

Capitulo II. Programa de generación de Puntos

2.1 Introducción

El programa de Recompensa Total de Puntos es un programa diseñado para clientes (personas Físicas y mayores de 18 años) del Banco X, que tengan una tarjeta de crédito. El programa de puntos promueve el uso activo de las tarjetas de crédito, pertenecientes al Banco X.

De acuerdo al programa, dependiendo del monto de la compra, son los puntos que se acumularán a favor del cliente, estos puntos posteriormente pueden ser cambiados por otros productos. Por ejemplo: Un cliente compra una televisión, realizando el pago de dicha televisión con su tarjeta de crédito, dependiendo del costo de la televisión, es el número de puntos que se generarán para el cliente.

2.2 Plataforma

El programa de puntos fue desarrollado en el lenguaje de programación de Cobol, bajo la plataforma de Altamira, esto se debe principalmente al volumen de información que es manejada por los bancos. Se considero que el programa de puntos, se ejecutaría diariamente mediante un proceso batch.

2.3 Capacitación Extra

Para poder realizar el programa de puntos, se tuvo que tomar una capacitación de tres semanas, con la finalidad de aprender a programar en el lenguaje de Cobol y conocer las características de la plataforma Altamira. La capacitación consto de los siguientes temas:

• Introducción a Cobol

• Instrucciones y tipos de datos en Cobol

• Lógica de programación

• Ambiente de Altamira

• JCL’s

• Control M

• Estándares de Softtek

• Estándares del Banco X

• TISAP7 1 y 2

7 TISAP es el acrónimo de Tecnología de Información de Softtek Aplicada a la Programación.

10

2.4 Condiciones Generales del programa de puntos

Los beneficios de Recompensa Total de puntos, son exclusivos para los CLIENTES del producto denominado Tarjeta de Crédito, se obtiene la membresía en forma automática al registrarse la contratación del producto. La membresía no tiene costo de inscripción.

Solo podrán registrarse un CLIENTE por producto. Los puntos generados al amparo del programa Recompensa Total de puntos serán registrados a favor del CLIENTE independientemente de que existan más participantes del producto en base al cual se hayan generado los puntos.

En caso de que el CLIENTE mantenga contratados dos o más productos participantes, estos serán ligados a su número de cliente y acumulara en este último el total de los puntos generados por el uso de sus productos participantes. En caso que el CLIENTE tenga una aclaración o duda sobre algún producto faltante debe solicitar que dicho producto sea agregado a su número de cliente (Ver Fig. 4).

Fig. 4 Relación entre cliente y producto

Todos los productos participantes deben estar vigentes y al corriente al momento de que el CLIENTE, solicite y obtenga la liga de sus productos participantes y solicite y obtenga los beneficios del programa Recompensa Total de puntos.

Es obligación de los CLIENTES el conocer y cumplir todas las reglas y políticas del programa Recompensa Total de puntos. Cada CLIENTE asumirá la responsabilidad de actualizarse e informarse regularmente acerca de dicha Reglamentación con el fin de conocer sus derechos y sus responsabilidades.

Banco “X” se reserva el derecho de modificar o terminar parcial o totalmente (Ver Fig.

5), según considere necesario, los Reglamentos, normas, privilegios, beneficios y ofertas especiales del programa Recompensa Total de Puntos, a su discreción y sin previo aviso.

11

Esto significa que Banco “X” puede introducir cambios que afecten, por ejemplo, a CLIENTES, las reglas para acreditar puntaje, los niveles de puntaje y las tablas para la obtención de las recompensas.

Fig. 5 Relación Banco-Clientes

BANCO “X” procurará mantener una comunicación oportuna con todos los CLIENTES, afiliados a Recompensa Total de Puntos, informando periódicamente en los estados de cuenta de sus productos participantes un resumen de la actividad de su número de cliente.

BANCO “X” pondrá a disposición de los CLIENTES un sitio de internet en el cual podrán consultar a detalle sus puntos, para tener acceso a dicho servicio el CLIENTE debe de contar con su número de cliente que será la llave de acceso, acompañado de una contraseña.

Los puntos generados al amparo del programa Recompensa Total de Puntos no son transferibles, ni negociables, y no pueden ser combinados entre miembros del programa.

12

2.4.1 Beneficios

Los CLIENTES que cuenten con su membresía recibirán puntos Recompensa Total de Puntos por el uso de productos participantes que tengan contratados y al corriente. La obtención de los puntos es de conformidad a lo siguiente:

Productos de Tarjeta de Crédito obtendrán 3 (tres) puntos por cada $10.00 (diez pesos 00/100 Moneda Nacional) de facturación derivado de los conceptos que más adelante se señalan, la generación de puntos aplica para las Tarjetas Adicionales ligadas al producto participante, en la inteligencia de que los puntos generados se registraran en el número de cliente que haya obtenido la afiliación.

Generan puntos las compras directas en establecimientos, pago de productos y servicios por teléfono o Internet, compras en promoción de pagos diferidos (meses sin intereses) y cargos automáticos de cualquier monto sobre consumos realizados en México y el extranjero (Ver Fig. 6).

Fig. 6 Obtención de puntos

Los puntos generados al amparo del programa Recompensa Total de Puntos no tienen valor monetario de ningún tipo y está prohibida su venta, regalo o traspaso a cualquier número de cliente que no sea el del CLIENTE registrado al producto participante que genere dichos puntos.

Banco “X” se reserva el derecho de revisar los saldos del puntaje acumulado por los CLIENTES, al amparo del programa Recompensa Total de Puntos. La generación de los puntos puede suspenderse hasta resolver satisfactoriamente cualquier discrepancia o anomalía observada. BANCO “X” se reserva el derecho de descontar el puntaje erróneamente acreditado a un CLIENTE al amparo del programa Recompensa Total de Puntos.

$ En puntos

13

2.4.2 Consideraciones en Promociones

BANCO “X” se reserva el derecho de adjudicar puntaje suplementario (bonos) con motivo de campañas promociónales puntuales, que serán oportunamente anunciadas a los CLIENTES o por compensación o buena voluntad.

Para efectos de tales bonos de Puntos, BANCO “X” se reserva el derecho de adjudicarlas a una porción o segmento de CLIENTES, de acuerdo a los parámetros de una promoción específica o según se crea conveniente; sin que esto se convierta en una obligación de adjudicación para todos los CLIENTES y para estos puntos no existirán aclaraciones ni reclamaciones.

2.4.3 Conceptos que no generan puntos

• Cargos por disposición de efectivo y sus respectivos intereses.

• Cargos por Cuotas Anuales.

• Cargos por Gastos de Cobranza.

• Pagos o abonos derivados de la gestión de cobranza.

• Cargos moratorios e intereses.

• Pagos a la tarjeta de crédito y cualquier cantidad dispuesta que no involucre la adquisición de bienes y/o pago de servicios.

2.4.4 Conceptos que disminuyen puntos

Cualquier compra o consumo que haya sido devuelto o cancelado que haya generado un abono en su tarjeta de crédito. Las compras o consumos derivados de fraudes con tarjeta crédito, aclaraciones o cualquier otro concepto que hubiera requerido la bonificación de los montos en la tarjeta de crédito. El uso de los puntos mediante transferencias a cualquiera de las empresas afiliadas al programa Recompensa Total de Puntos.

2.4.5 Canje

Para que El CLIENTE pueda canjear sus puntos al amparo del presente programa, será necesario que cuente un mínimo de 2,500 puntos acumulados en su número de cliente al momento de realizar el canje. Al acumular suficientes puntos para el canje de una recompensa, el CLIENTE puede hacer la respectiva solicitud en el Centro de Atención Telefónica de Recompensa Total de Puntos. Luego de deducir el puntaje necesario, si existe una diferencia en puntos a favor del CLIENTE, Recompensa Total de Puntos las mantendrá en su número de cliente pudiéndose acumular durante el período estipulado en el apartado de Vigencia de este documento.

14

Al tramitarse la solicitud de recompensa, el CLIENTE acepta que se tomen y descuenten de su número de cliente los puntos necesarios correspondientes al beneficio solicitado, según la tabla de premios en vigor en la fecha de la solicitud; descontándose con prioridad los puntos más antiguos y que califiquen para la obtención de dicha recompensa. Ciertas recompensas pueden tener restricciones adicionales que aplicarán según sea el caso. Es responsabilidad del CLIENTE actualizarse regularmente sobre las condiciones y/o restricciones de las promociones y utilización del puntaje.

BANCO “X” podrá ofrecer en ciertas recompensas la opción de un Pago Combinado, pagando una parte con puntos y una parte con cargo a la Tarjeta de Crédito del CLIENTE en cuyo caso lo hará del conocimiento del CLIENTE así como los valores y el procedimiento correspondiente. Esta opción es a discreción de BANCO “X” y no aplicará para todas las recompensas por lo que el CLIENTE solo podrá utilizar dicha opción de pago cuando BANCO “X” la anuncie y bajo las condiciones que establezca.

El CLIENTE reconoce que algunas recompensas están sujetas al pago de gastos de envío, impuestos o comisiones, bajo las políticas de las empresas afiliadas, en los cuales BANCO “X” no tiene ingerencia alguna y tampoco puede evitarlos. La determinación de la obligación del pago de cualquier tipo de impuestos, comisiones, costos de mensajería o tarifas generadas por las recompensas emitidas, son de absoluta y total responsabilidad del CLIENTE que las haya solicitado. El BANCO “X” se reserva el derecho de negar una solicitud de recompensa si no existe disponibilidad de la misma, y si no se cumple con las restricciones que presente el adquirir dicha recompensa.

BANCO “X” se reserva el derecho de revisar los saldos del puntaje acumulado, por los CLIENTES, al amparo del programa Recompensa Total de Puntos. En el caso de que se hayan abonado erróneamente dichos puntos, los mismos serán descontados del número de cliente. La emisión de recompensas puede suspenderse hasta resolver satisfactoriamente cualquier discrepancia o anomalía observada.

Una vez que los puntos hayan sido canjeados por cualquier recompensa, el CLIENTE no podrá solicitar su devolución, conversión o acreditación a su número de cliente de Recompensa Total de Puntos.

BANCO “X” se reserva el derecho de modificar las condiciones de obtención de todos los beneficios, en especial las recompensas, bonificaciones y número de puntos requeridos o de anular toda oferta de beneficio sin aviso previo y con efecto inmediato. La obtención de recompensas está sujeta a las restricciones establecidas para las mismas, estando éstas sujetas a disponibilidad.

15

2.4.6 Transferencias

El CLIENTE podrá realizar la transferencia de sus puntos a los Programas Afiliados a Recompensa Total de Puntos, para ello será indispensable que el o los productos participantes estén vigentes y al corriente en sus pagos.

El CLIENTE podrá transferir puntos de su saldo acumulado cuando este sea igual o mayor a 2,500 (dos mil quinientos) puntos y podrá transferir montos subsecuentes de acuerdo al Programa Afiliado que haya elegido.

Los Programas Afiliados se rigen por programas propios los cuales cuentan con términos y condiciones independientes del programa Recompensa Total de Puntos. BANCO “X” hará las transferencias de puntos al Programa Afiliado elegido por el CLIENTE, en un plazo de 5 días hábiles a partir de la fecha de la solicitud del CLIENTE.

BANCO “X” no podrá realizar transferencias de puntos obtenidos al amparo de este programa a números de usuarios, de los programas afiliados, registrados a un nombre distinto del nombre del CLIENTE Titular afiliado a Recompensa Total de Puntos. Una vez que los puntos hayan sido transferidos a cualquier Programa Afiliado, el CLIENTE no podrá solicitar su devolución, conversión o acreditación a su número de cliente de Recompensa Total de Puntos ni a cualquier otro de los Programas Afiliados. La solicitud de recompensas y/o reservaciones deben realizarse a través de los centros de atención telefónica que BANCO “X” establezca en conjunto con los Programas Afiliados para tal efecto.

La acumulación de puntaje y el uso de premios estarán sujetos a las condiciones establecidas por los Programas Afiliados. BANCO “X” no se hace responsable por las recompensas redimidas y no utilizadas a partir de la transferencia.

La transferencia de puntos a los programas afiliados estará sujeta a la permanencia de estos últimos como participantes en el programa Recompensa Total de Puntos.

Recompensa Total de Puntos puede integrar nuevas empresas afiliadas. En este caso, se informará a los CLIENTES, según considere conveniente, acerca de esta adhesión y de las condiciones impuestas por dichas empresas. Por otro lado, las empresas afiliadas al programa pueden terminar su participación en Recompensa Total de Puntos sin necesidad de previo aviso a los CLIENTES, y las recompensas ofrecidas por dichas empresas dejarán de ofrecerse.

16

2.4.7 Vigencia de puntos

Todos los puntos generados tienen una vigencia de dos años contada a partir de la fecha en que se generen, ya sea por bono, compra o consumo o bien por su generación natural de acuerdo al producto participante, en caso de no ser utilizados durante este período, los puntos expirarán y serán descontados del total que tiene registrado bajo su número de cliente. La fecha de eliminación se hará en un término de 24 horas posteriores a la fecha en que expiren los puntos. El CLIENTE es responsable de vigilar la vigencia de sus puntos y utilizarlos antes de su vencimiento. Una vez eliminados, los puntos no podrán ser abonados nuevamente.

2.4.8 Bloqueo

BANCO “X” se reserva el derecho de bloquear el uso de los puntos cada vez que un producto participante no se encuentre al corriente en sus pagos o se encuentre bajo un proceso de revisión de los puntos acumulados. Los puntos bloqueados permanecerán disponibles en el número de cliente y podrán ser utilizados hasta que el producto participante vuelva a estar al corriente en sus pagos y se cumplan todas las condiciones requeridas para canjear los puntos.

2.4.9 Cancelación

El CLIENTE puede cancelar en cualquier momento su membresía notificando a través del centro de atención telefónica de Recompensa Total de Puntos. Los puntos que tenga disponibles al momento de la cancelación serán cancelados inmediatamente. Banco “X” se reserva el derecho de cancelar la membresía del cliente, al programa Recompensa Total de Puntos, si se incumple alguno de los términos y condiciones del Programa.

En caso de que un CLIENTE haya ligado varios productos participantes y decida cancelar una o varios pero mantenga al menos uno de ellos activo, mantendrá su participación en el programa Recompensa Total de Puntos. BANCO “X” cancelará de manera automática los puntos acumulados en las cuentas que lleguen a una situación de cinco pagos vencidos en su Tarjeta de Crédito.

En caso de fallecimiento del Titular del producto participante, BANCO “X” cancelará automáticamente el número de cliente y todos los puntos acumulados en el mismo. En el caso de la terminación del programa, todos los puntos acumulados por los CLIENTES serán anulados por BANCO “X”, por lo que éste último no tendrá ninguna responsabilidad con respecto a puntaje acumulado y a recompensas no redimidas o utilizadas por sus CLIENTES en caso de terminar parcial o totalmente el programa.

17

BANCO “X” se reserva el derecho de cancelar la membresía a cualquier CLIENTE que a juicio de Recompensa Total de Puntos o BANCO “X” haya realizado fraude, abuso o violación alguna de los créditos de puntos, beneficios, uso de recompensas o cualquier otra reglamentación del programa. Al ser descalificado, el CLIENTE pierde todos sus derechos de membresía incluyendo todo su puntaje acumulado, privilegios y beneficios, estando sujeto a acciones administrativas y/o legales por parte de BANCO “X”, según sea el caso. También se procederá a la cancelación inmediata de su número de cliente de Recompensa Total de Puntos y de la participación futura del CLIENTE en otros programas de BANCO “X”.

2.4.10 Terminación del Programa

BANCO “X” se reserva el derecho de cambiar, modificar o suspender temporal o definitivamente el Programa Recompensa Total de Puntos en cualquier momento previo aviso publicado en la página Web de Recompensa Total de Puntos www.recompensatotalBanco “X”.com En cualquiera de los casos, BANCO “X” comunicará a sus CLIENTES, a través del medio antes indicado, el procedimiento y el plazo para redimir el puntaje acumulado antes de ser eliminado. Posterior a la fecha de terminación del programa Recompensa Total de Puntos todos los puntos serán anulados por BANCO “X”, por lo que BANCO “X” no tendrá ninguna responsabilidad con respecto a los puntos acumulados y a recompensas no redimidas o utilizadas.

Recompensa Total de Puntos es un Programa de Banco Mercantil del Norte, Sociedad Anónima, Institución de Banca Múltiple, Grupo Financiero Banco “X”. Los nombres comerciales, marcas y demás información es propiedad de BANCO “X”.

18

Capitulo III. Procesos de Mejora

3.1 Introducción

El PIC es el área de Softtek que se dedica a asegurar la calidad de los proyectos. El PIC se divide en tres grandes rubros:

• Auditoria a proyectos

• Procesos de Mejora (Proyectos Six Sigma)

• Digitalización de Procesos (Uso de la aplicación de PPM)

Las funciones principales del PIC son las siguientes:

• Responsable de los procesos de certificación en diversas metodologías de calidad.

• Diseñar plan de capacitación de calidad, así como de implementación.

• Asegurar que los sectores implementen las metodologías propuestas.

• Estimar presupuestos con implantación de metodologías de calidad.

• Justificar de proyectos.

• Negociar con clientes y entidades externas sobre proyectos de mejora.

• Establecer la relación con el cliente para conocer y negociar los criterios de satisfacción del producto y servicio contratado.

• Generar los cambios en la organización para mejorar el proceso.

• Apoyar a la solución de conflictos en diferentes grupos, enfocándose en los procesos.

• Proveer a la operación los procesos y métodos necesarios para establecer en el trabajo una disciplina de ingeniería de software.

• Realizar los proyectos de mejora necesarios para lograr en la operación el nivel “Six Sigma”.

• Planeación, Seguimiento, entrenamiento para proyectos “Six Sigma” para mejorar la forma en que se trabaja.

• Comunicar a los colaboradores y socios las mejoras y su costea dentro de la organización.

• Establecer, Coordinar, entrenar y adoptar los procesos en la operación asegurando la certificación CMM Nivel 5.

• Responsable de las auditorias a los proyectos.

En el área del PIC aplique mis conocimientos a la sección de Digitalización de Procesos, en donde la herramienta que se utiliza para la digitalización de procesos se llamaba Kintana, su nombre actual es PPM de esta forma nos referiremos a ella, de aquí en adelante.

19

3.2 Plataforma

A continuación se muestra la plataforma de PPM (Ver Fig. 7):

Fig. 7 Plataforma de PPM

Los procesos que se desarrollan para la administración de PPM contienen funciones, procedures, Jobs y triggers todos ellos son desarrollados en PL/SQL.

20

3.3 Capacitación Extra

Para poder ser administrador de la herramienta de PPM se tuvo que tomar una capacitación de dos semanas la que incluyo los siguientes cursos:

CMM I Introduction - Quality Strategy of the

Organization

Introducción a CM MI – Estrategia de Calidad para

la Organización

Decisions Analy sis: Pugh Matrix Anális is de Decisiones – Pugh MAtrix

Identification of Risks and Issues Identificación de Riesgos y Problemas

Induction to O peration Introducción a la Operación

Introduction to Configuration ManagementIntroducción a la Administración de la

Configuración

Introduction to Kintana Introducción a Kintana

Introduction to Orga nizational M etrics - Service

Levels

Introducción a las métricas organizacionales –

N iveles de Servicio

Introduction to SOFTTEK Culture –GALATEA Introducción a la cultura de Softtek - Galatea

Introduction to SOFTTEK M ethodolog ies Introducción a la metodologia de Softtek

Six Sigma Awareness and Process Improvement Conocimiento de Six Sigma y procesos de mejora

Validation and Verification Validación y Verif icación

Basic Workflow Configuration Configuración Básica de F lujos de Trabajo

Configuring Decision Step Sources Configuración de Pasos de Desiciones

Configuring Portlet Definitions Configuración de la definición de Portlets

Configuring Portlets Data Sources Configuración de codificación para Portlets

Configuring Request Header TypesConfiguración de Tipos de encabezado de

requerimientos

Configuring Request Types Configuración de Tipos de requerimientos

Configuring Request Work flowsConfiguración de flujos de trabajo para

requerimientos

Controlling Data Integrity Using ValidationsControlando la integración de los datos usando

va lidaciones

Dashboards M odules Modulos Dashboards

Designing Workflows Diseño de Flujos de trabajo

Managing Security Administración de la S eguridad

Managing User Accounts and Licenses Administración de cuentas de usuario y licencias

Personalizing Your Dashboard Personalización de Das hboards

PreAssigment ITG Induction Inducción a ITG

Processing Requests and Tasks Procesamiento de requerimientos y tareas

Request Type and Request Header Type O verviewDescripción genera l de tipos de ecabezados y

requerimientos

Using Request Statuses and Status DependenciesUsando estados y sus dependencias en los

requerimientos

Using Request Type Rules Usando tipos de reglas en los requerimientos-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

Fig. 8 Capacitación recibida

21

3.4 Overview de PPM

Básicamente el área de Digitalización de Procesos se basa en la administración de la herramienta de PPM, en donde PPM es la tecnología de información utilizada por Softtek para digitalizar los procesos del los diferentes Negocios, tanto de la organización (áreas staff), como los de producción (proyectos), permitiendo su seguimiento e interacción entre los niveles de la organización, desde los líderes de proyecto hasta los integrantes de los equipos.

PPM esta compuesto por ocho módulos (Ver Fig. 9), de los cuales en Softtek solo se utilizan cinco (Los módulos marcados en rojo). Los módulos son los siguientes:

• Demand Management Permite la administración de la demanda de requerimientos, permitiendo la consolidación y priorización de los requerimientos, la administración de los niveles de servicio y el ciclo de vida de los requerimientos.

• Portfolio Management Permite la alineación de la cartera de proyectos con la estrategia del negocio, administrando la aceptación, rechazo o cancelación proyectos y el seguimiento a todos los proyectos de la organización.

• Program Management Provee una estructura de proyectos out-of-the-box5 que permite la administración de los cambios de alcance, los riesgos, la calidad, los issues6, por otro lado permite la administración de los tiempos, los recursos y los costos de los proyectos que contiene un programa.

• Project Management Permite la administración de proyectos, tomando en cuenta los tiempos, los recursos y los costos asignados a un proyecto.

• Resource Management Permite la administración de los recursos asociados a un proyecto, indicando la productividad, el porcentaje de utilización, los proyectos a los que esta asociado, los roles y skills7 que tiene el recurso.

5Out-of-the-box se refiere a la administración independiente de los cambios de alcance, riesgos, calida e issues,

estos procesos no están contenidos en un proyecto. 6 Issue se refiere a un problema actual que se esta presentando en un proyecto determinado.

7 Skill es una habilidad que tiene una persona.

22

• Time Management Permite conocer el tiempo invertido en cada una de las actividades que realizan los recursos dentro de la organización.

• Financial Management Permite la administración de los presupuestos, costos reales, inversiones de los proyectos, permitiendo así escenarios de comparación que se pueden proyectar a futuro.

• Deployment Management Permite la migración de objetos de PPM entre los ambientes de test, calidad y producción.

Fig. 9 PPM y sus módulos

La administración de los módulos de PPM se divide en dos rubros: 1.- Soporte a Usuarios

Atención de Kintana Help Desk8 2.- Digitalización de Procesos

Análisis del proceso Construcción del proceso Pruebas del proceso (Peer Review9) Pruebas de UAT10 (Peer Review realizado por el cliente) Liberación del proceso

8 Kintana Help Desk abreviado se llama KHD.

9 Peer Review es parte de la metodología de Softtek para asegurarse que los procesos desarrollados tengan los

mínimos errores posibles. 10

UAT es el acrónimo de User Acceptance Testing y es parte de la metodología de Softtek para reducir defectos.

23

3.5 Soporte a Aplicación de PPM

El soporte a la aplicación se da a través de requerimientos llamados Kintana Help Desk, el objetivo de este requerimiento es el ofrecer el contacto directo con el equipo que administra el proyecto de PPM, para resolver dudas sobre requerimientos, corregir nombres de campos, crear usuarios nuevos, o cualquier cosa que no afecte al proceso en si.

Todos los usuarios internos de Softtek tienen definidos una serie de accesos básicos que son aplicables a cualquier proyecto, el requerimiento KHD, viene en ese kit básico de accesos.

El proceso de soporte para el usuario es el siguiente y comienza cuando se crea un requerimiento de KHD (Ver Fig. 10).

Fig. 10 Proceso de KHD (Usuario)

24

3.5.1 Tipos de KHD

Existen once tipos de ayuda dentro de los KHD, dependiendo de cuales sean las necesidades del usuario, se debe de seleccionar el tipo del KHD (Ver Fig. 11). Los tipos de KHD son los siguientes:

⇒ Change User Info

⇒ Change Request Data

⇒ Deactivate User

⇒ Create New User

⇒ Change User Access

⇒ Solve Problem

⇒ User Support

⇒ Delete Request

⇒ Deactivate Project

⇒ Reactivate User

⇒ Modify Project Data

⇒ Create Project ID Cada uno de los tipos de KHD se resuelve de manera diferente, lo que siempre debe de estar presente es la atención que se le da al cliente, dado que el soporte es un servicio.

Para mejorar la calidad del servicio, los soportes de KHD cuentan con los SLA’s11 de OTR12 y OTD13, con estos SLA’s los usuarios conocen la fecha en la que debe de ser resuelta su petición, por parte del equipo administrador de PPM.

Prioridad OTR (hrs.) OTR (hrs.)

Low 8 24 Normal 8 24 Medium 4 12 High 2 8 Critical 2 4

11

SLA es el acrónimo de Service Level Agreement. 12

OTR es el acrónimo de On-Time Response, métrica definida por Softtek. 13

OTD es el acrónimo de On-Time Delivery, métrica definida por Softtek.

Fig. 11 Tipos Ayuda en los KHD

25

El proceso de KHD se muestra a continuación (Ver Fig. 12), mostrando las vertientes dependiendo de la ayuda que se haya solicitado:

Fig. 12 Proceso de los KHD

26

A continuación se explica cada uno de los diferentes soportes así como las soluciones genéricas que se les da.

3.5.1.1Create New User

El usuario creador del requerimiento debe de llenar la tabla de Kintana New User Details (Ver Fig. 13), todos los campos son obligatorios y si el usuario no llena los datos, el requerimiento se manda a Need More Info .

• Nombre

• Apellidos

• e mail

• Proyecto

• Role

• SSO (Usuarios de GE14)

• Compañía (GDC15)

Fig. 13 Tabla de New User Details

Proceso de creación de usuario (Ver Fig. 14).

Fig. 14 Proceso de creación de un usuario

14

GE es el acrónimo de General Electric 15

GDC es el acrónimo de Centro Global de Entrega

27

3.5.1.2 Change User Info

El usuario que cree el KHD, debe de enviar los datos que desee cambiar de un determinado usuario. Los datos a cambiar pueden ser:

• Username

• Información a modificar (Nombre, email, GDC Asignado)

Proceso de cambio de información (Ver Fig. 15).

Fig. 15 Proceso de cambiar información de un usuario

3.5.1.3 Deactivate User

El usuario que cree el KHD, debe de enviar el nombre del usuario que desea desactivar.

Proceso de desactivación de usuario (Ver Fig. 16).

Fig. 16 Proceso de desactivación de un usuario

28

3.5.1.4 Change User Access

El usuario que cree el KHD, debe de enviar, el nombre del usuario al que desea cambiar los accesos a PPM (Ver Fig. 17).

ROLE K

inta

na U

se

r

Pro

ject

ID S

ec G

rou

p

De

velo

pm

en

t T

ea

m M

em

be

r

Kin

tana D

rive

Pro

ject M

ana

ge

r

Pro

ject

Lead

ers

Op

era

tion L

ea

de

r

GD

C (

Ge

ogra

ph

y)

Man

age

r

Dire

cto

rs

Bla

ck B

elts

Custo

me

r

(Pro

ject

ID)

- C

usto

me

r

(Pro

ject

ID)

- (R

ole

)

Man

ag

e R

eq

uests

Assig

nm

en

t L

oa

d I

nfo

GD

C I

MS

S K

inta

na

Use

r

IMS

S E

quip

o (

Co

ord

inació

n)

IMS

S-G

ere

nte

s y

LP

IMS

S-G

ere

nte

s y

LP

(C

oo

rdin

ació

n)

IMS

S -

Sta

ff

IMS

S -

Clie

nte

(C

oo

rdin

ació

n)

AMS Team Member x x

AMS Project Leader x x x

Development Team Member x x x

Development Project Leader x x x x x

Operation Leader x x x

GDC Manager x x

Softtek Top Management x x

Customer x x

Black Belt x x

IMSS STK Team Member x x

IMSS STK Manager x x x x

IMSS STK Staff x x

IMSS Customer x x

Fig. 17 Relación Rol - Seguridad

Proceso de cambio de accesos (Ver Fig. 18).

Fig. 18 Proceso de cambio de accesos

29

3.5.1.5 Solve a Problem

El usuario que cree el KHD, debe indicar el error que se le ha presentado y un Screenshot del error.

Proceso de Solución de problemas (Ver Fig. 19).

Fig. 19 Proceso de solución de problemas

3.5.1.6 Delete Request

El usuario que cree el KHD, debe de enviar el número del requerimiento que desea eliminar, y el porque de esta decisión.

Proceso de eliminación de un requerimiento (Ver Fig. 20).

Fig. 20 Proceso de eliminación de un requerimiento

30

3.5.1.7 Deactivate Project

El usuario que cree el KHD, debe de indicar los siguientes datos:

• Nombre del proyecto

• GDC Asignado

• Indicar si es un desarrollo o AMS16

• Autorización de GDC Manager en donde esta localizado el proyecto

Proceso de desactivación de un proyecto (Ver Fig. 21).

Fig. 21 Proceso de desactivación de un proyecto

3.5.1.8 Modify Project Data


• Nombre del Proyecto

• Datos a cambiar en el proyecto

16

AMS es el acrónimo de Application Maintenance and Support.

31

Proceso de modificación de un proyecto (Ver Fig. 22).

Fig. 22 Proceso de modificación de un proyecto

3.5.1.9 Create Project ID



• OL

• PL

• Cliente

• GDC Asignado

Proceso de creación de un proyecto (Ver Fig. 23).

Fig. 23 Proceso de creación de un proyecto

32

3.5.1.10 Change Request Data


• Request Id

• Campo a modificar

• Valores que deben de tener los campos

Proceso de cambio de datos de un requerimiento (Ver Fig. 24).

Fig. 24 Proceso de cambio de datos de un requerimiento

33

3.6 Digitalización de Procesos

Los procesos de digitalización, consisten en la transformación de documentos físicos a imágenes digitales que son ejecutados bajo un enfoque basado en procesos, es decir, basado en un flujo de trabajo, controlado por etapas, balanceando los sub-procesos, y controlando los documentos para permitir administrar el proceso en forma integral.

La digitalización de los procesos se da a través de requerimientos llamados Process Improvement, el objetivo de este requerimiento es el ofrecer el contacto directo con el equipo que administra el proyecto de PPM, para la creación de nuevos procesos o la mejora de los procesos existentes.

Todos los usuarios internos de Softtek tienen definidos una serie de accesos básicos que son aplicables a cualquier proyecto, el requerimiento PI17, viene en ese kit básico de accesos. El proceso de PI comienza cuando se crea un nuevo proyecto (Ver Fig.

25).

Fig. 25 Proceso de PI (Usuario)

17

PI es el acrónimo de Process Improvement.

34

3.6.1 Tipos de PI

Existen tres tipos de PI que se pueden crear (Ver Fig. 26):

• Portlets

• Workflows

• Interfaces

El proceso de PI cuenta con las fases de Análisis, construcción (se incluyen las pruebas unitarias en esta fase), pruebas de Peer Review, pruebas de UAT y liberación del proceso.

Estas fases aplican para cualquier tipo de PI; el proceso de PI se muestra a continuación (Ver Fig. 27).

Fig. 27 Proceso de los KHD

Fig. 26 Tipos de PI

35

A continuación se explica cada uno de los diferentes PI’s así como las soluciones genéricas que se les da.

3.6.1.1 Creación de un Portlet

Un portlet es una vista configurable de datos, estos datos muestran el estatus del proyecto, los requerimientos pendientes, cerrados, etc.

Los portlets contienen filtros, en donde el usuario hace uso de ellos de acuerdo a los criterios necesarios para que realice su trabajo.

A continuación se muestra el ejemplo de un portlet y su Drill Down18 (Ver Fig. 28).

Fig. 28 Ejemplo de un portlet en PPM

18

Drill Down es un tipo de portlet que muestra la información en forma de lista.

36

Para poder desarrollar un portlet en PPM, el usuario que cree el PI, debe de proporcionar los siguientes datos:

• Nombre del portlet

• Descripción

• Indicar si es nuevo o una modificación

• Localización del portlet

• Tipo de portlet

• Información que debe mostrar

• Estatus que va a incluir

• Indicar si va a tener Drill Down19

• Columnas del Drill Down

• Consideraciones especiales para el portlet

• Proyectos o personas que tendrán acceso al portlet

Estos datos se establecen en el template de Portlets y posteriormente se deben de adjuntar al requerimiento de PI.

Proceso de creación de un nuevo portlet (Ver Fig. 29).

Fig. 29 Proceso de creación de un nuevo portlet

19

Drill Down es un tipo de portlet que muestra la información en forma de lista.

37

Ejemplo del análisis de un portlet (Ver Fig. 30).

Fig. 30 Ejemplo del Análisis de un PI de tipo Portlet

Ejemplo de estimación de un portlet (Ver Fig. 31).

Fig. 31 Ejemplo de una Estimación de un Portlet.

38

3.6.1.2 Creación de Workflow

La creación de un Workflow en PPM, significa la creación de un proceso para un proyecto: un requerimiento

Los procesos que se realizan para los proyectos, permiten tener el control del proyecto, es decir, permite la administración de personas, recursos, tiempos y métricas.

Un requerimiento en PPM se compone de cinco secciones (Ver Fig. 32).

Fig. 32 Secciones de un requerimiento

De acuerdo a lo anterior, los usuarios solo tienen acción sobre las secciones de Header y Details. La digitalización de Workflow abarca ambas secciones mas el flujo de trabajo (Ver Fig. 33).

Fig. 33 Partes de un Workflow

Secciones proporcionadas por PPM, están presentes en todos los requerimientos.

Secciones que contienen los campos dados por los usuarios.

39

A continuación se muestra el ejemplo de la digitalización de un workflow (Ver Fig. 34).

Fig. 34 Ejemplo de un requerimiento en PPM

Para poder desarrollar un workflow en PPM, el usuario que cree el PI, debe de proporcionar los siguientes datos:


• Campos del proyecto

• Diagrama en Vicio del proceso

• Participantes en proceso

• Notificaciones del proceso

Estos datos se establecen en el template de AMS y posteriormente, el template es adjuntado al requerimiento de PI.

40

Proceso de creación de un flujo de trabajo (Ver Fig. 35).

Fig. 35 Proceso de creación de un flujo de trabajo

Ejemplo del análisis de un portlet (Ver Fig. 36).

Fig. 36 Ejemplo del Análisis de un PI de tipo AMS

41

Estimación de un flujo de trabajo (Ver Fig. 37).

ObjectsSTD

Time(SLA)Qty.

Time per

Object

Adding a Step to a WF 0.35 2 0.7

Deleting a Step of a WF 0.42 0

Security Change (WF) 0.35 4 1.4

Adding Notifications 0.7 0

Simple Executions 0.35 0

Complex Executions 4.2 1 4.2

Create a Store procedure or a

function 4.2 1 4.2

Add a function already created 2.1 1 2.1

12.6Time in hours

Wo

rkfl

ow

s

Fig. 37 Ejemplo de una Estimación de un AMS

Estimación de un request type (Ver Fig. 38).

ObjectsSTD

Time(SLA)Qty.

Time per

Object

Create a Copy of AMS Std 5.6 1 5.6

Request Type Copy 4.2 0

Adding a Field 0.7 0

Changing a Validation Form

1-10 fields 1 1 1

11-50 fields 2 0

50-100 fields 4 0

+ 100 fields 5 0

Changing a functionability to a

Validation Form 4.25 0

Changing Status Dependencies 0.7 0

Simple Rules 0.35 2 0.7

Complex Rules 2.8 0

7.3

Req

uest

Typ

e

Time in hours

Fig. 38 Ejemplo de una Estimación de un AMS

42

3.6.1.1 Creación de una Interfaz

Una interfaz, es la transferencia de información proporcionada por el cliente a PPM. La información dada por el cliente, la información puede ser dada en las siguientes formas:

• Archivo de Excel

• Acceso a la BD del cliente

• Archivo XML

Ejemplo de una interfaz. Con un botón en una hoja de Excel, se genera un macro, que realiza la interfaz entre la BD y PPM (Ver Fig. 39).

Fig. 39 Ejemplo de una interfaz en PPM

43

Para poder desarrollar una interfaz en PPM, el usuario que cree el PI, debe de proporcionar los siguientes datos:

• Razón de porque es necesaria la interfaz para el proyecto.

• Especificar en que forma va a enviar la información el cliente.

• Como se va a ejecutar la interfaz.

• Información que se desea cargar en PPM.

Estos datos deben ser llenados a través del template de Portlets y posteriormente debe de ser adjuntado al requerimiento de PI.

Proceso de creación de una interfaz (Ver Fig. 40).

Fig. 40 Proceso de creación de una interfaz

Estimación de una Interfaz (Ver Fig. 41).

ObjectsSTD

Time(SLA)Qty.

Time per

Object

Modifying Interface 11.2 0

Interfaces 33.6 1 33.6

33.6Time in hours

SQ

L

Fig. 41 Ejemplo de Estimación de una Interfaz

44

Ejemplo de una interfaz (Ver Fig. 42).

Fig. 42 Ejemplo del código de una interfaz.

Private Sub cmdExecute_Click()

Dim Quarter As String

Dim Product_Group As String

Set Cn = New ADODB.Connection

Conn = "UID=PHPAP23;PWD=PHPAP23;DRIVER={Microsoft ODBC for Oracle};" _

& "SERVER=KINTANA;"

Set Cn = New ADODB.Connection

With Cn

.ConnectionString = Conn

.CursorLocation = adUseClient

.Open

End With

Quarter = Sheet1.Cells(i + 1, 1)

Product_Group = Sheet1.Cells(i + 1, 2)

tableRequests = "INSERT INTO KCRT_REQUESTS_INT" & _

"(GROUP_ID, ASSIGNED_TO_USER_ID, CREATED_BY , CREATION_DATE, LAST_UPDATE_DATE," & _

" REQUEST_TYPE_NAME, STATUS_NAME, DESCRIPTION, RELEASED_FLAG," & _

" KNTA_PROCESSED_DATE, TRANSFER_DATE, TRANSACTION_TYPE, KNTA_PROCESSED_FLAG) " & _

"VALUES(" & v_id & "," & "'" & Assigned_to & "'" & "," & "'" & _

Created_By & "'," & "'" & Created_On & "'" & "," & "'" & last_updated_date & "'" & "," & "'PHPAP23'" & "," & "'Closed'" & "," & _

"'" & Description & "'," & " 'Y', " & "null, " & "sysdate" & "," & "'I'" & "," & "0" & _

");"

Next

' Cn.Close

MsgBox " ¡¡¡ Inserts Completed Successful !!!"

End

End Sub

Private Sub CommandButton1_Click()

End Sub

45

3.7 Proyecto Six Sigma

3.7.1 Definición de Six Sigma

Six Sigma es una metodología de mejora de procesos, centrada en la eliminación de defectos o fallas en la entrega de un producto o servicio al cliente; Entendiéndose como “defecto”, cualquier evento en que un producto o un servicio no logra cumplir los requerimientos del cliente.

Six Sigma esta enfocado al: mejoramiento de la rentabilidad y la productividad.

3.7.2 Necesidad de un Proyecto Six Sigma

El proyecto Six Sigma que se desarrollo para Softtek, se llama “Increase the percentage of Process Improvement analyzed”, este proyecto se desarrollo, partiendo de la necesidad del área de Digitalización, en reducir los tiempos de análisis del proceso de PI.

Reduciendo el tiempo de análisis del proceso de PI, se reduce el ciclo de vida completo del proceso de PI (Ver Fig. 43).

Fig. 43 Proceso de PI’s

66.4% de los PI’s generados exceden los 9 días del proceso de análisis.

46

3.7.3 Proceso del proyecto Six Sigma

La metodología que se aplico para el proyecto Six Sigma fue la metodología de DMAIC, esta metodología se caracteriza por 5 etapas (Ver Fig. 44):

1. Define 2. Measure 3. Analyze 4. Improve 5. Control

A continuación se muestra un resumen de los procesos internos que tiene cada una de las fases de esta metodología (Ver Fig. 45):

Fig. 45 Resumen por fase DMAIC

Fig. 44 DMAIC

47

3.7.3.1 Define

En la fase de Define se realizaron las siguientes acciones:

• VOC20

• Definición del proyecto

• Análisis costo-beneficio

• Selección de equipo de Trabajo

• SIPOC21

• Mapa de Proceso Detallado

• Sign off del Champion

• Plan de trabajo

• Formalización del proyecto

• Junta de Kick off

3.7.3.1.1 VOC

El VOC fue generado internamente por el líder del equipo de PPM, dado que necesitaba que él área de PPM fuera mas productiva. El tiempo de atención de un requerimiento de PI estaba excediendo los límites establecidos. Los tiempos del proceso de PI se miden de la siguiente forma (Ver Fig. 46):

Fig. 46 Tiempos de atención

20

VOC es el acrónimo de Voice of Customer (Voz del Cliente). 21

SIPOC es el acrónimo de Supplier Input Process Output Customer.

9 días

Tiempo estimado de

inicio y término del

requerimiento Tiempo que toma el usuario en

hacer pruebas (No esta dentro

de las métricas del área).

48

El 66.4% de los requerimientos de PIS se estaban excediendo en los 9 días definidos para la realización del análisis (El tiempo variaba entre 2 hasta 100 días desde su creación). El VOC del proyecto se dio a través de un mail, en el que se solicita el permiso para ejecutar este proyecto Six Sigma (Ver Fig. 47).

Fig. 47 VOC 3.7.3.1.2 Definición del Proyecto

La definición de proyecto se llevo a cabo en un Project Charter que es el documento en el cual se estableció el Business Case, Problem Statement, Goal Definition, Project Scope, Defect and opportunity definition y Benefits.

En donde:

• Business case: se establece la razón por la cual es importante generar el proyecto.

• Problem Statement: se establece el problema que se va a atacar.

• Goal Definition: se define el objetivo cuantitativo que se desea cumplir.

• Project Scope: se definen los límites del proyecto.

• Defect and opportunity definition: se establece la definición de defecto para el proyecto y la oportunidad de que un defecto suceda.

• Benefits: se establecen los beneficios económicos que tendrá el proyecto.

El Project charter es la base del todo proyecto, en ningún momento durante el desarrollo de proyecto se deben de perder de vista las definiciones dadas en él.

49

El Project Charter del proyecto (Ver Fig. 48) fue realizado por el líder del proyecto Six Sigma con apoyo del Black Belt.

Fig. 48 Project Charter

3.7.3.1.3 Equipo de trabajo

El equipo de trabajo para el proyecto se formo, pidiendo voluntarios dentro del equipo de PPM, para realizar las mejoras al proceso. El equipo quedo de la siguiente forma:

Champion: Ana Fernandez Black Belt / Master Black Belt: Griselda Chevalier Team/Project Leader: Sandra Sanchez Perez Team Members: Silvia Jaimes, Edith Arredondo, Christian

Hernández y Erick Ruiz Stakeholders: Ricardo Garza, Approvers y Luis Cuellar

50

3.7.3.1.4 Análisis costo-beneficio

El beneficio del proyecto se dio en Soft Dollars22. La realización del análisis costo-beneficio de se llevo a cabo de la siguiente forma:

• Se realizo el calculo de la mediana, de una muestra 3 meses en donde se crearon 244 requerimientos de PI’s.

• Se realizo el promedio de requerimientos excedidos por mes.

• Se realizo el calculo para saber el número de días ahorrados por mes, para este calculo se multiplico la mediana que esta dada en días por el número de requerimientos de PI’s excedidos por mes.

• Se realizo el cálculo para saber los Soft Dollars ahorrados anualmente, para este cálculo se multiplicaron, los días ahorrados por mes, el costo por hora y los 12 meses del año.

El Análisis costo-beneficio (Ver Fig. 49) fue realizado por el líder de proyecto, con el apoyo del Black Belt y aprobado por el Champion.

Fig. 49 Análisis costo-beneficio

22

Soft Dollars es el dinero que se ahorra Softtek en fuerza de trabajo.

51

3.7.3.1.5 SIPOC

Se desarrollo un mapa del proceso de alto nivel en donde se desglosa a grandes rasgos el proceso indicando: la persona que origina el proceso, las entradas al proceso, el proceso, las salidas del proceso y las personas que reciben el producto o servicio terminado.

El SIPOC del proyecto (Ver Fig. 50), solo abarca la fase de análisis que incluye desde que el requerimiento del PI es creado hasta su asignación.

Fig. 50 SIPOC

3.7.3.1.6 Mapa Detallado del Proceso

Se desarrollo un mapa de todo el proceso de los PI (Ver Fig. 51), indicando en un recuadro, la parte que va a ser afectada por el proyecto Six Sigma.

La finalidad del mapa detallado del proceso es dar visibilidad del proceso de PI a los miembros del equipo, cuando se realice la junta de Kick off.

52

El mapa de proceso fue validado por el Champion y el Black Belt, para establecer una vez más el alcance del proyecto.

Fig. 51 Mapa Detallado del Proceso

3.7.3.1.7 Sign off del Champion

El Sign off es la petición formal (vía correo) en el que el líder del proyecto Six Sigma pide al Champion, su autorización para la realización del Proyecto Six Sigma (Ver Fig.

52). El Líder del Proyecto debe mostrar al Champion lo siguiente: el Project charter, el análisis costo-beneficio, el SIPOC y el Mapa detallado del proceso, para que el Champion pueda tener el contexto del proyecto y ver si es factible su realización

.

Fig. 52 Sign off del Champion

53

3.7.3.1.8 Plan de trabajo

El Black Belt de acuerdo a su experiencia, realiza un plan de trabajo por fase del proyecto Six Sigma (Ver Fig. 53), este plan posteriormente es revisado con el líder del proyecto para ajustar fechas de entrega de cada una de las fases.

Fig. 53 Plan de trabajo por fase.

3.7.3.1.9 Formalización del proyecto

La formalización del proyecto se lleva a cabo, creando un requerimiento de tipo Six Sigma en PPM (Ver Fig. 54).

Fig. 54 Requerimiento de Six Sigma

54

El requerimiento de Six Sigma en PPM, cuenta con toda la información del proyecto, el Black Belt y Champion responsable del proyecto. Esta información es enviada vía correo al Quality Council23 de Softtek para que conozcan el nuevo proyecto que se esta desarrollando y puedan darle seguimiento.

3.7.3.1.10 Junta de Kick off

La junta de arranque se llevo a cabo con todos lo miembros del equipo definidos para el proyecto Six sigma, con la finalidad de que estén en contexto del proyecto que se va a desarrollar.

En esta junta de arranque se crea en PPM a través de un requerimiento de tipo Meeting Request (Ver Fig. 55), en donde se establecen los temas a tratar, el lugar y la hora de la junta, así como los participantes involucrados.

Los temas que se revisan son los siguientes:

• La necesidad de crear un proyecto Six Sigma

• La definición del proyecto

• Los beneficios que va a aportar el proyecto al equipo de trabajo.

Fig. 55 Requerimiento de tipo Meeting Request.

23

Quality Council es el departamento que da seguimiento a los proyectos Six Sigma de todas las geografías de

Softtek.

55

3.7.3.2 Measure

En la fase de Measure se realizaron las siguientes acciones:

• Identificación del CTQ24 en la Y afectada.

• Definiciones operacionales del proyecto.

• Determinación del tamaño de la muestra.

• Proceso de medición ha utilizar.

• MSA25.

• RCA26.

• Matriz de Impacto.

• Colección de Datos.

• Prueba de normalidad.

• Definición de Causas Espaciales.

• Definición de la Capacidad del Proceso.

• Definición del objetivo a alcanzar.

3.7.3.2.1 Identificación del CTQ en la Y afectada

La Y es la métrica clave del proyecto Six Sigma y esta dado bajo la perspectiva del cliente. Softtek tiene definidas sus Y’s para las métricas de atención al cliente. En base al proyecto Six sigma que se desarrolla, se hace la selección de la Y en el Árbol de CTQ’s de Softtek. En el caso de este proyecto la Y identificada es el cumplimiento del 97% de los SLA’s (Ver Fig. 56).

Fig. 56 Selección de Y

24

CTQ es el acrónimo de Critical to Quality (Critico para la Calidad). 25

MSA es el acrónimo de Measurement System Analysis (Análisis del Sistema de Medición) 26

RCA es el acrónimo de Root Cause Analysis (Análisis de las causas raíz).

56

3.7.3.2.2 Definiciones operacionales del proyecto

Las definiciones operacionales (Ver Fig. 57), son esenciales y necesarias en el proyecto Six Sigma, ya que de manera clara se define que es lo que se va a medir (Unit), la oportunidad de defecto por unidad (Opportunity), lo que se considera como defecto en el proyecto (Defect), la unidad de medida con la que se va a medir (Unit Measure), lo que se va a medir (Operational Definition), el tipo de datos que se va a utilizar (Data Type), el objetivo que se pretende alcanzar (Target), los límites superiores e inferiores (LSL y USL).

Fig. 57 Definiciones operacionales

3.7.3.2.3 Determinación del tamaño de la muestra

El tamaño de la muestra (Ver Fig. 58), va a depender de la desviación estándar de los datos (se tomaron todos los PI’s que se crearon de Agosto 2008 a Noviembre 2008) y la desviación de en días del objetivo (9 días a partir de la creación del PI) que se esta dispuesto a permitir.

Sample size determination

Continuous data

Standard deviation 13.07Delta value * 3.5

"N" = 54 Fig. 58 Tamaño de la muestra

57

El tamaño de la muestra fue de 54 PI’s seleccionados aleatoriamente, de los tres meses de muestra que se tomaron (Ago-Nov).

3.7.3.2.4 Proceso de medición ha utilizar

El método que se utilizo para medir los PI’s es e siguiente: 1. Ejecutar el el query en la base de datos de producción (Ver Fig. 59).

Fig. 59 Query de Medición de tiempos

2. Exportar los resultados del query a un archivo de Excel. 3. Revisar la diferencia en días de cada uno de los PI’s.

a. El tiempo que se toma en cuenta va desde la creación hasta la asignación del PI.

b. Marcar cada uno de los PI’s que excedan los nueve días. 4. Aplicar una regla de tres para ver el porcentaje de PI’s que no excedan los 9

días de Análisis. 5. Revisar que el porcentaje se mayor o igual al 95%.

SELECT c.request_id, u.username, c.CREATION_DATE, a.CREATION_DATE,

trunc(ddm_hd_real_working_hours (c.CREATION_DATE, a.CREATION_DATE, 3, 2),4)

total_hours, FUN_BUSINESS_DAYS(c.creation_date,a.creation_date) OPEN_DAYS

FROM kwfl_step_transactions a, kwfl_workflow_instances b, kcrt_requests c,

kwfl_transition_transactions d, kcrt_req_header_details rhd, knta_users u

WHERE a.workflow_instance_id = b.workflow_instance_id

AND c.request_id = b.instance_source_set_id

AND c.request_id = rhd.REQUEST_ID

AND C.ASSIGNED_TO_USER_ID = U.USER_ID

AND c.request_type_id = 30208--tipo de requerimiento

AND a.step_transaction_id = d.FROM_STEP_TRANSACTION_ID

AND d.RESET_STEP_TRANSACTION_ID is null

AND d.TO_WORKFLOW_STEP_ID in

(select workflow_step_id

from kwfl_workflow_steps

where workflow_id in

(select workflow_id from kcrt_requests where request_type_id = 30208)

and step_name = 'Working')

and rhd.PARAMETER5 = '2'

and c.CREATION_DATE BETWEEN TO_DATE('01/08/2007','DD/MM/YYYY')

AND TO_DATE('01/11/2007','DD/MM/YYYY')

58

3.7.3.2.5 Evaluación del método de medición

En este caso, no aplico la realización de un método de medición, por las siguientes causas:

1. El tiempo de análisis es calculado automáticamente por PPM. 2. Todos lo PI’s se miden de la misma forma.

3.7.3.2.6RCA

Se realizaron reuniones con todos los miembros del equipo. Se realizaron tres sesiones de dos horas cada una, para terminar el RCA (Ver Fig. 60), En todas las sesiones se planteo el siguiente problema:

“Porque no estamos cumpliendo los 9 días de análisis en los PI’s”

Fig. 60 RCA

Las causas raíces encontradas se llaman también X’s del proceso.

59

Todos los miembros del equipo opinaron, cuales eran las posibles causas raíces de este problema y las causas reagruparon en las siguientes categorías:

- Gente - Procesos - Materiales - Métricas

Una vez que se termino de realizar el RCA el Líder del Proyecto y el Champion asignaron prioridades a las causas raíz del problema encontrado y se seleccionaron cuales de ellas ser van a medir.

3.7.3.2.7 Matriz de Impacto

Se detectaron 21 causas raíces en el RCA a las cuales se les asignaron las prioridades 1 y 2, por lo tanto son las únicas que se van a medir. Una vez asignadas las prioridades a las causas raíces, se procede a evaluar las causas en base al impacto que tienen y al control que podemos ejercer sobre esas causas (Ver Fig. 61).

High Low

X1.- Falta de documentación de los objetos. X14.- La persona que solicitó el PI no es el dueño del proceso.

X2.- Falta de entrenamiento. X15.- Barrera del idioma - caso Brasil

X3.- El conocimiento se centraliza. X16.- Los analistas no pueden contactar al usuario para hacer el análisis requerido

X4.- No hay un proceso definido para la distribución de PI X17.- El usuario no envía la información necesaria

X5.- No están indicados los tiempos de OTR y el tiempo de analisis. X18.- El OL tarda mucho tiempo en aprobar el cambio.

X6.- No se tiene una base de conocimiento de referencia (checklist) X19.- El equipo de ITG tarda mucho tiempo en aprobar los cambios.

X7.- No estan definidas las actividades a realizar de los Analistas y desarrolladoX20.- La cantidad de Process Improvements que se generan es muy alta.

X8.- No hay una revisión periódica de la métrica. X21.-Diferencia de horarios

X9.-Por el perfil de contratación del analista

X10.-No se tiene la cultura de monitorearla

X11.- No existe una división de trabajo.

X13.- Los Analistas no contactan al OL para pedirle su pronta aprobación.

Imp

ac

t

Control

X12.- No se indica desde la creación del PI cuál es la información que debe

proporcionar de acuerdo al tipo de PI.

Hig

hL

ow

Fig. 61 Matriz de Impacto

60

3.7.3.2.8 Colección de Datos

De los 54 requerimientos tomados aleatoriamente, se medio cada uno contra las 21 causas raíces encontradas en el RCA (Ver Fig. 62). Cada una de las causas raíces se midieron con valores binarios de 0 o 1.

0 No afecta al requerimiento esa causa raíz. 1 Si afecta al requerimiento la causa raíz.

Fig. 62 Colección de Datos VS Causas raíces

3.7.3.2.9 Prueba de normalidad

Se analizaron los resultados de la hoja de datos, verificando cada uno de los valores binarios asociados a los requerimientos que se analizaron.

Posteriormente se verifico que los datos obtenidos en las colecciones de datos sean normales (Ver Fig. 63).

La prueba de normalidad se realiza con la finalidad de saber que tipo de prueba de hipótesis se va a aplicar a las causas raíces en la fase de Analyze, ya que las pruebas de hipótesis dependen de si los datos son normales o no.

61

La prueba de normalidad se aplico con el programa de Minitab que es un programa usado para resolver problemas estadísticos.

Fig. 63 Prueba de Normalidad

3.7.3.2.10 Definición de Causas Espaciales

Cuando se realizo la prueba de normalidad de los datos (Ver Fig. 64), se observo que los dados del proceso no son estables, ya que hay dos requerimientos que están fuera de control, por lo que se investigo cuales fueron las causas que lo provocaron.


El PI número 242143 es una causa especial

ya que se creó en la red Softtek, cuando la

mejora se llevará a cabo la red de GE. El PI

se creó en una instancia equivocada.

El PI número 244835 también es una causa

especial porque la mejora se realizo sobre

un proceso organizacional. Los cambios a

procesos organizacionales requieren

múltiples aprobaciones.

62

Después de la prueba de Normalidad, se aplico una prueba de la estabilidad del proceso, en donde se observaron también los dos puntos que están fuera de control (Ver Fig. 65).

Fig. 65 Prueba de Estabilidad del Proceso

Posteriormente se aplico una prueba de Run Chart, para verificar los valores de Clustering, Mixtures, Trnes and Oscillation (Ver Fig. 66).

Fig. 66 Prueba de Run Chart

63

Como se encontraron causas especiales en el proceso, los valores que estaban fuera de control (Requerimientos 242143 y 244835), se sacaron de la colección de datos y se ejecutaron nuevamente la prueba de normalidad (Ver Fig. 67), de estabilidad del proceso (Ver Fig. 68) y el Run Chart (Ver Fig. 69).

A continuación se muestran los nuevos resultados de las pruebas:

Los datos siguen siendo no normales, pero ya no tienen puntos fuera de control.


La prueba de estabilidad del proceso, en esta nueva prueba los datos ya están mas unidos y ya no tiene valores fuera de control.

Fig. 67 Prueba de Estabilidad del proceso

64

En la prueba de Run chart, se observa que el proceso solamente tiene problemas de mezcla (Mixture).

Fig. 69 Prueba de Run Chart

3.7.3.2.11 Definición de la Capacidad del Proceso

Para medir la capacidad del proceso actual, se ejecuto una prueba llamada Process Capability of Analysis Time.

El proceso actual genera 312,286 defectos por un millón de oportunidades.

65

3.7.3.3 Analyze

En esta fase se analizaron los datos de la hoja de datos generada en la fase de Measure, cada una de las causas raíces será medida con la finalidad de descubrir estadísticamente, cuales de las causas afecta realmente el proceso.

En la fase de Analyze se realizaron las siguientes acciones:

• Pruebas de Hipótesis

• Lista de las causas raíces significantes (X’s)

3.7.3.3.1 Pruebas de Hipótesis

Se realizaron las pruebas de hipótesis para cada una de las causas raíces con la finalidad cual de ellas afecta realmente el proceso.

Todas las pruebas generan un valor de p-value27 que es el valor que determina si la causa raíz afecta o no al proceso que se desea mejorar.

El valor de p-value esta condicionado a los siguientes puntos:

• Si el valor del resultado de p-value en la prueba es menor a 0.05, la causa raíz evaluada realmente afecta el proceso, por lo que debe de ser controlada.

• Si el valor del resultado de p-value en la prueba es mayor a 0.05, la causa raíz evaluada no afecta el proceso, por lo que no debe de ser considerada.

Para ver las pruebas de hipótesis realizadas revisar el Anexo A.

27

P-Value es el valor de la probabilidad de error que se desea manejar en el proceso. Por estandarte p-value debe

ser menor o igual a 0.05.

66

3.7.3.3.2 Lista de las causas raíces significantes (X’s)

Una vez que fueron realizadas todas las pruebas de hipótesis, se realizo una tabla (Ver Fig. 70) indicando cuales de las causas raíces fueron significantes para el proceso (en donde el valor de p-value fue menor a 0.05).

Fig. 70 Lista de Causas raíces significantes

67

3.7.3.4 Improve

En esta fase, una vez que se determinan las causas raíces del problema en la fase de Análisis, se deben de encontrar soluciones nuevas y creativas y factibles de implementar.

En la fase de Improve se realizaron las siguientes acciones:

• Proponer y evaluar posibles soluciones

• Mapa del nuevo proceso

• Desarrollo del FMEA28

• Definicion de los limites y valores optimos para las causas raíces.

• Análisis Costo-Beneficio

• Implementación de las mejoras

3.7.3.4.1 Proponer y evaluar posibles soluciones

Para esta actividad se realizaron tres sesiones de dos horas cada una de ellas con el fin de proponer y evaluar soluciones para eliminar los efectos de las causas raíces en el proceso actual.

En estas sesiones el Champion y el LP seleccionaron de las soluciones propuestas por el equipo de PPM cuales eran las que se tenian que implementar, la selección se realizo en base a la factibilidad de cada una de ellas.

Posteriormente se realizo una lista de las soluciones (Ver Fig. 69) seleccionadas indicando el objetivo, las actividades a realizar, a que causa raíz afecta y a que objeto hay que aplicar cada una de las soluciones.

Existen siglas para identificar a que objeto se le van a aplicar los cambios. A continuación se aplicará cada una de ellas:

RT Request Type WF Workflow VF Validación PD Portlet Definition T Training

28

FMEA es el acrónimo de Failure Modes and Effects Analysis.

68

A continuacion se muestra la lista de las soluciones selecciones (Ver Fig. 71).

Report selec te d solutions

Imp rove X1

7.

Th

e u

se

r d

oes

no

t se

nd

the

nec

es

sa

ry i

nfo

rma

tio

n

X16

. T

he

an

ali

st

can

no

t

co

nta

ct

th

e u

se

r

X1.

La

ck

of

do

cu

men

tati

on

of

the o

bje

cts

X2

. L

ack

of

train

ing

X1

0.

Th

e P

I's

are

no

t

mo

nit

ori

ng

X5.

No

t th

is i

nd

icate

d t

he

tim

e

of

OT

R a

nd

An

aly

sis

in

th

e P

ís

A pply the change

R T

Categorizar los PI, de acuerdo a lo que se necesi ta .

Objetivo: Limitar desde la creac ión del PI la sol ic itud del so lcita nte de un

PI (No p ueda pedir en un so lo P I dos categorias de la d igitaliza ción) y g enerar

una idea al solic ita nte de l P I y al Ad minsitrado r de kintana d e lo que se req uiere

digitalizar.

Actividades : C atego rizar los PI's; Las categorias serán Digitaliza ción de

W F, Inte rfaces y Po rtlets.

X X

R T

Ge ne rar las v ersiones descargables en el not submmit de la informacion

que se requiere de acuerdo a la c ategorias.

Objetivo: El usuario defina y solicite lo que es necesario para su proyecto

y el adm ins itra dor vea de forma ma s clara lo que se e sta pid iend o digita lizar.

Actividades : Ge nerar las versione s descarga ble s d e los te mplates de las

categoria s m en cionad as.

X X X X X

R T and W F

Indicar e l tiempo de OTR y de Anal isis dentro de un campo en el PI

Obje tivo: Los adm in is tradores y solcitantes del PI cono zcan la fecha de

ven cimiento del OTR y el tie mpo de A nalis is .

Actividades: Gen erar dos camp os en el RT de l Req uest de PI, en donde

se indique la fecha de ven cimiento del OTR , así como la fecha de vencimiento del

Analisis respectivam ente .

X X X

VF a nd W F

Definir la metrica de OTR y Analisis considerando el horar io de servicio

que es de 9 am a 6.30 pm

Objetivo: M edir e l tiemp o real de trab ajo , basado en las regla s d e

negocio.

Activ idades: Generar una función que realice el calculo de tiem po rea l

tra bajado e n base a las reglas del negocio de fin idas.

Implem entar e sta funció n en el p ro ceo s d e lo s P I y e n el

portle t que va a se r generad o (El portlet tam bien es pa rte de las me joras)

X X X

PD

Ge ne rar un portlet que indique el vencimiento de OTR y de Analisis en los

Pi's

Obje tivo: Los adm in is tradores m onitoren de una manera efe ctiva los

re querim ientos que van a vencer.

Ac tividades: Gen erar un po rt let q ue indiq ue la fecha de vencim iento de l

OTR , así como la fecha de ven cimiento del Ana lisis. Yo propo ngo q ue el portlet

sea de tipo d e semaforos.

Carga r e l po rt let e n el Dashboa rd Pre-Conf igu ra do de

Segu im ien to de PI.

Pu bicar el dashbo ard a to dos los ad ministrado re s.

X X X X

T

Modificar las practica s de Softtek univ ersity(corregir las que es tan mal )

Obje tivo: Dar un entrenam iento a decuado y ap licab le al areá de traba jo a

las nue vas pe rsonas que se integ re n al equipo.

Ac tividades: Gen erar un nu evo ma terial de entrenam ie nto.

Utilizar los m anu ales prop orcionad os por Mercury.

Corregir las Practicas d e STK University (Portlets).

X X X

T

Ge ne rar un repositorio e n donde s e guarde la informacion.

Objetivo: Tene r toda la inform ación con ce ntrada.

Actividades : Definir en dond e se tend ra el rep ositorio, s i sera en una

carpe ta com partid a para todo e l eq uipo , si se ad jun tara a los request u na solu ción

detallad a en base un che ck lis t, o si se tendra un repo sitorio com o SourSa fe.

X X X X

T

Ge ne rar un proceso de atención para los pi's, cua ndo no obtenemos la

informacion nece saria .

Objetivo: Generar u n proceso estandar para solic itar inform ación al

usu ario.

+B6 Ac tividades: Defin ir en que pa rte del proceso se le va a solicitar la

info rm acio n al usuario , Si se le va a pedir cuando e l P I esta en New o cua ndo e sta

en Analizing o en am bos casos es factib le, Cuand o se prond ra en Ho ld el PI y

cua ndo se rea lizar un ca mbio de Prio ridad.

X X X

Action s

V ital X's

69

T

Generar un template con la informacion necesaria para generar un PI

Objetivo: Reducir el tiempo que se aplica para pedirle al usuario todos los

datos necesarios, para digitalizar un proceso, portlet o interfaz.

Actividades: Generar los templates para las categorias de digitalización.

Documentar como deben de ser llenados los templates

generados.

X X

T

Difundir el proceso de PI's para los administradores.

Objetivo: Los adminsitradores sigan el proceso establecido.

Actividades: Generar la docuementación de los cambios a procesos

organizacionales.

Generar la documentación del proceso de solicitud de mas

información al usuario.

X X X X

T

Generar una referencia (check list) de creacion de objetos mas comunes.

Objetivo: Los administradores conozcan la información que deben de

solicitar y conozcan como deben de crear los objetos.

Actividades: Publicar los estandares de ITG a todo el equipo de

adminsitradores.

Generar el checklist de objetos mas comunes

(validaciones, vistas de datos fijos, vistas de datos variables, procs, reglas, jobs,

etc.).

X X

T

Envio de Notificaciones cuando este por vencerse el tiempo de OTR(4 días)

y de Analisis. La notificacion seria para el LP y los analistas asignados al

GDC correspondiente.

Objetivo: Mejorar la atención de los PI.

Actividades: Generar las notificaciones que serán enviadas a los LP y

a los Analistas.

Generar el timeout en el proceso para que las

notificaciones se envien en el plazo definido.

Definir el tiempo de envio de la notif icación.

X X X

Fig. 71 Soluciones seleccionadas

3.7.3.4.2 Mapa del nuevo proceso

Las soluciones que se propusieron no afectaron el proceso de PI. Las soluciones se enfocaron a generar documentación para el proceso (Ver Fig. 72).

Fig. 72 Mapa de Proceso

70

3.7.3.4.3 Desarrollo del FMEA

El factor a evaluar en el FMEA es el RPN29 (Ver Fig. 73) que es el producto de la severidad, la probabilidad de ocurrencia y la detectabilidad del error.

RPN = Sev * OCC * DET

Efectos Causas Controles

Fig. 73 RPN

En el FMEA se evalua el modo de falla y los efectos que puede tener cada una de las soluciones para las causas raíces (Ver Fig. 74) con el fin de conocer el RPN.

Process StepKey Process

InputPotential Failure Mode Potential Failure Effects

S

E

V

Potential Causes

O

C

C

Current Controls

D

E

T

R

P

N

What is the process step What is the Key

Process Input?

In what ways does the Key

Input go wrong?

What is the impact on the Key

Output Variables (Customer

Requirements) or internal requirements?

How

Severe

is

the

effe

ct t

o the

cuso

tmer? What causes the Key Input to

go wrong?

How

often d

oes c

ause

or

FM

occur? What are the existing controls and

procedures (inspection and test)

that prevent eith the cause or the Failure Mode?

How

we

ll ca

n y

ou

dete

ct cau

se o

r F

M?

X5, X10, X16 Indicar el tiempo

de OTR dentro

de un campo en

el pi

Los administradores no le

den seguimiento.

La metrica no se cumple.

10

Exceso de trabajo.

7

División del trabajo por GDC's

1 70

X5, X10, X16 Indicar el tiempo

de OTR dentro

de un campo en

el pi


den seguimiento.


10

Exceso de trabajo.

7

Envio de Notificaciones cuando

este por vencerse el tiempo de

OTR. La notificacion seria para el

LP y los analistas asignados al

GDC correspondiente.

3 210

X1, X5, X10, X17 Generar un

portlet que

indique el

vencimiento de

los Pi's


den seguimiento.


10

El porltet no este cargado en el

dashboard de seguimiento de

PI's1

Ninguno.

1 10


portlet que

indique el

vencimiento de

los Pi's

Los administradores no

entiendan la información

arrojada por el portlet .


9

El portlet no muestre el tiempo

de OTR y de Analisis

2

Ninguno.

5 90


portlet que indique el

vencimiento de

los Pi's


entiendan la información arrojada por el portlet .


10

No explicarles el

funcionamiento del portlet

5

Ninguno.

5 250

X1,X2,X17 Modificar las

practicas de STK

University

(corregir las que

estén erroneas)

Los nuevos integrantes

encuentren las practicas

confusas

No se adquiera el

conocimiento

9

No tener un plan de estudio el

cual seguir.

5

Material de Autoevalución por

temas

5 225


practicas de STK University

(corregir las que

estén erroneas)

Los nuevos integrantes

encuentren las practicas confusas

La practica no se realice con

el estandart7

No se le realice un PR al

material generado.5 9 315


practicas de STK

University

(corregir las que

estén erroneas)

No se les habilite el curso a

las nuevas personas que se

van a integrar al equipo

No sea utilizado.

9

Generar un material de solo

lectura, que no contenga

ejercicios practicos y

aterrizados a las necesidades

del servicio que se brinda.

3

Material de Autoevalución por

temas

6 162

X1,X2,X17 Entrenamiento

de SQL

El material generado, sea

general y no indique como

aplicarlo en ITG

No sea utilizado.

8

El material generado sea

general y no tenga las

excepciones y restricciones que

se manejan en ITG.

8

Examén de SQL a los candidatos

que se pretende sean miembros

del equipo.2 128

X1,X2,X17 Entrenamiento de SQL

El material no sea distribuido a todos los

administradores

No sea utilizado.

8

No existe un proceso de KT, por medio del cual se de el material

y conocimiento. 8

Ninguno.

7 448

29

RPN es el acrónimo de Risk Priority Number

71

X10, X16, X17 Acordar como

vamos a seguir el

proceso, cuando

el usuario no

envia la

información

completa

(Tiempos de

Acknowledge y

need more info)

El proceso no sea seguido

de la misma forma por

todos los administradores.

Las metricas no sean

consistentes.

10

No existe un proceso de KT, por

medio del cual se de el material

y conocimiento.

7

Ninguno.

9 630

X10, X16, X17 Acordar como

vamos a seguir el

proceso, cuando el usuario no

envia la

información

completa

(Tiempos de

Acknowledge y

need more info)

No sea distribuido el

proceso a todos los

administradores

Los PI's sean atendidos de

diferente manera y esto

genere confucion a los solicitante del PI.

8



y conocimiento.

7

Ninguno.

9 504

X10, X17 Generar un

template con la

información

necesaria para

generar cada tipo

de PI

No sea distribuido el

proceso a todos los

administradores

No sea utilizado

7



y conocimiento.7

Ninguno.

8 392

X10, X17 Generar un template con la

información

necesaria para

generar cada tipo

de PI

El template no sea claro tanto para los

administradores como para

los solicitantes del PI

No se le solicite toda la información necesaria la

usuario y dar espacio a las

supociciones de lo que

requiere el solcitante del PI

8

No se le realice un PR al material generado.

5

Templete para la creación de nuevos flujos de tipo AMS

1 40

X10, X17 Generar un

template con la

información

necesaria para

generar cada tipo

de PI

El template no sea claro

tanto para los

administradores como para

los solicitantes del PI

El solcitante del PI no sepa

como debe de llenar el

template con la información

de su proyecto.8

No incluir notas acerca de cómo

debe ser llenado cada uno de

los campos de l template8

Ninguno.

1 64

X10,X17 Categorizar los

PI's.

El solcitante del PI, cree el

PI en la categoria equivocada.

El solicitante del PI no sepa

cual elegir de acuerdo a sus necesidades.

8

No existan guias sobre la

clasificacion de los PI 's 3

Ninguno.

1 24

X1,X2,X10, X16,X17 Generar la

version

descargable de

los templates de

acuerdo a las

categorias.

El solcitante del PI no

revise los templates

El usuario no envie la

infromación necesaria

9

No se ponga como requerido el

template al momento de crear

el PI.5

Ninguno.

7 315

X1,X10,X16 Publicar el

proceso de

atención para la

modificacion de

procesos

organizacionales.


conoscan el proceso

No se atiendas todos los PI

organizacionales de la misma

forma y que generen

confusion en los usuarios 9



y conocimiento.

7

Ninguno.

7 441

X1,X10,X16 Publicar el

proceso de

atención para la

modificacion de

procesos

organizacionales.


sigan el proceso

Las mejoras no se vean

reflejados en todos lados

(Especificamente en ambas

redes) o no se pida la

aprobación a la persona

dueña de el proceso

organizacional

10



y conocimiento.

7

Ninguno.

5 350

X2, X17 Generar un

checklist de

creacion de los

objetos mas

comunes

El checklist no sea claro

para los administradores.

No sea utilizado.

9

No se le realice un PR al

material generado.

5

Ninguno.

2 90

X2, X17 Generar un

checklist de

creacion de los

objetos mas

comunes

No sea distribuido a todos

los administradores

No sea utilizado.

9



y conocimiento. 7

Ninguno.

4 252

X5, X10, X17 Def inir la metrica

de OTR y

Analisis

considerando el

horario de

servicio que es

de 9 am a 6.30

pm

La metricas sea definida de

forma incorrecta, no

tomando en cuenta la regla

del Negocio.

No se cumpla con la metrica.

10

La regla de negocio no este

definida de forma correcta.

3

Ninguno.

7 210

X10,X16, X17 Envio de

Notificaciones

cuando este por

vencerse el

tiempo de OTR(4 días) y de

Analisis. La

notificacion seria

para el LP y los

analistas

asignados al

GDC

correspondiente.

El timeOut de la notificacion

no se cumpla.

La notificación no sea

enviada.

8

El timeOut este definido de

forma incorrecta

4

Ninguno.

1 32

Fig. 74 FMEA

72

3.7.3.4.4 Definicion de los limites y valores optimos para las causas raíces.

El Champion y el LP definen los valores limites superiores e inferiores y el valor objetivo (Ver Fig. 75) que debe de tener cada una de las causas raíces.

Fig. 75 Limites y valor objetivo

3.7.3.4.5 Implementación de las mejoras

Para la implementación de mejoras (Ver Fig. 76) se llevo a cabo una sesión de dos horas en donde se explicaron las mejoras a implementar (soluciones seleccionadas); se busco el apoyo del equipo de trabajo para realizar las mejoras y una vez que las mejoras fueron asignadas a miembros del equipo, se establecieron fechas de inicio y termino de acuerdo a la disponibilidad de tiempo de las personas asignadas. Category Activity Responsible Start Date Finish Date # of Requirement

RT

Categorizar los PI, de acuerdo a lo que se necesita.

Objetivo: Limitar desde la creación del PI la solicitud del solcitante

de un PI (No pueda pedir en un solo PI dos categorias de la digitalización)

y generar una idea al solicitante del PI y al Adminsitrador de kintana de lo

que se requiere digitalizar.

Actividades: Categorizar los PI's; Las categorias serán

Digitalización de WF, Interfaces y Portlets.

Christian

Hernandez(STK)) /

Pablo Hernandez

(GE)

26/07/2008 12/08/2008 386016

RT

Generar las versiones descargables en el not submmit de la

informacion que se requiere de acuerdo a la categorias.

Objetivo: El usuario def ina y solicite lo que es necesario para su

proyecto y el adminsitrador vea de forma mas clara lo que se esta

pidiendo digitalizar.

Actividades: Generar las versiones descargables de los templates

de las categorias mencionadas.

Christian

Hernandez(STK)) /

Pablo Hernandez

(GE)

26/07/2008 12/08/2008 386016

RT and WF

Indicar el tiempo de OTR y de Analisis dentro de un campo en el PI

Objetivo: Los administradores y solcitantes del PI conozcan la

fecha de vencimiento del OTR y el tiempo de Analisis.

Actividades: Generar dos campos en el RT del Request de PI, en

donde se indique la fecha de vencimiento del OTR, así como la fecha de

vencimiento del Analisis respectivamente.

Christian

Hernandez(STK)) /

Pablo Hernandez

(GE)

26/07/2008 12/08/2008 386016

73

VF and WF

Definir la metrica de OTR y Analisis considerando el horario de

servicio que es de 9 am a 6.30 pm

Objetivo: Medir el tiempo real de trabajo, basado en las reglas

de negocio.

Actividades: Generar una función que realice el calculo de

tiempo real trabajado en base a las reglas del negocio definidas.

Implementar esta función en el proceos de los PI y

en el portlet que va a ser generado (El portlet tambien es parte de las

mejoras)

Christian

Hernandez(STK)) /

Pablo Hernandez

(GE)

26/07/2008 12/08/2008 386016

PD

Generar un portlet que indique el vencimiento de OTR y de Analisis

en los Pi's

Objetivo: Los administradores monitoren de una manera efectiva

los requerimientos que van a vencer.

Actividades: Generar un portlet que indique la fecha de

vencimiento del OTR, así como la fecha de vencimiento del Analisis. Yo

propongo que el portlet sea de tipo de semaforos.

Cargar el portlet en el Dashboard Pre-Configurado de

Seguimiento de PI.

Pubicar el dashboard a todos los administradores.

Efren Ruiz

12/08/2008 26/08/2008 386017

T

Modificar las practicas de Softtek university(corregir las que estan

mal )

Objetivo: Dar un entrenamiento adecuado y aplicable al areá de

trabajo a las nuevas personas que se integren al equipo.

Actividades: Generar un nuevo material de entrenamiento.

Utilizar los manuales proporcionados por Mercury.

Corregir las Practicas de STK University (Portlets).

Ricardo Alvarado

09/07/2008 23/07/2008 385935

T

Entrenamiento en SQL

Objetivo: Los administradores, puedan entender, crear y resolver

cualquier problema presentado en un portlet, vista, proc, job.

Actividades: Generar un entrenamiento general de SQL.

Enseñar a los administradores a aplicar el conocimiento

generico de SQL que se tiene a ITG (Incluyendo las limitaciones

conocidas).

Ana Fernandez/Jose

Alvarado / Gerardo

Gonzalez

09/07/2008 15/08/2008 385937

RT y T

Generar un repositorio en donde se guarde la informacion.

Objetivo: Tener toda la información concentrada.

Actividades: Definir en donde se tendra el repositorio, si sera en

una carpeta compartida para todo el equipo, si se adjuntara a los request

una solución detallada en base un check list, o si se tendra un repositorio

como SourSafe. Solución Generar un campo de tipo Attachment en donde

podamos agregar la solucion del problema conforme a un template

establecido.

Gerardo Gonzalez

11/07/2008 21/07/2008 385939

T

Generar un proceso de atención para los pi's, cuando no obtenemos

la informacion necesaria.

Objetivo: Generar un proceso estandar para solicitar información

al usuario.

Actividades: Definir en que parte del proceso se le va a solicitar la

informacion al usuario, Si se le va apedir cuando el PI esta en New o

cuando esta en Analizing o en ambos casos es factible, Cuando se

prondra en Hold el PI y cuando se realizar un cambio de Prioridad.

Yessica Pérez

11/07/2008 15/07/2008 385939

T

Generar un template con la informacion necesaria para generar un PI

Objetivo: Reducir el tiempo que se aplica para pedirle al usuario

todos los datos necesarios, para digitalizar un proceso, port let o interfaz.

Actividades: Generar los templates para las categorias de

digitalización.

Documentar como deben de ser llenados los

templates generados.

Sandra

Sanchez/Marco

Jauregui

21-Jul-08 31-Jul-08 385940

T

Publicar la informacion de cambios a procesos organizacionales.

Objetivo: Los administradores sepan como tratar la modificación a

un Proceso Organizacional.

Actividades: Definir los aprobadores que aceptaran o rechazaran

la modificacion para cada proceso organizacional.

Definir que procesos estan en ambas redes (STK y

GE).

Definir que procesos se atenderán en un GDC en

particular.

Gerardo Gonzalez

21/07/2008 15/08/2008 386011

Fig. 76 Plan de implementacion

Una vez que las mejoras son terminadas pasan a revision de LP y el Champion, si las mejoras cumplen con el objetivo pasan al ambiente productivo, si las mejoras desarrollasdas no cumplen don el objetivo se hacen las correcciones pertinentes para poder ser enviadas al ambiente productivo.

74

3.7.3.5 Control

En esta fase, una vez que se implementaron todas las mejoras, se verifica que el proceso tenga un menor numero de DPMO’s y se halla cumplido con el objetivo definido en el Project Charter.

En la fase de Control se realizaron las siguientes acciones:

• Confirmación estaditica

• Plan de control 3.7.3.5.1 Confirmación Estadística

Se realiza una prueba de hipótesis para comprar si las mejoras aplicadas redujeron el número de DMPO’s del proceso (Ver Fig. 77).

La prueba de hipótesis fue la siguiente: Ho: El # de defectos de OTA antes de las mejoras es < A El # de defectos de OTA después de las mejoras

Fig. 77 Hipótesis de mejoras implementadas

75

3.7.3.5.2 Plan de control

Una vez que se verifico que las mejoras implementadas funcionaron adecuadamente, se realiza un plan de control (Ver

Fig. 78), indicando los pasos que se tienen que realizar para que el proceso siga en control.

KPOV K PIV

x

x

x

x

x

x

x

Analis ta

Lide r

PL rev iew th e m etric whit thei

te am, if t he OTA is lea st t han

95 %, the PL will co nvo ca te a

m eeting to review be cau se thno t being rea che d the minim a

OTA


te am, if t he OTR is least tha n


m eeting to review be cau se th

no t being rea che d the minim a

OTR

SLA (OT A) SL A rev iew SL A reviewed by PL 9 5% - 100%Review P ortlet of O TA (On t im e An alisys -

Step Ana liz ing )

Every PI Dai ly

Review P ortlet of O TR

(On t im e Respon se -

Step New)

Every PI W eekly PLSLA (OT R) SL A rev iew SL A reviewed by PL 9 5% - 100%

If ch ecklis t fo r e ach object is

com ple ted a nd PI ful fil ls its

function ali ty th en app ro ve the

P I, in ca se it f ails som e o f the

previo us points se nt to rewo rk

Ob ject's Do cum entatio n O bjects

docum entation

Obje cts ' d ocume ntation

gen erated (V iew,Fu nc,

Procs, Trigg ers)

10 0% of

docum enta tion

checklist

Ob ject do cu men tation

Checklis t Every Ob jectject is ge nerate

PLReview th e Dashbo ard

cal le d 'PI Traking'

Every

resourceE very 4 days

Peer

Reviewer

PL rev iew th e work lo ad of th

te am. If the PL detects that th

work load for an an alist is

grather than othe r, PL shou ld

ask to the an alist with a lowe r

work load supp ort to d is tribut

th e service load .


te am, if t he OTA is lea st t han




OTA

W ork lo ad (G loba l)W ork load

Rev ie wW ork lo ad rev iewe d by PL

1 P I assigned - 3

PI a ss ig ned

Review P ortlet of O TA

(On t im e An alisys -

Step Ana liz ing )

Every PI W eekly PLSLA (OT A) SL A rev iew SL A reviewed by PL 9 5% - 100%

Analis ta

Lide r


te am, if t he OTR is least tha n




OTR

M ain analyst of t he GDC will

en ro ll new resource to the

correspond ing t ra ining

SLA (OT R) SL A rev iew SL A reviewed by PL 9 5% - 100%

Review P ortlet of O TR

(On t im e Respon se -

Step New)

Every PI Dai ly

% Com pleted of Control

Check Lis t

Every

resourceMon thly

Main

analyst of

the G DC

Training Taking trainingTrain ing taken everytime

there's a new te am mem ber9 0% - 100%

W ho

MeasuresDecision Rule/ Correct ive Acti

Specification/

Requiremen t M easuremen t Meth od Sample Size Frequency

USL L SL

Sub ProcessSu b Process

Step

CT QSpecificatio n Characteristic

Fig. 78 Plan de Control

76

Conclusiones

La experiencia laboral que he obtenido durante los tres años y medio que he trabajado en Softtek, me ha permitido obtener varios triunfos a lo largo de mi carrera, los dos principales fueron: certificarme como Green Belt y obtener una certificación Técnica de PPM

Sin duda, estos logros no los hubiera alcanzado, si no hubiera contado con la excelente educación académica que brinda el Instituto Politécnico Nacional a través de sus centros de educación, en mi caso personal UPIICSA.

En este sentido creo que la educación y formación que recibí en UPIICSA, me dio las bases para poder trabajar en cualquier empresa y desempeñar un papel sobresaliente en el rol que desempeñara.

La conclusión final de mi experiencia profesional se resume en dos necesidades cubiertas por los dos proyectos en los que he laborado en Softtek:

• Resolver las necesidades de uno o varios clientes.

• Ayudar a las personas a mejorar su calidad de vida.

77

Bibliografía

Softtek University http://capabilities.softtek.com/Bienvenida.aspx

American Society for Quality http://www.asq.org

Process Improvements http://h20507.www2.hp.com/Saba/Web/Main

78

Anexo A X1: El tiempo de análisis es independiente de la falta de documentación de los

objetos generados.

X2: El tiempo de análisis es independiente de la falta de entrenamiento.

79

X3: El tiempo de análisis es independiente de la centralización del conocimiento.

X4: El tiempo de análisis es independiente de la distribución de PI’s.

80

X5: El tiempo de análisis es independiente de si el tiempo de OTR y OTA están indicados en el PI.

X6: El tiempo de análisis es independiente de no contar con un repositorio.

81

X7: El tiempo de análisis es independiente de si hay actividades definidas, tanto para analistas y desarrolladores.

X8: El tiempo de análisis es independiente de las revisiones periódicas de

métricas.

82

X9: El tiempo de análisis es independiente del perfil del analista.

X10: El tiempo de análisis es independiente del monitoreo de PI’s.

83

X11: El tiempo de análisis es independiente de la división del trabajo.

X12: El tiempo de análisis es independiente de la información dada por los solicitantes de PI’s.

84

X13: El tiempo de análisis es independiente del aprobador del PI.

X14: El tiempo de análisis es independiente del dueño del proceso.

85

X15: El tiempo de análisis es independiente del lenguaje.

X16: El tiempo de análisis es independiente del contacto que tenga el analista con

el solicitante del PI.

86

X17: El tiempo de análisis es independiente de la información dada después de la creación del PI.

X18: El tiempo de análisis es independiente de la división del trabajo.

87

X19: El tiempo de análisis es independiente del tiempo de aprobación..

X21: El tiempo de análisis es independiente de la carga de trabajo.

88

X21: El tiempo de análisis es independiente de la diferencia de horarios.

“P R O Y E C T O S E N S O F T T E K” -...

Documents

Transcript of “P R O Y E C T O S E N S O F T T E K” -...