Application Six Sigma Methodology Financial Process - En.es PDF

La aplicación de la metodología Seis Sigma DMAIC a un proceso financiero Pág.
Resumen (Español)
En Esta memoria se describen las Naciones Unidas Proyecto Seis Sigma Realizado párr El Negocio de HP BPO. Mas en
concreto para el Proceso Financiero de rembolso de Gastos de Viaje de Empleados de HP en la región de EMEA (Proceso de T
& E-EMEA).
El objetivo m of this Proyecto época Ayudar al Proceso de T & E Alcanzar una SUS Objetivos para el año fiscal 06
establecidos en la “T & E FY06 cuadro de mando integral”. En particular, el Proyecto pretendía impactar Directamente al área
financiera de la “cuadro de mando” aportando UNOS Ahorros Anuales de al Menos $ 8600 / año y al área de cliente
aportando Una Reducción de escalaciones de Clientes y Aumento de la ONU en el índice de Satisfacción del Cliente
(puntuación de COV ).
Este Proyecto se Realizo SIGUIENDO la Metodología Seis Sigma DMAIC: “Definir, Medir, Analizar, Mejorar y Controlar”.
Previamente a la Realización del Proyecto Todos Los particantes recibieron la Formación Necesaria En un curso de
“Cinturón Verde” impartido internamente en HP BPO. La memoria describen detalladamente Los Pasos seguidos En Cada
Una de las fases pudiendo asi servir al lector de Como modelo para la Realización de Proyecto Seis Sigma Otro DMAIC.
Los Resultados obtenidos en el Proyecto descrito en memoria this were Superiores una previsos inicialmente los Alcanzando
Una Reducción de Defectos del 79%, ahorro anual de la ONU superiores a Los $ 13000 / Anuales y Una Reducción de
escalaciones de cliente del 79%. La cuantificación del impact of this Proyecto En El Aumento del índice de Satisfacción del
Cliente (puntuación COV) Queda Fuera de this memoria.
Finalmente this memoria Presenta Una serie de reflexiones about La metodologia / cultura Seis Sigma. Por un Lado sí
Presentan Tres Razones Que Hacen de Seis Sigma Una cultura util para un negocio: Provee al Negocio con Una
Herramienta para cuantificar las Mejoras Realizadas en los Procesos, Mejora la Relación con el Cliente al atacar los
Defectos y crea Una Mentalidad de Mejora continua y compromiso en todos los Niveles de la Empresa. Por Otro Lado sí
Presentan Factores Críticos para Alcanzar una Implementación satisfactoria de la Cultura Seis Sigma en Negocio de la ONU:
el Compromiso de los Directivos y el rol motivador (de Lider) de los Cinturones Negros (BB), Master Black Belts (MBB).
Pág. 2 Memoria
La aplicación de la metodología Seis Sigma DMAIC a un proceso financiero Pág. 3
Índice
RESUMEN (ESPAÑOL) _________________________________________1 ÍNDICE
_______________________________________________________3
1. ______________________________________________5 GLOSARIO
2. ANTECEDENTES DEL PROYECTO __________________________________7
2.1. Introducción a HP BPO .............................................. ...................................... 7

2.2. Introdction al proceso de T & E ............................................. .......................... 10
2.3. Justificacion de proyecto ................................................ ........................................ 11
2.3.1. El uso de un cuadro de mando integral ............................................. ................................ 11
2.3.2. La vinculación del proyecto con el Proceso de T & E Cuadro de mando integral ............................. 11
3. INTRODUCTION__________________________________________13
4. DEFINIR FASE __________________________________________15

4.1. Objetivos y salidas ............................................... ........................................... 15
4.2. El desarrollo de la carta del proyecto .............................................. ......................... 15
5. PHASE________________________________________22 MEDIDA
5.1. Meta y los productos ............................................... ............................................. 22
5.2. ¿Por qué medir? .................................................. .......................................... 22

5.3. Qué medir? .............................................. ............................................ 22
5.4. ¿Cómo medir?.............................................. ............................................. 24
5.5. rendimiento de los procesos de medición de resultados actual ..................................... 25
6. ANALIZAR FASE ________________________________________26

6.2. Identificar los diferentes segmentos para el análisis individual ......................................... 26
6.3. Análisis para el segmento A- Entidad 88, Suecia ......................................... .......... 27

6.3.1. Razones para el rechazo dadas por Citibank ............................................ .................. 27
6.3.2. normas para la comprensión de las cuentas bancarias suecas ....................................... 28
6.3.3. La identificación de posibles causas fundamentales .............................................. ............................ 31
6.3.4. Estrecha a las causas fundamentales ............................................. ...................................... 34
6.4. Análisis para el segmento B-82 Entidad, Italia ......................................... ................ 35
6.4.1. Razones para el rechazo dadas por Citibank ............................................ .................. 35
6.4.2. normas para la comprensión de las cuentas bancarias italianas ........................................... 36
6.4.3. La identificación de posibles causas fundamentales .............................................. ............................ 37
6.4.4. Estrecha a las causas fundamentales ............................................. ...................................... 40

Pág. 4 Memoria
6.5. Análisis de Entidades segmento C- 91 (Finlandia), F9 (España) y 63 (Francia) .. 41
7. MEJORAR LA FASE ________________________________________42

7.2. Implementación de acciones correctivas .............................................. .............. 42
7.3. Implementación de acciones preventivas .............................................. .............. 44

7.3.1. -acciones preventivas especial solución para el segmento A, Suecia ......................... 44
7.3.2. acciones preventivas solución estándar (Segmento B Segmento C +) ...................... 47
7.3.3. Preventivas acciones-apalancamiento de la solución general para el resto de entidades ....... 50
7.4. resultados de mejora: “antes” y “después” de datos ....................................... ...... 50
8. CONTROL DE PHASE________________________________________52
8.2. Los mecanismos de control para asegurar la coherencia de los resultados .................................. 52
8.3. Proyecto beneficia a la cuantificación ............................................... ......................... 53
8.3.1. BPO clientes internos: T & E en equipo y equipo de banca. .................................... 53
8.3.2. clientes de BPO externa: los empleados de HP ............................................ ............... 53
8.4. aprendizajes y recomendaciones del sistema .............................................. ........ 54
CONCLUSIONES ______________________________________________55
BIBLIOGRAPHY______________________________________________57
Las referencias bibliográficas ................................................ .......................................... 57
1. Glosario
• T & E: Viajes y entretenimiento
• EMEA: Europa, Meddle Oriente y África.
• TRAMS: solicitud de reembolso utilizada por HP.
• VOC: Voz del cliente.
• CTQ: críticos para la calidad.
• TER: Viaje informe de gastos.
• BPO: externalización de procesos de negocio.
• DPMO: Los defectos por millón de oportunidades.
• DPU: defectos por unidad.
• DPO: Defectos por oportunidad.
• DMAIC: Definir, Medir, Analizar, Mejorar y Controlar.
• GHRMS: Base de datos global de los recursos humanos.
• SIPOC: Proveedores, entradas, procesos y salidas.

