ASESORÍA EN LA TRANSFORMACIÓN OPERACIONAL PARA COMPAÑÍA CERVECERA A NIVEL REGIONAL

WILDER DARIO GOMEZ NOREÑA

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2009

ASESORÍA EN LA TRANSFORMACIÓN OPERACIONAL PARA COMPAÑÍA CERVECERA A NIVEL REGIONAL

WILDER DARIO GOMEZ NOREÑA

Pasantía para optar al Titulo de Ingeniero Informático

Directora LYDA PEÑA PAZ

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE

FACULTAD DE INGENIERÍA DEPARTAMENTO DE CIENCIAS DE LA INFORMACION

PROGRAMA DE INGENIERÍA INFORMÁTICA SANTIAGO DE CALI

2009

3

Nota de aceptación: Aprobado por el comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al titulo de Ingeniero informático LYDA PEÑA Directora

Santiago de Cali, Marzo 21 de 2009

4

AGRADECIMIENTOS

El desarrollo de este proyecto de grado ha sido posible gracias a varios factores relevantes y fruto de un enorme trabajo e invaluables aportes que han hecho de esta una idea factible, y aun más que eso, una historia con futuro. Quiero agradecer a mis padres por hacer el esfuerzo y pensar siempre en mi bienestar, dándome la oportunidad de ser hoy un profesional de éxito. A Dios que me dio la vida y me permitió culminar mi carrera, dándome su guía y su respaldo, mostrando soluciones y otorgándome el entendimiento necesario. A la gente que de una u otra manera me aportaron valiosas ideas y a aquellos que dieron las bases necesarias para desarrollar este proyecto.

5

CONTENIDO

pág.

GLOSARIO 12

RESUMEN 14

INTRODUCCIÓN 16

1. OBJETIVOS 18

1.1 OBJETIVO GENERAL 18

1.2 OBJETIVOS ESPECÍFICOS 18

2. PLANTEAMIENTO DEL PROBLEMA 19

3. METODOLOGÍA 20

4. JUSTIFICACIÓN 21

5. ANTECEDENTES 22

6. MARCO DE REFERENCIA CONCEPTUAL 24

6.1 DEFINICIÓN DE ERP 24

6.1.1 Beneficios del ERP 25

6.1.2 Importancia de sistemas ERP 25

6.2 DEFINICIÓN DE SAP 26

6.2.1 Módulos de SAP R/3 27

6.3 EVOLUCIÓN DE SAP R/3 A MYSAP ERP 28

6.3.1 Beneficios de MYSAP ERP 28

6.4 SAP DIRECT STORE DELIVERY (DSD) 30

6

6.4.1 Funciones de DSD 31

6.4.2 Funcionamiento de DSD 31

6.4.3 Ciclo de procesos DSD 32

6.5 BACK OFFICE EN EL CICLO DSD 34

6.6 CONTROLES SOX PARA LOS PROCESOS 36

7. DESARROLLO DEL PROYECTO 38

7.1 SITUACIÓN ACTUAL 38

7.1.1 Asignación de límite de crédito 39

7.1.1.1 Requerimiento liberación de pedidos bloqueados 39

7.1.1.2 Requerimiento actualización masiva de límite de crédito 39

7.1.1.3 Requerimiento para portal de autorización de límites de crédito 40

7.1.2 Cobranzas 41

7.1.2.1 Requerimiento para ruta de cobranza 41

7.1.2.2 Requerimiento de cobranzas electrónicas 41

7.1.2.3 Requerimiento de cobranzas automáticas 42

7.1.3 Liquidación caja de recaudo 42

7.1.4 Conciliación bancaria 43

7.1.5 Proceso de disputas 45

7.1.5.1 Requerimiento del proceso de disputas 45

7.2 PROPUESTAS DE MEJORA 45

7.2.1 Asignación de límite de crédito 47

7.2.1.1 Asignación de límite de crédito para clientes nuevos 48

7

7.2.1.2 Solicitud de aumento de límite de crédito 48

7.2.1.3 Asignación de límite de crédito para eventos o temporadas 49

7.2.1.4 Ejecución proceso credit scoring para asignar nuevo límite de crédito en clientes con histórico de ventas.

50

7.2.1.5 Liberación de límite de crédito y pedidos 51

7.2.2 Proceso de cobranzas 53

7.2.3 Proceso liquidación en caja de recaudo 56

7.2.3.1 Contabilizaciones contra cuenta de banco 56

7.2.3.2 Generación de reportes de cierre de caja 56

7.2.3.3 Compensación cuenta cobrador al efectuar el cierre 57

7.2.4 Conciliación bancaria 58

7.2.4.1 Carga del extracto bancario 59

7.2.4.2 Conciliación de los movimientos bancarios 59

7.2.4.3 Errores durante la conciliación bancaria 60

7.2.4.4 Registro no existente 60

7.2.5 Proceso de disputas 61

7.2.5.1 Falsificación de las vías de pagos excepto 62

7.2.5.2 Manejo de deudas vencidas 63

7.2.5.3 Manejo de provisión 63

7.2.5.4 Desconocimiento del pago del cliente 63

7.2.5.5 Aplicaciones erróneas en cuanto al cobro 64

7.3 IMPLEMENTACIÓN 64

7.4 PRUEBAS UNITARIAS 65

8

7.4.1 Pruebas en el sistema 66

7.4.2 Datos de prueba 67

7.4.2.1 Documentación para las pruebas unitarias 67

7.4.3 Documentación para las pruebas unitarias 67

8. VALIDACIONES 69

9. EVALUACIÓN DEL MODELO 70

10. BALANCE DEL PROYECTO 71

10.1 NIVEL DE CUMPLIMIENTO DE LOS OBJETIVOS PROPUESTOS 71

10.2 DIFICULTADES ENCONTRADAS 72

11. CONCLUSIONES 74

12. RECOMENDACIONES 75

BIBLIOGRAFÍA 76

ANEXOS 78

9

LISTA DE TABLAS

pág. Tabla 1. Módulos de SAP R/3 27

Tabla 2. Clasificación de Riesgo del Cliente 50

10

LISTA DE FIGURAS

pág.

Figura 1. Estructura de SAP R/3 27

Figura 2. Ciclo en el cual BackOffice esta involucrado 29

Figura 3. Ciclo de Proceso DSD 32

Figura 4. Estructura organizativa del proyecto 33

Figura 5. Ciclo de Conciliación Bancaria 34

Figura 6. Asignación de límite de crédito 47

Figura 7. Configuración de liberación de Pedidos en SAP 51

Figura 8. Ciclo de Conciliación Bancaria 58

Figura 9. Proceso de Conciliación Bancaria 60

Figura 10. Ciclo del Manejo de Disputas 62

11

LISTA DE ANEXOS

pág.

Anexo A. Liquidación de caja de recaudo 78

Anexo B. Asignación de limite de crédito 82

Anexo C. Cobranza en punto de venta 85

Anexo D. Cobranza en backend 87

Anexo E. Manejo de disputas 91

Anexo F. Conciliación bancaria 96

Anexo G. Script de prueba del límite de credito 98

Anexo H. Script de prueba del proceso de disputas 101

Anexo I. Script de prueba del proceso de cobranzas 103

Anexo J. Script de prueba del proceso de conciliación bancaria 105

Anexo K. Firma de aprobación de escenarios fbo 107

12

GLOSARIO BI. BUSINESS INTELLIGENCE: es una herramienta de apoyo a la decisión para captar, informar, y analizar un subconjunto de datos de la organización sin afectar a los sistemas operativos. A través de la utilización de un almacén de datos, los datos se almacenan y se utilizan para desarrollar la base de datos dimensional que se utiliza para el análisis y la presentación de informes a la unidad de toma de decisiones dentro de la organización. DSD. DIRECT STORE DELIVERY: es un escenario empresarial que se utiliza en la industria de bienes de consumo para la distribución secundaria de dichos bienes entregados al cliente final, sin pasar por el almacén del minorista. ERP: sistema de información orientado hacia la contabilidad, que permite identificar y planificar el total de los recursos que necesita una empresa para tomar, hacer, enviar y contabilizar los pedidos de los clientes. Las siglas significan, en inglés, “Sistema de Planificación de Recurso Empresariales”. FBO – BO. FINANCIALS BACK OFFICE: incluye los sistemas y procesos que ofrezcan la administración como también el apoyo a la empresa en la parte contable y financiera la cual nos permite medir la "línea" de rendimiento. FI – CO: es un módulo de SAP el cual sirve para generar informes financieros utilizados para efectos de información externa por ejemplo, hojas de balance y estados de Pérdidas y Ganancias. Estos informes suelen cumplir con las normas generales de contabilidad establecidas por las autoridades locales. HAND HELD (HH): dispositivo manual el cual contiene una aplicación específica para la gestión de distribución de productos basada en rutas de entrega integrada con la solución de reparto de SAP. Un conductor DSD visita una serie de clientes basado en una ruta preestablecida, mediante el dispositivo se puede gestionar las ordenes de entrega, facturas, cobros entre otros. R/3: sistema abierto, diseñado para cubrir de forma global y en tiempo real, las necesidades de gestión o información de corporaciones de tipo medio/grande. Está constituido por un conjunto de módulos integrados que cubren una amplia variedad de funciones del negocio. Utiliza la tecnología cliente-servidor.

13

SAP AG: empresa alemana creadora del sistema SAP, constituye hoy en día el distribuidor número uno de software de aplicaciones de negocios estándar y el distribuidor independiente de software en el mundo. Las siglas del nombre hacen referencia a Sistemas, Aplicaciones y Procesamiento de Datos. SFA: Sales Force Automation, sistemas que proporcionan un medio de vendedores de ventas para acceder a información de soporte (como los controles de existencias y los datos de los clientes) en tiempo real.

14

RESUMEN

La implantación de un sistema operativo integrado, como también el adaptar funcionalidades de mejora, se presenta como una actividad que es cada día más frecuente entre las empresas; anualmente se invierten millones de dólares en lograr mejorar los sistemas sobre los cuales se llevan a cabo las operaciones de las mismas. Paradójicamente muchas de estas inversiones lejos de mejorar el desempeño de las organizaciones, terminan resquebrajando su operatividad, puesto que se termina implantando un sistema que no siempre satisface las necesidades de la empresa. En Colombia una de las más importantes Empresas de consumo masivo ha venido realizando un proceso gradual de cambios, a través de los cuales ha llevado a cabo reestructuraciones, como manera de lograr tener un mayor control de la misma. A nivel regional, la Empresa no presenta una armonización de los sistemas operativos sobre los cuales se soportan las operaciones que realiza. Las oficinas principales manejan el sistema SAP R/3 al igual que muchas de sus plantas; sin embargo, las sucursales comerciales o sucursales de venta que la empresa posee a nivel regional y que constituyen su contacto directo con el consumidor, no tienen armonizados los procesos entre las mismas. Dado que uno de los objetivos de la Empresa es la estandarización de sus procesos y de los sistemas que lo soportan, se decidió migrar, de manera gradual, las operaciones realizadas a nivel de las sucursales comerciales, del sistema SAP R/3 4.7 al sistema SAP R/3 6.0 con la funcionalidad del módulo DSD de reparto. Para lograr cumplir con los objetivos establecidos se llevó cabo un proceso de análisis de cada uno de los procesos no comerciales, de manera de poder identificar las principales características de los mismos y sus debilidades. A través de esta actividad, se pudo definir el proceso propuesto para ser ejecutado dentro del sistema SAP R/3 y DSD; esta propuesta además de cubrir las necesidades de los usuarios presentaba características nuevas que le aporta mayor valor a la operación. Debido a que se realizó una reingeniería sobre los procesos, fue posible modificar la manera como algunos procesos eran ejecutados, estableciéndose nuevos

15

escenarios que eran perfectamente válidos bajo el sistema SAP R/3 y que mejoraban, considerablemente las operaciones. Se desarrollaron actividades de análisis para los procesos como también se definieron los requerimientos necesarios para la buena ejecución del proyecto; de esta manera se levantaron los flujos de procesos con lo cual se ajustarían al sistema operativo y que no tuviese complicaciones al momento de hacer el empalme entre el módulo FI el cual es el módulo perteneciente al equipo de Back Office a la nueva funcionalidad del modulo DSD. Los cambios propuestos y ejecutados en este Proyecto, forman parte de un proceso gradual a través del cual se está homologando el sistema operativo que soporta las actividades de la Empresa de consumo masivo; no debe pensarse que la información contenida en este informe constituye el final de un proceso, por el contrario, a través de este Proyecto se da inicio a nueva etapa dentro de la Organización.

16

INTRODUCCIÓN En la actualidad, los Sistemas de Información constituyen herramientas fundamentales en la toma de decisiones al interior de las organizaciones. Con más frecuencia las empresas llevan a cabo cuantiosas inversiones para cambiar sus plataformas tecnológicas, generando complejos procesos de “migración tecnológica e informática” que tienen como consecuencia cambios en sus estructuras funcionales. Así pues, un Sistema de Información es una estructura interactiva formada por personas, equipos y métodos, a partir de la cual se crea un flujo de información capaz de proporcionar una base adecuada para la toma de decisiones. En la actualidad no es suficiente con emplear versiones genéricas de la herramienta, es por esto que se habla de Sistemas Expertos, es decir, aquellos sistemas computarizados capaces de brindar información a los gerentes para tomar decisiones y solucionar problemas en cualquier etapa de los procesos a su cargo. Uno de los principales representantes de los llamados “Sistemas Expertos”, son los denominados Sistemas de Planeación de Recursos (ERP por sus siglas en inglés), los cuales son la tercera etapa de una cadena, a través de la cual se buscaba principalmente mejorar la información y planeación dentro del proceso productivo. En el año 1998, una de las más importantes empresas de consumo masivo del país decidió adoptar el sistema de información SAP R/3. Debido a la magnitud de las operaciones que dicha empresa lleva a cabo y a las modificaciones realizadas en su estructura organizacional, la implantación del sistema se ha realizado de manera gradual. Uno de los principales cambios estructurales que se implementó fue la creación de tres unidades estratégicas básicas, a partir de las cuales ha logrado aumentar el control de cada una de sus áreas, brindando respuestas rápidas a los clientes. La implementación del sistema SAP R/3 ha permitido simplificar procesos y reducir costos, al punto que en año 2003 se inició un proceso de reorganización de todas las empresas que conforman una de las unidades estratégicas de la organización.

17

Entre las consecuencias inevitables de esta reorganización se encuentran los ajustes a nivel de las empresas comercializadoras de dicha unidad estratégica. La implantación de la Plataforma Tecnológica SAP R/3 con el modulo DSD, dentro de las sucursales de venta, constituye un paso esencial para estandarizar todos sus procesos. Teniendo en cuenta este aspecto, en este trabajo de grado se evaluarán las operaciones financieras de todos los procesos de asignaciones de límites de créditos, pagos, diferentes medios de recaudo e inconvenientes generados al momento de efectuar los cobros, para llegar a unas conclusiones y recomendaciones que permitirán fortalecer y dar continuidad a este nuevo proceso en la organización. Los valores agregados no solo son del orden técnico, sino que trascienden al campo de los ingresos, del mejoramiento de procesos y por supuesto, aportan a la consolidación empresarial.

18

1. OBJETIVOS 1.1 OBJETIVO GENERAL Analizar el proceso de rediseño del modelo de ventas y distribución de clase global de todos los productos del grupo con una clara orientación a la satisfacción de las necesidades de sus clientes.

1.2 OBJETIVOS ESPECÍFICOS • Conocer íntegramente los procesos comerciales y las diferentes funciones que giran en torno al modulo de Back Office.

• Conocer el estado en que se encuentran los procesos del modulo Back Office.

• Diseñar procesos que permitan la optimización del proceso de ventas de acuerdo con las necesidades identificadas por la empresa, de acuerdo con la arquitectura y los servicios que presta la plataforma SAP R/3.

• Diseñar los procesos de Back Office para soportar el modelo comercial propuesto.

• Hacer la comparación de los procesos actuales y los procesos propuestos para identificar los beneficios que la Empresa puede obtener a partir de su implantación.

