Diseño del canal de ventas por internet integrado a SAP R/3 para Mathiesen S.A.C. (página 2)

5 Super conjunto de actividades y flujos aplicados a un proceso específico. 5.5.6.- Promoción y publicidad

La promoción y publicidad del nuevo canal de ventas, en una primera instancia estará a cargo de los operadores comerciales, ya que ellos serán quienes realizarán remotamente las primeras notas de ventas en las dependencias físicas de los clientes y serán los encargados de mostrar cómo opera. Luego, se tiene contemplado invitar a las principales empresas a probar un demo del canal y se les pedirá su opinión acerca de la operación del sitio, con el fin de analizar posibles mejoras. Posteriormente, se podrá promocionar y publicitar el canal por medio de charlas a ciertos clientes importantes, siendo los operadores comerciales los encargados de dar a conocer el sitio a su cartera de clientes. Por último, se realizará un lanzamiento oficial, en el que se invitarán a ciertos clientes y revistas de tecnologías de información presentes en Chile enfocadas a negocios, de modo de potenciar la noticia y divulgarla a actuales y potenciales clientes.

5.5.7.- Distribución

El nuevo canal de ventas actualizará en línea los nuevos pedidos, o sea los que se encuentran listos para ser despachados, y de ahí en adelante el proceso seguirá su curso tradicional, es decir cada 5 minutos aproximadamente el jefe de despacho verá en SAP cuáles son las órdenes de venta liberadas, luego realizará el ruteo de los camiones, cerrando al medio día las órdenes a despachar en la tarde y a las 17 horas las que serán despachadas al siguiente día.

III.- Modelo de la situación actual aplicando patrones de negocio.

La experiencia muestra que el diseño o rediseño de procesos lleva a soluciones similares en procesos del mismo tipo, los cuales se repiten en diferentes organizaciones, de la más variada naturaleza, y que la manera en que ellos se realizan en las empresas líderes –de acuerdo a lo que se denominan "mejores prácticas"– es muy parecida. El señor Oscar Barros en su libro “Rediseño de Procesos de Negocios mediante el uso de Patrones” [1], aplica este concepto, construyendo varios modelos Macro, los cuales han sido validados por medio de su especialización, detallando actividades y flujos a procesos en dominios específicos. La ventaja principal de usar esta estructura en el diseño de la arquitectura que definirá el nuevo canal de ventas de Mathiesen, radica en el hecho de mejorar los procesos actuales, internalizando las mejores prácticas, sin tener que empezar desde cero, lo cual tiene obvias implicancias en cuanto al aumento de productividad. La diagramación del tipo IDEFO mediante el uso de patrones5 (ver Figura N°5), es la técnica que mejor se adecua a este enfoque, pues permite analizar los procesos desde su comportamiento global, detallando cada actividad en niveles inferiores hasta llegar al grado requerido de detalle. Control: Orienta el comportamiento de esta actividad. Entrada: Información o Física Salida Información o Física

Mecanismos: Recursos tecnológicos y otros para desarrollar la actividad

Figura N°5: Diagramación Modelo Estructurado.

Para el proceso de ventas tradicionales, se adaptará el patrón Macro1vsd, apoyado con el software Bpwin. Este patrón se encuentra en el documento “Patrón del Proceso Venta y Distribución de Stock” [2], y es un caso especial del Macro 1 “Provisión de un Bien o Servicio”.

La venta tradicional la realizan operadores y vendedores comerciales directamente en terreno o vía telefónica con clientes de su cartera, (ver Figura N°6). El precio, cantidad y forma de pago se negocia directamente con el consumidor, para luego interactuar con SAP y crear la respectiva nota de venta, ingresando los antecedentes del cliente y del producto al sistema. Figura N°6: Venta al Cliente

La primera actividad de la Figura N°6, “Venta Telefónica”, se detalla en la Figura N°7. Un asistente comercial es el responsable de derivar el llamado del cliente a su correspondiente operador comercial o representante de ventas. El cual se encarga de crear en ese mismo momento la nota de venta. En el caso de ser un cliente nuevo se solicitan algunos antecedentes, como el balance comercial y el pago de IVAs de sus últimas compras, a fin de que el personal de finanzas evalúe el límite de crédito a otorgar.

Figura N°7: Venta Telefónica Algo distinto ocurre en el caso de las ventas que se realizan en terreno (Figura N°8), pues la creación de la nota de venta se realiza en dependencias de la empresa, en un momento posterior a la negociación y es por esta razón que se incurre en el riesgo de trabajar simultáneamente sobre un mismo stock. Los flujos que salen de la actividad “Creación nota de venta” de las Figuras N°7 y N°8, son los siguientes: ? Mensaje pedidos liberados: Aviso que se genera en bodega al aprobarse un pedido para su despacho. ? Cambio de estado clientes pedidos y productos: Actualización en la base de datos de SAP de la nueva transacción aprobada (pedido, monto de crédito del cliente y rebaja de stock). ? Mensaje pedido a decisión: Pedidos que deben someterse a distintas validaciones para decidir aprobarlos o rechazarlos. Se traduce en un control que gatilla la actividad “Ingreso de datos de Clientes y Productos en SAP” de la Figura N°9. ? Pedidos fallidos: Pedidos que por alguna razón no pudieron ser satisfechos directamente en SAP.

Figura N°8: Venta en Terreno

La figura N°9 comienza cuando el vendedor ingresa los antecedentes del cliente, pedido y producto para que el sistema decida aprobación, rechazo o derivación a decisión manual. De esta manera el pedido pasará por una verificación de disponibilidad del producto y un análisis de riesgo crediticio. Por otra parte, al momento de ingresar un pedido, el sistema devuelve distintas clasificaciones de riesgo, las cuales fueron creadas manualmente y no se han actualizado a la fecha. El personal de finanzas, cuando dispone de los antecedentes comerciales de los clientes, calcula informalmente el límite de crédito en una planilla excel, según criterios detallados en el capítulo siguiente y que se basan principalmente en el balance comercial de cada empresa. De excederse el pedido en el límite de crédito asignado a cada cliente o al tener clientes morosos o al cambiar la modalidad con la que pagará a la empresa, la decisión de aceptación o rechazo del pedido será derivada al personal de finanzas, el cual actuará en base a su criterio y experiencia para liberar o bloquear la venta. Esta situación ocurre aproximadamente para el 50% de los pedidos cursados en SAP y de no liberase la venta (aproximadamente en el 5% de los casos), el operador comercial –principal interesado en concretar la venta– acude al departamento de finanzas para tratar de revertir la situación, produciéndose en no pocos casos, fuertes diferencias de opinión.

Figura N°9: Decisión Pedidos IV.- Diseño de la arquitectura e-Business 1.- Modelo del diseño de la arquitectura Para realizar el diseño de la arquitectura se utilizarán los patrones que aparecen en el documento [3], en donde el autor especializa la actividad “Venta Internet” (Figura N°10), desde el patrón “Venta y distribución de stock” [2].

Figura N°10: Venta Internet De la figura anterior se detallarán las actividades “Búsqueda de información, verificación cliente y selección pedido” (Figura N°11) y “Procesamiento automático pedido” (Figura N°12). En el primero de los casos el navegante visitará la página viendo información de la empresa y los productos disponibles. Si el cliente desea conocer los precios de los distintos productos, el browser pedirá que ingrese login y password, y mediante el “Controlador de interacción” iniciará el procesamiento de autenticación por medio del flujo “Mensaje verificación ingreso cliente”. El flujo anterior pasará por la actividad “Lógica Verificación cliente y Precio”, en donde se verifica el password y se transfieren los datos de los productos y de los precios a la actividad “Lógica Interfaz Usuario” para que se genere la página HTML con los precios para el cliente particular. También en este proceso se llevará a cabo el almacenamiento de los datos de sesión en memoria y se actualizarán los productos seleccionados en el carro de compras. Este tipo de datos sólo persistirá durante el período que dure la sesión.