2. Antecedentes del Proyecto
2.1. Introducción a HP BPO
mundo de los negocios de hoy está marcado por el cambio, la complejidad y la necesidad de adaptarse rápidamente a las
nuevas demandas del mercado sin perder el impulso en los objetivos estratégicos. Las compañías exitosas crean
organizaciones ligeras que se centran en sus competencias básicas y externalizan o pareja para actividades que no son
estratégicamente crítico y no es esencial para la diferenciación de la empresa. Por lo general estas actividades incluyen los
puntos transaccionales y tácticos de finanzas y contabilidad, recursos humanos, compras y ventas y comercialización.
En particular, las empresas buscan Business Process Outsourcing (BPO) a:
• atención de la dirección de enfoque en las cuestiones estratégicas en lugar de bajo valor agregan actividades transaccionales.
• Reducir los costos operativos por la externalización de los proveedores de servicios que pueden tomar ventaja de arbitraje laboral,
mejores sistemas de TI y una mejor escala.
• Mejorar los controles financieros y cumplimiento de la normativa.
• Aumentar la velocidad y la calidad de los procesos de negocio, aprovechando la experiencia de un proveedor, las mejores prácticas
y la mejora continua de la calidad.
• Aumentar la flexibilidad operativa y minimizar el uso de capital.
• Enriquecer los procesos con tecnología y herramientas modernas.
• Aumentar la transparencia de las operaciones.
La externalización de actividades no esenciales libera capital, la gente y la tecnología, lo que permite a las empresas a
concentrarse en su negocio principal y aumentar la rapidez de las operaciones. A menudo, el ahorro de costes de hasta el
50 por ciento se puede lograr al mismo tiempo mejorar la calidad de los procesos. Con BPO, una empresa puede convertirse
en una Empresa Adaptable más delgado.
Muchas empresas líderes en la industria como Procter & Gamble, Nokia, Ford y Aventis han comenzado a externalizar parte
de sus operaciones. Aquellas empresas que no reconocen el nuevo imperativo del negocio de centrarse en lo que es el núcleo
de su negocio y la externalización del riesgo de las actividades no básicas están quedando atrás en la carrera para aumentar
la competitividad.
Pág. 8 Memoria
Participar en externalización de procesos empresariales es un reto importante transformación para cualquier organización. Se
requiere de un socio que entienda los requisitos de negocio, que tiene experiencia en los procesos a los niveles de rendimiento
de clase mundial y que tiene la flexibilidad para responder a las necesidades específicas de gestión.
HP ha sido calificada por la consultora de outsourcing EquaTerra como el primero de BPO proveedor de una empresa capaz de
gestionar con eficacia los servicios complejos a largo plazo. Pocos jugadores en el mercado hoy en día pueden proporcionar el nivel
de excelencia en los procesos, la profundidad de la experiencia de la externalización y la experiencia en TI de clase mundial que HP
pone en el mercado en su oferta de servicios de BPO. HP tiene más de 15 años de experiencia en la creación de soluciones de
back-office operacionales superiores. Con los años, ha mejorado continuamente y profesionalizado sus capacidades de proceso y ha
invertido en tecnologías facilitadoras de vanguardia.
Hoy en día, HP es una de las seis principales proveedores de servicios de externalización del mundo. HP proporciona consejos y
soluciones profesionales a sus clientes en todos los niveles de sus operaciones, de los procesos de negocio de la infraestructura
tecnológica. Mediante la combinación de su experiencia en torno a la infraestructura, aplicaciones y procesos, HP es capaz de
proporcionar soluciones de negocio integradas y efectivas que son robustos y fiables y que generan impacto en los resultados
inmediatos.
HP ofrece servicios de extremo a extremo de negocios, consejos de consultoría, la transformación, la transición, servicios web y la mejora
continua. HP pretende ser un socio de negocios en todas las cuestiones relacionadas con la optimización de las operaciones comerciales a
través de la contratación externa.
En el núcleo de nuestra oferta de BPO de HP ofrece los siguientes servicios a las empresas, ya sea en parte o en su totalidad:
Finanzas y Contabilidad es decir, cuentas por pagar, cuentas por cobrar, el tiempo y la administración de gastos, gestión de
activos fijos, en general libro de contabilidad, contabilidad de proyectos, y
la presentación de informes.
Solicitar a efectivo apoyo CRM administración -Customer, procesamiento de pedidos, análisis de crédito y aprobaciones, la facturación
y la facturación.
servicios de ciclo de ingresos-pedido hasta el cobro -INGRESOS, colecciones, resolución de conflictos, la aplicación de efectivo, la reconciliación y la
presentación de informes.
Procurar a pagar apoyo a las adquisiciones administración -supplier, procesamiento de PO, la administración P-tarjeta.
Procurar a pagar los servicios de pago -Cuentas por pagar, procesamiento de facturas, PO coinciden, devuelve crédito.
HP supera consistentemente parámetros de la industria de clase mundial en la eficiencia del proceso y aprovecha su posición
como líder del sector en soluciones de imagen e impresión y de flujo de trabajo. dedicado equipo de calidad de HP utiliza
metodologías Six Sigma para mejorar continuamente su desempeño del proceso. HP emplea a más de Seis Sigma expertos
entrenados que cualquier otro proveedor, a excepción de GE y Wipro. G Global B usinessServices
HP cuenta con una de las organizaciones de prestación de servicios globales más fuertes del mundo. Con Global Business
Centers en la India, China, Singapur, México, Costa Rica y España, y con más de 4.500 expertos en procesos en todo el
mundo, HP puede de manera rentable y fiable proporcionar servicios donde el cliente los necesita, cuando les-en torno a las
necesidades del mundo , 24 horas al dia.
Centros de Negocios Globales de HP se ve apoyada por las operaciones locales en más de 50 países, proporcionando al
cliente con una red que ya están construidos para una futura expansión. Dada la presencia global de HP, su personal
capacitado puede apoyar las operaciones comerciales en más de 30 idiomas. Sólo el año pasado, HP procesa más de 130
millones de transacciones para clientes en todo el mundo.
modelo de negocio de HP ha sido diseñado para una rápida escalabilidad y robustez. Hoy en día, HP puede ampliar las operaciones con
varios cientos de empleados adicionales cada semana cuando las operaciones de los clientes lo requieren. Mientras tanto, el modelo de
entrega global de HP reduce al mínimo el riesgo de tiempo de inactividad debido a las perturbaciones locales. HP puede cambiar
rápidamente las operaciones para ayudar al cliente a lograr la continuidad de negocio más alto. En resumen, HP cuenta con la cobertura
global y la capacidad para satisfacer las necesidades del cliente y responder rápidamente a los cambios en el alcance y la escala de las
operaciones.
Pág. 10 Memoria
2.2. Introdction al proceso de T & E
El proceso de T & E en uno de los múltiples procesos estándar de HP BPO cartera de soluciones.
El proceso de T & E es el proceso financiero diseñado para gestionar los gastos de viaje y representación de negocios de
todos los empleados. Actualmente varias empresas han adoptado la solución descrita en las siguientes líneas:
Todos los empleados de la empresa tienen una tarjeta corporativa vinculada a su cuenta personal. Hay dos características que
hacen de esta tarjeta diferente a una tarjeta de crédito estándar:
• Todos los gastos incurridos con esta tarjeta, son cargados directamente a la cuenta bancaria personal del empleado
dos meses después de la fecha de gastos.
• No hay un límite de crédito de estas tarjetas. En caso de que el empleado no está respondiendo a los gastos de la
empresa será responsable.
Cuando un empleado está viajando él debe pagar todos sus gastos con esta tarjeta. Al final del viaje, o durante el viaje, si se
desea, el empleado debe informar a la empresa todos los gastos pagados con la tarjeta corporativa. Entonces, la empresa
verificará que todos los gastos reportados están dentro de la política de viajes de la empresa. Si todo está bien en este
cheque al empleado se le reembolsará la cantidad reportada. Normalmente este proceso de facturación y reembolso no
toma más de 6 días de trabajo por lo que el reembolso se realiza antes de la carga de los gastos por la tarjeta de la empresa
(dos meses después de la fecha de gastos). En caso de que los gastos no están dentro de la política, que no son
reembolsados al empleado lo que resulta en un saldo negativo para él cuando la tarjeta corporativa cobra los gastos.
Si esta solución se implementa es crítico asegurar un procesamiento de cheques y reembolso lisa de modo es reembolsado
el empleado antes de los gastos se imputan en su cuenta personal. Este proyecto descrito en este documento tiene como
objetivo mejorar la suavidad del proceso de reembolso tal como se aplica para la región EMEA de HP.
2.3. Justificacion de proyecto
2.3.1. El uso de un cuadro de mando integral
Cada año fiscal alta dirección establece los objetivos estratégicos para el centro de servicios de Acciones Barcelona en el Barcelona
Centre cuadro de mando integral. Este cuadro de mando contiene cuatro tipos diferentes de objetivos: los objetivos
financieros, los objetivos de excelencia operativa, objetivos de clientes y objetivos de innovación.
Con el fin de alcanzar los objetivos del centro de las cascadas del encargado del centro estos objetivos en los diferentes procesos.
Para el proceso de T & E los objetivos FY pueden tomarse de la T & E Proceso de cuadro de mando integral. Todo el equipo de T
& E debe ser consciente de estos objetivos. Todas las actividades de mejora iniciados por el equipo T & E deben estar alineados
con el cuadro de mando T & E proceso equilibrado asegurar que todos los recursos se invierten de acuerdo con las necesidades del
negocio.
2.3.2. La vinculación del proyecto para el cuadro de mando T & E proceso equilibrado
Nota: Los objetivos del proceso no se presentan debido a las restricciones de confidencialidad.
Como se ha mencionado en las líneas anteriores antes de iniciar cualquier proyecto, el líder del proyecto tiene que asegurarse de que la
contribución de este proyecto está alineado con las necesidades del negocio. Si los beneficios del proyecto son coincidentes con los objetivos del
proceso, entonces el líder del proyecto puede proceder de una propuesta de proyecto y buscar un patrocinador del proyecto.
El objetivo de este proyecto es reducir en un 50% el número de pagos de reembolso rechazados.

Pág. 12 Memoria
Esto tendrá un impacto directo en dos áreas del cuadro de mando integral T & E del proceso:
- Impacto en el Área financiera: Al reducir el número de pagos rechazados se reducirá el número de pagos manuales que
resulta en un ahorro económico para HP, como Citibank cobra $ 16 por cada pago manual procesado. El costo anual debido
al pago manual considerando 50 semanas en un año se estima alrededor de $ 17000.
- Impacto en el Zona del cliente: Al reducir el número de pagos rechazado la satisfacción del cliente se incrementará.
Como parte del sistema de gestión de calidad implementado en el proceso de T & E, la voz de la encuesta al cliente (VOC) se ejecuta
cada 6 meses para los principales segmentos externos de los clientes. La última COV ejecutar antes de este proyecto para el
segmento de clientes “empleados de HP” confirmaron la exactitud de los pagos como una de las principales (CTQs críticos para la
calidad).
Este COV se llevó a cabo en septiembre 05 y sus resultados se presentan en la siguiente tabla:
BASE 04-Dic-05 de mayo de Sep-05

El reembolso en el tiempo 3.36 3.61 4.34
precisa Reimburesement 3.15 3.26 3.31

CTQ's
La resolución consultas de tiempo 3.26 3.48 3.81
resolución de consultas precisas 3.27 3.34 3.60
Rendimiento global 3.32 3.73 3.93
Calificación general 3.32 3.73 3.90

5 = excelente - 1 = pobre
La calificación más baja fue dado a la CTQ “El reembolso exacto”. puntuación de VOC para este CTQ está por debajo de la
meta establecida en el cuadro de mando integral T & E. Comentarios de los clientes calificación de 1 (mala) o 2 (Casi pobre)
en este CTQ donde todos frente al mismo problema: “Los pagos rechazados”. Desde los ojos de la perspectiva del cliente
esta frustración es fácil de entender: los pagos rechazados no son reconocidos por la aplicación de reembolso “tranvías”:
una vez a la nota de gastos de viaje ha sido liberado por el pago del estado de la aplicación va a cambiar a PAGADO. Si el
pago no se realiza correctamente (de pago desestimado) estado cambiará de todos modos. Esto creará confusión en el
cliente, ya que la aplicación le dirá que la reclamación se paga cuando en realidad fue rechazada y se pone en una cola para
el procesamiento manual.
Como este proyecto está perfectamente alineado con las necesidades del negocio que tenía sentido para llegar a una
propuesta de proyecto y buscar un patrocinador que nos proporcionará los recursos apropiados.
3. Introducción
El proyecto descrito en el presente documento es un proyecto de mejora Seis Sigma DMAIC para el proceso de reembolso de HP
EMEA T & E. Todas las entidades legales de la EMEA con el reembolso de pago automático a través de Citibank están en el alcance.
El objetivo de este proyecto es reducir en un 50% el número de pagos de reembolso rechazados.
Esta reducción tendrá un impacto directo en dos áreas del proceso de cuadro de mando integral T & E ayudar al proceso para
lograr sus objetivos de calidad FY06:
- Impacto en el Área financiera: Al reducir el número de pagos rechazados se reducirá el número de pagos manuales que
resulta en un ahorro económico para HP, como Citibank cobra $ 16 por cada pago manual procesado. El costo anual debido
al pago manual considerando 50 semanas en un año se estima alrededor de $ 17000.
- Impacto en el Zona del cliente: Al reducir el número de pagos rechazado la satisfacción del cliente se incrementará.
El proyecto que se describe en este proyecto sigue la metodología Seis Sigma DMAIC: “Definir, Medir, Analizar, Mejorar y
Controlar”. Antes de ejecutar el proyecto, el equipo fue entrenado en la metodología Seis Sigma por tener una de dos semanas de
formación del cinturón verde.