• Realizar la documentación para el inventario de pruebas.

19

2. PLANTEAMIENTO DEL PROBLEMA En un mercado cada vez más competitivo en el cual, el aumento vertiginoso del flujo de información y de las técnicas para efectuar su manejo son frecuentes, las empresas optimizan sus procesos como medio para maximizar sus ingresos y alcanzar un reconocimiento y posicionamiento sólido. En la búsqueda de ese objetivo, plantean e implementan procesos de mejoramiento continuo, en el cual las plataformas tecnológicas son fundamentales. En este trabajo se analizan y proponen acciones concretas en torno al rediseño del modelo comercial de una empresa de consumo masivo, que tiene presencia en los países andinos, considerando que la adecuada integración de los procesos de facturación, cobranza, venta y distribución le permitirán maximizar su nivel de ingresos y consolidación en el mercado.

20

3. METODOLOGÍA Para cubrir los objetivos se debió, en primer lugar, establecer un marco de referencia conceptual para entender el funcionamiento del sistema de información SAP R/3 y las mejoras propuestas. Unido al marco de referencia conceptual, se presento un marco de referencia organizacional, a partir del cual se describía la organización dentro de la cual se llevo a cabo el estudio. Se analiza la organización como un todo y luego se hace una descripción detallada de los procesos que se afectan directamente con las acciones de mejora. Se hace un análisis de los requerimientos funcionales que se presento, luego de detallarlos bien y hacer la revisión necesaria se procedió a realizar el rediseño de los flujos de procesos que se van a mejorar incluyendo los requerimientos. Finalmente se analizarán las ventajas y desventajas del modelo propuesto para la organización.

21

4. JUSTIFICACIÓN

La compleja y creciente competencia por el mercado hace que las Empresas de los sectores de productos de consumo masivo y de servicios, principalmente, hayan explorado de manera exhaustiva el mejoramiento de sus procesos productivos y hayan definido y puesto en marcha estrategias de marketing, que si bien han traído importantes consecuencias operacionales, parecen haber agotado el espacio de la innovación. Por tal razón, el interés de muchas empresas, como es el caso de la estudiada en este trabajo de grado, se centra en el mejoramiento continuo de la gestión logística, informática y tecnológica de la cadena de suministro para ofrecer un mejor servicio y conseguir los máximos ingresos posibles. En este caso particular, el aprovechamiento de SAP ERP y la adición del módulo de “Distribución Directa en Tiendas” (DSD por sus siglas en inglés) mediante el cual se hacen llegar los productos directamente a los minoristas, respondiendo oportunamente a las necesidades del mercado, con una clara orientación hacia las estrategias de mercadotecnia y comercialización. Su mejoramiento continuo, sin lugar a dudas, será un factor determinante en el mantenimiento de esta ventaja competitiva. El proceso de mejoramiento continúo del sistema de información empresarial SAP R/3, en pro de optimizar las relaciones cliente/usuarios – Empresa no es exclusivo de las Empresas del sector de bienes de consumo masivo. Se ha extendido a empresas del sector de servicios públicos domiciliarios, donde es ampliamente conocido el caso de la Empresa de Acueducto y Alcantarillado de Bogotá - ESP, quien en el año 2002, con una inversión cercana a los 50 millones de dólares convirtió al SAP en el eje central de todos sus procesos comerciales, técnico – operativos, financieros, de cartera, de gestión del talento humano, manejo de nómina, etc. En 2008 realizó de manera exitosa un proceso de up grade y a comienzo de 2009 realizó la implantación del módulo de presupuesto público como parte de la implementación de la nueva ley de presupuesto público que expidió el gobierno nacional. Actualmente está estudiando la posibilidad de implementar el módulo de CRM (Customer Relationship Managment) como respuesta a las crecientes necesidades de sus usuarios y a las condiciones reales de prestación de los servicios de acueducto y alcantarillado∗. Es claro que el tema del mejoramiento continuo y afianzamiento de los procesos afecta al sistema de información empresarial SAP R/3, es una necesidad inobjetable en la que todas las empresas, no solo privadas, sino también públicas, que han decidió implantarlo avanzan exitosamente.

∗ Información suministrada por la Dirección de Apoyo Comercial de la Empresa de Acueducto y Alcantarillado de Bogotá ESP

22

5. ANTECEDENTES La empresa objeto de estudio decidió hacer presencia y/o ampliar su participación en algunos mercados del mundo, como el Latinoamericano, el cual tiene importantes perspectivas de crecimiento en el mediano plazo.

En la década de los 90’s una de las empresas productoras de consumo masiva en el sector de bebidas en Colombia, empezó a convertirse en un jugador más activo en términos de movidas internacionales. Para el efecto, realizó estrategias comerciales en pro de un mejor posicionamiento en una industria que como la de bebidas, se ha venido consolidando con gran rapidez en el mundo entero. A Ecuador ingresó a comienzos de la década de los noventa, cuando adquirió un paquete mayoritario de sus dos principales cerveceras. En diciembre del 2001, la compañía adquirió la Cervecería Nacional, la cervecería más importante de Panamá. El 19 de julio de 2002, la compañía adquirió la Cervecería Nacional, la cervecería más importante de Perú y a finales de 2002, se expandió a Bolivia y Venezuela, convirtiéndose en la compañía más grande de Suramérica.1

A la par de su expansión comercial, la compañía por su gran tamaño y su alto índice de productividad reconoció que se hacia necesario la implantación de una plataforma tecnológica, la cual permitiera la integración de procesos y la organización de la información que se estaba generando en grandes cantidades. De este modo, se concretó la implementación de la plataforma tecnológica SAP a finales de la década de los 90’s, para dar apoyo en áreas estratégicas del negocio. Entre ellas se destacan manejo de presupuestos, consolidación financiera, mantenimiento, desarrollo de personal y soporte de la toma de decisiones, que permitirían sostener el rápido crecimiento de la corporación y la integración flexible, en línea y en tiempo real de las diferentes empresas que se habían ido sumando al grupo. Teniendo en cuenta lo señalado, se realizó el proyecto de la implantación de SAP, cuyo objetivo primordial era establecer un único modelo de negocio corporativo en las compañías que integraban la organización cervecera homologando y estandarizando sus procesos, sus datos y el manejo de la información del negocio. Adicionalmente, se buscaba determinar el modelo base para su réplica, como la estandarización de procesos de las otras compañías ubicadas en Latinoamérica. Así se facilitaría la consolidación de información corporativa sin importar las fronteras, dando a la organización una herramienta potente de análisis de

1 ¿Qué es Bavaria? [En línea] Bogota D.C.: Grupo Bavaria, 2008 [consultado 06 de Octubre de 2008]. Disponible en Internet: http://www.grupobavaria.com/espanol/queesbavaria/historia.php

23

información de tipo estratégico que utilizaría como base la solución SAP Strategic Enterprise Management, sobre la plataforma de Business Warehouse. La versión SAP que se manejó hasta diciembre de 2008 era SAP ERP R/3 4.6c y se están manejando las funcionalidades estándar del R/3. Actualmente se está desarrollando un proyecto para lograr la estandarización de los procesos de las compañías y para realizar mejoras en los servicios que presta. La plataforma que se esta utilizando es SAP ERP R/3 versión 6.0, que agrega nuevas funcionalidades y presta una mayor cobertura de servicio.

24

6. MARCO DE REFERENCIA CONCEPTUAL Una parte importante del éxito de las empresas que producen bienes de consumo masivo está en el manejo consistente de su cadena de suministro. La creciente demanda de los consumidores está presionando a las empresas para que busquen herramientas a partir de las cuales satisfagan las necesidades de los agentes, con productos de mayor calidad y una red de distribución robusta. En este entorno, el éxito depende de la habilidad para aprovechar con rapidez las nuevas oportunidades, responder a los nuevos gustos y demandas de los consumidores y adaptarse a las nuevas condiciones del mercado, principalmente aquellas relacionadas con otras empresas que pueden definir estrategias no solo de mejoramiento continuo de procesos, sino también de precios que en algunas circunstancias no necesariamente reflejan las condiciones del mercado. La Empresa decidió que el éxito de las actividades inmersas en la cadena de suministro se encuentra en la implementación de herramientas tecnológicas que faciliten el intercambio de información, como la plataforma tecnológica SAP ERP la cual brinda una infraestructura integral, abierta y flexible que permite a la compañía tener un control de sus las operaciones. Para el efecto, en las siguientes secciones se hará una presentación de lo que es un sistema ERP, el cual sirve como marco referencial para el desarrollo de las acciones de mejora propuestas, las cuales son el eje central de este trabajo. 6.1 DEFINICIÓN DE ERP El término ERP es “la abreviación de Enterprise Resource Planning, herramienta desarrollada a comienzos de 1990 por el Gartner Group's Computers-Intégrate Manufacturing Services de Stanford, Estados Unidos, los cuales son sistemas integrados de gestión empresarial basados en el ofrecimiento de una solución que permite a las empresas evaluar, implementar y gestionar más fácilmente su negocio”.2

2 RAMIREZ CORREA, Patricio y GARCIA CRUZ, Rosario. Una investigación empírica sobre los factores que afectan el éxito de los sistemas ERP en Chile: El éxito de los sistemas ERP. En: Revista Informatica. Abril, 2005, No. 11 [en línea]. Santiago de Chile: Universidad de Concepcion, 2005 [consultado 06 de Octubre de 2008]. Disponible en: www.inf.udec.cl/revista/ediciones/edicion11/InvestigacionEmpirica.pdf

25

El sistema ERP es un paquete del software comercial que logra la integración de toda la información que fluye a través de la compañía: información financiera y contable, información de recursos humanos como también la información de todos los productos o servicios de la compañía. 6.1.1 Beneficios del ERP. Los siguientes puntos muestran cuales son los beneficios del ERP.

• Disponer de una solución integrada para muchas de las funciones de la compañía. • Garantía de una actualización continua y más inmediata de la aplicación a las necesidades del negocio y la reducción de los costos fijos. • Optimización de los procesos empresariales. • Acceso a toda la información de forma confiable, precisa y oportuna (integridad de datos). • La posibilidad de compartir información entre todos los componentes de la organización. • Eliminación de datos y operaciones innecesarias (o redundantes). • Reducción de tiempos y de los costos de los procesos (mediante procesos de reingeniería). • Fácil adaptabilidad. Los sistemas ERP se pueden modificar a través de la redefinición de sus distintos procesos de negocio, esto hace fácil que se adapte y reestructure para satisfacer los nuevos requerimientos. • Mejoras en “escalabilidad”. Debido a un diseño modular y estructurado los sistemas. • Alcance fuera de la organización. Los módulos de extensión de los sistemas ERP como son los CRM ( Customer Relationship Management - Gestión de la relación con el cliente), y los SCM ( Supply Chain Management - Gestión de la cadena de abastecimiento) hacen que la organización se integre con clientes y proveedores, fuera de los límites tradicionales de la empresa. • Comercio electrónico y e-Business. Por una parte esto es posible debido a que la infraestructura tecnológica de los sistemas ERP soportan procesos en Internet, lo que es básico para el comercio electrónico, y por otra parte, a que la adopción de los sistemas ERP desarrolla una cultura de colaboración3.

En resumen, el propósito fundamental de un ERP es apoyar a los clientes del negocio, lograr tiempos rápidos de respuesta a sus problemas, así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de operación. 6.1.2 Importancia de sistemas ERP . Estas aplicaciones se han asentado como soluciones integrales en la mayor parte de las funciones a desarrollar por la

3VELASCO, Arelis. Definición de ERP [en línea]. Caracas: Sistema de Información Gerencial, 2008, [Consultado el 10 de Noviembre de 2008]. disponible en Internet: <http://es.geocities.com/alexis_velazco/e3/foro/ii.html>.

26

empresa. Esto ayuda a dichas empresas a entender mejor su actividad, estandarizar sus procesos de negocios y definir mejores políticas. Las ERP ayudan a crear procesos más eficientes con lo que las empresas se pueden concentrar más en otros esfuerzos, como es el servir a sus clientes y maximizar los beneficios. 6.2 DEFINICIÓN DE SAP SAP es un software abierto, basado en la tecnología cliente/servidor, diseñado para manejar las necesidades de información de una empresa. SAP R/3 es la versión mejorada de un producto anterior (sistema R/2) que ha permitido a SAP AG convertirse en la empresa líder de software empresarial. No se limita a ser un simple paquete de programas informáticos; SAP R/3 va más allá: supone todo un equipo de personal, programas, comunicaciones trabajando 24 horas para la empresa con el objetivo de tener mayor control de los procesos y servicios que la compañía emplea.

El sistema R/3 es un sistema "on-line" y en tiempo real diseñado para cubrir de forma global las necesidades de gestión o información de corporaciones de tamaño mediano o grande. Consta de un conjunto de módulos totalmente integrados que cubren una amplia variedad de funciones de negocio entre las que se incluyen: Gestión Económico Financiera (Contabilidad General, Contabilidad Analítica, Activos Fijos, Módulo Financiero, etc.), Logística, Comercial y Distribución, Producción (Planificación, Control, Sistemas de Producción en serie, lotes, JIT, entre otos.), Control de Calidad, Mantenimiento, Gestión integrada de Proyectos, Recursos Humanos, Workflow, etc4.

SAP R/3 cubre todas las áreas funcionales de la empresa. Adicionalmente se están desarrollando y en su caso mejorando, las llamadas Soluciones Industriales, lo que significa una mayor adecuación del sistema SAP a las particularidades de cada negocio sectorial: Petróleo, Automoción, Publishing, Laboratorios Farmacéuticos, Retail, Alimentación, Sector Público, Telecomunicaciones, etc. Las aplicaciones o módulos de SAP R/3 se dividen en tres grandes áreas: financiera, logística y de recursos humanos. Estos tres grupos no son independientes unos de otros. Además de éstos, existen otros componentes. Los principales módulos del sistema R/3 incluyen cientos de procesos de negocio para satisfacer las necesidades de las empresas en sus aplicaciones de gestión e información. Las aplicaciones del programa funcionan de modo integrado, de

4 Sistema R/3 [en línea]. Madrid: trípode, 2000 [Consultado el 07 de Noviembre de 2008]. disponible en Internet: http://usuarios.lycos.es/cblsap/sisr3.html

27

forma que existe una conexión implícita entre los procesos financieros y logísticos, y también con los humanos.

Figura 1. Estructura de SAP R/3

Fuente: Modulos De Sap R3 [En linea]. Madrid: Mundo SAP.com, 2006 [Consultado el 09 de Septiembre de 2008]. Disponible en: http://www.mundosap.com/foro/showthread.php?t=281

6.2.1 Módulos de SAP R/3 Tabla 1. Modulos de SAP R/3

Fuente: Modulos De Sap R3 [En linea]. Madrid: Mundo SAP.com, 2006 [Consultado el 09 de Septiembre de 2008]. Disponible en: http://www.mundosap.com/foro/showthread.php?t=281

FI CONTABILIDAD FINANCIERA

MM GESTION DE MATERIALES

IM INVERSIONES

TR TESORERIA

QM CALIDAD

CO CONTROLLING

PP PRODUCCION

LO GESTION DATOS GENERALES DE LOGISTICA

HR GESTION DEL PERSONAL

SM GESTION DEL MANTENIMIENTO

EC ENTERPRISE CONTROLLING

SD VENTAS Y DISTRIBUCION

IS-R INDUSTRY SOLUTION RETAIL

PS GESTION DE PROYECTOS

PM GESTION DEL MANTENIMIENTO

28