Figura N°11: Búsqueda de Información Verificación Cliente y Selección Pedido Cuando el cliente completa el pedido definitivo y se decide a comprar comenzará el proceso de decidir la aprobación o rechazo del pedido por medio del flujo ”Invocación procesamiento SAP”. De igual modo, el controlador de interacción se encargará de grabar el pedido en tablas SAP por intermedio del flujo llamado “Grabación pedido a SAP”, con el fin de ir construyendo un repositorio de datos, el cual podrá ser procesado a futuro para analizar el comportamiento de los clientes. Para llevar a cabo la decisión del pedido, el “Controlador de interacción” de la Figura N°13, mandará el flujo llamado “Invocación remota a lógica de crédito SAP” a la actividad “Lógica de otorgamiento de crédito”, y de manera análoga el flujo “Invocación remota a lógica de stock SAP” activará la lógica de disponibilidad y rebaja de stock.

La decisión de aprobación o rechazo de la compra irá en el flujo “Decisión pedidos (crédito, stock)” y se informará al cliente mediante “Página HTML (respuesta a pedidos)” de la Figura N°11. Figura N°12: Procesamiento Automático Pedido

El “Controlador de interacción” realiza una serie de otras actividades:

? Cuando el pedido del cliente ha sido aceptado, genera “Mensaje pedidos liberados” y “Cambio de Estado Clientes y pedidos”, para que se grabe el nuevo pedido en SAP y se rebaje el stock del producto comprado, así también se actualizará el crédito disponible. De ahí en adelante la venta seguirá el curso tradicional. ? Cuando el pedido requiere estudio por algún cambio en las condiciones de crédito, genera “Pedidos a finanzas”. ? Cuando el pedido no se pudo resolver por cualquier motivo, genera “Pedidos derivados a O.C.” para que el operador comercial realice un procesamiento tradicional. Figura N°13: Decisión pedidos Internet – SAP

Por otra parte, en la Figura N°14 se detalla el “Cálculo de parámetros de crédito”. Estos parámetros servirán como input para el otorgamiento de crédito en SAP. Se tiene contemplado como un periodo razonable, que la clasificación y la determinación de la línea de crédito, sean actualizados semestralmente por el personal de finanzas en una Intranet Corporativa. Figura N°14: Cálculo de Parámetros Crédito

2.- Lógica de apoyo a la arquitectura e-Business 2.1.- Determinación de la Clasificación de Crédito

Cada uno de los clientes de Mathiesen cuenta entre sus atributos con una clasificación crediticia, que define la confiabilidad que la empresa puede depositar en la capacidad de pago de sus clientes. Esta clasificación es definida por Mathiesen de acuerdo a tres variables. (En el Anexo N° 1.1 se encuentra el detalle de las características de las diferentes clasificaciones) 1. Deuda morosa histórica del cliente 2. Protestos de los pagos del cliente 3. Propietarios del cliente

A fin de estructurar el manejo de estas variables para que puedan ser incluidas en la lógica programada del proceso a automatizar, se les asigna valores según los siguientes criterios:

? DDME (días existentes de deuda morosa) Variable cuantitativa que indica históricamente el tiempo (en días), que el cliente ha presentado morosidad en el pago de sus deudas.

? DMSP (deuda morosa sin plan de pago) Variable cualitativa que define la situación de pago que ha presentado un cliente con deuda morosa. Se asigna el valor 1 si el cliente tiene deuda morosa sin plan de pago, y el valor 2 si el cliente presenta deuda morosa con prórrogas reiteradas.

? Protestos Variable cualitativa que indica la situación del cliente en cuanto a la presentación de protestos a sus pagos. Los valores asignados a esta variable son los mostrados en la Tabla N°8. Tabla N°8: Situación Protestos

? Propiedad Variable cualitativa que discrimina a los clientes según la organización a la que pertenecen. (Ver Tabla N°9). Tabla N°9: Situación Propiedad

Utilizando de manera lógica las variables recién definidas, Mathiesen determina para cada cliente su clasificación crediticia, representada por una letra para los distintos casos. Se identifican las siguientes clasificaciones6: 6 Este proceso se encuentra explicado con mayor detalle en el Anexo N° 1.1

Tabla N°10: Clasificación Crediticia de los Clientes En el Anexo N° 2.1 se muestra la lógica de este proceso en lenguaje seudo-estructurado. Esta lógica será la base para una posterior programación que automatice el proceso en una Intranet. 2.2.- Determinación del Límite para el Monto del Crédito Paralelamente a la determinación de la clasificación crediticia de los clientes, Mathiesen define el monto máximo de crédito disponible (MC) para ellos, atendiendo a ciertos parámetros comerciales del cliente y a algunas variables cualitativas. Aspectos Cuantitativos En general, el límite de crédito se determina en base al balance comercial del cliente, aunque en no pocos casos se recurre a otras fuentes de información, tales como DICOM, estimaciones cualitativas y minoritariamente apoyo mutuo con los competidores. Para los clientes que presentan balances comerciales se calcula el siguiente algoritmo en una planilla excel: 1) Se pondera por 0.2 el monto total de las compras realizadas por el cliente en los últimos tres meses, asegurando de esta manera no entregar un crédito que supere el 20% de tal cantidad. 2) Se determina las utilidades del cliente en el último año. 3) La tercera variable depende de la relación entre el pasivo exigible del cliente y su patrimonio: ? Si los pasivos exigibles son menores al patrimonio, se entregará un crédito no superior al 20% de este último. ? Si los pasivos exigibles están entre una y dos veces el patrimonio, se entregará un crédito no superior al 15% de este último. ? Si los pasivos exigibles están entre dos y tres veces el patrimonio, se entregará un crédito no superior al 10% de este último. ? Si los pasivos exigibles son superiores a tres veces el patrimonio, no se entregará crédito al cliente (MC=0). El promedio simple de los tres valores recién obtenidos determina la línea de crédito del cliente, la que además debe ser ajustada según variables cualitativas definidas en la Tabla N°11.

Aspectos Cualitativos

Se designa una calificación para cada cliente en dos ámbitos: riesgo del cliente y riesgo del sector económico al que pertenece. Para determinar esa calificación se utiliza en ambos casos la escala ilustrada en la Tabla N°11. Tabla N°11: Escala de Riesgo Crediticio Si el promedio simple de las dos calificaciones anteriores es menor a tres, la línea de crédito determinada cuantitativamente se castiga en un 25% (se multiplica por 0.75).

Restricción Finalmente, se restringe el crédito obtenido determinando que no puede sobrepasar el 10% del patrimonio de Mathiesen.

Un par de ejemplos pueden ser consultados en el Anexo N°1.2 del presente informe. Además, en el Anexo N°2.2 se encuentra la lógica asociada a este proceso en lenguaje seudo-estructurado.

2.3.- Otorgamiento del Crédito (SAP) Cada compra que realiza un cliente de Mathiesen está sujeta a la clasificación determinada anteriormente y según ésta se le asignan distintos montos de crédito, el cual no deberá exceder el límite total. Las condiciones establecidas en SAP para cada categoría se pueden observar en la siguiente Tabla N°12 Clasificación

A+

A

B

B-

C Cliente

Prime

Bueno

Normal

Problema

Riesgoso Tipo de Pago

Crédito 75.000 25 30 45 3 50.000 15 30 45 3 25.000 10 7 30 3 10.000 10 5 15 3 0 Condiciones

Valor máximo de venta ($US) % tolerancia PA Días tope Días tope antigua Nivel de reclamación Valor máximo de venta ($US) % tolerancia PA Días tope Días tope antigua Nivel de reclamación Valor máximo de venta ($US) % tolerancia PA Días tope Días tope antigua Nivel de reclamación Valor máximo de venta ($US) % tolerancia PA Días tope Días tope antigua Nivel de reclamación Valor máximo de venta ($US)

Tabla N°12: Condiciones según Clasificación Crediticia