4. Definir la Fase
4.1. Objetivos y resultados
El objetivo de la etapa de definir es definir el propósito y el alcance del proyecto y obtener información sobre los
antecedentes del proceso y de sus clientes.
El principal resultado de Definir es una declaración clara de la mejora prevista: La carta del proyecto. Una carta del proyecto bien
definido debe ser una documento de una página que contiene todos estos elementos:
• Un gráfico de equipo.
• Un planteamiento del problema claramente definido.
• Uno de los objetivos del proyecto claro.
• Todos los clientes afectados por el problema (interno / externo).
• Todos CTQs por segmento de clientes que va a mejorar el proyecto.
• Una estimación cruda de la mejora de cada CTQ. (Esta estimación puede ser revisada después de la fase de
medición).
• Una definición clara del alcance del proyecto.
• La oportunidad para la finalización de cada fase entregables +.
• Todos los riesgos y dependencias que pueden afectar a la finalización del proyecto.
4.2. El desarrollo de la carta del proyecto
Con el fin de llegar a todos estos elementos que, como líder del proyecto, se procedió como se describe a continuación:
1. La participación del equipo: lo primero que hice como líder del proyecto fue la identificación de la mejor
jugadores para el equipo. Se requieren diferentes perfiles: una persona con conocimiento profundo en el día a T & E
operaciones del día, una persona con conocimientos técnicos (herramienta de informes y solicitud de reembolso), una
persona dentro del equipo de pago (Bangalore) y una persona en el cliente Centro de respuesta con el conocimiento en
las consultas de T & E. UN

Pág. dieciséis Memoria
total de 4 personas más el beneficiario principal. Una vez identificado el reto consistía en participar en el proyecto.
Las buenas habilidades interpersonales son necesarias para tener éxito en esta tarea. Tipo de motivación de las
personas involucradas es crítico: En este caso todos los miembros del equipo simplemente eran graduados realmente
motivados en aprender cosas nuevas. Eran entusiastas de involucrarse en un proyecto Seis Sigma DMAIC. Desde el
principio, el equipo vio el valor del proyecto y se comprometió totalmente. También necesitaba involucrar al jugador más
importante en el equipo: el Cinturón Negro. El cinturón negro es una persona a tiempo tiempo completo dedicado a
dirigir y guiar a los proyectos Six Sigma. Para este proyecto proporciona entrenamiento y experiencia en el uso de las
herramientas de Seis Sigma.
2. Crear el mapa de procesos proceso SIPOC + alto nivel: Identificar a los proveedores, a las entradas
el proceso, los principales pasos en el proceso, los resultados del proceso y clientes. El SIPOC se desarrolló en
una sesión de grupo de alrededor de 2 horas. El mapa de procesos se desarrolló en una sesión de grupo de
alrededor de 4 horas. El equipo completo y el Cinturón Negro participaron en las dos sesiones. En las siguientes
tablas se puede ver el proceso SIPOC y el mapa de proceso de alto nivel:

Proveedores y entradas de proceso
GHRMS (la base de datos de recursos humanos) se carga automáticamente dos veces por semana los detalles
personales del empleado (incluyendo la cuenta bancaria de nómina) en la aplicación tranvías.
Si se desea, el empleado puede configurar manualmente en la aplicación TRAMS una cuenta bancaria distinta a la
cuenta bancaria de nómina.
Además, después de un viaje de negocios el empleado informa de sus gastos de viaje en la aplicación TRAMS
generar un TER “Informe de gastos de viaje”.
Los clientes y los resultados de los procesos
Los clientes externos: los empleados de HP recibe la notificación de reembolso (estado que se
muestra en la solicitud de tranvías) y el propio reembolso.
Los clientes internos: HP BPO (T & E + equipo de equipo de Banca) recibe un conjunto de pagos
que tienen que ser reprocesado. Estos pagos defectuosos tienen un costo asociado ($ 16 / unidad + el tiempo
dedicado a reprocesar ellos).

Pág. 18 Memoria
Principales pasos en el proceso de T & E
Durante un viaje de negocios, el empleado de HP paga por adelantado sus gastos utilizando una tarjeta corporativa AMEX
ligado a su cuenta bancaria personal. Después de / durante el viaje de negocios, el empleado de HP informa de sus gastos
de viaje en una aplicación llamada TRAMS bruja genera un TER “Informe de gastos de viaje”. Este TER, junto con los
recibos originales, se envía físicamente al equipo TRAMS que lo valida contra la política de gastos de viaje EMEA. Todos los
gastos que están dentro de la política son liberados para el pago. Si no hay ningún problema en el proceso de pago, la
cantidad total reclamada en el TER debe ser reembolsado al empleado antes AMEX le cobra los gastos incurridos. El
problema es que a veces los pagos no tienen éxito. Algunos pagos son rechazados por el proceso de pago automático
de Citibank, mientras que el estado de aplicación TRAMS mostrado al empleado de HP es “el estado de pago”.
Actualmente, el proceso genera un total de 1075 los pagos rechazados / año. Estos pagos rechazados (defectos)
son reportados a HP en una base diaria por Citibank. pagos defectuosos son reelaborados de forma manual,
mientras que el estado de la TER muestra en la aplicación TRAMS al empleado sigue siendo “el estado de pago”.
Tiempo de ciclo para el procesamiento manual puede tomar más de una semana (media de 5 días, Span 10). Esta
falta de coincidencia entre el estado que se muestra en la aplicación y el estado real, conduce a la insatisfacción del
cliente. También cada uno de estos pagos defectuosos tienen un coste asociado de $ 16 de acusados por Citibank +
el costo del tiempo de reprocesamiento.
El objetivo de este proyecto es reducir en un 50% el importe de los pagos rechazados.
3. Comprender CTQs cliente (requisitos de los clientes de las salidas de proceso) y
cómo el proyecto mejorarlas:
CTQs para clientes externos: los empleados de HP
Estos CTQs son conocidos a partir de encuestas de COV anteriores. CTQs en este proceso para los empleados de HP son:
• En Tiempo de reembolso = El reembolso realiza dentro de 6 días hábiles a partir del momento en que
el TER se crea en la aplicación tranvías. Este CTQ se relaciona con el número de salida 2 “El
reembolso a los empleados”.

• El reembolso precisa (véase el árbol CTQ) =
Se espera que dos cosas en términos de precisión. En primer lugar que la cantidad pagada es igual a la cantidad reportada.
En segundo lugar que la situación del pago que se muestra al empleado en la aplicación TRAMS coincide con el estado real
del pago. Como se ha explicado antes de que el segundo requisito no se cumple cuando se rechaza el pago.
El proyecto mejorará ambas CTQs. Al reducir el número de pagos rechazados el número de empleados de HP reembolsará
a tiempo y con precisión se incrementará.
Antes de iniciar el proyecto de un promedio de 15 denuncias al mes se recibieron debido a los pagos rechazados. Normalmente
mediante la reducción de los pagos rechazados en un 50% el número de quejas por cada mes debido a pagos
rechazados debe disminuir al menos a 8.
CTQs para los clientes internos: T & E equipo y equipo de Banca.
Después de la discusión con los responsables de T & E y equipos Bancarios su requisito era claro:
Sin retrabajo como salida del proceso. El proyecto mejorará directamente este CTQ. Tenga en cuenta que cada pago
rechazado tiene un coste asociado de $ 16 / unidad + el tiempo dedicado por ambos equipos a la reanudación. Al reducir el
número de pagos rechazados se reducirá la cantidad de trabajo. También se reducirán los costos asociados a este reproceso. Una
reducción del 50% en los pagos rechazados significa un ahorro a HP BPO de $ 8600 / año (cantidad que se paga
actualmente a Citibank debido a los pagos rechazados).
4. Definir claramente lo que está en el alcance del proyecto y lo que está fuera del alcance del proyecto: La siguiente
tabla muestra todas las entidades legales con el apoyo de proceso EMEA T & E:
Pág. 20 Memoria
Las personas jurídicas en rojo están fuera del alcance de este proyecto. El pago de estas entidades se realiza a nivel local
después de un proceso completamente diferente.
5. Desarrollar un diagrama de Gantt estimar fechas de entrega y terminación: F o el desarrollo
el diagrama de Gantt el apoyo forma el Cinturón Negro es crítica.
Times estimaciones se basan en la experiencia pasada. El Cinturón Negro ha completado / entrenado a varios proyectos por lo
que sus estimaciones son realistas. El diagrama de Gantt anterior muestra todos los pasos del proyecto con fechas de
terminación. Al final de cada fase del proyecto se revisa con el promotor del proyecto y el Cinturón Negro. (Los comentarios están
marcados en negro).
6. Identificar los riesgos y las dependencias que pueden afectar a la finalización del proyecto: A
algún momento en el proyecto puede ser necesario un cambio en la aplicación tranvías. Actualmente el equipo de
apoyo TRAMS es casi totalmente dedicado al desarrollo de

nueva herramienta de reembolso. cambios grandes en la aplicación TRAMS no serán aprobados. Esta
limitación se debe considerar en el diseño de la solución al problema.
7. Que patrocina el proyecto: El promotor del proyecto es una persona en la gestión
equipo de apoyo del proyecto y la asignación de los recursos. Su participación es fundamental. Si muestra poco
interés en el proyecto la probabilidad de terminación es muy pequeño. En el caso de este proyecto fue el
patrocinador del gestor de T & E. Al final de la fase de definir el estatuto del proyecto fue revisado con él y se
acordó un plan de revisión de comunicación (véase el diagrama de Gantt).