6.3 EVOLUCIÓN DE SAP R/3 A MYSAP ERP MySAP ERP constituye una versión actualizada de la antigua SAP R/3 software, presenta una nueva plataforma (NetWeaver) así como nuevas tecnologías de interfaz, nuevos análisis y un número considerable de nuevas funcionalidades. MySAP ERP brinda funciones específicas de industria y mejores prácticas basadas en tres décadas de experiencia SAP. Esto quiere decir que se puede lograr una mejora en la gestión de la empresa convirtiendo los datos en información, la información en conocimiento y el conocimiento en acción. MySAP ERP se puede expandir fácilmente para brindar funcionalidades mejoradas mediante la incorporación de Soluciones como mySAP Customer Relationship Management, mySAP Supplier Relationship Management, mySAP Product Lifecycle Management y mySAP Supply Chain Management. Otra de las alternativas que brinda es la posibilidad de pasar fácilmente a mySAP Business Suite, que expande su sistema para ingresar al mundo interempresarial. mySAP Business Suite es la familia más completa de soluciones de negocio, que ofrece procesos adaptables, integración total y fácil colaboración a través de Internet. MySAP ERP se basa en la tecnología SAP NetWeaver, una amplia plataforma de aplicaciones e integración que proporciona el soporte necesario para llevar a cabo procesos de negocio inter funcionales, reduce su costo total de propiedad (TCO) ya que requiere de una menor integración personalizada y ofrece una completa gestión del ciclo de vida para su solución. Esta plataforma basada en servicios Web constituye el sustento de Enterprise Services Architecture, y permite alinear personas, información y procesos de negocios trasponiendo las barreras tecnológicas y empresariales. 6.3.1 Beneficios de MYSAP ERP. � Nuevas eficiencias en procesos de negocio end-to-en d integrados: lleva a cabo procesos de negocio completos y totalmente integrados para finanzas, gestión del capital humano, gestión de operaciones y servicios corporativos y a la vez optimiza las inversiones en informática relacionadas e incrementa los beneficios del negocio.

29

� Agilidad de negocios: trabaja en tiempo real para tomar decisiones con mayor celeridad y reaccionar más rápidamente ante las oportunidades que se presentan en el mercado. � Menor costo total de propiedad: con la potencia de SAP NetWeaver, amortiza las inversiones de informática existentes, reduce la complejidad de la integración y minimiza la necesidad de un desarrollo personalizado. Esta solución es fácil de instalar y ofrece flexibles opciones que simplifican la implementación y las actualizaciones, lo cual reduce aun más el costo de propiedad. Al brindar soluciones que son inter operables con tecnologías de terceros, SAP ayuda a las organizaciones a proteger sus actuales inversiones en informática. � Una funcionalidad creciente que puede ser implement ada sobre la marcha: mejora el flujo de caja y reduce los elevados costos relacionados con los préstamos, implementando funcionalidades clave en la medida en que se vayan ajustando las necesidades, según los requerimientos de la empresa van siendo analizados y requeridos para su implementación.

– Estructura MYERP. Teniendo implantada la plataforma ERP se desea anexar un nuevo modulo para soportar un modelo de venta directa el modulo DSD. En el siguiente grafico se mostrara la estructura tecnológica de myERP el cual es la estructura que se va a utilizar en el proyecto.

Figura 2. Estructura de myERP

Fuente: Project Charter. Bogota D.C, 2008. 1 Archivo de Computador.

30

6.4 SAP DIRECT STORE DELIVERY (DSD) Es un escenario empresarial que se utiliza en la industria de bienes de consumo para la distribución secundaria de dichos bienes entregados al cliente final, sin pasar por el almacén del minorista. Además de algunas configuraciones estándar de Sales and Distribution (SD) y parametrizaciones básicas de SAP Direct Store Delivery (DSD), en este building block que exactamente son unidades preconfiguradas y reutilizables suministradas por Best Practices SAP, que permiten implementar cualquier solución de forma rápida y sin problemas, estas proporcionan parametrizaciones de configuración para los componentes DSD siguientes: • Control de visitas � Definición de tipos de calendario, grupos de visita, tipos de planes de visitas y rangos de números. � Especificación de las clases de documentos de ventas utilizados en el proceso DSD. • Planificación de transporte � Especificación de las clases de entrega permitidas, utilizando el proceso de planificación dinámica de transporte. � Definición de límites de capacidad. • Definición de unidades de carga � Se especifican las unidades de carga que se van a tener almacenadas y las que van a ser entregadas. • Configuración de control de salida DSD � Lista de visitas y nota de entrega valorada. • Especificación de la función de pagador al contado � Se realiza la especificación de las funciones que debe tener la persona que hace el pago de contado.

31

• Contabilización de rutas � Definición de una nueva unidad organizativa: oficina de liquidación, incluida la determinación � Definición de una clase de liquidación, incluida la determinación Parametrizaciones del proceso de compensación � Definición de clases de operación de volumen de negocios de cliente y su integración en el control de documentos. 6.4.1 Funciones de DSD.

� Poner mercancías a disposición rápidamente para tiendas y clientes. � Influir directamente a los clientes finales como fabricante de bienes de consumo. � La función de control de salida DSD permite ver e imprimir notas de entrega. valoradas y listas de visitas. � Ver e imprimir listas de pedido y carga. � Ver el stock del camión durante la ejecución de la ruta mediante una consulta comercial. � Comparar los límites de capacidad de los vehículos con las unidades de carga del documento de transporte. � Introducir datos de ruta mediante la nueva función de entrada de datos de ruta. � Optimizar el proceso de liquidación en ventas y distribución. 6.4.2 Funcionamiento de DSD. Usando la capacidad por manejo de grandes órdenes, las ventas y profesionales de entrega pueden ingresar las mismas en los dispositivos móviles y luego crearlas en el sistema principal. Los órdenes se liberan desde el almacén escogido, consolidando y cargando en los camiones para ser entregado según los ciclos de entrega periódicos especificados por el cliente. La funcionalidad contable en la ruta le permite al chofer comprobar los materiales, hacer las entregas, regresar al almacén para registrar los materiales devueltos y las cobranzas realizadas. El modulo DSD hace una interacción con diferentes módulos de SAP lo cual lo hace un modelo integrador el cual empieza desde la toma de pedido al cliente pasando por la validación de la información tomada lo cual consiste en verificar si el pedido es correcto si los productos que se han pedido se encuentran en disposición para ser puestos en proceso de despacho, también se valida la información del cliente tal como lo es si tiene partidas vencidas o si no tiene crédito para poder ser entregado el pedido, si el caso es exitoso se procede a

32

verificar la forma de pago que va a realizar el cliente ya que se cuentan con diferentes vías de pago para hacer efectivos los cobros, luego se finaliza con el despacho de la mercancía hacia la tienda del cliente. 6.4.3 Ciclo de procesos DSD. Figura 3. Ciclo de Procesos DSD

Fuente: Project Charter. Bogota D.C, 2008. 1 Archivo de Computador.

En el siguiente gráfico se ilustra detalladamente la división de los grupos estipulados para el proyecto DSD para la empresa objeto de análisis.

33

Figura 4. Estructura organizativa del proyecto

Fuente: Project charter, Bogota D.C , 2008. 1 Archivo de Computador.

El objetivo del proyecto es llegar al cliente de forma directa para disminuir los problemas de pedido, facturación y despacho para que la Empresa logre un mayor control de sus clientes. En la actualidad este proceso está a cargo de terceros, quienes por el hecho de no estar vinculados directamente a la empresa, pueden generar cuellos de botella. Con la implantación de este nuevo módulo se realizan mejoras en la gestión de entrega y toma de pedidos, logrando una mejor relación entre la empresa y el cliente final, tal que se tendría un mayor control sobre los precios y los productos entregados al cliente.

Master Data Management tenance Policies & Procedures, Files

Definition and Configuration, Upholding Master Data Integrity, A

Master Data Management

Business Intelligence (Executive Dashboards SAP Portal, Tropical Data Marts, Data Ware house SAP BW)

Business Intelligence (Executive Dashboards SAP Portal, Tropical Data Marts, Data Ware house SAP BW)

Technology (SAP Version Upgrade, SAP Hardware Upgrade, SAP Sizing & Update)

Technology (SAP Version Upgrade, SAP Hardware Upgrade, SAP Sizing & Update)

Elements of Sales Force Automation

Direct StoreDelivery

(Order Entry, Shipment Preparation, Download order, Check Out, Physical Delivery, Check In,

Upload of route Data, Product Settlement Delivery Check Out/In)

BackOffice(Credit Management, Cash

Systems Links)

-

BackOffice (Credit Management, Cash

Collection, Finance and Accounting Systems Links)

Change Management (Communications,

Training)

(Cleansing Prior Implementation, Data Management Plan, Data Maintenance Policies & Procedures, Files Definition and Configuration, Upholding Master Data Integrity, Archiving)

Senior Management

Scope Validation (Sponsors,

Country Managing Directors,

Country Vice-Presidents)

34

6.5 BACK OFFICE EN EL CICLO DSD Figura 5. Ciclo en el cual BackOffice esta involucrado

Procesos Back Office Fuente: Project charter. Bogota D.C, 2008. 1 Archivo de Computador Back Office gestiona todos los procesos organizativos que configuran el eje del negocio y dan forma al mismo, pero con los que el cliente no entra directamente en contacto. El Back Office asegura los procesos de la cadena de suministro de la empresa o Supply Chain Management que básicamente es la gestión global de la cadena de abastecimiento se puede definir como la forma de generar valor económico a los accionistas y a los clientes, a través de un modelo de gestión que sincroniza el

8

TToommaa ddee ppeeddiiddoo

•Registrar cobro •Verificar crédito del cliente

•Embarque / •Entrega/ •Picking / Empaque/ Carga

Check out Entrega Física

•Registrar Cobro •Verificar Crédito del cliente •Entrega de productos •Devoluciones •Vacíos •Factura

Check in Materiales

•Confirmar cantidades

Liquidación Ruta

Sincronización HH

Liquidación Caja de

Recolección

•Contabilizar cobranza en cuentas de Banco/Impuesto/ Hurto

2 3

4

7

5

1

Check In Cobranza

•Registrar cobranza recaudada

6

BO

BO

BO

BO

BO

•Generación de Pedidos •Verificación crédito •Contabilizar salida de mercancía •Determinación de diferencias en inventario •Contabilizar y Compensar

35

flujo físico de materiales y la información asociada desde el productor al consumidor final. Este proceso de cadena de abastecimiento se inicia con la recogida del pedido del cliente, continúa con su incorporación a los procesos productivos y finaliza con el recorrido logístico y la entrega. En el Supply Chain Management interviene un extenso entramado de relaciones internas y externas altamente complejo. La coordinación entre lo que se suministra y lo que se solicita supone un proceso crítico en la empresa y en el que, hoy, más que nunca no podemos fallar. Paralelamente al funcionamiento de la propia cadena de suministro, el Back Office acomete toda una serie de actividades que involucran a otras áreas (Finanzas, Recursos Humanos, Logística, etc.) con soluciones tecnológicas que ayudan a su planificación, haciendo que los flujos de información que afectan a los procesos productivos y relacionales, sean fluidos y estén orientados a asegurar la viabilidad y proyección en el tiempo de la empresa. Dentro del equipo de Back Office se busca optimizar los siguientes procesos: • Recaudo: � Gestión de recaudo electrónico y manual. � Cobro electrónico. • Manejo de Disputas: � Manejo y resolución de reclamos. � Mejora en tiempos de respuesta de las disputas. • Facturación: � Facturación en punto de venta y Backend. • Conciliación Bancaria: � Conciliación Bancaria automática. • Manejo de Créditos: � Diferenciación en manejo transaccional por cliente y país. � Manejo de diferencias en las condiciones de pago según liquido o vacío. � Gestión de solicitud, cálculo y asignación de crédito.

36

6.6 CONTROLES SOX PARA LOS PROCESOS En los flujos de procesos que se desarrollaron con base en los temas expuestos, se hace una validación e incorporación de controles SOX que afectan directamente los controles financieros internos, ya sean automatizados o manuales, dependiendo de la interpretación y de las regulaciones existentes en cada país. El objetivo de los controles SOX es hacer la dirección corporativa más rigurosa, las prácticas financieras más trasparentes y a la administración potencial y penalmente responsable por errores. La ley de controles SOX “se aplica a todas las empresas que están registradas en la New York Stock Exchange (NYSE) y la National Association of Securities Dealers by Automatic Quotation, conocida como NASDAQ, y bajo la supervisión de la Securities and Exchange Commission (SEC)”.5. Grandes compañías multinacionales están utilizando SOX como herramienta de gestión que contribuye a hacer más visibles los controles financieros. SOX es un proceso de aprendizaje: conocer los controles críticos que deben ser probados e implementados es un primer paso. Una vez que se identifica el alcance, se pueden implementar las tecnologías apropiadas para facilitar la tarea de cumplimiento. Además, cuando las compañías desarrollen competencias SOX y seleccionen las tecnologías instrumentales, continuarán encontrando nuevas formas de perfeccionar los esfuerzos de cumplimiento. A medida que las compañías comienzan a transitar el camino hacia el cumplimiento de SOX, empiezan a obtener los beneficios de una organización mejor administrada.

5 Sarbanes-Oxley Sox [en línea]: Controles SOX. Madrid: Piramide Digital, 2008 [Consultado el 10 de Noviembre de 2008]. Disponible en Internet: <http://www.piramidedigital.com/Documentos/ICT/pdictleysarbanesoxley2.pdf>

37

– Beneficios de SOX

• Implantación de mecanismos de evaluación de riesgos y revisión de los procesos. • Formalización y divulgación de actividades y responsabilidades. • Implantación de un Código de ética. • Protección de la empresa contra fraudes internos, estableciendo controles y revisiones de delegación de autoridad y aprobaciones. • Comprometimiento de los colaboradores en relación a las mejoras de control. • Elevación del nivel de seguridad de las aplicaciones. • También es importante destacar el hacer viables los controles internos y la evaluación del flujo de información, el mapeo de procesos críticos de las empresas, gestión de los riesgos asociados a estos procesos, asignación de responsabilidades a los responsables internos, identificación de no conformidades con informaciones gerenciales y rapidez en la resolución de riesgos.6

6 SOX [en línea]: Beneficios SOX. Bogota: Software for Excellence, 2008 [Consultado el 10 de Noviembre de 2008]. Disponible en Internet: http://www.softexpert.es/norma-sox.php

38

7. DESARROLLO DEL PROYECTO 7.1 SITUACIÓN ACTUAL Como parte de las actividades llevadas a cabo para elaborar este proyecto, se efectuaron reuniones con los diferentes líderes de los países (Honduras, Salvador, Panamá, Ecuador, Perú, Colombia y Bolivia) en los cuales tiene operaciones la Empresa, con el objetivo de definir las modificaciones a los procesos. Cada uno de los líderes expuso sus propuestas de mejora, posteriormente se analizó la viabilidad de cada una de ellas y se consolidó una sola propuesta que se ajustara al formato estándar de la Empresa. Seguidamente, en la etapa de diseño, contenida en la propuesta de mejora de este documento, se rediseñaron los flujos de procesos, los cuales se enviaron a cada uno de los líderes de los países para su aprobación. En esta fase los líderes efectuaron nuevos ajustes a los flujos, los cuales fueron incorporados en la propuesta final. Los procesos administrativos que se van a analizar, son ejecutados por las sucursales comerciales de la Empresa, en cuya estructura organizacional existe un Área de Ventas, un Área Logística y un Área Administrativa, con las siguientes responsabilidades. • Área de Ventas: se encarga de monitorear todas las actividades que son ejecutadas por el personal de ventas. • Área de Logística: controla todas las gestiones que de una u otra forma están relacionadas con la salida y entrada de productos al almacén. • Área Administrativa: controla que todas las actividades relacionadas con las cuentas por pagar y las cuentas por cobrar de la sucursal se cumplan a cabalidad. El área administrativa durante el proyecto será impactada por mejoras introducidas através de los distintos equipos de trabajo, de los cuales, resalta el quipo de FBO, a continuación se señalan los procesos afectados por las distintas definiciones levantadas.

39

7.1.1 Asignación de límite de crédito. La asignación del límite de crédito se realiza manualmente, haciéndolo un proceso muy lento si se tiene en cuenta las velocidades crecientes a las que se dan las transacciones de mercado: se revisan las últimas compras de cada uno de los clientes, su comportamiento histórico, sus deudas/pagos y se revisa si ha tenido algún tipo de problema para hacer los pagos de sus pedidos. Con esta información se evalúa la capacidad crediticia del cliente y se define si se le otorga el crédito, en caso negativo, se le informa que puede adquirir algún tipo de crédito con la empresa. Actualmente se trabaja en la automatización de este proceso. A continuación se mostrarán los requerimientos identificados en el proceso de asignación de Límite de Crédito.