En donde7 ? % tolerancia: es la cantidad porcentual que puede excederse un cliente por sobre su línea de crédito. ? PA (Partida Abierta) días tope: es el promedio permitido de días con deudas vencidas del cliente para no bloquear el actual pedido. ? Días tope antigua: es la máxima cantidad permitida de días desde que ha vencido la deuda más antigua del cliente para no bloquear el actual pedido. ? Nivel de reclamación: se refiere al número permitido de cartas por deuda que se le ha enviado al cliente antes de bloquear su crédito.

En el Anexo N°2.3 se encuentra la lógica asociada al proceso de otorgamiento de crédito en lenguaje seudo-estructurado.

Con el fin de realizar un proceso transparente y no tener replicación de recursos, esta lógica no se programará, sino que tendrá que ser integrada a la nueva aplicación.

V.- Diseño de los componentes e-Business 1.- Derivación de los casos de uso y sus escenarios

El diseño de la arquitectura del sitio presentada anteriormente permitió identificar los procesos que serán apoyados con tecnología Internet. Para pasar de tal arquitectura a una definición de los requerimientos que deben satisfacer los componentes (y siguiendo con la metodología ilustrada en la Figura N°3), se utilizarán los Casos de Uso, los cuales serán detallados mediante el lenguaje UML (Unified Modeling 7 En el Anexo N°1.3 se describen con más detalle las condiciones de bloqueo de crédito impuestas por Mathiesen

Figura N°15: Caso de Uso “Seleccionar Pedido” Language), el cual permite un enfoque orientado a objetos que llevará a definir con precisión los componentes a automatizar. Concretamente, a partir de los modelos de la arquitectura e-Business presentados en Figuras N°11 a la N°14 se derivan los casos de uso de las Figura N°15, N°16, N°17 y N°18, apoyados con el software Rational Rose. Figura N°16: Caso de uso “Decisión Pedidos SAP”

La relación < < includes>> de la Figura N°16 indica que el caso “Atención Pedido” incluye el caso “Decisión Pedidos” para su ejecución. Esto significa que para atender completamente un pedido será necesario invocar la lógica de SAP para que tome la decisión sobre el otorgamiento de crédito y la disponibilidad de stock.

Por otra parte, en una Intranet un usuario de finanzas atenderá los pedidos que por alguna razón (cambio de condiciones de pago, fallas del sistema, etc.) quedaron para estudio de crédito, liberando o bloqueando los pedidos según corresponda.

De la misma manera un usuario de finanzas semestralmente invocará las lógicas de clasificación crediticia y del cálculo del límite de crédito para cada cliente. Este proceso derivará el caso de uso llamado “Cálculo de parámetros”. ? Entity: Clases que describen por medio de atributos las representadas en la aplicación por medio de métodos u entidades que serán operaciones. También ilustra los servicios que se proveerán a partir de los datos almacenados para atributos de objetos en SAP (particularmente se muestran los nombres de las tablas relacionales de SAP que serán abordadas). Se simboliza como: ? Control: requerimiento del “Controlador Clases que ejecutan lógica, tanto de presentación como del negocio, a de otras; una clase particular de control es aquella que implementa la función de interacción” el cual dirige distintos flujos computacionales que utilizará la adaptan al caso particular por medio del mecanismo

: Interface aplicación. Se simboliza como:

? Interface: Otro tipo de clases que se de estereotipo. Se simboliza como: Figura N°17: Caso de Uso “Otorgar Crédito a Estudio”

Figura N°18: Caso de Uso “Calcular Parámetros”

2.- Identificación de clases y su interacción

2.1- Clases de objetos genéricas

A continuación se detallan las clases de objetos que materializan los nuevos componentes del canal de ventas por Internet y de la Intranet de la empresa, adoptando la clasificación de UML, que las divide en:

? Boundary: Clases a través de las cuales un usuario interactúa con la aplicación; en este caso serán las páginas invocadas y desplegadas por medio de un browser, las cuales serán de ingreso o de respuesta de pedidos. Se simboliza como:

2.2- Realización de los casos de uso Las relaciones y la lógica ligan las actividades descritas por medio de diagramas de secuencia, lo que también corresponde a una realización de los casos de uso descritos con anterioridad. Tales diagramas se muestran en las Figuras N°19, N°20, N° 21 y N°22, y representan una buena aproximación al diseño de las clases y sus interacciones y tiene, implícitamente una asignación de responsabilidades. Cuando un cliente ha navegado por el sitio de la empresa informándose de las novedades y de los productos disponibles y desea entrar a la “tienda virtual” como un nuevo comprador, entonces se dará curso al primer caso de uso llamado “Seleccionar Pedido” (Figura N°19), para lo cual será necesario que el nuevo cliente se registre. Luego la clase de control “Registrar” informará por medio de la misma página y por mail, la existencia de un nuevo cliente al respectivo operador comercial de su cartera (asignado según la información del rubro de la “empresa cliente”), y de verificar que es una empresa real, se le informará su password por medio de mecanismos de encriptación con las llamadas “llaves públicas y privadas”. No se automatiza el registro de clientes por un tema meramente estratégico, pues dada la alta competencia del mercado será conveniente dar acceso a la información de precios sólo a potenciales clientes, previamente verificados. Si se trata de un cliente registrado, entonces él ingresará inmediatamente su login y password, (teniendo tres posibilidades de errar). Estos datos de autentificación serán validados por medio de los RFC (llamadas remotas a las funciones de SAP). La integración (Internet – SAP) se desarrollará mediante un tipo de “midleware” o conector, cuya elección se tomará cuando se detalle el diseño de la aplicación (Subcapítulo 4). El comprador ingresará el ítem del producto seleccionado en el carrito de compras, el cual será manejado con variables de sesión, útiles para almacenar en forma unívoca la información temporal para cada comprador. Específicamente la clase de control “Seleccionar” será la encargada de ingresar en la clase definida por medio del mecanismo de estereotipo “Session” el producto y la cantidad requerida. Luego se actualizará la nueva sesión y se enviará a la página de respuesta al cliente, quien tendrá la libertad de seguir agregando productos, eliminarlos o confirmar su compra. En el caso que el cliente decida comprar los productos seleccionados, se dará curso al segundo caso de uso de la Figura N°20 llamado “Decisión Pedidos SAP”. En el cual la página inicial, (clase “boundary”) obtiene el pedido actualizado virtualmente en memoria desde el control “Carrito”. Luego envía remotamente –vía RFC– estos parámetros a las funciones respectivas de SAP, capaces de guardar el pedido en las tablas de nombre VBAP y VBAK para finalmente decidir su aprobación chequeando condiciones de crédito y stock. Se enfatiza el hecho de que se guardarán todos los pedidos (aprobados y no aprobados), a fin de tener un registro del comportamiento del cliente y poder en el futuro realizar ofertas proactivas a cada cliente. Los diagramas de las Figuras N°21 y N°22 se relacionan directamente con el apoyo que se brindará al departamento de finanzas para que su personal cuente con una buena herramienta de apoyo al cálculo y actualización semestral de todos los parámetros de crédito en la Intranet. Se pretende con este sistema disminuir en un 80% los pedidos que requieren de una decisión manual en su tramitación, dejando que lleguen a estudio sólo aquellos pedidos en que el cliente desee ampliar el plazo en su condición de pago. En el caso "Otorgar Crédito a Estudio” el usuario de finanzas entrará al sistema con una clave que se validará contra una nueva tabla llamada Usuario_finanzas. Luego el control “Actualizar_SAP” rescatará desde la tabla VBKD los pedidos que han quedado a estudio y según su parecer liberará o bloqueará remotamente la nota de venta en SAP. Para el caso “Calcular Parámetros” (Figura N° 22), se presupone que se ha validado el ingreso del usuario (ilustrado en la figura anterior). Acá el personal de finanzas, en una primera etapa poblará una nueva tabla llamada “balance comercial” con los datos del balance, el promedio de las compras totales y algunos datos de riesgo, con lo cual la clase boundary “Calcular_límite” estará en condiciones de proponer un límite de crédito. De ser aceptado este límite, la misma clase anterior actualizará el límite de crédito en SAP. En caso contrario se actualizará una nueva cifra ingresada por el mismo usuario. Luego de poblada esta tabla, será necesario modificar cada 6 meses estos valores. También con esta misma frecuencia de tiempo se actualizarán los parámetros de clasificación de crédito, en donde la clase