Pág. 22 Memoria
5. Medir la Fase
5.1. Meta y los productos
El objetivo de la etapa de Medida es enfocar el esfuerzo de mejora mediante la recopilación de información sobre la situación
actual.
Las salidas de la etapa de medida incluyen los siguientes:
• Los datos que identifica la tasa de aparición del problema.
• datos de referencia sobre lo bien que el proceso cumple con las necesidades del cliente (sigma proceso actual).
5.2. ¿Por qué medir?
Si usted no es capaz de expresar un fenómeno en número, no se sabe de él adecuadamente. (Lord Kelvin)
Una de las razones de la medida es ser capaz de cuantificar el beneficio de nuestra mejora al final del proyecto. datos
de rendimiento del proceso antes de la mejora tiene que ser comparado con los datos de rendimiento de proceso después
de la mejora.
Las conclusiones basadas en hechos y datos son necesarios para cualquier mejora (K. Ishikawa)
Otra razón importante para la medición es tener datos de referencia para el análisis.
Las decisiones han de basarse en el análisis de datos no en suposiciones. Los datos nos permitirá identificar las áreas
donde se pueden hacer mejoras.
5.3. Qué medir?
Desde el paso de definir sabemos los CTQs que van a ser mejorados:
BPO interna CTQ`s clientes:
Sin retrabajo como salida del proceso ($ ahorros)
CTQ's clientes externos:

CTQs
pago de reembolso precisa y En el tiempo de pago de reembolso
Al establecer como nuestro proyecto Y el% de los pagos rechazados podemos cuantificar la mejora de todos los CTQs.
Para el CTQ “No retrabajo como salida del proceso ($ ahorros)” podemos enlazar fácilmente el proyecto de mejora Y con la
mejora CTQ:
• La cuantificación de los ahorros de $: ( Y antes de proyecto-Y después del proyecto) * número anual de transacciones * $ 16 por
unidad prestada a Citibank
• Cuantificar el ahorro de tiempo en las operaciones de: ( Y antes de proyecto-Y después del proyecto) * número anual de
transacciones * (10 min de reproceso en el equipo T & E + 15 minutos de la reanudación en equipo de Banca)
Nota: El tiempo de reanudación asignado a la reelaboración de un pago rechazado (+ 15min 10min) fue estimado por el equipo de
ingeniería industrial HP BPO cuando se ejecuta una actividad de costes por procesos de estudio (ABC) para estos procesos.
Para el “pago de reembolso exacto” CTQ y “El pago de reembolso de tiempo” ligamos el proyecto de mejora Y con la mejora
CTQ por la siguiente ecuación: Número de quejas de los clientes en un mes debido a los pagos rechazados = K * número de
pagos rechazados en una meses = K * Y * Número de transacciones en un mes.
Nota: Asumimos linealidad entre el número de quejas de los clientes, debido a pagos rechazados y el número de pagos
rechazados, una suposición razonable.
Tenemos dos tipos de quejas de los clientes originados por pagos rechazados. El primero es cuando las quejas de los
clientes acerca de la falta de correspondencia entre el estado de pago de reembolso en la aplicación de los tranvías y el
estado de reembolso real. Por ejemplo: el estado TRAMS se paga y el dinero no está en la cuenta !! La segunda es cuando
las quejas de los clientes sobre el retraso en el reembolso. Por ejemplo: He informado de mis gastos hace más de una
semana y todavía no tienen el dinero en mi cuenta”.

Pág. 24 Memoria
5.4. ¿Cómo medir?
Con el fin de medir hemos desarrollado el siguiente plan de recolección de datos: Tipo de datos: datos
discretos. estrategia de la muestra: ninguno.
período de medición: período de 3 meses a partir de la semana 37 fiscales (5 º Septiembre) a la semana fiscal 48 (21 S t Noviembre).
Fuente de datos: faxes envían la confirmación del pago por Citibank. Estos documentos son archivados físicamente, así que no había
necesidad de recoger datos. Los datos ya estaba disponible en copias impresas de los dos últimos años.
procedimiento de recogida de datos: Recuperar formar el archivo de todo el fax de confirmación de pago enviado por Citibank
entre el 5 º de septiembre y el 25 º de noviembre. Consolidar en un solo archivo de la siguiente información:
Definiciones operacionales: Fuente de datos
definición oportunidad Todos los reembolsos liberados para el pago. la confirmación del pago de fax enviar por Citibank
la confirmación del pago de fax enviar por Citibank

definición de defectos Todos los pagos de reembolso rechazados por
Citibank proceso de pago automático.
información de defectos que deben recogerse: Fuente de datos
Nombre de empleado: la confirmación del pago de fax enviar por Citibank
Entidad legal: la confirmación del pago de fax enviar por Citibank
Citibank razón para el rechazo: la confirmación del pago de fax enviar por Citibank
El archivo con todos los datos consolidados se adjunta en el anexo A. Medida.

5.5. Los resultados de medición de corriente rendimiento de los procesos
Tendencia central:
• La mediana de los pagos rechazados por día = 3 defectos
• La media de los pagos rechazados por día = 4.017 defectos
• La mediana de los pagos rechazados por semana = 18 defectos
• La media de los pagos rechazados por semana = 19.75 defectos
la variación del proceso:
En los siguientes diagramas de series de tiempo podemos ver la evolución de defectos totales por día y semana:
gráfico de series temporales de defectos por día

gráfico de series temporales de defectos por semana
Índice
Índice
15
30
10
Defects week
Defects
20
0 10
40 30 20 10 50 10 8 6 4 2 12
los datos a partir del 5 de septiembre al 25 de noviembre al día solamente trabajan datos desde la semana 37 a la semana fiscal fiscal 48
Span (P95-P5) por día: Span (P95-P5) por semana:
Contar 0.05 Medicina 0.95 Lapso Contar 0.05 Medicina 0.95 Lapso
462 0 3 10 10 462 11.65 18 29.45 17.8
Proceso contra las necesidades del cliente (cálculo de sigma proceso):

Pág. 26 Memoria
6. Analizar la Fase
El objetivo de la etapa de analizar es el de identificar las causas de raíz y confirmarlas con datos. El resultado de este paso es una
teoría que se ha confirmado con los datos.
6.2. Identificar los diferentes segmentos para el análisis individual
Lo primero que el equipo hizo fue mostrar los defectos en un Pareto por la entidad legal:
Este gráfico de Pareto muestra que 5 entidades
legales de los 24 en el perímetro (20%), donde la
acumulación de 85% de los defectos. En este
punto, el equipo decidió analizar los defectos
solamente para las entidades 88 (Suecia), 82
(Italia), 63 (Francia), 91 (Finlandia) y F9 (España).
También el equipo ha acordado volver al resto de
entidades en el
mejora fase y
aprovechar las acciones de mejora a todas las
entidades aplicables.
Mirando en el desempeño individual de las entidades analizadas (Sigma proceso individual) el equipo identificó tres
segmentos diferentes de actuación:

También un gráfico de dispersión ayudó al equipo a visualizar estos diferentes niveles de rendimiento:
El segmento A
El segmento B
segmento C
Segmento de la
analysisPotential
El equipo hizo un análisis individual de los segmentos A, B y C, y luego se extendió las conclusiones con el resto de las
entidades.
6.3. Análisis para el segmento A- Entidad 88, Suecia
6.3.1. Razones para el rechazo dadas por Citibank
El punto de partida para el análisis en el segmento A fue los datos de “código de error” dadas por Citibank en el formulario de
confirmación diario y recogidos durante la fase de medición. De acuerdo con Citibank, los motivos del rechazo fueron:
Tenga en cuenta que un pago puede ser rechazado por

Razón de Rechazo Citibank %
varias de estas razones, al mismo tiempo. Con el fin de
cuenta beneficiaria no válido 51% procesar los pagos de la aplicación TRAMS genera un vale
diario con todo

dígito de control no válido 36% los detalles necesarios.
TRAMS aplicación utiliza los datos de la Base de Datos

receptora no válido de compensación ID 10%
TRAMS para generar estos vales.
La razón no especificada 2%
Varios campos se utilizan en TRAMS DB de datos bancarios tienda de los empleados:

Pág. 28 Memoria
ID Clearing 1- este es el conjunto de dígitos que especifican el banco, la sucursal y la oficina. Este campo se actualiza en una base diaria
con los datos de GHRMS (base de datos de recursos humanos utilizados para la nómina).
1- cuenta bancaria este es el conjunto de dígitos que el banco utiliza como un identificador para la cuenta del empleado. Este campo se actualiza
en una base diaria con los datos de GHRMS (base de datos de recursos humanos utilizados para la nómina).
Nombre del banco 1- Este es el nombre del banco del empleado. Este campo se actualiza en una base diaria con los datos de GHRMS (base de datos
de recursos humanos utilizados para la nómina).
ID cuenta de compensación 2 / Nombre del banco 2 / Banco 2- TRAMS aplicación da la opción de crear una cuenta
diferente para los pagos TRAMS que para los pagos de nómina (GHRMS datos). Si se desea, el empleado puede configurar
una cuenta diferente directamente en la aplicación oa través del Centro de respuesta al cliente.
cuenta- bancaria activa Este campo especifica los datos bancarios que están activos. El valor puede ser 1 (igual que
detalles GHRMS bancarios) o 2 (diferente de detalles GHRMS bancarios). Dependiendo del valor de este campo el
comprobante de pago se genera con los datos en el grupo 1 o del grupo 2.
Así que de acuerdo a los datos de Citibank los pagos rechazados eran debido a datos incorrectos en TRAMS DB.
6.3.2. normas para la comprensión de las cuentas bancarias suecas
Con el fin de entender por qué TRAMS DB fue acumulando datos bancarios de datos incorrectos para la entidad 88 el
equipo tuvo puño para aclarar la definición de los datos bancarios correctos (datos correctos). Sorprendentemente,
esta tarea se convirtió en uno de los más difíciles en el proyecto. Ni el equipo de operaciones TRAMS ni el equipo de
Banca conocían la estructura formato correcto para las cuentas bancarias suecas. No había documentación en el lugar
en cualquiera de los procesos de BPO que especifican cómo el formato de la cuenta bancaria sueca debe ser. Después de
varias investigaciones y las interacciones con los diferentes grupos dentro y fuera del equipo HP le ocurrió una documento
oficial del Comité Europeo de las normas bancarias
explicando todas las normas europeas para números de cuentas bancarias.
Después de leer detenidamente este documento el equipo entiende que para Suecia hay dos maneras de identificar una
cuenta bancaria:
• Utilizando el IBAN (número internacional de cuenta bancaria): el formato de la sueca IBAN se compone como
se describe en la siguiente tabla:
Total de 24 caracteres alfanuméricos. La
representación de papel de IBAN es
compuesto de 4 caracteres separados por un espacio en blanco.
Ex: SE12 1231 2345 6789 0123 4561 Para las transacciones
electrónicas no hay espacios en blanco se
permitido. Ej: SE1212312345678901234561
El proceso de pago automático real contratada por HP para pagos de reembolso no admite pagos mediante IBAN.
Por lo que todos los datos bancarios almacenados en TRAMS DB referencia a los códigos IBAN serán datos
incorrectos.
• Utilizando el número de
cuenta interna: el formato
del número de cuenta
sueco es increíblemente
compleja.
Varias estructuras de
cuentas se utilizan no
sólo por diferentes
bancos, sino también
a veces en el mismo
banco. En esta tabla el
más importante
estructuras bancarias existentes se enumeran.

Pág. 30 Memoria
A partir de este archivo y después de una gran investigación, el equipo creó un documento que explica para cada uno de los
bancos de Suecia cómo los datos bancarios fueron proporcionados por el banco y cómo deben ser almacenados en los tranvías
DB para asegurar una transacción automática correcta. Este documento define claramente por el nombre del banco de la
definición de los datos bancarios correctos (formato) para el almacenamiento de datos en la estructura de cuentas
interno. Este documento se adjunta en el anexo B. 1 estructuras cuenta bancaria nacional de Suecia. A modo de ejemplo
podemos ver a continuación las diferentes estructuras utilizadas por uno de los bancos más importantes: Föreningssparbanken.
estructura Föreningssparbanken 1-
Las especificaciones para los datos bancarios en TRAMS

DB para
estructura Föreningssparbanken 1: Clearing ID: debe

ser de 4 dígitos. No se permiten espacios en blanco o
caracteres especiales. Todas las cuentas con un ID de
compensación empezando por el dígito 7 pertenecen a
este grupo por lo que el primer dígito del ID de
compensación está proporcionando el nombre del
banco.
Nombre del banco: Föreningssparbanken. Este

campo es opcional y no se utiliza para
generar el electrónico
transacción. De todas formas a partir de una
informar perspectiva es importante

actualizarla en TRAMDS DB.
Cuenta bancaria: debe ser de 7 dígitos. Los espacios en blanco o caracteres especiales deben ser eliminados. anuncios TRAMS 3
ceros iniciales cuando la generación de la transacción aumentar el número de dígitos de este campo hasta 10 dígitos.
estructura Föreningssparbanken 2-
Las especificaciones para los datos bancarios en TRAMS

DB para
estructura Föreningssparbanken 2:
Eliminación de ID: debe ser de 4 dígitos. No se

permiten espacios en blanco o caracteres
especiales. Todas las cuentas con
un ID de compensación comenzando con el dígito 8 pertenecerá a este grupo por lo que el primer dígito del ID de compensación nos está
diciendo el nombre del banco. Para estos casos el banco proporciona un quinto dígito en la ID de compensación. Este quinto dígito no
debería aparecer en TRAMS DB. Sólo los cuatro primeros dígitos deben estar en la base de datos.
Nombre del banco: Föreningssparbanken. Este campo es opcional y no se utiliza para generar la transacción electrónica. De todos
modos desde una perspectiva de la información es importante para actualizarlo en TRAMDS DB.
Cuenta bancaria: Cualquier número de dígitos de 2 a 10 dígitos. Los espacios en blanco o caracteres especiales deben ser
eliminados. Tranvías anuncios ceros a la izquierda hasta 10 dígitos cuando se genera la transacción.
6.3.3. La identificación de posibles causas de raíz
En este punto del análisis, el equipo sabía que los datos datos bancarios para algunos empleados suecos no se almacenan
adecuadamente en TRAMS DB, pero, por otro lado, ahora el equipo sabía cómo se deben almacenar estos datos bancarios.
El siguiente paso fue identificar todas las fuentes de datos de origen que se actualizan TRAMS DB. En este nivel se utilizó una
técnica de mapeo de proceso sub. En el siguiente cuadro latas ver todos los diferentes flujos de datos actualización de los
tranvías DB:
Pág. 32 Memoria
Los resultados del mapeo de procesos sub eran extremadamente sorprendente:
1. No hubo datos bancarios de actualización automática de GHRMS (base de datos de recursos humanos).
Antes se suponía que este proyecto datos bancarios para todas las personas jurídicas que se actualizará en una base diaria
de GRS (base de datos de recursos humanos). Después de la investigación con el departamento local de recursos humanos
sueca el equipo descubrió que la base de datos de recursos humanos para Suecia no contiene ninguna información
relacionada con los datos bancarios. Nómina en Suecia no se hace desde los GHRMS sino de sistema de nómina
separada. detalles de los empleados como nombre, identificación de empleado ... se actualizan en una base diaria
en TRAMS DB de GHRMS pero como no había datos bancarios en GHRMS, ninguna actualización automática se
hizo con los datos bancarios. Además no había flujo de información entre el sistema de nómina local sueco y tranvías DB.
2. Los empleados pueden actualizar manualmente los datos en ambos “1” datos bancarios y campos
“datos bancarios 2” campos. Este flujo de información se pone de relieve en el mapa de procesos en rosa. Sin
comprobación de validación se llevó a cabo mediante la aplicación al introducir los datos bancarios. No dio ninguna
explicación al empleado en la forma de actualizar los datos bancarios.
3. Los agentes CRC podrían actualizar manualmente los datos en ambos “datos bancarios 1” y “campos de datos
bancarios 2” campos. Este flujo de información se resalta en verde. Cuando así lo solicite a través del Centro de respuesta
al cliente el equipo de CRC era actualizar el banco de los empleados en “datos bancarios 1” campos o en los “datos
bancarios 2” campos dependiendo del agente de tratamiento de la actualización. Como se mencionó anteriormente había sin
el conocimiento o la documentación existente en el equipo de cómo actualizar correctamente en TRAMS DB los
datos bancarios para Suecia. se introdujeron los datos bancarios según lo declarado por el empleado.
4. agentes TRAMS podrían actualizar manualmente los datos en ambos “1” datos bancarios campos
y “2” datos bancarios campos. Este flujo de información se pondrá en naranja. Cuando un pago rechazado se
produjo TRAMS equipo solicitó el IBAN al empleado y lo envía al equipo de pago en la India para procesar un
pago manual. IBAN se solicitó en lugar de los datos bancarios internos porque para el equipo de pago Los pagos
manuales con IBAN eran más fáciles de procesar que los pagos manuales con estructura de cuentas interno. El
equipo de tranvías actualiza TRAMS DB con el IBAN.
Después de completar el ejercicio de mapeo subproceso para el flujo de información de actualización de TRAMS DB, el equipo desarrolló
un diagrama de espina de pescado lista de todas las posibles causas fundamentales de los pagos rechazados en la Entidad 88:
Las causas fundamentales potenciales para los pagos rechazados para Suecia se agruparon en tres categorías:
zona de riesgo 1-empleado: Potencialmente tres acciones en este ámbito daría lugar a un pago rechazado. La primera fue
cuando el empleado actualiza sus datos bancarios con un formato diferente al formato requerido por TRAMS DB. Esto es
algo que podría suceder fácilmente. A medida que el equipo descubrió en su investigación, los datos bancarios se
proporcionan a los empleados por sus bancos en un formato diferente al formato requerido por TRAMS DB. Siempre y
cuando el empleado no era consciente de este problema que iba a actualizar sus datos bancarios según lo previsto por el
banco, lo que lleva a un pago rechazado. La segunda acción fue cuando el empleado, siendo consciente del formato
requerido por TRAMS DB, introducen datos incorrectos en el formato correcto Ex: error tipográfico. Estos casos también dará
lugar a un pago rechazado (dígito de control no válido). Por último, la tercera acción fue cuando el empleado utiliza una
cuenta extranjera. El proceso de pago automático no admite transacciones internacionales. Los empleados de la entidad 88
deben ser restituidos en una cuenta sueco. De lo contrario será rechazado el pago.
zona de riesgo 2-CRC: Potencialmente dos situaciones en esta área llevaría a un pago rechazado. La primera fue cuando el
agente CRC actualiza los datos bancarios del empleado con un formato diferente al formato requerido por TRAMS DB. Esto
es algo que puede ocurrir fácilmente. El empleado puede presentar su solicitud de proporcionar sus datos bancarios que se
ofrecen a él por el banco. El agente de CRC, falta del conocimiento de la actualización de detalle banco sueco en el formato
correcto, actualizaría los datos bancarios, tal como figura en la solicitud, dando lugar a un pago rechazado. La segunda
situación es cuando el empleado o el agente CRC entraron en una

Pág. 34 Memoria
dígito incorrecto al escribir los datos, incluso si el formato utilizado era correcta. Estos casos también daría lugar a un pago
rechazado (dígito de control no válido).
zona de riesgo del equipo 3-TRAMS: Potencialmente tres situaciones en esta área podría dar lugar a un pago rechazado. Los dos
primeros eran idénticas a las situaciones potenciales en el área de riesgo de CCR. La tercera situación fue cuando después de
procesar algunos pagos manuales del equipo TRAMS actualiza los tranvías DB con el IBAN del empleado. Incluso si IBAN se puede
utilizar para los pagos manuales de procesamiento de la simplificación de la complejidad de este proceso, el proceso de pago
automático no es compatible con este formato de los datos bancarios. Por lo que esta acción podría dar lugar a pagos recurrentes
rechazado cada vez que el empleado presenta una reclamación de gastos de viaje.
6.3.4. Estrecha a las causas fundamentales
El siguiente paso en el análisis fue para confirmar nuestra espina de pescado con los datos. El objetivo fue cuantificar la
contribución de cada una de las posibles causas de raíz para el número total de pagos rechazados por la entidad 88.
El equipo no pudo utilizar los datos recogidos en la fase de medición de hacerlo cuantificación. TRAMS sistema mantiene
datos de la última persona que hizo la actualización de los datos bancarios. Así que no fue posible conocer por el pasado
rechazó los pagos que hizo la actualización de la información. El equipo decidió entonces para recoger datos de 2 semanas.
En una base diaria, después de recibir la lista de pagos rechazados de Citibank, el equipo recogió datos de quién hizo la
última actualización de los datos bancarios para ese empleado (origen de la causa raíz) y cómo se realiza esta actualización
(causa). Los resultados se incluyen en la espina de pescado se presenta en la página anterior.

La salida de nuestro análisis se presenta on la matriz de prioridades flollowing:
6.4. Análisis para el segmento B-82 Entidad, Italia
6.4.1. Razones para el rechazo dadas por Citibank
El punto de partida para el análisis en el Segmento B era los datos de código de error dado por Citibank y recogidos durante
la fase de medición. De acuerdo con Citibank, los motivos del rechazo fueron:
Pág. 36 Memoria
Razón de Rechazo Citibank %

Como en el análisis de los pagos de segmento anterior fueron
cuenta beneficiaria no válido 38%
debido a datos incorrectos en TRAMS DB. Pero esta vez el
receptora no válido de compensación ID 25% Citibank no sólo se refería a detalles del banco de datos, sino
también a dirección y código postal de datos de los empleados.

Beneficiario dirección no válida 23%
Beneficiario de código postal no válido 13%
dígito de control no válido 1%
6.4.2. normas para la comprensión de las cuentas bancarias italianas
Al igual que en el análisis del segmento A se utilizó el documento oficial del Comité Europeo de estándares bancarios.
Después de leer detenidamente este documento el equipo entiende que para Italia hay dos maneras de identificar una cuenta
bancaria:
• Utilizando el IBAN (número internacional de cuenta bancaria).
• Utilizando el número de cuenta interna.
La aplicación de los resultados de análisis de segmento A, todos los datos bancarios almacenados en TRAMS DB referencia
a los códigos IBAN serán los datos incorrectos y no serán Basándose en el proceso de pago automático. Así que no
había interés en la comprensión de la estructura IBAN italiano.
La estructura de la cuenta interna de Italia fue mucho más simple que la sueca. Hay un único formato estándar:
Señalan que los bancos italianos proporcionan los datos datos bancarios como descried en la tabla de la derecha.
En cuanto a Suecia, el equipo creado para Italia un documento que explica cómo los datos bancarios fueron proporcionados por el
banco y la forma en que se deben almacenar en los tranvías DB para asegurar una transacción automática correcta:
Las especificaciones para los datos bancarios en
TRAMS DB para El banco italiano
cuentas:
Borrado ID: debe ser de 10 dígitos. No se permiten
espacios en blanco o caracteres especiales.
Eliminación de ID se compone de ABI nombre de
código + CAB Código del banco: Este campo es
opcional y no se utiliza para generar la transacción
electrónica. De todos modos desde una perspectiva
de la información es importante para actualizarlo en
TRAMDS DB.
Cuenta bancaria: debe ser de 12 dígitos. Los espacios en blanco o caracteres especiales deben ser eliminados. TRAMS al
generar la transacción no añaden ceros a la izquierda.
Los pagos automáticos a través de Citibank para Italia requieren el nombre de la ciudad del empleado (debe ser una ciudad
italiana) y un código postal válido dentro de esa ciudad (5 dígitos código postal).
6.4.3. La identificación de posibles causas de raíz
Una vez que todas las especificaciones para pagos automáticos se conocen el equipo procedió como en el análisis del segmento
A por hacer un análisis de mapeo de procesos sub.
En el siguiente cuadro latas ver todos los diferentes flujos de datos actualización de los tranvías DB para la entidad 82:
Pág. 38 Memoria
Los resultados de la asignación de sub proceso fueron los siguientes:
1. Como era de esperar hubo una actualización automática de GHRMS (base de datos de recursos
humanos). Después de las investigaciones el equipo descubrió que la actualización se realiza en una base diaria.
Todos los detalles del empleado como nombre, identificación de empleado, código postal, dirección, datos
bancarios se rellenan automáticamente en los tranvías de GHRMS. También GHRMS fue poblada manualmente y
mantenido por el empleado mediante la introducción de sus datos a través del portal de HP “transacción de
autoservicio”. No hay pruebas de validación se realizaron en este portal al introducir los datos bancarios.
Dirección, ciudad y código postal no eran campos obligatorios en este portal. Este flujo de información se resalta en
color marrón.
2. Los empleados pueden actualizar manualmente los datos bancarios 1 campos y datos bancarios 2
campos. Este flujo de información se pone de relieve en el mapa de procesos en rosa. No hay pruebas de validación
se realiza mediante la aplicación al introducir los datos bancarios. No dio ninguna explicación al empleado en la
forma de actualizar los datos bancarios.
3. CRC agentes podrían actualizar manualmente los datos bancarios 1 campos y datos bancarios 2
campos. Este flujo de información se resalta en verde. Sin documentación existente en cómo actualizar
correctamente los datos bancarios en TRAMS DB para Italia estaba en su lugar. se introdujeron los datos
bancarios como se indica en el empleado en su petición.
4. Los agentes del equipo tranvías podrían actualizar manualmente los datos bancarios 1 campos y
datos bancarios 2 campos. Este flujo de información se pondrá en naranja. Cuando un pago rechazado se
produjo TRAMS equipo solicitó el IBAN al empleado y lo envía al equipo de pago en la India para procesar un
pago manual. Se solicitó IBAN porque los pagos manuales con IBAN eran más fáciles de procesar que los pagos
manuales con estructura de cuentas interno. En la mayoría de los casos, el equipo de tranvías actualiza
TRAMS DB con el IBAN.
Después de completar el ejercicio de mapeo subproceso para el flujo de información de actualización de TRAMS DB, el equipo fue capaz de
desarrollar un diagrama de espina de pescado lista de todas las posibles causas fundamentales de los pagos rechazados en la Entidad 82:
Las causas fundamentales potenciales para los pagos rechazados para Italia se agruparon en cuatro categorías diferentes:
Pág. 40 Memoria
zona de riesgo 1-Viniendo del empleado: Idem como para Suecia. zona de riesgo
2-Viniendo de CRC: Idem como para Suecia. zona de riesgo 3-Viniendo de equipo
TRAMS: Idem como para Suecia.
zona de riesgo base de datos 4-HR: En una base diaria GHRMS actualiza TRAMS DB. Si los datos bancarios incorrectos o
dirección incorrecta (ciudad) o código postal en GHRMS los datos incorrectos serán transferidos a los tranvías DB. Por entidad
de base de datos 82 GHRMS está poblada y mantenido por el empleado a través de la “transacción de autoservicio” portal de
HP. Comentar que todos los meses un pago electrónico mensual se hace para todos los empleados de GHRMS de nómina.
Este hecho debería ayudar a mantener GHRMS actualizados con datos correctos y completos.
También señalar que incluso si la Entidad 82 y 88 tienen las mismas causas fundamentales de las zonas de riesgo 1,2 y 3 la
probabilidad de ocurrencia de estas causas fundamentales en la entidad 88 es mucho mayor que la complejidad de los datos bancarios
para Suecia es mucho mayor que la la complejidad de los datos bancarios para Italia.
6.4.4. Estrecha a las causas fundamentales
Con el fin de cuantificar la contribución real de los pagos rechazados en Italia de cada raíz potencial de causar el equipo
procedió como para la entidad 88. Los resultados en la siguientes:
12%
2 2%
2 0%
36%
Lo que la salida de nuestro análisis de los pagos rechazados en la entidad 82 será una lista de las causas fundamentales organizados en una matriz
de la siguiente prioridad.
6.5. Análisis de Entidades segmento C- 91 (Finlandia), F9 (España) y 63 (Francia)
El equipo siguió los mismos pasos para el análisis de segmento C como para los segmentos anteriores. El mapa de procesos
de los flujos de datos actualizando TRAMS DB fue, para estas entidades, exactamente el mismo que para la entidad 82.
La única diferencia entre la entidad 82 y las entidades en el segmento C que fue de pagos electrónicos en los países de
las entidades en el segmento C el código postal y la dirección no era necesario. Así que para las entidades en el segmento
C, los pagos rechazados sin ocurrirán si el empleado no está actualizando su dirección y código postal en la “transacción de
autoservicio” HP Portal. Después de analizar el segmento C, el equipo llegó a la conclusión de que todas las acciones
tomadas en la fase de mejora para eliminar las causas fundamentales de los pagos rechazados en la entidad 82 (con
exclusión de los que tratan el tema con la falta de dirección del empleado y código postal) serían aplicables a las
entidades en el segmento C. estructuras de cuentas nacionales de Finlandia, España y Francia se unen en
estructuras de cuenta bancaria nacional B.2 para el segmento C.

Pág. 42 Memoria
7. Mejorar la Fase
El objetivo de la etapa de mejora es desarrollar, probar e implementar soluciones que aborden las causas fundamentales y utilizar los
datos para evaluar las soluciones, así como los planes que se utilizan para llevarlas a cabo.
Las salidas del paso Mejorar incluyen los siguientes:
• Planeado, las acciones que eliminen o reduzcan el impacto de la causa identificada (s) de un problema probado.
• “Antes” y “después de' análisis de datos que muestra la cantidad de la brecha inicial estaba cerrado.
Las acciones tomadas en la etapa de mejora de este proyecto se dividen en dos grupos en función de su naturaleza:
• Las acciones correctivas: Durante el análisis de paso, el equipo se enteraron de que los diferentes Xs (causas
fundamentales) había generado una cantidad relevante de los datos bancarios del empleado incorrectos en TRAMS DB.
Estos datos incorrectos darían lugar a un pago rechazado en caso de que el empleado relacionada solicitó un reembolso.
Todas las medidas adoptadas para limpiar todos los datos bancarios incorrectos acumuladas en TRAMS DB se clasificaron
como las acciones correctivas.
• Las acciones preventivas: Todas las acciones tomadas para eliminar las diferentes Xs (causas raíz). Estas acciones
impiden la acumulación de datos bancarios incorrectos en TRAMS DB y pagos rechazados, por lo tanto potenciales.
7.2. Implementación de acciones correctivas
El equipo decidió aplicar las acciones correctivas (base de datos de limpiar) para todas las entidades.
Las acciones correctivas se presentan en la siguiente tabla:

1. Para las entidades 88, 82, F9, 91 y 63 la estructura de
cuenta bancaria nacional se entendía y se documentan en
la etapa de análisis. En este punto, el equipo hizo el
mismo ejercicio para el resto de entidades. Toda la
documentación se adjunta creada en las estructuras de
cuentas doméstica anexo C.1
para el resto de ENTIDADES.
2. Una vez que toda la producción nacional
cuentas estructuras
se entiende el equipo
desarrollado,
conforme, a el
país rige una consulta (Brio
consulta) para identificar todos
los empleados con formato
incorrecto datos bancarios en
TRAMS DB. El código de la
consulta por países se adjunta
en el anexo C.2 Código de
Consulta brio. En la tabla
siguiente, la una
se presenta instantánea de la consulta diseñada para Suecia. En el caso de países con varias estructuras de
cuentas nacionales se utilizó el número de código del banco para identificar la estructura de cuentas interno
aplicable. Tenga en cuenta la complejidad de la consulta para Suecia debido a las diferentes estructuras de cuentas
existentes en el país. El número total de empleados del detectados por la consulta añadió hasta 370 líneas (156 de
ellos empleados en sueco).
Se asignaron recursos 3. Una vez que se han detectado todos los empleados con los datos bancarios incorrectos para limpiar la
base de datos. Seguimiento directo con los empleados era necesaria en muchos casos. La limpieza tomó una semana con 3
recursos de tiempo completo.

Pág. 44 Memoria
7.3. Implementación de acciones preventivas
7.3.1. -acciones preventivas especial solución para el segmento A, Suecia
Las soluciones potenciales no se han aplicado
Before arriving to the final solution, the team considered two actions to eliminate the Xs in Sweden. Due to IT limitations these
actions were not implemented.
The first request was to link the TRAMS DB to the actual Payroll system. As described in the analysis phase, TRAMS DB
is linked to HR database but for Sweden HR database doesn’t contain bank details information. All the bank details are
maintained in a separate payroll database. The reason for rejecting this IT change request was the limitation of IT TRAMS
resources due to the implementation of the new Employee reimbursement application. This change requested supposed a big
implementation effort from the IT TRAMS team that currently was fully dedicated to the development of the new Employee
reimbursement application. Even though the change was rejected for TRAMS the IT team included the request as a
requirement for the new tool. Remark that the “go live” of this new tool is planned for end 2007.
The second request was to incorporate to TRAMS the possibility to generate electronic transactions using IBAN. IBAN
format for Sweden is standard. This fact would simplify the complexity of the Swedish bank details diminishing the actual
number of rejected payments. The reason for rejecting this change request was the same as for the first change request:
availability of resources. Even though the change was rejected for TRAMS the IT team included the request as a requirement
for the new tool.
Implemented solutions
The actions taken to reduce/eliminate the Xs generating the rejected payments in Sweden were:
• Implementation of a weekly report capturing all the employees with bank details not meeting the requirements. This
report is exactly the same report as the one used for cleaning up TRAMS DB. The Team leader should run it in a
weekly basis. Employees in the report should receive a notification mail with a document explaining how to
Application of the Six Sigma DMAIC methodology to a financial process Pág. 45
correctly update bank details in TRAMS. This procedure was included in the ISO material as a weekly activity.
Trams team is responsible of updating the report with changes in the Swedish accounts structures.
• Creating Knowledge in the Teams-The documentation created in the analysis phase specifying the correct format
of bank details for Sweden in TRAMS DB was added to the ISO documentation of the CRC and TRAMS team. This
documentation is critical for CRC to answer the queries related to bank details. Also work instructions for TRAMS
team were modified highlighting the importance of updating the domestic account structure in TRAMS after a
manual payment avoiding recurrent manual payments.
In the following table all the actions taken are assigned to their related X:
Pág. 46 Memoria
Origin of Xs Xs Preventive actions
Employee updates his bank details in TRAMS with a format different to the format
required by TRAMS DB to perform electronic transactions successfully Manual report (Brio query) to detect all the employees with bank
details not meeting the requirements- Potential
rejected payments.
Employee uses a foreign bank account in TRAMS (bank account form a country Template to explain employees in the report how to correctly update
Employee
different to the country of his legal entity) bank details in TRAMS
Employee updates incorrect bank details with the correct format

No action was taken
Creating knowledge-Documentation was created (templates)
explaining the complex domestic account

CRC agent updates employee's bank details in TRAMS with a format different to the
structure for Sweden. This
format required by TRAMS DB to perform electronic transactions successfully
documentation was included in the work
Customer Response Center instructions of ISO material. Team was trained in this material.
CRC agent updates employee’s incorrect bank details with the correct format
No action was taken
Documentation was created (templates)
explaining the complex domestic account structure
for Sweden.
TRAMS agent updates employee's bank details in TRAMS using IBAN format after
Templates were designed to request bank details to employees for
processing a manual payment-
processing manual payments. Procedure for processing manual
> Recurrent manual payment
Payments in ISO material was updated highlighting the importance of
not using IBAN structure for manual payments. Team was trained on
this material.
TRAMS operations team
Documentation was created (templates)
TRAMS agent updates employee's bank details in TRAMS explaining the complex domestic account structure for Sweden. This
with a format different to the format required by TRAMS DB to perform electronic documentation was included in the work instructions of ISO material.
transactions successfully Team was trained in this material
TRAMS agent updates employee's incorrect bank details with the correct format
No action was taken
7.3.2. Preventive actions-Standard solution (Segment B+ Segment C)
As discussed in the analysis step, all actions taken in the improvement phase to eliminate root causes for rejected payments
in entity 82 (excluding the ones addressing the issue with missing employee’s address and zip code) would be applicable for
entities in Segment C. Actions taken can be grouped in three categories:
1. Format validation checks in TRAMS:
Before this project all type of characters could be entered in the account number and clearing ID fields in TRAMS. Eg: blanks,
-, /…. Also there was no minimum or maximum number of digits allowed for the account number and clearing ID fields in
TRAMS. The team, based on the specification formats documented in the analysis phase, requested the following IT changes
in TRAMS:
Entity 82 (Italy):
Changes requested for the updating bank details screen:
• Bank 1/Clearing ID 1: Block manual updating of these fields.
• Clearing ID 2: Check that the update contains 10 digits and that the update contains only numerical values.
• Bank 2: Check that the update contains 12 digits and that the update contains only numerical values. Entity F9
(Spain):
• Bank 2: Check that the update contains 12 digits and that the update contains only numerical values. Entity 91
(Finland):
• Bank 2: Check that the update contains 8 digits and that the update contains only numerical values.
Pág. 48 Memoria
Entity 63 (France):
• Bank 2: Check that the update contains 13 digits and that the update contains only numerical values.
These validation checks are applicable to updates done by employees, CRC agents and TRAMS agents. In the following
screen shoot we can see the error message that will result if bank details are not entered according to the specifications:
2. Validation check in HP portal “Self
service transaction menu”:
Same checks as in TRAMS were requested to the HP portal IT team. Also an extra request was submitted.
Additional request for entity 82:
Employee address in Italy (name of the city) and zip code should be a mandatory field. Zip code should be 5
numerical digits.
3. Creating documentation (templates)+ training to teams:
The documentation created in the analysis phase specifying the correct format of bank details in TRAMS DB was added to
the ISO documentation of the CRC and TRAMS team. This documentation was especially critical for CRC to answer the
queries related to bank details. Also work instructions for TRAMS team were modified highlighting the importance of updating
the domestic account structure in TRAMS after a manual payment avoiding recurrent manual payments. Templates
explaining specifications of bank details were designed in a manner that the TRAMS team could use them to request to
employee’s their bank details after a rejected payment. By using this templates for requesting bank details the TRAMS team
will not only get the bank details in the correct format but also will train the employee in the correct format of bank details for
electronic transactions.
In the following table all the actions taken are assigned to their related X:
Preventive actions
Origin of Xs
Segment B Segment C
Employee updates his bank details in TRAMS with a format different to the format required by TRAMS DB
to perform electronic transactions successfully Automatic format validation check was added in TRAMS to ensure that
bank details updates are done correctly.
Employee Employee uses a foreign bank account in TRAMS (bank account form a country different to the country
of his legal entity)
Employee updates incorrect bank details with the correct format No action was taken
Employee updates his bank details in the HP portal "Self service transaction" with a format different to the Automatic format validation check was added in the HP portal to ensure
format required by TRAMS DB to perform electronic transactions successfully that bank details updates are done correctly.
HR database (employee)
Zip code and address were set up as
mandatory fields in the HP portal "Self
Employee doesn't update his address and zip code in the HP portal "Self service transaction" service transaction". Automatic format
validation check was added for zip code in
the HP portal "Self service transaction"
Automatic format validation check was added in TRAMS to ensure that

CRC agent updates employee's bank details in TRAMS with a format different to the format required by
Documentation was created (templates) explaining the domestic
Customer Response TRAMS DB to perform electronic transactions successfully
account structure for each country. This documentation was included in
Center
the work instructions of ISO material. Team was trained on this
material.
CRC agent updates employee's incorrect bank details with the correct format No action was taken


account structure for each country.
TRAMS agent updates employee's bank details in TRAMS using IBAN format after processing a manual
Templates were designed to request bank details to employees
payment->Recurrent manual payment
for processing manual payments.
Procedure for processing manual in ISO material was updated
highlighting the importance of not using IBAN structure for manual
payments processing. Team was trained on this material.
TRAMS operations team

TRAMS agent updates employee's bank details in TRAMS with a format different to the format required by
TRAMS DB to perform electronic transactions successfully
account structure for each country. This documentation was included in
the work instructions of ISO material.
Pág. 50 Memoria
7.3.3. Preventive actions-Leverage of the general solution to the rest of entities
Most of the solutions implemented for Segments B and C were also implemented for the entities were the solution was
applicable:
• Validation checks in TRAMS:

Implemented for entities in Belgium, Germany, Portugal, Switzerland, Denmark, Ireland, Norway and UK.
Validation checks were done according to specifications attached previously documented.
• Validation checks in the HP portal:
Not applicable for any of the remaining entities. Only Entities 82, F9, 63 and 91 were using the HP portal “Self
service transaction” to update the HR database. For the rest of the entities the HR local team did the update of HR database.
Knowledge on how to update the bank details correctly existed in the team so no action was necessary.
• Documentation (templates)+training
Implemented for entities in Belgium, Germany, Portugal, Switzerland, Denmark, Ireland, Norway and UK.
7.4. Improvement results: “Before” and “After” data.
The following results include 7 weeks data: 4 weeks of piloting+ 3 weeks of control. All entities in the scope of the project are
included.
Central tendency:
Central tendency measure Before After
Median of rejected payments by day 3 defects 0.457 defects
Mean of rejected payments by day 4.017 defects 0 defects
Median of rejected payments by week 18 defects 2.429 defects
Mean of rejected payments by week 19.75 defects 2 defects
Process variation:
Span (P95-P5) by day: Span (P95-P5) by week:
Count P 05 Med P 95 Span Count P 05 Med P 95 Span
Before 462 0 3 10 10 Before 12 11.65 18 29.45 17.8
After 35 0 0 1.3 1.3 After 7 11.3 14 16.7 5.4
Process performance versus customer needs:

Pág. 52 Memoria
8. Control Phase
8.1. Goals and outputs
The goal of the Control step is to maintain the gains that have been made by standardizing the work methods or processes,
anticipating future improvements and preserving the lessons learned from this effort.
The outputs of the Control step include the following:
• Complete documentation of the project.
• A system for monitoring the consistent use of the new method and for checking results.
• Quantification of benefits.
• Learnings and recommendations.
8.2. Control mechanisms to ensure consistency of results
1 st control mechanism:
Sigma for accuracy of payments will be included to the actual process sigma calculated and reported in a monthly basis.
This metric will be exactly the same metric as the one used in this project:
2 nd control mechanism:
The following procedures have been updated in the work instructions of ISO material:
T&E process:
• Procedure for processing manual payments: highlighting the importance of not using IBAN.
• Weekly reports: Adding the report for Sweden detecting the potential rejected payments.
• Country specifics updated with bank details structure templates.

CRC:
• Country specifics updated with bank details structure templates. Banking team:
• Procedure for processing manual payments: highlighting the importance of not using IBAN.
• Country specifics updated with bank details structure templates. The following procedures are auditable and can be
checked in any of the ISO internal audits.
8.3. Project benefits quantification
Project Y defects reduction= 19.75 defects/week-4.07 defects/week=15.68 defects/week = 79%
Expected project Y defects reduction of 50%.
By improving project Y we have improved CTQ’s for internal and external customers.
8.3.1. Internal BPO customers: T&E team and banking team.
(CTQ: No rework as an output of the process) Benefits:
• $ Savings/Year: 50weeks/year*15.68 defects/week * 16.83$/defect= $ 13194.72/year.
Expected $ savings of $8600.
• Rework time reduction: Cost of defects:
Rejected payments
T&E team: 50weeks/year*15.68 defects/week *
1Cost of initial payment 0.33
0.166hrs/defect= 130 hrs/year. 2Cost of reject 10
3Cost of manual payment 6.5
4Cost of Trams team (10 min) 5Cost of
Banking team: 50weeks/year*15.68 payment team (15 min)
16.83
defects/week * 0.25hrs/defect= 196 hrs/year.
8.3.2. External BPO customers: HP employees
(CTQs: Accurate reimbursement payment and On time reimbursement payment).

Pág. 54 Memoria
Benefits:
• Increase customer satisfaction:
Reduction of customer complaints related to rejected payments of 79%.

Expected reduction of 50%.
Increase of VOC score for CTQs Accurate reimbursement payment and On time reimbursement payment. The
increase of VOC score could not be quantified due to the delay in the roll out of the VOC survey for ER.
8.4. System learnings and recommendations
Learning: TRAMS only supports domestic account structures not IBAN structure.
Recommendation to process team designing new reimbursement tool:
The new tool should support transactions using IBAN.
Learning: HR database for Sweden has no bank details on it. Payroll is done from a separate system
For Sweden the new tool should be linked not only to the HR database but also to the local payroll system.
Learning: Domestic account structure for Sweden is quite complex.
The new tool should support transactions using IBAN.
Recommendation to TRAMS team (BPA):
Changes in the structures may occur: Regular checks of the European committee for banking standards. If any change
identified, update the code of the Brio query.
Learning: No format validation checks existed in TRAMS before this project.
The new tool should automatically check the format of bank details according to country specifications when any update
occurs.
Conclusions
The following conclusions and recomendations are not only based on this project learnings but also in my two and a half
years of experience in Six Sigma.
In my opinion there are three reasons that make Six Sigma useful for the business: 1. The first reason is that Six Sigma
DMAIC methodology provides the business with a measurable way to track performance improvements. By having “before”
and “after” improvement data the benefit of the project can be quantified. Having the improvement quantified allows
management to act according to the new scenario like, for example, setting new priorities or reorganizing the resources. Also,
by having the improvement quantified, the project team members can give visibility of the results of their efforts. 2. The second
reason is that Six Sigma DMAIC methodology improves customer’s relationships by addressing defects. Six Sigma DMAIC
methodology is not focused in the average performance of the process. It is based in the defects. It is based in those tail
cases generating unhappy customers. 3. The third reason is that by growing a Six Sigma Culture the business creates
process management and process ownership at all organization levels. By deploying a Six Sigma Culture at all levels people
knowing the day-to-day operations will participate and own process changes. People in the process front line are the people
that really now the problem and by providing them with basic statistical tools and project management tools the results can be
huge.
But implementing the Six Sigma DMAIC methodology/Culture in the business is not an easy task. In my opinion the following
factors are critical to the successful deployment:
1. Management commitment is a must. Building the culture, training the people, changing the main set requires time. There
may be no short-term benefits. Management have to support the initiative, get involved and align the projects to the business
needs. 2. Six Sigma should be a language understood by everyone in the business. If only the BB and MBB are participating
and understanding what is going on the initiative will not be successful. People from operations with a strong knowledge in
the process to be improved should be the ones leading the initiatives. BB and MBB should act as coaches providing the team
with project management expertise and providing support with statistical tools. The most important task of MBB and BB is to
deploy the religion. It is not about completing successful projects; it is about making the others completing successful
projects.
Bibliography
Bibliographic references
[1] Jehad Fahour, GB training for EMEA BPO, HP publications-Barcelona March 2005.
[2] Ravichandran Venkataraman, HP BPO overview, HP publications Bangalore Dec 2005 .
[3] Xavier Tort-Martorell Labres, Metodos estadisticos, Barceloan Ediciones UPC Sept
1997.
[4] European Committee for banking standards, Register of European account nubers,
TR201 V3.8 January 2005.

Application Six Sigma Methodology Financial Process - En.es PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Application Six Sigma Methodology Financial Process - En.es PDF

Transféré par

Droits d'auteur :

Formats disponibles

La aplicación de la metodología Seis Sigma DMAIC a un proceso financiero Pág.

Cliente (puntuación COV) Queda Fuera de this memoria.

RESUMEN (ESPAÑOL) _________________________________________1 ÍNDICE

2. ANTECEDENTES DEL PROYECTO __________________________________7

2.1. Introducción a HP BPO .............................................. ...................................... 7

4. DEFINIR FASE __________________________________________15

5.2. ¿Por qué medir? .................................................. .......................................... 22

6. ANALIZAR FASE ________________________________________26

6.3. Análisis para el segmento A- Entidad 88, Suecia ......................................... .......... 27

6.3.2. normas para la comprensión de las cuentas bancarias suecas ....................................... 28

6.3.3. La identificación de posibles causas fundamentales .............................................. ............................ 31

6.3.4. Estrecha a las causas fundamentales ............................................. ...................................... 34

6.4. Análisis para el segmento B-82 Entidad, Italia ......................................... ................ 35

6.4.1. Razones para el rechazo dadas por Citibank ............................................ .................. 35

6.4.2. normas para la comprensión de las cuentas bancarias italianas ........................................... 36

6.4.3. La identificación de posibles causas fundamentales .............................................. ............................ 37

6.4.4. Estrecha a las causas fundamentales ............................................. ...................................... 40

6.5. Análisis de Entidades segmento C- 91 (Finlandia), F9 (España) y 63 (Francia) .. 41

7. MEJORAR LA FASE ________________________________________42

7.3. Implementación de acciones preventivas .............................................. .............. 44

7.3.2. acciones preventivas solución estándar (Segmento B Segmento C +) ...................... 47

7.3.3. Preventivas acciones-apalancamiento de la solución general para el resto de entidades ....... 50

7.4. resultados de mejora: “antes” y “después” de datos ....................................... ...... 50

8.3. Proyecto beneficia a la cuantificación ............................................... ......................... 53

8.3.1. BPO clientes internos: T & E en equipo y equipo de banca. .................................... 53

8.3.2. clientes de BPO externa: los empleados de HP ............................................ ............... 53

8.4. aprendizajes y recomendaciones del sistema .............................................. ........ 54

• T & E: Viajes y entretenimiento

• EMEA: Europa, Meddle Oriente y África.

• TRAMS: solicitud de reembolso utilizada por HP.

• VOC: Voz del cliente.

• CTQ: críticos para la calidad.

• TER: Viaje informe de gastos.

• BPO: externalización de procesos de negocio.

• DPMO: Los defectos por millón de oportunidades.

• DPU: defectos por unidad.

• DPO: Defectos por oportunidad.

• DMAIC: Definir, Medir, Analizar, Mejorar y Controlar.

• GHRMS: Base de datos global de los recursos humanos.

• SIPOC: Proveedores, entradas, procesos y salidas.

2. Antecedentes del Proyecto

2.1. Introducción a HP BPO

En particular, las empresas buscan Business Process Outsourcing (BPO) a:

mejores sistemas de TI y una mejor escala.

• Mejorar los controles financieros y cumplimiento de la normativa.

y la mejora continua de la calidad.

• Aumentar la flexibilidad operativa y minimizar el uso de capital.

• Enriquecer los procesos con tecnología y herramientas modernas.

• Aumentar la transparencia de las operaciones.

en una Empresa Adaptable más delgado.

invertido en tecnologías facilitadoras de vanguardia.

tecnológica. Mediante la combinación de su experiencia en torno a la infraestructura, aplicaciones y procesos, HP es capaz de

través de la contratación externa.

activos fijos, en general libro de contabilidad, contabilidad de proyectos, y

entrenados que cualquier otro proveedor, a excepción de GE y Wipro. G Global B usinessServices

necesidades del mundo , 24 horas al dia.

millones de transacciones para clientes en todo el mundo.

2.2. Introdction al proceso de T & E

hacen de esta tarjeta diferente a una tarjeta de crédito estándar:

dos meses después de la fecha de gastos.

empresa será responsable.

2.3. Justificacion de proyecto

2.3.1. El uso de un cuadro de mando integral