7.1.1.1 Requerimiento liberación de pedidos bloquea dos. – Descripción. Al analizar la situación de las funcionalidades que se necesitan para el buen funcionamiento del módulo, se requiere crear una funcionalidad que integre Portal y SAP y que permita realizar la liberación de los Pedidos Bloqueados que un cliente pudiera tener en un determinado momento. La persona que libera los pedidos recibirá un e-mail por Outlook de acuerdo con los niveles de autorización parametrizados, el cual le indicará que debe proceder con la liberación. La liberación de pedidos bloqueados está ligada a la asignación de límites de crédito. En aquellos eventos en los cuales los clientes tienen pedidos bloqueados porque excedieron su límite de crédito, estos pueden llegar a un acuerdo con la Empresa para que se revise su estado financiero y su historial de pedidos, con el fin de analizar la viabilidad de aumentar el cupo de crédito. – Resultado. El proceso permitirá la liberación de todos aquellos pedidos bloqueados por existencia de partidas abiertas vencidas o por límite de crédito superado. 7.1.1.2 Requerimiento actualización masiva de limi te de crédito – Descripción del Problema. El límite de crédito a clientes comerciales será asignado a partir de conversión de datos de los sistemas actuales. Su cálculo en

40

base al comportamiento crediticio de un cliente, será determinado de forma externa. En clientes nuevos, de igual forma, se determinará el cálculo de forma externa a SAP. Previo a la incorporación de una herramienta automática, se propone ofrecer herramientas de actualización masiva de límite de crédito, ya sea por incrementos de precio o impulsos al crédito. – Descripción del Requerimiento / Solución . Se requiere el desarrollo de un programa de actualización del límite de crédito en forma masiva, basado en parámetros de selección por distintas características de clientes. A los clientes seleccionados se les debe sugerir un incremento del límite de crédito en una pantalla de aprobación, aplicando el porcentaje establecido en los datos de la pantalla de selección. 7.1.1.3 Requerimiento para portal de autorización de límites de crédito. – Descripción. Se trabajará sobre la funcionalidad de gestión de crédito que hoy en día está activa en Colombia y Ecuador. La solución debe permitir una mayor rapidez en el flujo de la información desde el momento en que se realiza la solicitud para la autorización de cambio del límite de crédito hasta la llegada de la solicitud a las personas autorizadas para realizar estos cambios. Los niveles de autorización se definirán por país con base en el tipo de cliente y el monto a autorizar. – Escenarios. Los escenarios que se van a tomar en consideración para realizar los cambios para los límites de crédito por incremento serán: • Validación periódica del cliente. • Solicitud del cliente. • Temporadas o Eventos especiales por región.

41

7.1.2 Cobranzas. En la actualidad solo se cuenta con cobros en cheques o pagos directos en banco (depósito bancario), tal que se requiere automatizar (pago electrónico) los procesos para realizar las cobranzas, con ello se tendría una información más actualizada y con más control en el sistema SAP. De momento no existen Rutas de Cobranza definidas dentro del sistema, ya que se asume que el proceso se llevará a cabo dentro de las rutas de ventas. Durante la realización del análisis a los procesos de Cobranza, se identificó la necesidad de definir y construir una lista que contenga todos los clientes con situación de morosidad, de forma que se puede generar una Ruta de Cobranza que debe sincronizarse al Hand Held (HH). Esto permitirá emitir un Reporte de Ruta de Cobranza, con el detalle de las partidas en el evento que estén vencidas, que tengan partidas abiertas o si se desconoce un pago por parte del cliente o de la empresa, caso en el cual el cliente ingresará a una lista de morosos que generará un reporte propio. A continuación se presentan los requerimientos del proceso de cobranzas. 7.1.2.1 Requerimiento para ruta de cobranza. – Descripción del Requerimiento / Solución. Este programa se creará en dos partes: la primera comprende el Reporte de cobranza: Acceso directo y emisión y la segunda la Generación Lista de visitas para HH. Se requiere crear un programa que permita seleccionar todos los clientes que hayan sido asignados a una Ruta de Cobranza y que además presenten morosidad dentro del pago de sus Partidas Abiertas. Esta selección permitirá: • Programar las visitas a dichos clientes (con la ejecución de la Cobranza correspondiente y el registro en HH). • Crear un listado/reporte, del total de clientes a visitar por día. 7.1.2.2 Requerimiento de cobranzas electrónicas. Se desea construir un reporte (conjunto de datos organizado y formateado de acuerdo a un criterio específico) que establecerá los requerimientos a incluir.

42

– Descripción del Problema. Se requiere, para tener control de los cobros electrónicos recibidos, emitir un reporte que liste los casos en los cuales los números de confirmación de cobro electrónico registrados a nivel de HH no coincidan con los números de confirmación enviados desde el Banco o la entidad financiera. – Descripción del Requerimiento / Solución. Durante el proceso de Liquidación de la Ruta de Reparto se registrarán los cobros electrónicos que no hayan sido procesados previa visita del Entregador dentro del HH de manera de permitir la entrega de mercancía. Durante este proceso el Repartidor deberá registrar, a nivel del HH el Monto y el Número de Confirmación del Cobro Electrónico. 7.1.2.3 Requerimiento de cobranzas automáticas. Se requiere el desarrollo de un programa que permita la carga de archivos provenientes de los proveedores del servicio de cobranzas automáticas, para ser registrado en el sistema SAP. – Descripción del Problema. • El registro de las cobranzas automáticas a clientes, se origina desde una operación bancaria, la cual debe ser incluida en el sistema por medio de una interfaz, mientras no se disponga de un medio automático de registro. • Se incorpora un modelo automatizado como impulsador de cobros. Para mejorar y optimizar el modelo de distribución se requiere el registro de los cobros de forma inmediata el sistema. Esto obliga a crear una interfaz dinámica que garantice el registro del cobro el mismo día en que es registrado por en banco para garantizar la actualización de los cobros antes de la ejecución del despacho. – Descripción del Requerimiento / Solución. Se requiere desarrollar una interfaz que tome las cobranzas de los bancos correspondientes a cada país, convertir cada formato del banco a un formato universal y disponerlo en una cola de ejecuciones automáticas. En una próxima etapa de enlace entre los bancos y la compañía esto será realizado de forma automática a través de de un software que actúe como un puente entre ambas partes.

7.1.3 Liquidación caja de recaudo. En este proceso el cajero realiza todos los registros de cobros manualmente por lo tanto pueden ocurrir errores o pueden

43

pasar por alto algunas validaciones. En el evento que ocurran errores difíciles de detectar, este pudo ser causado por no hacer las validaciones continuas al hacer pagos duplicados a una misma cuenta en un mismo día en cheques, depósitos bancarios y efectivo, por lo tanto no se verifica el número del cheque con el cual se hizo el pago. El problema toma importancia teniendo en cuenta que las validaciones de los registros se hacen mensualmente. A continuación se presentan los requerimientos de este proceso. Requerimiento de liquidación en caja de recaudo. El programa solicitado debe cubrir los siguientes escenarios: • Manejo de Recaudación proveniente de las Liquidaciones de las Rutas de Venta. • Diferenciación en el tratamiento de la recaudación a partir de la vía de pago. • Manejo de Diferencias en Cobro. • Contabilización hacia Cuenta de Caja de Recaudación. • Contabilización hacia Cuenta de Banco. • Compensación de Cuenta del Cobrador. • Manejo de la Recaudación recibida directamente en Caja. • Manejo de reposición de Caja Chica a partir de la recaudación en contado existente en Caja. • Manejo de las diferencias en caja al momento del cierre de Caja de Recaudo. • Emisión de Reportes de Control. 7.1.4 Conciliación bancaria. Existen dos formas para realizar la conciliación bancaria: manual y automática. La automática consiste en descargar las planillas bancarias de una pagina Web la cual habilita un archivo plano txt, mostrando las transacciones y las compensaciones realizadas. En este caso se deben revisar manualmente si hay conflictos al momento de la compensación de las partidas a las cuentas del cliente. En el caso de las compensaciones manuales se deben hacer las contabilizaciones de manualmente y se valida que no haya habido inconsistencias en las compensaciones. El objetivo es que este proceso sea totalmente automatizado. A continuación se presentan los requerimientos del proceso de conciliación bancaria.

44

Compensación automática de partidas abiertas. – Descripción del Problema • Dentro del modelo diseñado se requiere que la compensación de las partidas abiertas de los clientes se realice diariamente de manera automática, tal que se pueda relacionar la partida abierta con el cobro recibido. • El proceso de compensación automática estándar de las partidas abiertas no considera restricciones de clase de documento. • La compensación automática para ejecutarse deberá considerar las particularidades relacionadas con la clase de documento y la fecha de vencimiento. – Descripción del Requerimiento / Solución Se requiere desarrollar un programa de compensación automática de partidas abiertas que considere los siguientes escenarios: • El programa deberá vincular los Cobros de los clientes realizados con “Envase” (Botella Vacía) con las Partidas Abiertas de “Envase” que tenga el cliente. • En caso de tener Cobros de clientes realizados con dinero, los mismos se relacionarán a la Partida Abierta más antigua que tenga el cliente. • Si se presentase saldo del pago recibido con vacío, el mismo podrá ser aplicado a la Partida Abierta de líquido más antigua. • Si se presentase saldo del pago recibido con dinero, el mismo podrá ser aplicado a la siguiente Partida Abierta más antigua (líquido o vacío). – Rutina que debe realizar el programa • El programa se ejecutará de manera automática diariamente. Se generarán tantas variantes como procesos se quieran correr y se deberán tener en cuenta los parámetros a ser incluidos. • El programa deberá buscar dentro de las tablas por sociedad el total de partidas abiertas que existan a la fecha de ejecución

45

• Una vez identificadas las Partidas Abiertas, se organizarán por cliente, se seleccionarán los siguientes campos y se incluirán en una tabla temporal para su posterior procesamiento. 7.1.5 Proceso de disputas. El proceso de disputas presenta atrasos por resolver ya que no se tienen procedimientos para el tratamiento de algunos conflictos en las entregas y faltantes de los productos, las cobranzas, diferencias en los precios, de modo que se pretende formalizarlo y generar así ganancias en eficiencia para la organización. Adicionalmente se otorgan una serie de responsabilidades al funcionario que conduce el procedimiento.

7.1.5.1 Requerimiento del proceso de disputas. –– Descripción del Problema. El proceso de disputas consiste en el envío de notificaciones a clientes en caso de atraso en el pago de su deuda. Con el fin de realizar el envío de las reclamaciones con diferente énfasis, de acuerdo a la categoría de cliente y días de atraso, se utiliza la funcionalidad estándar, la cual requiere de la utilización de formularios que darán salida a un documento de reclamo con la información requerida para gestionar el correspondiente cobro. – Descripción del Requerimiento / Solución. Se deben desarrollar formularios que serán integrados a la funcionalidad estándar de disputa, utilizando los siguientes criterios: • Tipo de Cliente: Microcrédito, Detallista, Mayoristas, Supermercados, Exportadores. • Plazo del atraso en pago. • Nivel de reclamación. 7.2 PROPUESTA DE MEJORA En la medida en que se fueron conociendo los procesos que la Empresa ejecutaba, se hizo evidente que los mismos, si bien era cierto que, a primera vista no parecían generar mayores retrasos operativos a nivel de sucursal, eran incapaces de brindar soluciones acordes a las necesidades que la organización estaba solicitando.

46

Se decidió analizar cada uno de los procesos del módulo de BO para visualizar la forma como debían ser modificados. Se determinó que los procedimientos que estaban vinculados con dichos procesos, se debían rediseñar para que el nuevo modelo de sistema DSD pudiera interactuar sin conflictos, con el elemento clave que es el HH (Hand Held) del sistema de información empresarial SAP R/3. En ese orden de ideas, este trabajo de grado ofrece alternativas de optimización de los módulos DSD y SFA, mediante el diseño de procedimientos en Back Office. Puntualmente se describirá la forma en que los procesos del negocio se ajustan a sus requerimientos y objetivos, cambiantes según las condiciones de mercado. La propuesta de mejora sobre los procesos de liquidación en caja de recaudo, asignación de límite de crédito, proceso de cobranzas, proceso de disputas y conciliación bancaria fue incorporada en la compañía como la fase de diseño del proyecto, en la cual se rediseñaron todos los flujos de los procesos, como resultado de las reuniones con los líderes de los países, la que a su vez se denominó fase de análisis. La aplicación de las mejoras sobre cada uno de los procesos optimizará el desempeño de las sucursales, facilitando las actividades del equipo de FBO con la incorporación de los controles de SOX a los flujos de procesos, como se indica más adelante. Desde el punto de vista corporativo, la Empresa podrá afianzar y mejorar no solo las relaciones con cada uno de sus clientes externos, sino también con los clientes internos que de manera creciente demandan información en mayor cantidad y de mejor calidad. Con los requerimientos identificados se rediseñaron los flujos de procesos que están contenidos de manera detallada en los Anexos identificados con los numerales 1 a 10. A continuación se señalarán cada uno de los requerimientos revisados, con sus respectivas propuestas de mejora. En algunos casos se incluyen mejoras que no se identificaron en el capítulo anterior, pero que dada su relevancia y pertinencia para el éxito del proceso de optimización, se hizo necesario incluirlos.

47

7.2.1 Asignación de límite de crédito Figura 6. Ciclo de Limite de Crédito

Fuente: Business Document Design. Bogota D.C , 2008. 1 Archivo de Computador El flujo de procesos detallado perteneciente a la asignación de limite de crédito se puede visualizar en el anexo 2 del documento. El proceso de Asignación de Crédito define el valor de Límite de Crédito que se debe asignar a un cliente, considerando los siguientes escenarios: • Asignación de Límite de Crédito para cliente nuevo.

• Solicitud de aumento de Límite de Crédito (en Punto de Venta y en Planta).

• Asignación Límite de Crédito para Eventos/Temporadas.

• Ejecución proceso de Credit Scoring para determinar Límite de Crédito de Clientes con histórico de venta.

• Autorización Límite de Crédito.

• Ajuste Dato Maestro.

48

7.2.1.1 Asignación de límite de crédito para client es nuevos. Durante la asignación de Límite de Crédito a clientes nuevos se crea un Informe de Crédito en el cual se consideran: Datos Generales del Cliente, Condiciones Financieras, Garantías y Referencias. Todo cliente nuevo, deberá tener compras históricas de contado con tres (3) meses. A partir de la evaluación del Informe de Crédito se determina si el cliente es apto para asignarle condición de crédito y Límite de Crédito. Como está establecido en la política, la garantía del crédito por tipo de cliente debe ser una referencia para el otorgamiento de créditos. El proceso de evaluación y resolución de un crédito no debe superar las 72 horas. Finalmente, en caso de ser apto para tener Límite de Crédito, se asigna Límite con base en la garantía que el cliente haya entregado. El monto de Límite de Crédito asignado nunca será superior al monto de la garantía. 7.2.1.2 Solicitud de aumento de límite de crédito. La solicitud de aumento de Límite de Crédito puede llevarse a cabo a partir de un requerimiento del cliente en el Punto de Venta o mediante la evaluación, a nivel de Planta/CD del historial del cliente. Se indica a continuación el procedimiento vinculado con cada una de estas actividades: • Solicitud de Aumento de Límite de Crédito en Punto de Venta � A nivel del Punto de Venta, el Vendedor podrá registrar dentro del HH el ajuste al Límite de Crédito solicitado por el cliente.

� Esta solicitud se vinculará en HH con un objetivo comercial que soportará el requerimiento del cliente.

� A partir del proceso de Liquidación se generará una solicitud de Aumento de Límite de Crédito en SAP que será el insumo a partir del cual se llevará a cabo el proceso de Credit Scoring y ajuste al Límite de Crédito. �

• Solicitud de Aumento de Límite de Crédito en Planta/CD � El proceso de solicitud de aumento de Límite de Crédito en Planta/CD se origina a partir de un requerimiento del Área Comercial o de una evaluación del cliente determinará que el Límite de Crédito asignado no es suficiente.

49

� La evaluación del cliente considerará el Límite de Crédito inicialmente asignado y el historial de venta y de pagos que tenga el cliente.

� El límite de crédito estará calculado por una formula, la cual estará establecida por país. Este proceso no debe superar un máximo de 72 horas para la evaluación y resolución.

� Una vez identificado el cliente para el cual es válido el ajuste, se creará una solicitud de ajuste de Límite de Crédito dentro de SAP y se asignará un objetivo comercial que justifique la necesidad del ajuste.

� Las evaluaciones de los límites de crédito de los clientes deben realizarse a nivel “Preventivo” cada 3 meses.

� El sistema deberá permitir la medición de los objetivos comerciales, según los tipos de crédito concedidos (esto tendrá un impacto en BI).

7.2.1.3 Asignación de límite de crédito para evento s o temporadas. • Los Límites de Crédito definidos para cubrir Eventos/Temporadas presentan un período de validez a partir del cual los montos asignados a los clientes son superiores a su crédito regular. • El calendario de Temporadas se definirá por país y se identificará por tipo de cliente, un porcentaje de aumento de Límite de Crédito. • Al identificarse la llegada de una temporada se calculará automáticamente dentro de SAP (con base en el % de incremento real definido por tipo de cliente), el Límite de Crédito a asignar a todos los clientes. • En los casos en los cuales los montos de Límites de Crédito obtenidos sean inferiores al monto de garantía, no se requerirá de autorización para ejecutar el ajuste al Límite de Crédito. Se modificará el dato maestro del cliente y se le informará a éste del período de validez y del crédito asignado. • Se emitirá un reporte en SAP que incluirá todos aquellos clientes para los cuales el monto del Límite de Crédito obtenido es superior al monto de Garantía de éste. Estos casos deberán pasar por un proceso de Autorización que definirá si se asigna el Límite de Crédito obtenido. • Los Eventos, al igual que las Temporadas, implican aumentos temporales del Límite de Crédito. En caso de identificar la celebración de algún evento en un cliente se ejecutará en SAP, por cliente, el cálculo del monto a asignar a éste.

50

• Nuevamente si el monto es superior a la Garantía que el cliente proporcionó, se deberá solicitar autorización, en caso contrario se realizará el ajuste al dato maestro indicando la validez del mismo. 7.2.1.4 Ejecución proceso credit scoring para asign ar nuevo límite de crédito en clientes con histórico de ventas. • El proceso de Credit Scoring permitirá identificar el nuevo monto recomendado de Límite de Crédito a asignar a los clientes. Igualmente permitirá validar/ajustar el Grupo de Crédito al cual está asignado el cliente. • Los Grupos de Crédito de clientes identificados son los que se muestran en la siguiente tabla: Tabla 2. Clasificación de Riesgo del Cliente

Calificación de Riesgo A Excelente B Bueno C Regular D Malo

• El proceso de Credit Scoring no se realizará para clientes nuevos ni para temporadas/eventos, únicamente se realizará para identificar el aumento de Límite de Crédito a asignar con base en la solicitud de ajuste a Límite de Crédito recibida a nivel de punto de venta o identificado previo análisis de la situación del cliente. • El programa se ejecutará automáticamente en SAP a partir de los códigos de clientes incluidos. • Este programa considerará los pesos otorgados por país y tipo de cliente a las variables financieras a partir de las cuales se definirá el porcentaje de aumento del Límite de Crédito. • En los casos en los cuales los montos de Límites de Crédito obtenidos sean inferiores al monto de garantía, no se requerirá de autorización para ejecutar el ajuste al Límite de Crédito. Se modificará el dato maestro del cliente y se le informará a éste del nuevo valor.

51

• Para todos aquellos casos con Límite de Crédito superior al monto de Garantía se emitirá un reporte que incluirá a los clientes y montos de Límite de Crédito que requieren de autorización. 7.2.1.5 Liberación de límite de crédito y pedidos. A través de Portal el usuario que autoriza debe tener acceso al proceso de liberación de pedidos de venta, este proceso debe ejecutarse similar al proceso realizado a través de la transacción de SAP VKM1: • Visualización del total de pedidos que han sido bloqueados: Figura 7. Configuración de liberación de Pedidos en SAP

- Diseño a nivel tecnológico, Con esta solución se ofrece una arquitectura que integra herramientas que provee SAP para tener aplicaciones on-line por medio de un Portal (SAP EP) y que interactúa directamente sobre el sistema SAP R/3. Esta solución se basa en el desarrollo de la aplicación bajo el entorno Web Dynpro de SAP R/3, comunicado a través de RFC’s y publicada en SAP Enterprise Portal. - SAP Enterprise Portal. SAP Enterprise Portal es el medio donde se publica la solicitud de cupo, permitiendo una integración rápida y efectiva de la solución y el uso de una administración centralizada de usuarios y perfiles.

52

Cuando se realiza la instalación del servidor SAP Enterprise Portal, por defecto se crea un Web AS, lo cual permite contar con la implantación de aplicaciones virtuales y servicios virtuales altamente escalables. La integración de Portal se propone con correo electrónico y con el sistema SAP (ERP). - Web Dynpro. Es el ambiente de desarrollo de SAP para crear interfaces de usuario profesionales para aplicaciones de negocio. Se basa en un conjunto de modelos que minimiza el código que debe escribirse y usa herramientas visuales para diseñar y reutilizar componentes. La solicitud de liberación de pedidos debe desarrollarse en Web Dynpro, permitiendo utilizar las mejores prácticas para las transacciones delimitadas por el alcance y mostrando la información relevante para el usuario. Esta herramienta de SAP portal, es la interfase que se va a utilizar para la liberación del limite de crédito para los clientes que deseen ampliar su credito por que bien sea que tienen sus pedidos en estatus de bloqueo o por que tienen una temporada como ferias o basares. Esta herramienta se hace necesaria para tener un mayor control a nivel de las liberaciones y tambien de mayor rapidez en este proceso ya que solo esta dedicado a esta operación. En esta seccion se esta describiendo la parte tecnica que va a conetener este portal de liberacion que esta ligado al proceso de asignación de limite de credito, muestra su proceso y sobre el sistema que se implemento el portal. - Sistema SAP R/3. La aplicación maneja la administración de usuarios y perfiles suministrada por SAP Enterprise Portal. – Flujo de Proceso • Los usuarios aprobadores acceden a la Aplicación de Liberación de pedidos publicada en SAP Enterprise Portal. • La validación de autenticación de usuario es hecha por la Administración de SAP Enterprise Portal. Esto permite a la vez verificar los permisos de los usuarios sobre el proceso.

53

• SAP Enterprise Portal muestra el detalle de los pedidos que deben ser liberados y el detalle de los clientes, de forma que el Aprobador tenga suficiente información para llevar a cabo el análisis y tomar la decisión de liberar o mantener bloqueado el pedido. • Los pedidos bloqueados y la acción (cambio de estatus) son transferidos desde y hacia SAP donde se ejecutan las funciones correspondientes y se retorna la información para su aprobación. • Los Aprobadores recibirán, a través de un e-mail por Outlook, los pedidos que deben ser liberados de acuerdo con los niveles de autorización parametrizados. 7.2.2 Proceso de cobranzas. En la actualidad no existen Rutas de Cobranza definidas dentro del sistema debido a que se asume que el proceso de Cobranza se llevará a cabo dentro de las rutas de ventas. Durante el análisis realizado a los procesos de Cobranza, se identificó la necesidad de definir una “Lista de Visitas” en la cual se incluya a todos aquellos clientes con situación de morosidad y generar una Ruta de Cobranza, que pueda ser sincronizada al HH y que permita emitir un Reporte de Ruta de Cobranza, con el detalle de las partidas y clientes a ser cobrados. – Modelo de procesos propuesto para el proceso de c obranzas. Este es el modelo que se propone para el proceso cobranzas como se muestra a continuación. – Cobranza en hand held (punto de venta). El proceso de Cobranza en el Punto de Venta se apoya en las gestiones efectuadas por el Responsable de Cobro en el momento de visitar al cliente. Esta actividad se realiza dentro del HH a partir de las Partidas Abiertas que son sincronizadas hacia el dispositivo móvil a la hora de efectuar la preparación de la ruta del Responsable de Cobro. A continuación se mencionan los principales eventos que se efectúan dentro del proceso de Cobranza en el Punto de Venta: • Límite de crédito consumido a partir del pago de las partidas abiertas. • Durante el registro del Cobro, el Responsable del Cobro deberá identificar el código del cliente y determinar si el cliente posee partidas abiertas y si las mismas están vencidas.

54

• En caso de presentar partidas abiertas no vencidas, será posible vincular el cobro a dichos documentos y emitir el recibo de cobro correspondiente. • Una vez identificados los documentos contra los cuales registrar el cobro, será posible llevar a cabo el registro de dicho cobro en las siguientes vías de pago estándar a nivel de HH: Efectivo: se incluye el monto a cancelar. Cheque: se incluye el número de cheque, el monto a cancelar, el Banco al cual pertenece y la fecha del cheque. Depósito Bancario: se incluye el monto a cancelar, el número de depósito bancario y la cuenta de banco. Para la cuenta de banco, el Responsable de Cobro tendrá un menú con todas las cuentas de banco disponibles de manera que se seleccione la cuenta contra en la cual se está realizando el depósito. Tarjeta de Crédito: se debe incluir el monto a cancelar, el número de la tarjeta, la fecha de vigencia de la misma y numero de verificación. • Para el caso de Tarjeta de Crédito, el HH seleccionado no presentará “Datáfono” (lector de Tarjeta de Crédito), con lo cual el HH únicamente permitirá incluir los datos del pago en tarjeta pero no llevar a cabo validación alguna referente a este pago. • Una vez realizado el registro de la Cobranza HH se emitirá un Recibo de Cobro con el detalle del monto recibido por el cliente. • Es posible realizar el registro de la cobranza en más de una vía de pago, distribuyendo dentro de cada vía el monto que le corresponde. – Cobranza en back end. El proceso de Cobranza en Back End va a considerar los siguientes escenarios: � Registro de Cobranza en Cheque, Efectivo, Depósito Bancario, Tarjeta de Crédito (Cobranza Manual) en Planta/CD. � Tratamiento para la Cobranza Electrónica. � Registro de Cobros Parciales. � Manejo de Tolerancia en el cobro. � Manejo de Ruta de Cobranza (para clientes Cuentas Clave y clientes morosos). � Manejo de Cobros especiales (cheque devuelto, pagos con billetes falsos o planillas falsas)

55

� Proceso de Disputa (Reclamo). El flujo de procesos detallado perteneciente al registro de cobranzas en Punto de venta se puede visiualizar en el anexo 3 del documento. – Registro de cobranza manual en planta/cd. � A nivel de Backend no existen restricciones en relación al número de vías de pago que es posible manejar. Inicialmente se definieron cuatro vías de pago: efectivo, cheque, depósito bancario y tarjeta de crédito. � Se realizará el registro del cobro dentro de la Caja de Recaudo indicando el código del cliente, el monto cancelado y el número de factura que se está pagando. � Se emitirá un Recibo de Cobro por cada recaudo recibido directamente en Planta/CD � Para las vías de pago inicialmente consideradas se indicarán los siguientes datos a la hora de realizar los registros en SAP:

• Efectivo: se incluye el monto a cancelar. • Cheque: se incluye el número de cheque, el monto a cancelar, el Banco al cual pertenece y la fecha del cheque. • Depósito Bancario: se incluye el monto a cancelar, el número de depósito bancario y la cuenta de banco. Para la cuenta de banco, el Responsable de Cobro tendrá un menú con todas las cuentas de banco disponibles de manera que se seleccione la cuenta contra en la cual se está realizando el depósito. • Tarjeta de Crédito: se debe incluir el monto a cancelar, el número de la tarjeta, la fecha de vigencia de la misma y numero de Verificación.

� Se realizará la compensación automática de las cuentas que están siendo cobradas. Se compensarán inicialmente las partidas abiertas de fecha más antigua y luego las partidas abiertas con fechas más nueva. El flujo de procesos detallado perteneciente al registro de cobranzas en Backend se puede visiualizar en el anexo 4 del documento.

56

7.2.3 Proceso liquidación en caja de recaudo. Este proceso se basa en el manejo dentro de los Centros de Distribución (Plantas) de las cobranzas y su direccionamiento hacia las cuentas bancarias y tiene como fuente de información: • Liquidación de las Rutas: durante el proceso de liquidación se cancela la Cuenta por Cobrar del Cliente y se transfiere la deuda hacia la cuenta del Cobrador. Dentro de este proceso es requerido que el Cobrador esté creado en SAP como Deudor y que tenga una cuenta asociada. • Cobros recibidos directamente en Planta/CD: la cobranza en Planta/CD se deben registrar dentro de la cuenta de Caja de manera de consolidar el total de la recaudación diaria para proceder a la posterior transferencia física y en el sistema de la recaudación hacia la cuenta de Banco. En ambas circunstancias es necesario ejecutar un proceso adicional que permita trasladar los montos recaudados desde las cuentas de Caja o de Cobrador hacia las Cuentas de Banco o de Impuestos correspondientes. Esto evidencia la necesidad de desarrollar un programa para gestionar masivamente la recaudación hacia las cuentas finales en las cuales se debe contabilizar. 7.2.3.1 Contabilizaciones contra cuenta de banco. Una vez efectuada la validación del saldo de caja, se procede a la contabilización de los registros hacia la cuenta de Banco. Las contabilizaciones hacia la cuenta de Banco van a mantener los datos que son utilizados para la Conciliación Bancaria (Fecha Valor, Monto y Texto). Al ejecutarse el cierre de la caja se generará automáticamente una llamada de transacción en SAP a partir del cual se realizará el siguiente asiento en las cuentas de banco. 7.2.3.2 Generación de reportes de cierre de caja. Durante el proceso de cierre de Caja será posible emitir los siguientes reportes: – Reporte de Planillas Bancarias : incluirá el detalle de las planillas bancarias creadas dentro de la Caja de Recaudo, muestra el número de la planilla y el detalle de los cheques incluidos dentro de la Planilla: monto, número de cheque y banco.

57

– Reporte de Verificación de Planillas Duplicadas : identificará si existe duplicidad en el número de las planillas, incluye el número de planilla, el detalle de los cheques o efectivo incluido y el número de clientes. – Reporte de Cuadre de Caja : mostrará el manejo de las recaudaciones, se identifica el total recaudado, los depósitos realizados, los montos trasferidos hacia Caja Chica, los montos transferidos hacia cuentas de impuestos y los montos transferidos hacia cuenta de hurto. 7.2.3.3 Compensación cuenta cobrador al efectuar el cierre. La compensación en la cuenta del cobrador se efectuará una vez que la caja se haya cerrado; para la ejecución de esta compensación deberán tomarse las siguientes consideraciones: – La cuenta del cobrador únicamente se compensará si al validar el comportamiento de la misma, tomando como parámetro la fecha de cierre, se observa que el saldo es cero (0). – Durante la ejecución de la compensación de los Cobradores se ejecutará automáticamente una transacción en SAP tomando como parámetros de ejecución la cuenta del cobrador, la fecha de compensación (la cual debe coincidir con la fecha del día en que se efectúa el cierre) y la fecha de contabilización que corresponderá a la fecha de cierre de la caja. – Estas delimitaciones permitirán visualizar el total de registros recibidos en la cuenta del Cobrador durante la liquidación y el total de registros entregados a nivel de Caja de Recaudo. – Únicamente si el saldo del cobrador es cero (0), el programa podrá llevar a cabo la compensación de la cuenta del mismo; en caso contrario, la cuenta se mantendrá sin compensar. – En caso de que para un determinado día (día 1) el saldo del cobrador a la hora del cierre no sea cero (0), no se efectuará la compensación. Si al día siguiente (día 2) el saldo del movimiento correspondiente al día es cero (0), se efectuará la compensación de las partidas tratadas en el día 2, manteniéndose abiertas las partidas del día 1 hasta que se solvente la diferencia.