boundary “Calcular_Clasificación” obtendrá la deuda histórica de la tabla “Deuda_Histórica” y actualizará dichos valores de manera similar al caso anterior.

Figura N°19: Realización del Caso “Seleccionar Pedidos”

Figura N°20: Realización del Caso “Decidir Pedidos SAP”

Figura N°21: Realización del Caso “Otorgar Crédito a Estudio”

Figura N°22: Realización del Caso “Calcular Parámetros”

3.- Arquitectura del diseño

A partir de la identificación de clases del punto anterior, se definen subsistemas que agrupan las clases según criterios de similitud e interrelación o cohesión. En primer lugar, para el caso de procesamiento del pedido en el nuevo canal de ventas se agrupan los datos en clases relacionadas por medio de atributos llegando al paquete “Comprador registrado” (Figura N°23). Figura N°23: Clases Paquete “Comprador registrado”

Similarmente para los casos que se desarrollarán como apoyo al departamento de finanzas, se llegará al paquete “Usuario Finanzas” (Figura N°24). Figura N°24: Clases Paquete “Usuario_finanzas”

Se da a continuación un detalle del contenido de estos paquetes a partir de las clases del tipo boundary y de control. Es así como en la Figura N°25 se encuentra el detalle del paquete “Seleccionar Pedido”, y en las tres figuras siguientes las clases paquete “Decidir Pedidos SAP”, “Otorgar Crédito a Estudio” y “Calcular Parámetros”. Figura N°25: Clases Paquete “Seleccionar Pedido” Figura N°26: Clases Paquete “Decidir Pedidos SAP”

Figura N°28: Clases paquete “Calcular Parámetros” Figura N°27: Clases Paquete “Otorgar Crédito a Estudio”

4.- Diseño detallado de la aplicación

Con todo lo anterior se está en condiciones de avanzar hacia el diseño detallado de la aplicación. Esto implica la selección de una tecnología y modalidad de implementación específica, detallando el diseño expresado en las clases y sus interacciones. Para ello se explícita la tecnología de implementación, la cual ya está definida como la de Internet, con el modelo de n capas.

Dentro de Internet se elige a ASP (Active Server Pages) como lenguaje de programación, por ser la que mejor se adecua a la realidad de la empresa, dado que se trabaja total y exclusivamente en un ambiente Micrososf, con el sistema operativo Windows NT y con bases de datos relacionales SAP en SQL Server, para el almacenamiento de información. 4.1.- Integración Web SAP

Para el caso en estudio existen dos maneras distintas en que la aplicación web interactuará con SAP:

1. La primera corresponde al caso trivial donde se accede directamente a las tablas de SAP sólo con permiso de lectura y con el propósito de mostrar información. Ejemplos de estos casos se producen al buscar clientes, mostrar cuentas corrientes, mostrar productos disponibles, etc. Para utilizar esta información, la aplicación Web llamará al controlador de la base de datos (ODBC) mediante una cadena de conexión, el cual consta con todos los parámetros necesarios para establecer dicha conexión.

2. El caso complejo ocurre en el momento en que se desea actualizar la base de datos de SAP, (ejemplo de ello ocurre al grabar una nota de venta). Debido a la gran cantidad de tablas relacionadas en el modelo de datos (aproximadamente 14.000) y a la dependencia de muchas de ellas, sería muy difícil lograr consistencia actualizando los registros que correspondan.

Para este último caso SAP dispone de diferentes alternativas de solución basados en los llamados RFC (Remote Function Call). Entre las más importantes se pueden mencionar:

? ITS (Internet Transaction Server)8: Corresponde a la alternativa mayormente difundida y usada a la fecha y se trata básicamente de un software que permite la interacción entre un servidor web y un sistema SAP R/3, mediante transacciones preprogramadas y desarrolladas especialmente para mantener la consistencia [9]. ITS está basado a su vez en otras dos aplicaciones llamadas Internet Application Components (IAC) y Easy Web Transactions (EWT).

? DCOM Connector: Programa diseñado en conjunto por SAP y Microsoft, que genera el código binario de componentes COM (Modelo de objetos componentes), y que puede comunicarse directamente con las BAPIs (Business Application Programming Interface) de SAP, integrándolas a programas de Microsoft (Visual Basic, ASP, Office, etc), sin necesidad de conocer el lenguaje de programación de SAP (ABAP/4) o los detalles de la ejecución de las BAPIs.

? Java Connector: Programa integrador en que las llamadas a las BAPIs son realizadas desde código Java. Por esta razón posee las ventajas típicas de este lenguaje, como son la flexibilidad y su carácter multiplataforma.

? Net Connector: El mismo caso anterior, sólo que ahora SAP se integra al mundo .net.

Dado que Mathiesen trabaja plenamente con tecnología Microsoft se opta por utilizar el SAP Dcom Connector como medio para que las aplicaciones web –desarrolladas en ASP– se conecten remotamente al sistema SAP R/3. Se descarta el uso de los ITS por su complejidad e inflexibilidad, puesto que no poseen inteligencia propia, sino que funcionan a nivel de transacciones SAP. Por lo cual no permiten agregar lógica y de 8 En el Anexo N°4 se puede consultar mayor información a cerca de los ITS

querer modificar la aplicación web habría que programar nuevas transacciones en ABAP/4 (lenguaje nativo de SAP).

4.2.- Arquitectura tecnológica

1. Para el primer caso, en que se accede directamente a las tablas de SAP con permiso de lectura y con el propósito de mostrar información, se implementará la arquitectura de tres capas.

Como se puede observar en la Figura N°29, el servidor web con plataforma tecnológica Windows NT CLIENTE SERVIDOR WEB Windows NT. IIS. Aloja archivos ASP SERVIDOR APLICACIONES Procesa contenidos del ASP SERVIDOR DE B.D. SAP ADEXUS SQL SERVER Figura N°29: Arquitectura de acceso a tablas SAP alojará las páginas ASP. Mientras que la lógica del negocio se procesará en el servidor de aplicaciones, el cual a su vez llamará al controlador de Base de Datos ODBC (Open Database Connectivity) mediante una cadena de conexión, con los parámetros respectivos para realizar las consultas necesarias.

2. Por otra parte, la arquitectura tecnológica que soportará el segundo caso se ilustra en Figura N°30. En ella, el servidor web basado en Windows NT será quien aloje las páginas ASP con sus respectivos scripts. Será necesario instalar en este servidor el MTS (Microsoft Transaction Server) y el Dcom Connector.

El proceso comienza cuando el cliente invoca la aprobación de su pedido en una página ASP. Esta Figura N°30: Arquitectura de Integración usando Dcom Connector

página llamará al objeto Dcom connetor que generará los componentes COM capaces de comunicarse con métodos escritos en el lenguaje ABAP/4 (BAPIs) y residentes en el Repositorio de Objetos Business de SAP (ROP). Acá se obtendrá una respuesta a la petición, chequeando condiciones de crédito y stock, tal cual como si se hubiese utilizado SAP directamente, retornando la página ASP de respuesta al pedido del cliente.

Por su parte el MTS (Micrososft transacción Server) será el encargado de coordinar las transacciones, resolviendo problemas de concurrencia y gestionando recursos. Los componentes COM se convertirán en componentes MTS constituidos como una DLL y se agruparán en paquetes para su gestión conjunta.

4.3.- Programación de la lógica del negocio

Existirán también dos casos diferentes de programar la lógica del negocio en la nueva aplicación:

1. Cuando se requiera programar lógica anexa a SAP (Ej: Cálculo de parámetros de crédito), lo adecuado será programar procedimientos en VBScript o Javascript indicando a la página ASP que procese las secuencia de comandos en el servidor de aplicaciones. La principal ventaja de utilizar estos lenguajes será su simplicidad y su baja demanda de requisitos comparado con otros lenguajes, (como es el caso de Java propiamente tal). Y aunque Javascript no es orientado a objetos, puede utilizar los objetos en muchas ocasiones con funciones del tipo constructor, las cuales se encargarán de construir los objetos en memoria e inicializarlos, definiendo sus propiedades y métodos [8]. Por último, cabe mencionar que para hacer más clara y estructurada la programación, en la mayoría de los casos se crearán pequeños programas que serán invocados por distintas páginas ASP, de manera que el código pueda ser reutilizado.

2. Para el segundo caso sólo se incorporará la lógica con que actualmente trabaja SAP (Ej: otorgamiento de crédito, disponibilidad y rebaja de stock). Esta acción será transparente para el programador, pues – como se ha mencionado– la aplicación se integrará al sistema SAP por medio del Dcom Connector. 4.4.- Mapeo de clases

A partir de los diagramas de las Figuras N°19, N°20, N°21 y N°22 se mapearán las clases lógicas a componentes físicos Active Server Page (ASP) de la siguiente manera:

Caso “Seleccionar Pedido”: Página_ingreso_pedido Registrar ? ? Página HTML ASP Verificar ? ASP (VBScript – Dcom Connector) Dar precio ? ASP Carrito Página_respuesta_pedido

Caso “Decidir pedidos SAP”: Página_Venta ? ?

? ASP ASP

ASP (VBScript – Dcom Connector) Carrito ? ASP Página_respuesta_pedido ? ASP Caso “Otorgar Crédito a Estudio”: Página_ingreso_finanzas ? Página HTML Verificar ? ASP Actualizar_ Estado ? ASP (VBScript – Dcom Connector) ASP Página_respuesta_finanzas ?

Caso “Calcular Parámetros”: Página_cálculo Calcular_clasificación Calcular_límite Página_respuesta_finanzas ? ? ? ? Página HTML ASP (VBScript – Dcom Connector) ASP (VBScript – Dcom Connector) ASP

La justificación de las elecciones anteriores radica en que cada tecnología elegida se ajusta a los requerimientos de procesamiento de la clase respectiva. En particular, HTML es la tecnología apropiada para las páginas estáticas de ingreso que servirán a los usuarios para entregar información. Por su parte se emplea ASP –con secuencia de comandos en VBScript o Javascript– para generar las páginas de respuesta de contestación al cliente, ya que se trata de una lógica con variadas alternativas y páginas diferentes. Por su parte, VBScript (de Microsoft) es el lenguaje que permite realizar las llamadas necesarias al DCOM Connector desde las clases Verificar, Página_venta, Actualizar_Estado, Calcular_ límite y Calcular_clasificación.

4.5.- Tablas requeridas por la Aplicación En las Figuras N°19, N°20, N°21 y N°22 se aprecian los nombres de las tablas que ocupará la aplicación. Nuevamente se distinguen dos casos:

1. Los nombres de las tablas complementarias a SAP –o sea que deberán crearse en SQL Server– serán las siguientes:

? Usuario_Finanza. ? Deuda_Histórica. ? Balance_Comercial.

2. Por su parte, las tablas de SAP que serán llamadas a modo de consultas desde la nueva aplicación serán: ? ? ? ? ? KNKK (Datos maestros): Clientes, parámetros de crédito, forma de pago, moneda. KONP (Condición): Condición cliente, precio, material. VBKD (Crédito a estudio): Bloqueo crédito. VBAK (Nota_Venta): Documento de ventas, datos de cabecera. VBAP (Nota_Venta): Documento de ventas, datos de detalle. VI.- Conclusiones del diseño Primeramente, se considera importante mencionar que la metodología empleada facilitó en gran medida, la definición en forma precisa –y en un tiempo razonable– de los componentes a automatizar. Al utilizar los patrones para modelar la arquitectura e-Business se identificaron rápidamente los procesos que serían apoyados con tecnología Internet, se definió la lógica del negocio de manera clara y precisa y se derivaron casi directamente los casos de uso junto con la información necesaria para seleccionar la tecnología y modalidad de implementación específica.

Por otro lado, como consecuencia del actual trabajo, la empresa se ha dado cuenta de los beneficios que conllevaría comercializar sus productos por este nuevo canal, mostrando un claro interés en seguir adelante con el proyecto. Por este hecho, el autor ha considerado apropiado construir una Intranet con un módulo orientado a que las distintas personas que están involucradas en el proyecto –personal de informática, finanzas y comerciales– puedan ir probando un prototipo funcional del sitio.

De esta manera, el prototipo está orientado más que a una autoatención9 por parte del cliente, a una primera etapa de prueba, permitiendo inicialmente que los vendedores creen de forma remota una orden de venta en SAP. Además, siendo consistente con el diseño planteado, se ha creado una herramienta de apoyo al cálculo de los parámetros necesarios para el otorgamiento automático del crédito a los clientes, el cual está siendo usado de manera informal por el personal de finanzas.

VII.- Construcción del prototipo

Esta aplicación –como se mencionó anteriormente– inicialmente está destinada a que los mismos operadores comerciales realicen las órdenes de venta en las dependencias físicas de los clientes, (en el 9 En el Anexo N°3 se encuentran las pantallas de Internet, que simulan una autoatención por parte del cliente.

Anexo N°3 pueden ser consultadas las pantallas del diseño del sitio orientadas a una autoatención por parte de los clientes).

A continuación se recorrerán las principales pantallas del prototipo, mostrando los pasos que seguirá cada operador comercial para realizar remotamente la orden de venta.

Figura N°31: Página Inicial del Módulo Comercial En la primera pantalla del módulo comercial (Figura N°31), inicialmente se dan las opciones de crear una nota de venta, buscar las órdenes que se le han procesado a un determinado cliente o buscar clientes según algún criterio.

De querer crear una nota de venta se pedirá autentificación, el tipo de orden –normal o importación a terceros– y el número del cliente al que se le desea cursar la orden (Figura N°32).

Figura N°32: Página de Autentificación Comercial

Suponiendo que el vendedor en vez de ingresar directamente el número del cliente, desea buscarlo (Figura N°33), entonces digitará parte del nombre recibiendo como respuesta el o los clientes que coincidan con tal petición (Figura N°34). Para el caso del ejemplo, se procesará una venta al cliente “Agric y Ganadera Mc Osker y Cia. Ltd.”, cuyo número es el 10048. Éste tiene asociado dos canales de distribución “Químico y Plástico”, por lo cual el vendedor que esté cursando la orden elegirá el canal que le corresponda para quedar como responsable de la venta.

Luego deberá ingresar los productos que requiera comprar. En la Figura N°35 busca el producto que tenga la sigla AB, lo encuentra (Figura N°36) y lo agrega al portafolio de productos (Figura N°37). Notar que inmediatamente aparecerá la unidad de medida del tal producto –que en este caso es kilos- y la moneda que utiliza el cliente para comprar (CLP, que en SAP equivale a pesos).

A continuación insertará el producto en el carro de compras (Figura N° 38), no sin antes indicar cantidad, precio y clase de valoración (importado normal, importado a terceros o nacional). Es importante que se ingrese la clase de valoración por un tema contable, pues dependiendo de la opción elegida, el producto tendrá un distinto margen sobre el precio de compra. En este momento el vendedor tiene la opción de borrar, agregar productos o confirmar la compra para que el DCOM Connector procese la aprobación del pedido llamando a las BAPIs de SAP10. Notar que la condición de pago negociada es de crédito a 18 días. En el caso que desee cambiar la condición por un crédito de mayor plazo, deberá tener presente que la venta quedará en espera de liberación por parte del personal de finanzas. 10 En el Anexo N°5 se encuentra parte del programa que permite la conexión con SAP (en VBScript).

Figura N°33: Página de Búsqueda de Clientes Después de ingresado un segundo producto (Figura N°39) y de confirmada la compra aparecerá la pantalla con el resumen y el número de la orden de venta (Figura N°40). Finalmente se puede comprobar con el número de la orden, que efectivamente la nueva venta ha sido grabada en SAP (Figura N°41).

Figura N°34: Resultado de la Búsqueda de Clientes Figura N°35: Ingreso del Canal de Distribución Figura N°36: Resultado de la Búsqueda de Productos