58

El flujo de procesos detallado perteneciente al proceso de liquidación de caja de recaudo se puede visualizar en el anexo 1del documento. 7.2.4 Conciliación bancaria.

Figura 8. Ciclo de Conciliación Bancaria

Fuente: Business Document Desgin. Bogota D.C, 2008. 1 Archivo de Computador.

El proceso de Conciliación Bancaria se efectúa diaria o mensualmente (varía según el país) y permite verificar la información registrada en las Cuentas Bancarias SAP, con la información registrada a nivel de las Cuentas Reales de Banco, garantizando que no existan diferencias a nivel de movimientos bancarios. Para la ejecución de este proceso es necesario obtener del Banco la información

Liquidación

Caja de Recaudo

Conciliación Bancaria

Gestión de Cobranza

4

Conciliación Bancaria

• Obtención extracto bancario diario

• Validación datos extracto vs. Registros Cuenta de Banco

1

3

2

59

correspondiente con los movimientos que sobre las Cuentas Bancarias se realizan. Esta información debe ser cargada en SAP para garantizar que los registros realizados sobre las Cuentas de Banco coinciden con lo enviado por el Banco. 7.2.4.1 Carga del extracto bancario. • A través de las páginas de los Bancos se accede a los archivos que contienen la información de los movimientos Bancarios existentes.

• Una vez que se ha obtenido el archivo, se ejecuta un programa para eliminar los tipos de operaciones que no estén relacionadas con Conciliación Bancaria.

• En caso de ser necesario, se realiza el ajuste del formato de archivo enviado por el Banco y se genera un formato que pueda ser cargado en SAP.

• Mediante la ejecución automática de un programa en SAP se carga el archivo modificado de los movimientos bancarios correspondientes con la Conciliación (débitos y créditos).

7.2.4.2 Conciliación de los movimientos bancarios. • Sobre el archivo generado con los movimientos a ser conciliados, se ejecuta de manera automática el programa de conciliación.

• La Conciliación se realiza validando los registros incluidos en el archivo obtenido del Banco contra lo registrado en la Cuenta de Banco Tránsito.

• El programa de conciliación valida los registros a partir de la información incluida a nivel de los campos: monto, fecha, número de referencia de la transacción, código de cliente, código de repartidor, código de trabajador, RUC o DNI (en campo de Referencia), clave de contabilización y campo texto.

• Los criterios de validación considerados por el programa de Conciliación son variables, permitiendo que se seleccionen uno u otro valor según sea el caso.

60

El proceso descrito anteriormente se refleja en el siguiente diagrama: Figura 9. Proceso de Conciliación Bancaria

Fuente: Business Document Desgin. Bogota D.C, 2008. 1 Archivo de Computador 7.2.4.3 Errores durante la conciliación bancaria. Al ejecutarse la validación de los registros existentes en el archivo enviado por el Banco vs. Los registros de la Cuenta de Banco Tránsito, se pueden presentar los siguientes errores: Registro no Existente, Diferencia en Fecha Valor, Diferencia en Monto y Diferencia en Texto. Una vez identificados dentro de la Cuenta de Banco Real los registros con error se lleva a cabo el siguiente tratamiento:

7.2.4.4 Registro no existente. – En archivo de banco. Se debe verificar a nivel de la recaudación en SAP el origen del registro y determinar las razones por las cuales el monto no fue depositado en el Banco. En caso de confirmarse el faltante en el monto

Extracto Bancario

Cobro Electrónico (Se excluye del análisis de

Conciliación)

Movimientos a Conciliar (Extracto Bancario menos Cobro

Electrónico)

Conversión data depurada del Extracto Bancario a formato

SAP

Ejecución Programa Conciliación en SAP

Banco Tránsito SAP

Banco Real SAP

200 – 01.08. 08 - BOGOTÁ 400 – 02.08. 08 - BOGOTÁ 500 – 05.08. 08 - BOGOTÁ

200 200

400 400

500

Cuenta Banco Real para Análisis Incluye diferencias entre Extracto y

Cuenta Banco Tránsito

61

depositado en Banco se identificará, con base en las Políticas/Procedimientos de cada país, el tratamiento a darles a las personas involucradas en el evento. A nivel de la Cuenta de Banco Tránsito el registro extra que se visualiza se transferirá hacia una Cuenta de Resultados, previa autorización del Gerente de Cartera. – En cuenta banco tránsito (SAP). Validar con el Banco el origen del registro y determinar si efectivamente es un registro válido. En caso positivo se debe solicitar la autorización con el Gerente de Cartera para crear el registro manual en la Cuenta de Banco Tránsito. En caso de error por parte del Banco, se solicitará el envío del archivo ajustado y se deberá realizar nuevamente el proceso de Conciliación. – Diferencia en fecha valor/monto/texto. • Validar el origen de la diferencia.

• Determinar si el error se encuentra en el registro de la Cuenta de Banco Tránsito o en el Archivo del Banco.

• En caso de presentarse error en la Cuenta de Banco Tránsito, solicitar la autorización al Gerente de Carter apara efectuar el ajuste del registro y la posterior compensación.

• En caso de presentarse el error en el Archivo del Banco, solicitar al Banco el re-envío de la información. El flujo de procesos detallado perteneciente al proceso de conciliación bancaria se puede visualizar en el anexo 6 del documento. 7.2.5 Proceso de disputas. Para los casos en Disputa, los cuales serán identificados en este proceso por su estatus, se reclasificarán las cuentas solamente si existe un cobro judicial o un uso de la provisión de manera que no se afecte la cartera crediticia de los clientes (excepto manejo de deudas vencidas) por lo menos no antes de analizar el caso y llegar a la conclusión. Una vez que se identifique la razón por la cual esta en disputa el caso, este podría tener distintos resultados.

62

Figura 10. Ciclo del Manejo de Disputas

Fuente: Business Document Design. Bogota D.C, 2008. 1 Archivo de Computador 7.2.5.1 Falsificación de las vías de pagos excepto. • Una vez que se identifique la vía de pago falsificada se contacta al cliente para poder identificar la razón de lo sucedido. • Si se contacta al cliente se le informa de lo sucedido; en caso de que no se pueda contactar por medio de varias vías (mails, teléfono, cartas, etc.) se visitará al lugar físico del cliente. Si éste aún no se contacta, se re-planifica una visita, si al ejecutar la visita no se encuentra al cliente, automáticamente se enviará el caso al departamento legal expresando que se han agotado las formas de contactar al cliente y se bloqueara la cuenta del cliente. • Se contacta al cliente con la finalidad de identificar si hay una responsabilidad compartida entre el cliente y la persona que realizó el cobro, si el cobrador tiene responsabilidad y sigue trabajando en la Empresa, se le cobrará, dependiendo de la legislación del país, el monto como penalidad por no seguir los reglamentos de la Empresa para verificar la veracidad de las vías de pago.

63

7.2.5.2 Manejo de deudas vencidas. • Para el manejo de las cuentas con deudas vencidas se afectará la cartera crediticia de los clientes morosos y se bloqueará la cuenta del cliente. • Una vez identificado el cliente y las cuentas que están vencidas, se observa si la cuenta está constituida por vacíos. En caso afirmativo, se informará al cliente que podrá pagar la deuda de vacíos en efectivo en caso de que tenga un faltante de los retornables. • Tanto la deuda vencida del líquido y del vacío, será negociada con el cliente para alcanzar un Acuerdo de Pago. • Al llegar a un Acuerdo de Pago, una vez que el cliente cumpla con la promesa de pago, se regularizará su situación y se mantendrá bloqueada. Si no se llegase a un Acuerdo de Pago, se bloqueará la cuenta y se llevará el caso al Departamento Legal para su manejo posterior.

7.2.5.3 Manejo de provisión. • Una vez que el cliente tenga deudas vencida, se identificará en el reporte de “Deudas Vencidas por Cliente” para examinar aquellas cobranzas que no hayan sido exitosas con él. Con esta información se realizará una propuesta de Provisión en caso de que no se pueda realizar la cobranza.

• Esta propuesta será revisada por el comité de crédito para verificar que todo esté en orden, si no está en orden, la propuesta será ajustada.

• Realizar el cuadre de los saldos de las cuentas por cobrar en el sistema SAP cuando se utilice la provisión.

• Luego se verificará que el saldo de la provisión contable de cobranza dudosa sea el mismo que el saldo de créditos provisionados. 7.2.5.4 Desconocimiento del pago del cliente • Este caso se presenta si al solicitar el pago a un cliente determinado se obtiene como respuesta que el pago ya ha sido hecho y se recibe la documentación para probarlo.

64

• En este evento se revisará la documentación en manos del cliente para observar si es real. Si la documentación que el cliente posee es real y los pagos han sido realizados, se debe revisar si ha ocurrido un error en la aplicación del pago a otro cliente; si es así, se debe identificar la orden que ha sido pagada erróneamente y las cuentas del cliente que realizó el pago. • Se le debe notificar a los clientes la reclasificación que se realizó sobre sus cuentas por medio de la emisión de un cargo para la orden con el pago que ha sido mal aplicado y la emisión de un abono para la orden que efectivamente realizó el pago (cargo y abono no está sujeto a impuestos).

7.2.5.5 Aplicaciones erróneas en cuanto al cobro . Se puede presentar un escenario en el cual el cliente indique a la Empresa que ya realizó el pago de la factura pero no fue aplicado correctamente el descuento o se presentó un error durante la aplicación del cobro en la cuenta del cliente. En este caso se revisará la documentación en mano del cliente para identificar la veracidad de ésta. En el caso de que sea incorrecta, se terminará el proceso de manejo de Disputas y el reclamo no tendrá validez. El flujo de procesos detallado perteneciente al proceso de conciliación bancaria se puede visualizar en el anexo 5 del documento. 7.3 IMPLEMENTACIÓN Una vez que los usuarios de los distintos países aprobaron los documentos de diseños de procesos y estos fueron enviados con sus respectivas firmas, la gerencia procedió a gestionar la realización de las diferentes configuraciones. Todas las configuraciones planteadas en las propuestas de mejoras fueron enviadas a la casa matriz de SAP en Alemania, para que de esta manera se empezaran a preparar los materiales y los escenarios para las posteriores fases en el proyecto. Los representantes de los distintos grupos de trabajo, así mismo como los jefes de las distintas empresas contratadas, se reunieron en varias ocasiones para formalizar la definición los recursos a utilizar, ya fuesen recursos humanos o materiales, los tiempos de ejecución de la fase, la resolución de los problemas

65

(Issues) que seguían abiertos y que habían surgido en la fase anterior, la planificación de las actividades, sus seguimiento y control, el sistema de información del proyecto y los roles y actividades de los participantes en el proyecto. Los Roles definidos en las destinas reuniones, fueron asignados a las compañías trabajadoras dentro de Génesis, estos fueron clasificadas de la siguiente forma: configuradores, diseñadores de procesos y usuarios. Las responsabilidades fueron asignadas según los roles de la siguiente forma: Los configuradores: Realización de la configuración del sistema basado en el diseño del negocio, documentar los procesos de parametrización del sistema, creación y pruebas de los distintos programas necesarios y resolución de cualquier problema que surgiera en el sistema. Diseñadores de procesos: Control del seguimiento de las actividades, análisis y resolver cualquier problemas que surja con respecto al diseño, participar y promover la comunicación entre los distintos integrantes de proyectos, participar en la revisión de la calidad de las configuraciones, diseño de las actividades y materiales a utilizar en las pruebas del sistema y evaluar y acordar un plan de puesta en marcha una vez terminada la fase de realización. Usuarios: Realización de las pruebas del sistema, apoyar en la resolución de problemas con respecto al diseño, participar y entender en el proceso de parametrización, documentación del proceso del proyecto, aprobación del sistema por medio de pruebas, validación del trabajo de configuradores y diseñadores de procesos. Una vez que se entendió cada rol y responsabilidad dentro de la fase, se procedió a realizar las actividades planificadas para cada grupo. 7.4 PRUEBAS UNITARIAS El objetivo de las pruebas unitarias fue verificar si todas las configuraciones y los procesos que se definieron en la fase de diseño fueron configurados de la manera correcta, es decir, establecer si los procesos estaban acorde a lo diseñado e

66

identificado en las reuniones y retroalimentaciones con los líderes de los países involucrados. – Tipos. Existen diferentes tipos de pruebas que ocurren durante el proyecto y cada una tiene un rol crítico para el éxito del proyecto. La estrategia de pruebas incluye: • Pruebas unitarias de configuración. • Pruebas unitarias de desarrollo. • Pruebas unitarias de acceso al sistema (Roles). • Pruebas Integrales. • Pruebas de Aceptación de Usuario. Las pruebas unitarias son pruebas independientes de las demás pruebas de esfuerzos. Estas pruebas que se realizan para todo el sistema se producen antes de las Pruebas de Integración para garantizar que todos los programas funcionen de acuerdo a las especificaciones y el diseño de la documentación. Este es el nivel más bajo de los ensayos cuando el programa o transacción es probado y evaluado por los errores. Unidad de prueba es normalmente la primera prueba que se ha completado durante la configuración, y se centra en el programa de configuración y funcionalidad, en lugar de hacia la integración. – Enfoque de Pruebas unitarias – Datos Maestros. – Transacciones comerciales. – Requisitos de campos específicos (tanto positivos como negativos). Los datos maestros se pueden probar mediante la creación de un cliente o un cliente con jerarquía. Se crea un estándar para las ventas lo cual es un ejemplo de una transacción comercial del módulo de ventas y distribución. 7.4.1 Pruebas en el sistema. Las pruebas unitarias se realizan en el sistema de desarrollo (si es necesario utilizar un cliente de diferentes pruebas para garantizar los ajustes de configuración tienen que ser copiado a otro cliente antes de la prueba que se inicia). Se debe asegurar que los sistemas a seleccionar para la

67

prueba sean compatibles con su sistema global de clientes y sus respectivos campos. 7.4.2 Datos de prueba. Se definieron los requisitos a probar, los datos de pruebas y los resultados esperados de las pruebas durante la dependencia de la misma, se utilizaron los flujos de procesos de negocio y seleccionaron todas las actividades relacionadas con el sistema para formar parte de la Unidad de secuencia de comandos de prueba. Las pruebas unitarias se realizan sobre datos simulados para crear unidad de prueba, se añaden los detalles sobre los datos necesarios para que estén listos para la Unidad de ensayo o de prueba, incluido el tipo de datos necesarios (datos simulados), la cantidad de datos necesarios, tiempos estimado para la prueba de cada escenario, la persona responsable de los datos de prueba. 7.4.2.1 Documentación para las pruebas unitarias. Se elaboraron matrices con los diferentes escenarios, para cada uno de los procesos definidos para el grupo de Back Office las cuales estaban compuestas por las transacciones que serian evaluadas en el sistema SAP, los roles que se debían tener para cada tipo de actividad y los resultados esperados de cada una de las pruebas. Se trabajo con el rol de diseñador de procesos, por lo tanto, se gestionaba la creación de la documentación de las pruebas. Mientras los configuradores parametrizaban dentro del sistema, los diseñadores procedieron a realizar la definición de los escenarios por procesos, que deberían ser probados por la solución en el sistema. Se creó un documento para cada procesos de todos los escenarios posibles a suceder en el día a día en la empresa, a partir de estos documentos se creó una matriz, señalando los pasos en el sistema y transacciones el cual se utilizaría para ejecutar los distintos escenarios levantados. Esta matriz, llamada Script de Pruebas, se realizo con el apoyo de los configuradores, ya que eran ellos quienes daban las transacciones del sistema y con los usuarios, quienes realizaban las pruebas y daban la aprobación de las mismas si estaban en orden y cumplía con los requerimientos del negocio. La dinámica de la prueba se daba de forma tal que los todos los grupos de trabajos se sentaban en una sala a realizar la pruebas tomando como guía el script, los diseñadores lideraban y guiaban la pruebas para los usuarios que eran

68