Figura N°37: Portafolio de Productos Figura N° 38: Carro de Compras (1 producto)

Figura N° 39: Carro de Compras (2 productos) Figura N° 40: Resumen de Venta

Figura N° 41: Orden Grabada en SAP Como se mencionó en el diseño, para disminuir el porcentaje de órdenes de venta que caen a finanzas, será necesario actualizar los parámetros actuales de crédito. Con este fin, se encuentra disponible una herramienta de apoyo al cálculo del límite de crédito efectuado por el personal de finanzas. Para ingresar se validará el username y password (Figura N°42), contra la tabla creada en SQL Server llamada “usuario_finanza” Figura N°42: Página de Autentificación Finanzas

De ser un usuario válido, se mostrará el módulo correspondiente al cálculo del límite de crédito (Figura N°43), y se proporcionarán las opciones de ingresar modificar o buscar –en la tabla llamada “Balance_Comercial”– la información necesaria para el cálculo de tal parámetro. En la pantalla ilustrada en Figura N°44 se ingresarán los valores del balance comercial del cliente, los que a su vez invocarán la lógica11 del cálculo para proponer un límite de crédito. De ser aceptado tal parámetro, el Dcom Connector tomará el control para grabarlo en SAP por intermedio de la BAPI correspondiente. En caso contrario el usuario podrá ingresar otro valor bajo algún criterio particular. Figura N°43: Página Principal Finanzas 11 En el Anexo N°2.2 se encuentra esta lógica en un pseudo lenguaje estructurado y en el Anexo N°5 está parte del script de programación.

Figura N°44: Página de Ingreso de Datos del Balance Figura N°45: Actualización del Límite de Crédito Por otro lado, se muestra en la Figura N°46 la posibilidad que tiene un determinado cliente de acceder al estado de su cuenta corriente, para lo cual primero tendrá que autentificarse. Finalmente, en la Figura N°47 se ilustra el resultado de la consulta anterior, desplegando todas las partidas abiertas que posee el cliente, específicamente la fecha de emisión y de vencimiento de cada documento, el importe y el impuesto, entre otros.

Figura N°46: Acceso a la Cuenta Corriente Figura N°47: Despliegue de las Partidas Abiertas

VIII.- Referencias 1. Barros, O.

2. Barros, O. Rediseño de Procesos de Negocios Mediante el Uso de Patrones, Dolmen, 2000.

Patrón del Proceso de Venta y Distribución de Stock, Depto. Ingeniería Industrial, U. de Chile, Serie Gestión Nº17, Octubre 2000. 3. Barros, O. Diseño de la Arquitectura de un e-Business, Depto. Ingeniería Industrial, U. de Chile, Serie Gestión Nº 27, Septiembre 2001. 4. Barros, O. Diseño de los Componentes de un e-Business, Depto. Ingeniería Industrial, U. de Chile, Serie Gestión Nº 28, Septiembre 2001. 5. Barros, O. Componentes de Lógica del Negocio Desarrollados a partir de Patrones de Procesos, U. de Chile, Serie Gestión Nº 34, Marzo 2002.

6. Cámara de Comercio de Santiago: La Economía digital en Chile, Departamento de Estudios. Año 2001. Capítulo XV.

7. http://www.nwfusion.com/ecomm2000/ecomm-endtoend.html

8. http://www.desarrolloweb.com/articulos/789.php

9. http://www.sapmania.com/comunicaciones/its.htm

10.http://www.ciudadfutura.com/sap/sap/info/its.htm

11.http://www.programming-vb.com/mts/docs/intro.htm

IX.- Anexos Anexo N°1: Políticas actuales de crédito 1.1.- Características de las diferentes clasificaciones de crédito

Cabe mencionar que las clasificaciones de crédito se asignaron de forma manual por un cómite de crédito y no han sido actualizadas a la fecha. Los criterios de clasificación actual son los siguientes:

Tipo Significado A+Premium A Buena B Normal B- Problema C Riesgoso D Estudio N Nuevo U Pesado J Judicial ? A+ PRIME MOROSIDAD: No presenta ni ha presentado morosidad. PROTESTOS: No presenta ni ha presentado protestos PROPIEDAD: La propiedad está en manos de grupos económicos de reconocido prestigio nacional e internacional. ? A BUENO MOROSIDAD: No presenta ni ha presentado morosidad. PROTESTOS: No presenta ni ha presentado protestos PROPIEDAD: La propiedad está en manos de grupos económicos de reconocido prestigio y solvencia nacional. ? B NORMAL MOROSIDAD: Variable entre 0-30 días. PROTESTOS: No presenta ni ha presentado protestos PROPIEDAD: La propiedad está en manos de socios de reconocido prestigio y solvencia en su respectivo mercado. ? B- PROBLEMA ? MOROSIDAD: Sobrepasa los 30 días, recae en prorrogas reiteradas ? PROTESTOS: No presenta pero ha presentado protestos, los cuales están aclarados ? PROPIEDAD: La propiedad está en manos de personas con patrimonio deteriorado y/o en riesgo. ? C RIESGOSO MOROSIDAD: Sobrepasa los 30 días, recae en prorrogas reiteradas PROTESTOS: Con protestos videntes y no aclarados. PROPIEDAD: La propiedad está en manos de personas que carecen de patrimonio. ? D ESTUDIO CARACTERÍSTICA GENERAL. No tiene historia como cliente. Se tienen sólo algunos antecedentes. A este tipo de cliente se le hará un seguimiento sistemático. ? N NUEVO CARACTERÍSTICA GENERAL. Es la categoría asociada a los clientes que ingresan a la base de datos. Se crea modalidad de pago al contado. Si requiere crédito se revisa DICOM. Crédito autorizado sin antecedentes financieros USD 800. ? U PESADO CARACTERÍSTICA GENERAL: Corresponde a aquellos clientes con cesación de pagos y que si presentaron un plan de pago. Sólo se podrán efectuar ventas al contado o ventas que en su valor estén generando excedentes que abonen la deuda vencida. Las ventas sólo podrán ser autorizadas por la Gerencia de Finanzas y Operaciones. ? J JUDICIAL CARACTERÍSTICA GENERAL: Clientes que han debido ser enviados a los abogados de Mathiesen para la regularización de su deuda. Ventas sólo podrán ser autorizadas por la Gerencia de Finanzas y Operaciones.

1.2.- Ejemplos para determinar línea de crédito 1.- Plásticos Temuplas ? Datos: Compras anuales: US$ 5.700.000 Utilidad anual: US$185.000 Patrimonio: US$ 3.600.000 Pasivo Exigible: US$ 4.000.000 Clasificación del cliente: peor que normal Clasificación de la Industria: Riesgosa ? Aspectos Cuantitativos: 1.- 20% de las compras. Son US$ 5.700.000/12 * 3 * 0,2 = US$285.000 2.- Utilidad anual US$185.000 3.- % del patrimonio. Un 15% son US$540.000 Promedio = US$ 336.000 ? Aspectos Cualitativos: Ambas calificaciones son peores que normal, por lo cual se aplica el castigo de 25%. La línea sugerida es US$ 252.000 ? Restricciones: El Patrimonio de Mathiesen es US$7.000.000, su 10% son US$ 700.000 por lo que no aplica. 2.- Cerámicas Cordillera ? Datos: Compras anuales US$ 30.000.000 Utilidad anual US$4.500.000 Patrimonio US$ 43.000.00 Pasivo Exigible US$ 21.400.000 Clasificación del cliente: Buena Clasificación de la Industria: Buena ? Aspectos Cuantitativos: 1.- 20% de las compras. Son US$ 30.200.00/12 * 3 * 0,2 = US$1.509.999 2.- Utilidad anual US$ 4.500.000 3.- % del patrimonio. Un 20% son US$8.600.000 Promedio = US$ 4.800.000 ? Aspectos Cualitativos: Ambas calificaciones son mejores que normal, por lo cual no se aplica el castigo de 25%. ? Restricciones: El Patrimonio de Mathiesen son US$7.000.000, su 10% son US$ 700.000 por lo la línea sometida a directorio es de US$ 700.000 1.3.-Condiciones de bloqueo de crédito Existen opciones de bloquear automáticamente la venta si se cumplen ciertas condiciones de crédito: ? Línea de crédito: Se bloquea al cliente una vez que excede su limite de crédito asignado. ? Partida Abierta Antigua: Se utiliza para no bloquear al cliente apenas tenga deuda vencida. Se permite la opción en que se indica el número de días necesarios para el bloqueo después de vencida esta deuda. ? Partida Abierta: Se utiliza para no bloquear al cliente por montos vencidos insignificantes. Se puede especificar un porcentaje por sobre el cual se bloquee al cliente si pasan mas de “n” días de su vencimiento. ? Campo Crítico: Al activarse este campo, se obliga a vender a esta clase de cliente según la condición de pago especificada en su maestro. ? Valor documentado: Indica el monto máximo de venta para cada clase de riesgo

? Fecha verificación: El sistema otorga la posibilidad de no bloquear al cliente, una vez cumplida la fecha de revisión de la línea de crédito durante n días. ? Nivel de reclamación: Se puede bloquear al cliente cuando se encuentre en algún nivel de reclamaciones avanzado. El nivel de reclamación corresponde al número de cartas por deudas que se le ha enviado al cliente. En el primer aviso se le recuerda al cliente que posee una deuda con la empresa y se le solicita que le pague a alguno de sus cobradores. En el segundo aviso se le pide que cancele a la brevedad la deuda sostenida, a fin de no tener dificultades en la entrega de futuras materias primas. En el tercer y último aviso se le informa al cliente que los documentos que certifican la morosidad, fueron enviados al Boletín Comercial para su publicación como deuda morosa y que de mantenerse la situación por un plazo mayor a 7 días, se traspasará dicha cobranza a los abogados de Mathiesen. Para cada uno de estos bloqueos existe la posibilidad de enviar un mensaje de advertencia al usuario o incluso de impedir que grabe dichos pedidos de venta. En la práctica, las principales causas de bloqueos son: campo critico (40%) – de estos pedidos un 50% se libera y el otro 50% se mantiene bloqueado – y sobregiro de línea (40%), repartiendo el 20% restante entre las otros tipos bloqueos. Anexo N°2: Lógica del cálculo de los parámetros crediticios en pseudo-lenguaje 2.1.- Lógica para la Determinación de la Clasificación de Crédito Si (DDME = 0 y Pto = 1 y Prop = 1) CL.Clasificacion = A+ Sino Si (DDME = 0 y Pto = 1 y Prop = 2) CL.Clasificacion = A Sino Si (0 < DDME < 30 y Pto = 1 y Prop = 3) CL.Clasificacion = B Sino Si (DDME >30 y Pto = 2 y Prop = 4) CL.Clasificacion = B- Sino Si (DDME >30 y Pto = 3 y Prop = 4) CL.Clasificacion = C Sino Si (DDME >30 y DMSP=1) CL.Clasificacion = U Sino Si (CL.Clasificacion = U y Fecha.3erAviso – Fecha.Actual > 7) CL.Clasificacion = J Sino Si (Pto = 0 y Prop = 0) CL.Clasificacion = N Sino // no se cumplio ninguna condición CL.Clasificacion = D

2.2.- Lógica para la Determinación del Límite para el Monto del Crédito

Leer Cliente = CL Leer (CL.promedio compra de ult. 3 meses) * 3 *0,2 = COM Leer CL.Utilidad= UTI // Resultado ejercicio Leer CL.Patrimonio= PAT Calcular Leverage= (CL.Pasivo Exigible / PAT) = LEV Calcular (Mathiesen.Patrimonio)*0.1= MAX

Si (LEV >3) MC= 0 // No dar crédito Sino Si (2< LEV< 3 ) LEVPAT=PAT*0,1 Sino Si (1< LEV< 2) LEVPAT=PAT*0,15 Sino Si (0< LEV< 1) LEVPAT=PAT*0,2

PROM= (LEVPAT+UTI+COM) / 3

Si (CL.Riesgo + SECTOR.Riesgo) / 2 < 3 // Peor que Normal LC= PROM *0,75 // Castigo Límite crédito con 25% Sino LC= PROM

Si (LC > MAX) MC=MAX // Monto máx crédito = 10% utilidad de Mathiesen (US$ 700.000) Sino MC=LC

2.3.- Lógica de otorgamiento de crédito MP MC CC PA PAA NR : Monto en $US del pedido solicitado (incluido impuestos) : Monto máximo de crédito : Monto de deuda en cuanta corriente del cliente con la empresa : Promedio de días vencimiento de todas las deudas : Días de vencimiento de la deuda más antigua :Número de reclamos que Mathiesen le ha realizado al cliente por no pago de alguna deuda Si NV.Pago = Contado NV.Estado = OK Sino Si (CL.clasificación = A+) Si (MP< 75000) y (CC + MP ? 1.25MC) y (PA< 30) y (PAA< 45) y (NR< 3) NV.Estado = OK Sino NV.Estado = Rechazada Sino Si (CL.clasificación = A) Si (MP< 50000) y (CC + MP ? 1.15MC) y (PA< 30) y (PAA< 45) y (NR< 3) NV.Estado = OK Sino NV.Estado= Rechazada Sino Si (CL.clasificación = B) Si (MP< 25000) y (CC + MP ? 1.1MC) y (PA< 7) y (PAA< 30) y (NR< 3) NV.Estado = OK

Sino NV.Estado= Rechazada Sino Si (CL.clasificación = B-) Si (MP< 10000) y (CC + MP ? 1.1MC) y (PA< 5) y (PAA< 15) y (NR< 3) NV.Estado = OK Sino NV.Estado= Rechazada Sino Si (CL.clasificación = D o N) Si (MP< 800) y (CC + MP ? 1.2MC) y (PA< 7) y (PAA< 15) y (NR< 3) NV.Estado = OK Sino NV.Crédito= Rechazada Sino Si (CL.clasificación = E) Si (MP< 75000) y (CC + MP ? 1.15MC) y (PA< 7) y (PAA< 15) y (NR< 2) NV.Estado = OK Sino NV.Crédito= Rechazada Sino // CL.clasificación = C o U o J NV.Crédito = Rechazada

Anexo N°3: Pantallas del canal de ventas de Internet Figura 1A: Página Ingreso Tienda Virtual La Figura 1A muestra la página de entrada al nuevo canal de ventas. En ella se encuentra el menú de opciones para el navegante (frame horizontal superior), que permanece fijo para las páginas interiores. En el cuerpo central está la información básica para contactarse con Mathiesen y, lo más importante, el formulario para ingreso de clientes (username y password). En caso de no ser un cliente, a un costado se encuentra la opción de registrarse. En la Figura 2A se simula la intención de un cliente registrado de ingresar a cotizar los productos de la empresa. Más adelante se señala la secuencia para un cliente no registrado (al que se nombrará simplemente como navegante).

Figura 2A: Portafolio de Productos de Mathiesen Al ingresar a la página de la Figura 2A, el cliente podrá optar entre dos maneras de buscar un determinado producto; por familia o bien mediante la letra inicial del producto. Al suponer que se elige la familia de plásticos y elastómeros, se derivará la Figura3A. Figura 3A: Familias de Productos de Mathiesen

Figura 4A: Elección del Producto Cuando el cliente selecciona un producto, aparecerá la pantalla que permite realizar la transacción (Figura 4A). Cabe destacar que el precio aparece inmediatamente, debido a que el cliente se registró con anterioridad. En la pantalla de la Figura 5A se muestra el caso contrario, o sea de un navegante que no se ha registrado; en tal caso cuando seleccione un producto en particular, el sitio le exigirá su identificación como cliente antes de enseñarle los precios. Figura 5A: Identificación Navegante para Indicar Precios

Si el sitio reconoce al navegante como cliente, accederá a la página de transacción (Figura 6A). Al ingresar la cantidad se agregará el producto al carro de compras (Figura7A). Figura 6A: Acceso de Navegante al Carro de Compras Figura 7A: Carro de Compra