los que probaban en sus computadoras el sistema y además modificaban el script si era necesario por falta de información o por error. Los configuradores eran llamados una vez que se encontraba algún problema para que fuesen resueltos. Una vez que se realizaban las pruebas, si en estas no surgía ningún problemas y estaba a las expectativas del diseño y de los usuarios, el script era firmado para así aprobar que las configuraciones del sistema estaba de forma correcta. En los anexos 7 a 10 se pueden visualizar los procesos que fueron descritos anteriormente, en el anexo 11 se encuentra la hoja que se utilizo para las firmas de las pruebas en donde los usuarios afirmaban si se aprobaban las pruebas o no.

69

8. VALIDACIONES Las soluciones propuestas fueron validada, en numerosas ocasiones, por personal perteneciente a algunas de las sucursales comerciales; igualmente se contó con el apoyo de personas pertenecientes a las firmas consultoras asociadas de la Empresa, quienes proporcionaron su opinión sobre las diferentes fases de desarrollo del proyecto. Las pruebas también se validaron con usuarios de los demás países, quienes contaron con un acompañamiento permanente de los asesores que idearon todos los procedimientos, de forma que la solución de interrogantes e inconsistencias se hizo en tiempo real, generando importante valores agregados para toda la organización. Luego de las validaciones, se llevaron a cabo una serie de reuniones con los directivos, quienes expresaron sus puntos de vista sobre las fases ejecutadas y se firmaron todas las pruebas unitarias efectuadas. En este momento la compañía está por realizar las pruebas integrales; evento que escapa al alcance de este trabajo de grado.

70

9. EVALUACION DEL MODELO Tanto en el proceso de ajuste y desarrollo del modelo, como en el de aplicación y ejecución de pruebas, se encontraron opiniones provenientes de los diferentes países, entre otros aspectos, sobre la manera en que se van a tomar los pedidos, la impresión de la factura in situ, que en el caso de Honduras no podrá hacerse en el local del cliente por razones legales, el reparto de las facturas en manos de terceros como ocurre en Perú, entre otras, que sirvieron para efectuar ajustes o plantearlos para una posterior fase de implementación. Todas estas consideraciones fueron valoradas por el equipo de trabajo y se tomaron las acciones del caso, tendiendo siempre al ajuste y optimización del modelo. En todo caso, la aplicación de este modelo permitirá tener un control directo sobre el cliente, el manejo de sus créditos, las compensaciones de las partidas, los estados de cuenta, entre otros, los cuales llevarán a la empresa a ejercer pleno control sobre el proceso financiero y de generación de ingresos. Una fortaleza del modelo es que el cliente al momento de tomar el pedido podrá consultar con el repartidor su estado de cuenta y de esa forma saber si puede realizarlo. Esto es equivalente a revisar, en el momento, si tiene limite de crédito, procedimiento que permite optimizar el manejo del tiempo por parte de clientes y empresa, y sobretodo, tomar decisiones rápidamente. La estandarización de los procesos, lo cual abre un mayor espacio para la interacción con los Proveedores y Clientes, es un paso gigantesco en el mejoramiento continuo de la gestión empresarial, pues significa que todos los funcionarios de la compañía, independientemente del país donde se encuentren, seguirán los mismos pasos, manejarán la misma información y podrán satisfacer las reales necesidades del cliente. No quedará espacio para que cada funcionario interprete y decida hacer lo que a su juicio está bien, de forma que se minimizan las asimetrías de información. La calidad y oportunidad de la información en los procesos de cobranza, por medio de las nuevas vías de recaudo y la conciliación bancaria son garantía de transparencia para ambas partes.

71

10. BALANCE DEL PROYECTO Al inicio del presente informe se indicó, un conjunto de actividades que debían ser cubiertas con miras al cumplimiento de cada una de las metas que el Proyecto/Trabajo de Grado perseguía. Estas actividades estaban relacionadas con el conocimiento de los procesos que eran realizados a nivel de sucursal, su análisis, la visualización de las principales debilidades inmersas en ellos y que, dentro del escenario en el cual se desarrollaban, eran difíciles de solventar. También, la definición e implantación de una propuesta a ser ejecutada en el sistema SAP R/3 para satisfacer las necesidades que el usuario y el negocio develaban. Durante el levantamiento de la información, se observó que, aún cuando en la mayoría de los casos los procesos ejecutados por las sucursales de venta de la Empresa estaban estandarizados, existían ciertas diferencias en la manera como algunos de ellos eran ejecutados; estas diferencias principalmente se generaban por la necesidad de algunas sucursales de evitar la acumulación de labores. Para solventar tal situación, fue necesario modificar los procedimientos que sustentaban las operaciones, y así adaptarlos a las condiciones de cada uno de los países donde la empresa hace presencia. Los resultados de esta actividad fueron exitosos. Así las cosas, es posible afirmar que las metas trazadas fueron cubiertas a cabalidad, logrando incluso, y a pesar del retraso generado por la actualización del sistema SAP R/3 y la sincronización del HH para poder realizar las pruebas de los procesos, avanzar en la solución de deficiencias relacionadas con el entrenamiento que se debe ofrecer a los usuarios finales. Si bien el entrenamiento no fue considerado en el plan inicial, debió ser incluido ya que era evidente que la implantación de un nuevo sistema requería de la realización de actividades que no solamente permitieran que los usuarios finales aprendieran a manejar el sistema, sino que también lo entendieran y lo aceptaran completamente. 10.1 NIVEL DE CUMPLIMIENTO DE LOS OBJETIVOS PROPUES TOS � Las jornadas de levantamiento de los procesos, permitieron tener una visión global y profunda de las actividades no comerciales que eran ejecutadas dentro de las sucursales de venta de la Empresa de consumo masivo.

72

� Luego de haber entendido el modelo y los diferentes procesos que debían ser mejorados, se tuvo una idea mucho más clara de la forma como el sistema SAP R/3 con el modulo DSD podía utilizarse para solventar las debilidades del escenario actual. � Se puso en práctica el manejo de los módulos del sistema SAP R/3 - DSD. � Se entendió a fondo la estructura y funcionamiento de SAP ERP. � Se conocieron todos los procesos manejados por la empresa y se hizo su rediseño, se levantaron todos los requerimientos en reuniones con cada uno de los líderes de las empresas a nivel regional, incorporando particularidades de cada país. � Se elaboraron los documentos de diseño para el desarrollo de las funcionalidades que requería el sistema SAP y cada uno de sus módulos para satisfacer las necesidades del cliente. � Se elaboraron los scripts para las pruebas unitarias contando con cada uno de los escenarios que se pudiesen presentar en el momento en que los usuarios hicieran las pruebas, de esta manera se propuso un modelo en el cual se mostraban todos los posibles escenarios con sus procesos, resultados esperados y las transacciones que se debían probar en el sistema SAP. La realización de actividades de mejora dentro del sistema SAP R/3 y la implantación de su modelo DSD, reseñadas en la sección anterior, obligó a la extensión de los procesos relacionados con la preparación previa a la implantación de la propuesta de mejora y por supuesto incidió en el retraso de la puesta en marcha del modelo diseñado dentro del Proyecto. 10.2 DIFICULTADES ENCONTRADAS � Dado que no se consideró, a nivel de la Empresa, que el Proyecto era de gran envergadura, la obtención de recursos humanos que apoyaran las actividades que se realizaban no fue sencilla, puesto que los mismos por no estar asignados al Proyecto le daban prioridad a sus otras actividades.

� Debido a que no se destinaron recursos para apoyar actividades de manejo del cambio, a nivel de las sucursales en las cuales iba a ser inicialmente implantado el sistema, el personal de las mismas mostró una actitud de rechazo en las primeras jornadas de entrenamiento. Este hecho llevó a establecer nuevas jornadas, en las

73

cuales se contó con el apoyo de un equipo de manejo del cambio, que ayudó a establecer estrategias para eliminar el rechazo inicial. � Se encontraron problemas en las pruebas unitarias ya que el sistema no estaba totalmente dispuesto para que estas se pudieran realizar en la fecha planeada.

74

11. CONCLUSIONES El establecimiento de un nuevo sistema operativo no debe ser una decisión tomada al azar, se requieren unas condiciones específicas que posibiliten la implantación, pues no se trata únicamente de sustituir un sistema por otro, sino de establecer una herramienta capaz de cubrir las necesidades actuales y futuras del negocio. El sistema SAP R/3 si bien es cierto que constituye una solución para muchas empresas, también puede significar, en caso de implantarse incorrectamente, un punto de quiebre para las operaciones y la gestión empresarial. Se crearon más fuentes de recaudo para evaluar de forma ágil el volumen creciente de información que ingresa a la compañía. Se creó un nuevo esquema de pago que requirió la realización de actividades paralelas para que todos los elementos involucrados en la emisión de los pagos (cuentas bancarias, cuentas contables, cheques, formas continuas, etc.), estuvieran disponibles y evitar problemas operativos. Se definió un modelo de límites de crédito mediante el cual la empresa dispone de mayor información sobre el riesgo crediticio de sus clientes, impactando positivamente la generación de ingresos. Los modelos desarrollados se constituyen en engranajes con los cuales se pretenden integrar todas las operaciones realizadas en la Empresa. La ejecución del mismo constituye un claro ejemplo de reingeniería de negocio.

75

12. RECOMENDACIONES

A manera de recomendación, es clave integrar las diferentes áreas de la empresa en este tipo de procesos y disponer de los recursos humanos para trabajar el tema de la resistencia al cambio. El factor humano, lejos de ser el último punto a considerar, debe ser siempre abarcado dentro de cualquier tipo de análisis en un lugar prominente, puesto que más allá de las mejoras que pudiera brindar la implantación de un sistema, es el elemento humano, el encargado de ejecutar las operaciones dentro del sistema. Se deberían asignar mayor tiempo para cada una de las fases y tener un tiempo prudencial al final de cada fase del proyecto con lo cual se pudiera cerrar las brechas que han quedado y dar solución a problemas que puedan surgir en la próximas fases por ítems que no hayan sido resueltos o se dejen pasar por alto. A manera de reflexión final, el éxito o fracaso de la implantación de un sistema de información está ligado, a juicio del autor, a tres factores básicos: el conocimiento del proceso que se quiere migrar, el correcto modelado de dicho proceso dentro de la nueva plataforma a emplear y la realización de una reingeniería humana que permita que lo usuarios finales realmente estén conscientes del impacto positivo que dichas mejoras van a ofrecer al proceso. No se trata únicamente de sustituir un procedimiento por otro, se trata de ser capaz de lograr que las personas involucradas en dicho proceso se comprometan con el cambio. Se conoce que aún cuando es la parte a la cual se le presta menos atención, es la más importante ya que, es al usuario final, al que le compete lidiar en el día a día con el sistema. Frente a esta situación se recomienda realizar una buena gestión del cambio lo cual es concientizar al usuario la importancia que representa para cada uno de ellos la manera de poder entender la nueva representación del proceso y como afecta a la empresa como también la forma de operarlo.

76

BIBLIOGRAFÍA ANCHONDO RUIZ, Hugo Benito. Evolución de los Sistemas de ERP [en línea]: Impacto En La Implementación. Bogota D.C.: Gestiopolis, 2008 [Consultado el 02 de Septiembre de 2008]. Disponible en Internet: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/erphbra.htm BITAR, Rodrigo. El grupo colombiano Santo Domingo y la venta de la cervecera Bavaria. En: Diario Financiero, Santiago, 16, febrero, 2006 [en linea]. New York: Athelera, 2008 [Consultado el 15 de Agosto de 2008]. Disponible en Internet: <http://www.athelera.com/081905diariofinanspa.pdf> Business Document Design. Bogota D.C, 2008. 1 Archivo de Computador GLYNN, Williams. Módulos de Ventas y Distribución SD. México: Mc Graw Hill, 2001, 320. GONZALES, Hernán. Que es SAP [en línea]. Buenos Aires: Hernan Gonzales, 2008 [Consultado el 19 de Agosto de 2008]. Disponible en Internet: http://www.hernangn.com.ar/SAP.pdf GONZALEZ RODRIGUEZ, Victoria El impacto de un ERP en la Empresa [en línea]. España: Infojobs, 2008 [Consultado el 25 de Agosto de 2008]. Disponible en Internet: http://www.infojobs.net/noticias_frame.cfm?id=187450103> HERNANDEZ, José Antonio. Implementación de SAP R/3. México: Mc Graw Hill, 2000, 410. Módulos De Sap R3 [En linea]. Madrid: Mundo SAP.com, 2006 [Consultado el 09 de Septiembre de 2008]. Disponible en: http://www.mundosap.com/foro/showthread.php?t=281 Project Charter. Bogota D.C, 2008. 1 Archivo de Computador. ¿Qué es Bavaria? [En línea] Bogota D.C.: Grupo Bavaria, 2008 [consultado 06 de Octubre de 2008]. Disponible en Internet: http://www.grupobavaria.com/espanol/queesbavaria/historia.php Que es un ERP [en linea]. Cataluña: AdPime Iberia, S.L, 2008 [Consultado el 02 de Septiembre de 2008]. Disponible en Internet: http://www.adpime.com/ERP/Es_ERP_intro.htm

77

RAMIREZ CORREA, Patricio y GARCIA CRUZ, Rosario. Una investigación empírica sobre los factores que afectan el éxito de los sistemas ERP en Chile: El éxito de los sistemas ERP. En: Revista Informatica. Abril, 2005, No. 11 [en línea]. Santiago de Chile: Universidad de Concepcion, 2005 [consultado 06 de Octubre de 2008]. Disponible en: www.inf.udec.cl/revista/ediciones/edicion11/InvestigacionEmpirica.pdf Sarbanes-Oxley Sox [en línea]: Controles SOX. Madrid: Piramide Digital, 2008 [Consultado el 10 de Noviembre de 2008]. Disponible en Internet: <http://www.piramidedigital.com/Documentos/ICT/pdictleysarbanesoxley2.pdf Sistema R/3 [en línea]. Madrid: trípode, 2000 [Consultado el 07 de Noviembre de 2008]. disponible en Internet: http://usuarios.lycos.es/cblsap/sisr3.html SOX [en línea]: Beneficios SOX. Bogota: Software for Excellence, 2008 [Consultado el 10 de Noviembre de 2008]. Disponible en Internet: http://www.softexpert.es/norma-sox.php Una investigación empírica sobre los factores que afectan el éxito de los sistemas ERP en Chile [en línea]: El éxito de los sistemas ERP. Santiago de Chile: Patricio Ramirez Correa, Abril 2005 [consultado 06 de Octubre de 2008]. Disponible en: <www.inf.udec.cl/revista/ediciones/edicion11/InvestigacionEmpirica.pdf> VELASCO, Arelis. Definición de ERP [en línea]. Caracas: Sistema de Información Gerencial, 2008, [Consultado el 10 de Noviembre de 2008]. Disponible en Internet: <http://es.geocities.com/alexis_velazco/e3/foro/ii.html>.

78

ANEXOS

Anexo A. Liquidación De Caja De Recaudo

79

80

81

82

Anexo B. Asignación De Limite De Crédito

83

84

85

Anexo C. Cobranza en punto de venta

86

87

Anexo D. Cobranza en backend

88

89

90

91

Anexo E. Manejo de disputas

92

93

94

95

96

Anexo F. Conciliación bancaria

97

98

Anexo G. Script de prueba del límite de credito

Escenario Gestión Transaccional de Crédito para Preventa (H): Liquidación de Preventa en Backend con creación de Pedido de Venta Bloqueado

ID Scenario FBO-010-040.14

Resultado Esperado Se ejecuta liquidación y se genera pedido de venta bloqueado por haber superado límite de crédito asignado

ID Actividad Nombre de la Actividad Transacción / Pantalla Pasos de la prueba y Datos de Entrada Resultados Actuales

FBO-010-040-027

Ejecutar automáticamente Liquidación /N/DSD/SL_COCKPIT

1. Ingresar el No. doc. O Ruta 1000000689 2. Escogemos Lista de Visitas 3. Damos el icono nuevo 4. Check In / out Ingresar el monto recibido: 10000 5. Determinación de diferencias. 6. Datos Generales de Ruta 7. Determinación de diferencias y liquidación manual 8. Grabar