Finalmente al confirmar la compra, el sistema integrará la lógica que utiliza SAP para verificar stock y crédito automáticamente, a fin de dar una respuesta en línea al cliente sobre la aceptación, estudio o rechazo de su pedido. En la pantalla de la Figura 8A se observa un caso en que el crédito será enviado a estudio, debido a que el cliente solicita cambiar su condición de pago desde un crédito a 60 días por un

crédito a 90 días. En la mayoría de los casos la decisión de aceptación o rechazo de la venta será un proceso automático, pero se quiso ejemplificar este caso para apreciar el ciclo completo que podría tener un pedido en Internet. Posteriormente el pedido que ha quedado a estudio será rescatado en la Intranet Corporativa por personal de finanzas, quien tendrá la responsabilidad de bloquearlo o liberarlo. Dicho cambio se actualizará automáticamente en SAP (Figura 9A).

Figura 8A: Confirmación de la Compra Figura 9A: Intranet Finanzas

Volviendo atrás en el sitio Internet, para el caso en que el navegante no es un cliente, deberá registrarse en el formulario de la página principal indicado para ello (Figura 10A).

Figura 10A: Formulario Ingreso Clientes Nuevos Una vez que el nuevo cliente llena y envía sus datos, se despliega la Figura 11A.

A partir del rubro que ingresa el nuevo cliente en el formulario se derivará la solicitud al operador comercial respectivo, el cual tendrá la misión de crear en el sistema los clientes nuevos. Rescatará estos requerimientos a través de un módulo especial para ello incluido en la página principal donde dice "Administrador". (Figura 1A) Cuando el operador comercial ingresa a esta opción se le exige su identificación (Figura 12A).

Figura 11A: Confirmación Envío de Datos Figura 12A: Ingreso Operador Comercial

Después de identificarse, el operador comercial podrá observar la información de los clientes nuevos y decidir su incorporación al sistema (Figura 13A).

Figura 13A: Identificación Nuevo Cliente De esta manera se han mostrado algunas de las secuencias principales del nuevo canal, para comprender la manera en que un cliente operará en el futuro sitio web de Mathiesen.

Anexo N°4: Función del Internet Information Server

Cuando un usuario de Internet hace una petición al servicio ITS pulsando un hipervínculo URL o tecleando una dirección URL en el navegador Web para ejecutar un IAC o un EWT, la petición es procesada como sigue [10]: 1. El navegador de Internet pasa a través de un servidor Web. 2. El Web Server llama a la extensión de servidor WGate del ITS. WGate es una extensión del servidor Web que encapsula varias interfaces del servidor HTTP, tales como: CGI (Common Gateway Interface), NSAPI (Netscape Server Application Programming Interface) e ISAPI (Internet Server Application Programming Interface). 3. WGate dirige la petición al proceso del servidor ITS denominado AGate (el cual puede o no residir en la misma máquina.). AGate es el vínculo entre ITS y el servidor de aplicaciones SAP R/3. O sea es el que recibe peticiones del navegador Web desde el WGate y se comunica con el servidor de aplicaciones SAP R/3 a través de DIAG o protocolos RFC. 4. AGate entonces procesa las peticiones y envía todos los detalles relevantes (incluyendo información de conexión) al sistema SAP R/3, el cual o inicia la primera pantalla de conexión o envía los datos de la siguiente transacción ya iniciada. 5. SAP R/3 inicia la transacción para el servicio solicitado y envía la salida de pantalla al AGate. 6. Cuando el diálogo ha finalizado, AGate recupera el resultado desde SAP R/3, siendo el responsable del tratamiento de la sesión, incluyendo el mapeo de la pantalla SAP R/3 o los módulos de la función a HTML. 7. AGate envía la página HTML formateada a WGate. 8. WGate envía la página HTML formateada al servidor Web. 9. Por último, el servidor Web envía la página HTML formateada al navegador Web, donde podrá ser visualizada por el usuario final. Anexo N°5: Principales scripts del prototipo

5.1.- Extracto de la lógica para crear la orden en SAP (VBScript)

< % Set oSAPDemoObj = Server.CreateObject("RFCSampObj.RFCSampObj.1") ‘ Le asigna al objeto oSAPDemoObj el valor del componente “RFCSampObj.RFCSampObj.1”

Call oSAPDemoObj.DimHeader(HeaderIn) ‘ Llama al método DimHeader y le asigna los datos de cabecera HeaderIn.AddNew HeaderIn.Fields("DOC_TYPE") = session("tipo") HeaderIn.Fields("SALES_ORG") = "MATH" HeaderIn.Fields("DISTR_CHAN") = session("canal") HeaderIn.Fields("DIVISION") = "00" HeaderIn.Fields("PMNTTRMS") = session("pagoy") HeaderIn.Update

Call oSAPDemoObj.DimPartners(Partners) ‘ Llama al método Partners y le asigna los datos del cliente Partners.AddNew Partners.Fields("PARTN_ROLE") = "AG" Partners.Fields("PARTN_NUMB") = session("clienteh") Partners.Update

if session("num_articulos") = "1" then Call oSAPDemoObj.DimItems(ItemsIn) ‘ Llama al método DimItems y le asigna los datos de detalle del ítem ItemsIn.AddNew ItemsIn.Fields("MATERIAL") = session("producto1") ItemsIn.Fields("PLANT") = "C100" ItemsIn.Fields("REQ_QTY") = session("Quantity1") * 1000 ItemsIn.Fields("COND_TYPE") = "PREC" ItemsIn.Fields("COND_VALUE") = session("precio1") ItemsIn.Update end if

REM set logon option: oSAPDemoObj.Destination= "PRUEBA2" ‘ Se conecta al Dcom Connector doneit = CreateOrder if DoneIt = true then BapiReturn.MoveFirst if BapiReturn.Fields("TYPE") = "E" then ‘ Existe error Response.Write( BapiReturn.Fields("TYPE")) ‘ Tipo de error Response.Write( BapiReturn.Fields("CODE")) ‘ Código del error Response.Write( BapiReturn.Fields("MESSAGE")) ‘Mensaje del error else Response.Write(OrderNumber) ‘ Graba pedido en SAP y devuelve el número de la orden end if ' finaliza la llamada a la BAPI end if ' finaliza la creación de la nota de venta Function CreateOrder() on Error Resume Next Call oSAPDemoObj.OrderCreate(HeaderIn, _ ItemsIn, _ Partners, _ OrderNumber, _ ,,,_ ItemsOut, _ BapiReturn) ‘ Llama a la BAPI OrderCreate y le ingresa los valores de sesión CreateOrder = True End Function %>

5.2.- Extracto de la lógica para calcular el límite de crédito (VBScript) < % Session ("clienteh")= request.Form("cliente") comprah = request("compra")* 0.6 utilidadh = request("utilidad") patrimonioh = request("patrimonio") pasivoh = request("pasivo") riesgoh = request("riesgo") riesgo2h = request("riesgo2") dolarh = request("dolar") if patrimonioh < > 0 then Leverage = pasivoh/patrimonioh end if if Leverage > 0 and Leverage < = 1 then Levpat = patrimonioh * 0.2 ‘ 20% del patriminio ElseIf Leverage > 1 and Leverage < = 2 then Levpat = patrimonioh * 0.15 ‘ 15 % del patrimonio ElseIf Leverage > 2 and Leverage < = 3 then Levpat = patrimonioh * 0.1 ‘ 10% del patrimonio Else mc=0 ‘ Si el leverage es mayor a 3 no se da crédito end if prom =(Levpat + utilidadh + comprah)/3 res= (riesgoh + riesgoh2)/2 ‘ Promedia el riesgo del cliente con el riesgo del sector if res < 3 then lc = prom * 0.75 ‘ Castiga con un 25% el promedio Else lc = prom end if if dolarh < > 0 then mc = lc/dolarh end if if mc > 700000 then '10% Patrimonio de Mathiesen en USD mc = 700000 end if %>