Se ejecuta la liquidación y debido al exceso de limite de credito el pedido nace bloqueado. Este deberá ser aprobado antes de su creación con la VKM1

FBO-010-040-031

Crear automáticamente Pedido de Venta y generar Entrega

Transacción / Pantalla VA03

1. Documento de venta: 2173469176 2. Suministrar 3. Grabar 4. Se crea el documento de salida # 2343469118

Se genera el documento de pedido bloqueado

99

Escenario Gestión Transaccional de Crédito para Autoventa (E): Cliente con pedido que no supera Límite de Crédito

ID Scenario FBO-010-040.5

Resultado Esperado Se genera pedido entre el rango de límite de crédito aceptado para el cliente

ID Actividad Nombre de la Actividad

Transacción / Pantalla Pasos de la prueba y Datos de Entrada Resultados Actuales

FBO-010-040-009

Registrar Pedido y Generar Entrega

VA01 1. Ingresar la clase de pedido ZPP1 2. Diligenciar los Datos Organizativos: Organización de Ventas, canal de distribución y sector 3. Existen dos alternativas para ingresar el pedido, una es especificando todas las condiciones anteriores o la otra es solamente determinando la clase de pedido. Ya en el programa tomara de forma automática los datos organizativos de acuerdo a lo parametrizado en el cliente. 4. En la primera pantalla se ingresa el código del cliente en la parte superior en solicitante al igual el campo de Destinatario de Mercancía. 5. Se dispone a realizar la captura de los códigos de los productos a solicitar en el pedido, dándole un enter el sistema automáticamente trae los valores del producto y totaliza como se puede observar en la parte superior derecha en el campo de Valor Neto. 6. Si se desea visualizar detalles de posición, damo clic en el icono visualizar detalles de la posición en la barra inferior. Se selecciona el producto que queremos ver y dar click, este icono nos lleva a los datos de posición del producto, donde podemos visualizar de forma general las características del producto, como valores, desde donde lo despacho etc. 7. Dar clic en el icono para grabar, si el documento se encuentra incompleto el sistema nos permite grabarlo sin embargo nos da la opción de tratar lo incompleto

Se ingresó todo correctamente pero al momento de grabar salió una ventana en donde decía que el cliente estaba excedido en 1,038. Ref. N° Pedido 2000001136 Se verificó que en el esquema de cálculo no se calculó el ISC que se entiende como una omisión en la prueba unitaria.

100

Escenario Gestión Transaccional de Crédito para Preventa (G): Liquidación de Preventa en Backend con creación de Pedido de Venta y de documento de Cobro

ID Scenario FBO-010-040.13

Resultado Esperado Ejecución de liquidación, generación de pedido de venta y de documento de cobro

ID Actividad Nombre de la Actividad Transacción / Pantalla Pasos de la prueba y Datos de Entrada Resultados Actuales

FBO-010-040-027 Ejecutar automáticamente Liquidación

/N/DSD/SL_COCKPIT

1. Ingresar el No. doc. O Ruta 1000000689 2. Escogemos Lista de Visitas 3. Damos el icono nuevo 4. Check In / out Ingresar el monto recibido: 10000 5. Determinación de diferencias. 6. Datos Generales de Ruta 7. Determinación de diferencias y liquidación manual 8. Grabar

Se ejecuta la lista de visitas (upload - HH preventa) Se genera el pedido 2173469176 con el documento de cobro 86000000209

FBO-010-040-028 Validar Partida Abierta vencida

FBL5N

1. Cuenta de deudor: 10000191 2. Sociedad BK00 3. Todas las partidas 4. Fecha de contab. Fecha actual

El documento de cobro que se visualiza es 86000000209 y documento de compensación 4490000081

FBO-010-040-030 Crear automáticamente Pedido de Venta y generar Entrega

Transacción / Pantalla VA03

1. Documento de venta: 2173469176 2. Suministrar 3. Grabar 4. Se crea el documento de salida # 2343469118

Documento de pedido: 2173469176 Se crea el documento de entrega # 2343469118

101

Anexo H. Script de prueba del proceso de disputas Resultado Esperado

Manejo de Disputas por Concepto de Pago. Se coloca la cuenta en estatus de Disputa. Se llega a un acuerdo con el cliente, manteniendo la factura original y cambiando condición de pago. Se solicita el desbloqueo del cliente si aplica

ID Actividad Nombre de la Actividad

Transacción / Pantalla Pasos de la prueba y Datos de Entrada

Persona que realiza la Prueba

Resultados Esperados Resultados Actuales

FBO-050- 020-004

Colocar en estatus de disputa a la cuenta del cliente CONTROL SOX: OCCN05 OCCN27

F-30

1. Ingresar la Fecha documento: Fecha Hoy 2. Ingresar la Fecha contab: Fecha Hoy 3. Ingresar el Txt.cab.documento Operaciones a tratar 4. Escogemos Traslado con compensación Primera posición del documento 5. Ingresar la clave de contabilización: 09 6. Ingresar la cuenta de deudor 10000193 7. Ingresar el in.CME " 8. Dar enter 9. Ingresar el Importe 10. Ingresar Vence el 11. Ingresar Ref.factura: Se debe ingresar el No. de documento orginal 12. Dar clic en el icono Tratar Pas 13. Ingresar la cuenta de deudor 10000193 14. Dar enter 15. Escoger la partida abierta a reclasificar 16. Dar el icono simular para revisar los registros del documento 17. Dar click en el botón Contabilizar

Usuario

Reclasificar cuenta de cliente hacia CME. Validar que el Límite de Crédito del cliente no se vea afectado por la partida en disputa Mensaje de error y no permite: a. Efectuar registros contables en el periodo cerrado. b. Contabilizar registros en periodos diferentes pasado/futuro (meses). Mensaje de error y no permite realizar ajustes manuales donde la suma de débitos y créditos es diferente a "0".

se logro colocar en status de disputa la cuena del cliente 10000193. El numero del documento es 4490000063

102

Resultado Esperado

Emisión de Nota de Cargo a nombre del cliente, asignando las fechas de vencimiento acordadas con el cliente. No se registra cobranza y se bloquea cuenta del cliente

ID Actividad Nombre de la Actividad Transacción / Pantalla Pasos de la prueba y Datos de Entrada Resultados Actuales Rol de Acceso al Sistema

FBO-050-020-013

Registrar nota con cargo al cliente CONTROL SOX: OCCN05 OCCN27 OCCN03

F-30

1. Ingresar la Fecha documento: Fecha Hoy 2. Ingresar la Fecha contab: Fecha Hoy 3. Ingresar el Txt.cab.documento Operaciones a tratar 4. Escogemos Traslado con compensación Primera posición del documento 5. Ingresar la clave de contabilización: 01 6. Ingresar la cuenta de deudor 10000194 7. Dar enter 9. Ingresar el Importe 10. Ingresar Cond. pago Z030 11. Ingresar Ref.factura: Se debe ingresar el No. de documento orginal 12. Dar clic en el icono Tratar Pas 13. Ingresar la cuenta de deudor 10000194 14. Ingresar el Indicador CME " 15. Dar enter 16. Escoger la partida abierta a reclasificar 17. Dar el icono simular para revisar los registros del documento 18. Dar click en el botón Contabilizar

se registra la nota de cargo al cliente, se reclasifica la deuda. El documento es 4490000052 el monto que se va a reclasificar es de 53,63

USBOPR04

FBO-050-020-103 Establecer los montos y las fechas para el cobro de los montos

FB03

1. Ingresar el No. Documento registrado en el paso anterior 2. Ingresar Sociedad 3. Ejercicio Dar enter Visualizar en la partida correspondiente al deudor la condición de pago asignada

Se ha logrado establecer los montos y las fechas para el cobro. El numero de documento es 4490000052

USBOPR04 – Rol de Usuario

FBO-050-020-110

Bloquear al cliente y reclasificar partida a cuenta de difícil cobro CONTROL SOX: OCCN05 OCCN27

FD05

1. Ingresar el Deudor 10000194 2. Ingresar la Sociedad BK00 Dar clic en el icono Ejecutar Bloqueo de contabilización --> Colocar el flag de bloqueo

Bloquear al cliente y validar que la información no se sincroniza en el HH

Se logro Bloquear al cliente y la cuenta fue reclasificada.

103

Anexo I. Script de prueba del proceso de cobranzas

ID Scenario FBO-040-011.30

Resultado Esperado

Se mantiene la CxC del cliente y el cobro recibido por éste. Validar si los datos de la transferencia bancaria se encuentran incluidos correctamente a nivel de cuenta de banco

ID Actividad Nombre de la Actividad

Transacción / Pantalla Pasos de la prueba y Datos de Entrada Resultados Esperados

FBA-040-011-001 Verificar CxC del Cliente

Visualización partidas abiertas del cliente

FBA-040-011-005 Validar vencimiento

FBL5N - Visualizar/Modificar partidas

Selección Deudor 1. Ingresar Cuenta de Deudor 10000189 2. Ingresar Sociedad BK00 Status 3. Escoger Partidas abiertas Clase 4. Escoger Partidas Normales y Operaciones CME

FBA-040-011-032 CONTROL SOX OCCN05, OCCN23 Y OCCN27 FBA-040-011-042 CONTROL SOX OCCN08

Registrar monto, la cuenta, el banco y el numero de planilla Realizar compensación de la Partida Abierta con el Cobro Recibido

F-28 1. Fecha de documento: Digite la fecha de documento. Con el matchcode (F4) se puede escoger la fecha desde un calendario. 2. Sociedad: Ingrese la sociedad BK00 3. Fecha de Contabilización: Digite la fecha de contabilización. El sistema trae por default la fecha actual. Con el matchcode (F4) se puede escoger la fecha desde un calendario. 4. Txt.cab.doc.: Digite un texto aclaratorio del pago que se va a realizar. 5. Texto compens.: Digite un texto breve que explique en su totalidad la operación a realizar. Datos Bancarios:

Generar asiento contable contra cuenta de banco por el monto recibido Validar compensación partida abierta

IFC-PERU OCCN08

Mensaje de error y no permite lo siguiente:

a)Afectar a cuentas contables diferentes del mapeo de cuentas

previamente establecido b)Contabilizar registros en periodos

diferentes pasado/futuro (meses)

104

105

Anexo J. Script de prueba del proceso de conciliac ion bancaria

Escenario Solicitud del extracto Bancario por medio de SWIFT, el documento presenta diferencias en los registros pero la diferencia es correcta por lo tanto se hace un ajuste manual al documento.

ID Scenario

FBO-030-040.2

Resultado Esperado

Modificar registro en cuenta de banco al identificar, durante la ejecución de la Conciliación Bancaria, que existen errores en las contabilizaciones hacia la cuenta de banco.

ID Actividad Nombre de la Actividad

Transacción / Pantalla

Pasos de la prueba y Datos de Entrada

Equipo Responsab

le Resultados Esperados Resultados Actuales

FBO-030-040-005 CONTROL OCCN28

Revisar el reporte de errores para validar que el extracto se cargo exitosamente Control SOX: OCCN28

Transacción FEBA_BANK_STATEMENT Tratar posteriormente

1. Seleccionar la aplicación: Extracto Cuenta electronico Manual. 2. Ingrese la información de: Sociedad=BK00, Banco Propio=02193, ID. Cta= 00413, No. Extracto=00001 y Fecha de extracto (De acuerdo con el extracto que acabó de subir). 3. Los demás campos

FBO

Obtención reporte errores de extracto bancario y realizar

las correcciones para verificar la

contabilización del extracto.

Se obtiene el reporte de errores y se hace correcciones para la

contabilizacion

FBO-030-040-007

Realizar una comparación automatica entre los registros del extracto y los registros de la cuenta de banco

Transacción FEBA_BANK_STATEMENT Tratar posteriormente

1. Seleccionar la aplicación: Extracto Cuenta electronico Manual. 2. Ingrese la información de: Sociedad=BK00, Banco Propio=02193, ID. Cta= 00413, No. Extracto=00001 y Fecha de extracto (De acuerdo con el extracto que acabó de subir). 3. Los demás campos

FBO

Generación automática de log de errores al comparar datos extracto vs.

datos SAP

Correcciones para la contabilizacion

106

Escenario Solicitud del extracto Bancario por medio de SWIFT, el documento presenta diferencias en los registros pero la diferencia es correcta por lo tanto se hace un ajuste manual al documento.

ID Scenario FBO-030-040.2

Resultado Esperado

Modificar registro en cuenta de banco al identificar, durante la ejecución de la Conciliación Bancaria, que existen errores en las contabilizaciones hacia la cuenta de banco

ID Actividad Nombre de la Actividad Transacción / Pantalla Pasos de la prueba y Datos de

Entrada Resultados Esperados Resultados Actuales

FBO-030-040-005 CONTROL OCCN28

Revisar el reporte de errores para validar que el extracto se cargo exitosamente Control SOX: OCCN28

Transacción FEBA_BANK_STATEMENT Tratar posteriormente

1. Seleccionar la aplicación: Extracto Cuenta electronico Manual. 2. Ingrese la información de: Sociedad=BK00, Banco Propio=02193, ID. Cta= 00413, No. Extracto=00001 y Fecha de extracto (De acuerdo con el extracto que acabó de subir). 3. Los demás campos

Obtención reporte errores de

extracto bancario y realizar las

correcciones para verificar la

contabilización del extracto.

Se obtiene el reporte de errores y

se hace correcciones para la

contabilizacion

FBO-030-040-007

Realizar una comparación automatica entre los registros del extracto y los registros de la cuenta de banco

Transacción FEBA_BANK_STATEMENT Tratar posteriormente

1. Seleccionar la aplicación: Extracto Cuenta electronico Manual. 2. Ingrese la información de: Sociedad=BK00, Banco Propio=02193, ID. Cta= 00413, No. Extracto=00001 y Fecha de extracto (De acuerdo con el extracto que acabó de subir). 3. Los demás campos

Generación automática de log

de errores al comparar datos

extracto vs. datos SAP

Correcciones para la contabilizacion

107

Anexo K. Firma de aprobacion de escenarios fbo

Resultados de las pruebas - Hoja de Frimas pruebas unitarias

ID Escenario

Fecha de la

Prueba

Persona que realiza la Prueba Problemas Abiertos Solución

Planeada Fecha solución

planeada APROBADO

FBO-050-020.1

13-12-2008

JOSE SALINAS, ELMER

QUINTANA

Debe identificarse una cuenta por cobrar al

responsable dentro de la sociedad San Ignacio o Dicoposac. En Backus y SanJuan la liquidación

queda cuadrada.

Change Request el cual fue

aprobado por el comite de PMO

Debe ser resuelto antes del Go-Live

de Ola 1 OK

FBO-050-020.2

13-12-2008

JOSE SALINAS, ELMER

QUINTANA

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.3

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

108

FBO-050-020.4

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.5

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.6

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

109

FBO-050-020.7

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.8

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.9

13-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

110

FBO-050-020.10

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.11

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.12

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

111

FBO-050-020.13

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.14

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.15

15-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja en Backend.La prueba fue

exitosa con el rol de usuario GPELAEZMNota:

Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

112

FBO-050-020.16

16-12-2008

USUARIO ASIGNADO

Estos escenarios son poco probables que se detecten

en la liquidación del reparto. Consideramos que la detección será cuando el cliente afectado reclame y si luego del análisis no se detecta se procede como en el escenario FBO-050-

020.1

Change Request el cual fue

aprobado por el comite de PMO

Debe ser resuelto antes del Go-Live

de Ola 1 OK

FBO-050-020.17

16-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.18

16-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

113

FBO-050-020.19

16-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.20

16-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK

FBO-050-020.21

16-12-2008

USUARIO ASIGNADO

sin mayores problemas en la actualidad ya se trabaja

en Backend. La prueba fue exitosa con

el rol de usuario GPELAEZM

Nota: Se volvio a probar el ingreso con el usuario

asignado para la prueba verificando que

efectivamente ya permitia el acceso.

OK