UNIVERSIDAD DE GUAYAQUIL FACULTAD DE INGENIERÍA …repositorio.ug.edu.ec/bitstream/redug/19774/1/TESIS TOMALÁ GARCÍA... · herramientas tecnológicas implementadas en otro tipo

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE INGENIERÍA INDUSTRIAL

DEPARTAMENTO ACADÉMICO DE TITULACIÓN

TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

LICENCIADO EN SISTEMAS DE INFORMACION

ÁREA DISEÑO DE SISTEMA

TEMA MODELAMIENTO DEL FLUJO DE VENTAS EN EL

ERP DYNAMICS AX PARA LA EMPRESA MAINT S.A.

AUTOR TOMALÁ GARCÍA EDGAR JESÚS

DIRECTORA DEL TRABAJO L.S.I. AGUILERA MONTEROS SILVIA, MBA

2016 GUAYAQUIL – ECUADOR

ii

DECLARACIÓN DE AUTORIA

“La responsabilidad del contenido de Trabajo de Titulación le corresponde

exclusivamente y el patrimonio intelectual del mismo a la Facultad de

Ingeniería Industrial de la Universidad de Guayaquil”

Tomalá García Edgar Jesús

C.C.: 0926375742

iii

DEDICATORIA

Dedico este trabajo de investigación a toda mi familia; que siempre

ha deseado mi superación personal y profesional.

Quiero también dedicar la culminación de éste proyecto a todos

mis compañeros de trabajo que aportaron su tiempo en la realización del

mismo, la cual fue de gran importancia en el desarrollo de los contenidos

de cada capítulo escrito en el presente trabajo.

iv

AGRADECIMIENTO

Agradezco infinitamente a Dios por brindarme sabiduría,

constancia, y sobre todo mucha voluntad para desarrollar sin pausa el

presente proyecto, sobre el cual se interpusieron muchas dificultades que

fueron superadas y marca un paso importante en la realización de mis

metas.

Deseo agradecer también a todas las personas que aportaron con

su granito de arena e hicieron posible este sueño de avanzar un peldaño

más en mi carrera profesional.

v

ÍNDICE GENERAL

No. Descripción Pág.

PRÓLOGO 1

CAPÍTULO I

INTRODUCCIÓN PLAN DE INVESTIGACIÓN


1. Tema 2

1.1. Introducción 2

1.2. Objeto de la Investigación 5

1.3. Justificación de la Investigación 7

1.4. Objetivos 10

1.4.1. Objetivos Generales 10

1.4.2. Objetivos Específicos 10

CAPÍTULO II

MARCO TEÓRICO


2. Marco Teórico 12

CAPÍTULO III

METODOLOGÍA


3.1 Metodología descriptiva 18

vi


3.2. Examinar características del problema escogido 19

3.3. Cuestionario y guía de pautas 23

3.4. Informar Resultados 24

3.5. Metodología ICONIX 33

3.5.1. Fases de la Metodología ICONIX 34

3.5.2. Análisis de requisitos 34

3.5.3. Listado de Actores y Funciones 35

3.5.4. Especificaciones funcionales 35

3.5.5. Especificaciones no funcionales 36

3.5.6. Diagrama de casos de uso 37

3.6.

3.6.1

3.7

Prototipo

Interfaz de configuración de grupo de descuentos

Diagrama de actividades

44

44

46

CAPÍTULO IV

PROPUESTA


4.1. Tema de la propuesta 50

4.2. Objetivos 50

4.3. Entorno del Software 50

4.3.1. Arquitectura 50

4.3.2. Capas de desarrollo 51

4.4. Diagrama de clases 52

4.5. Modelo entidad relación 54

4.6. Diccionario de la base de datos 56

4.7.

4.7.1

Lenguaje de programación

Diagramas de secuencia

57

57

4.8. Infraestructura del flujo de trabajo 60

4.8.1. Windows Workflow Foundation 61

4.8.3. Diagrama de actividad validación de crédito 63

vii

N°

4.8.2.

Descripción

Diagrama de flujo de aprobación de descuentos

Pág.

62

4.8.4. Dimensionamiento de Hardware 64

4.8.4.1. Requerimiento de red 64

4.8.4.2. Requerimiento de dominio 65

4.8.4.3. Dimensionamiento servidor base de datos 66

4.8.4.4. Dimensionamiento servidor Dynamics AX 68

4.8.4.5. Dimensionamiento AOS-Producción 70

4.8.4.6. Dimensionamiento Motores SSRS, SSAS 72

4.8.4.7. Características de Hardware estaciones clientes 73

4.8.4.8. Resumen de Licencias 75

4.8.5. Estructura del equipo de proyecto 75

4.9. Estudio de factibilidad 76

4.9.1. Factibilidad técnica 77

4.9.2. Factibilidad económica 78

4.9.3. Factibilidad operativa 79

4.9.4. Impacto 80

4.9.5. Conclusiones 81

4.9.6. Recomendaciones 82

GLOSARIO DE TERMINOS

ANEXOS

84

86

BIBLIOGRAFIA 91

viii

ÍNDICE DE GRÁFICOS

N° Descripción Pág.

1 Arquitectura de tres niveles Dynamics AX 21

2 Gráfico de Arquitectura Extendida 22

3 Formato de Encuesta 28

4 Antigüedad de la empresa 30

5 Resultado formas de pago 30

6 Aprobadores Rango 90.000 – 200.000 31

7 Aprobadores Rango 200.000 – 500.000 32

8 Aprobadores Rango 500.000 o superior 32

9 Reenvio de pedido al flujo 33

10 Envío de Notificaciones 34

11 Notificaciones 35

12 Descuento entre 10 – 20 % 36

13 Descuento entre 20% o superior 36

14 Beneficios por puntualidad 37

15 Líneas de Negocio 38

16 Interfaz de acuerdos comerciales 44

17 Interfaz de configuración del flujo de ventas 45

18 Interfaz de notificaciones del flujo de ventas 45

19 Arquitectura Dynamics Ax 51

20 Presentación del nivel de jerarquía de las capas 52

21 Estructura de tipos de flujo de trabajo 60

22 Relación entre la infraestructura de flujo de trabajo

Dynamics ax y windows workflow foundation 61

23 Arquitectura de dimensionamiento 74

24 Estructura del equipo de trabajo 76

25 El objetivo 79

ix

ÍNDICE DE CUADROS


1 Versiones Dynamics AX 15

2 Número de usuarios de la compaía 21

3 Actores del proceso 35

4 Especificaiones funcionales A 36

5 Especificaiones funcionales B 37

6 Registro de clientes 38

7 Configuraciones generales para la venta 40

8 Acuerdos comerciales 42

9 Capas de desarrollo 52

10 Cuadro diccionario de base de datos 56

11 Tiempo de respuesta de red 66

12 Servidor de base de datos de AX 67

13 Servidor Dynamics AX 2012- AOS (A) 68

14 Servidor Dynamics AX 2012-AOS (B) 70

15 SSR, SSAS 72

16 Estaciones clientes 73

17 Servidor base de datos (física) 75

18 Servidores AX pruebas, producción motores

Virtuales. 75

19 Factibilidad técnica 77

20 Factibilidad económica 78

21 Indicador de impacto sobre implementación del

flujo de ventas. 80

x

ÍNDICE DE DIAGRAMAS


1 Diagrama Ishikawa 20

2 Diagrama de caso de uso general 37

3 Diagrama de caso de uso registro de clientes 38

4 Diagrama de caso de uso configuraciones

Generales de ventas. 40

5 Diagrama de caso de uso de acuerdos comerciales 42

6 Diagrama de actividad registro de clientes 47

7 Diagrama de actividad configuraciones generales

De ventas. 48

8 Diagrama de actividad acuerdo comercial 49

9 Diagrama de clases 53

10 Diagrama modelo entidad relación 54

11 Diagrama de secuencia acuerdo comercial 58

12 Diagrama de secuencia transacciones de cliente 59

13 Diagrama de flujo de aprobación de descuentos 62

14 Diagrama de actividad validación de crédito 63

xi

ÍNDICE DE ANEXOS


1 Cronograma 87

2 Diagrama de GANTT 89

xii

AUTOR: TOMALÁ GARCÍA EDGAR JESÚS TEMA: MODELAMIENTO DEL FLUJO DE VENTAS EN EL ERP

DYNAMICS AX PARA LA EMPRESA MAINT S.A. DIRECTORA: L.S.I. AGUILERA MONTEROS SILVIA, MBA.

RESUMEN

El presente proyecto plantea la implementación de una nueva funcionalidad en el ERP Dynamics AX para la empresa MAINT S.A. de la ciudad de Guayaquil, con el objetivo de mejorar el proceso actual de ventas agregando una funcionalidad que permita activar el control de otorgar créditos a los clientes cuyo fin es aumentar la participación del departamento comercial en el mercado captando nuevos prospectos que permitan incrementar las utilidades de la compañía. Por medio de las encuestas realizadas, entrevistas con los usuarios claves se identificaron problemas que fueron documentados como registro clave a tener en cuenta en la mejora a implementar. En este estudio se aplicaron diferentes metodologías de análisis y de desarrollo que nos permitieron conocer todos los requerimientos indispensables para controlar, supervisar y aprobar todo un flujo de tareas. Los resultados de este trabajo se pueden apreciar en el sistema propuesto que organiza y controla todas las solicitudes del flujo mediante criterios parametrizados en el módulo y consultas de historiales que guardan un registro de la trazabilidad del proceso. PALABRAS CLAVES: Implementación, ERP, Prospectos,

Requerimiento, Dynamics AX, Trazabilidad, Desarrollo, Diseño, Sistemas.

Tomalá García Edgar Jesús L.S.I. Aguilera Monteros Silvia, MBA C.C. 0926375742 Directora del trabajo

xiii

AUTHOR: TOMALÁ GARCÍA EDGAR JESÚS SUBJECT: MODELING FLOW IN SALES DYNAMICS AX ERP

MAINT FOR THE COMPANY S.A DIRECTOR: L.S.I. AGUILERA MONTEROS SILVIA, MBA

ABSTRACT This project involves the implementation of a new functionality in the ERP Dynamics AX for the company MAINT S.A. of the city of Guayaquil, with the aim of improving the current sales process by adding a feature that allows enable control of lending to customers aimed at increasing the participation of the commercial department in the market attracting new prospects that will increase profits of the company. Through surveys, interviews with key users problems were documented as key record to be considered in implementing improvement were identified. In this study different methods of analysis and development that enabled to meet all the necessary requirements to control, monitor and approve a whole workflow were applied. The results of this work can be seen in the proposed system that organizes and controls all requests flow through the module criteria parameterized criterion and records that keep track of traceability of the process. KEY WORDS: Deployment, ERP, Leaflets, Request, Dynamics AX,

Traceability, Development, Design, Systems.

Tomalá García Edgar Jesús L.S.I. Aguilera Monteros Silvia, MBA C.C. 0926375742 Director of work

PRÓLOGO

El presente proyecto, abre puertas a la investigación interna, a la

reutilización de recursos que habiendo hecho un minucioso análisis se

determina que no han sido explotados en su totalidad, esta investigación

aborta una problemática en el área comercial que cierra la posibilidad de

expandir su mercado por falta de controles automáticos.

En la introducción se describen los diferentes puntos de la situación

actual de la compañía detallando ciertos procesos que evidencian las

limitaciones que actualmente posee la compañía al momento de realizar

una venta y termina perdiendo la posibilidad de registrar una cuenta en el

fichero de clientes.

En el Capítulo I se definen los conceptos teóricos, herramientas a

utilizar y el funcionamiento de cada uno de ellos, los cuales son

importantes en el desarrollo del presente trabajo.

En el Capítulo II se detallan las referencias de las diferentes

herramientas tecnológicas implementadas en otro tipo de negocio pero

que a su vez sirven en muchos de los escenarios.

En el Capítulo III se utilizan las metodologías con las cuales se

obtiene el análisis de los datos, la arquitectura de la solución, el rol de los

actores que forman parte del proceso cotidiano en los casos de uso.

Finalmente en el Capítulo IV se detalla la propuesta de la solución

a implementar con sus conclusiones y recomendaciones para el

modelamiento del flujo de ventas.

CAPÍTULO I

INTRODUCCIÓN

Plan de investigación

1.1 Tema

“Modelamiento del flujo de ventas en el ERP Dynamics AX para la

empresa MAINT S.A.”.

1.2 Introducción

MAINT S.A. es una empresa de servicios que brinda todo tipo de

soluciones tecnológicas, que incluye entre otras cosas la venta de

hardware, licenciamiento, soporte técnico, OUTSOURCING, y como

punto clave la consultoría en la implementación de herramientas de

gestión y soluciones de negocios manteniendo alianza con grandes

marcas internacionales, lo cual garantiza seguridad en la información y un

soporte a largo plazo gracias al respaldo de los PARTNERS (fabricantes).

Uno de los productos que vende la compañía es la implementación y

consultoría del ERP Dynamics AX que pertenece al gigante tecnológico

Microsoft.

Siendo la implementación del ERP Dynamics AX una de las líneas

de negocios de la empresa, el sistema también está implementado en

MAINT como herramienta principal para la administración de las

diferentes áreas de la organización, entre ellas el departamento

comercial, del cual surgió la necesidad de que el sistema posea la

Introducción 3

funcionalidad de flujo de ventas para ciertos clientes que no cumplen los

controles comerciales o no cuentan con el capital inmediato para iniciar un

proyecto y requieren financiación a plazos.

El problema principal radica en que no poseer un sistema con los

controles necesarios para otorgar crédito a clientes que deseen iniciar un

proyecto con MAINT; esto tiene como efecto la pérdida de ingresos y se le

niega al cliente la oportunidad de crecer en su negocio a través de la

implementación de un proyecto tecnológico debido a la falta de

financiamiento.

No contar con un historial crediticio de los clientes matriculados y

prospectos dificulta el análisis previo que se realiza en la generación de

una nueva orden de venta, todo esto atado a las diferentes obligaciones

que tiene el cliente con la empresa.

Si bien es cierto Dynamics AX te realiza por estándar el registro de

las obligaciones sean éstas facturas pendientes, letras de cambio,

cheques posfechados, pagarés, etc. pero no resume en ninguna interfaz

todas estas obligaciones que forman parte del análisis crediticio. Dicho de

otra manera, el proceso actual no cuenta con la información centralizada

para su visualización.

Otorgar un crédito forma parte de un flujo de aprobación donde se

delega a un determinado grupo de funcionarios de diferentes niveles que

le darán seguimiento al proceso de crédito, el sistema actual no posee

dicha funcionalidad ya que sus procesos de fábrica no aplican en la

configuración estándar.

Las aprobaciones comerciales dependerán del análisis y

validaciones que un cliente debe cumplir para otorgarle un crédito, estos

Introducción 4

parámetros deben ser estudiados y definidos por MAINT para la

implementación de un nuevo proceso en Dynamics AX.

Los estudios realizados por expertos en la materia siempre han

sostenido qué en el desarrollo de un sistema de cuentas por cobrar o

facturación, no se necesita de una aprobación para el cobro de una venta,

bajo la premisa de que “no se necesita un aprobador para vender y

cobrar”.

El modelamiento que se va a realizar aportará al sector comercial

como un valioso instrumento de control a los procesos de venta a gran

escala, manteniendo el estándar de los demás módulos, la seguridad de

la información, las pruebas integrales y la estabilidad operativa de la

herramienta.

Preparar y planificar las órdenes de venta a través de una bandeja

de pedidos para lo cual se requiere que el ERP Dynamics AX obtenga la

funcionalidad de realizar los controles respectivos. Dichos controles se

realizarán en base a funciones específicas, control comercial y control de

crédito los mismos que cumplen validaciones durante el proceso.

La activación de la bandeja de pedidos, ejecutará validaciones

comerciales cuyo fin es asegurarse de la disponibilidad de los recursos

humanos y tecnológicos para el proyecto, de no cumplir se procederá a

un ingreso de “BACKORDER” en la bandeja de pedidos inicial, el cual

permitirá a la empresa tener el registro de lo faltante dándole el tiempo

necesario para conseguir los recursos y proceder con el proyecto.

Obtener ésta funcionalidad en el ERP de la organización sin duda

alguna abrirá nuevas oportunidades de negocio en ésta línea, ya que en

el mercado existen muchas empresas que estarían interesadas en llevar

el mismo control sobre su ventas mayoristas.

Introducción 5

1.3 Objeto de la investigación

En tiempos de crisis una compañía no puede darse el lujo de

perder oportunidades comerciales, por el simple hecho de no contar con

las herramientas de control en el caso de otorgar créditos directos. Se

debe evaluar todas las posibilidades y oportunidades que puedan

solventar esta solución con el fin de obtener un producto eficiente y eficaz

que permita generar las divisas que se necesitan para el crecimiento de

la empresa en otros campos que aún no han sido explorados.

Hacer referencia a todos los procesos crediticios actuales que

manejan los bancos y cooperativas de ahorro y crédito regulados por un

ente de control público, enfocándose en aspectos importantes como las

mejores prácticas de recuperación de cartera, pasos que no se deben

pasar por alto a la hora de registrar un pedido, acciones a tomar post

aprobación; son entre otros temas las consideraciones a documentar

durante la investigación.

Realizar el diseño y modelamiento del flujo de ventas con todos los

escenarios posibles, medir el impacto que causaría cambiar la operativa

actual del módulo describiendo las ventajas y desventajas, definiendo los

requerimientos técnicos y funcionales, documentando todas las futuras

configuraciones, agrupando por fases todos los avances del desarrollo,

comparar y diferenciar los procesos actuales que resulten afectados

previo a la salida a producción, dimensionar los alcances de la nueva

funcionalidad describiendo sus beneficios y los resultados que obtendrá la

compañía posterior a la implementación.

Además de agilizar el proceso actual de ventas, se permitirá

notificar sobre las actualizaciones que afectan a la información maestra

integrando el ERP con herramientas de comunicación como el correo

electrónico; esto permitirá informar a los usuarios de manera periódica

Introducción 6

sobre las alteraciones que sufran los datos principales utilizados en sus

transacciones.

Modelar, diseñar y desarrollar la funcionalidad de “Flujo de ventas

en Dynamics AX” para la empresa MAINT S.A. ubicada en la ciudad de

Guayaquil provincia del Guayas durante el año 2015 – 2016.

Las diferentes marcas de ERP que existen a nivel mundial, trabajan

a diario por la innovación, mejora continua en los procesos de cada

módulo, estabilidad, seguridad de los datos, herramientas gerenciales

para la toma de decisiones, existen productos licenciados y OPEN

SOURCE para éste caso de estudio nombraremos algunos ERP sin

enfocar sus diferencias, entre los más conocidos tenemos los siguientes:

SAP

JD EDWARDS

BAAN

DYNAMICS AX

ADEMPIERE (OPEN SOURCE)

OPEN BRAVO (OPEN SOURCE)

OPEN ERP (OPEN SOURCE)

PEOPLESOFT

Crear una solución eficaz y eficiente, que en un futuro pueda ser

parte de la solución estándar del producto, es lo que conlleva a trabajar

sobre éste proyecto con el fin de brindar un aporte del intelecto

ecuatoriano a los fabricantes.

El poder de las alianzas incrementa la productividad y el desarrollo,

genera empleos, suma mejores resultados, satisfaciendo las necesidades

de los clientes reforzando la teoría del trabajo en equipo.

Introducción 7

La realización de éste proyecto comprende la necesidad de contar

con el recurso humano especializado, los recursos didácticos y

tecnológicos; para el recurso humano se contará con la colaboración del

autor del presente documento quien estará encargado de realizar las

investigaciones, análisis, estudio de los procesos actuales, diseño de la

propuesta, documentación técnica y funcional, cronogramas, casos de

uso detallando todos los escenarios posibles hasta la entrega del modelo

final.

Para los recursos didácticos y tecnológicos se contara con lo

siguiente:

Computador portátil DELL Core I3, 6 GB de memoria RAM (SO

Windows 8.1 PRO).

Disco duro portable de 2 TB.

Celular inteligente.

Impresoras.

Cuadernos de apuntes.

Acceso a internet.

Esferos, lápiz, borradores.

Manuales certificados del ERP elaborados por el fabricante.

1.4 Justificación de la investigación

En el mercado existen muchos productos que brindan soluciones

de negocios con diferentes puntos de vista, diferente operativa con cierto

valor agregado que diferencia una solución de otra, pero todos los

sistemas en su mayoría carecen de nuevas necesidades que a la

actualidad está incrementando su demanda debido al constante cambio

en el mercado de optar por alternativas en los negocios, ya que el factor

político – económico le está dando la vuelta a la manera de hacer las

cosas; factores que se están viendo reflejados en los indicadores de la

Introducción 8

organización. Teniendo como base éste precedente nos anima el hecho

de analizar, estudiar y probar ésas novedosas alternativas que brindarán

una solución frente a la situación que estamos viviendo, aportando con el

conocimiento y la experiencia del talento humano ayudado de los

recursos tecnológicos que tenemos al alcance hoy en día.

Con esta propuesta se busca dar paso a la innovación y

mejoramiento de los futuros cambios a las que muchas organizaciones

están sujetas utilizando el intelecto ecuatoriano registrando nuevos

aportes a la sociedad.

El sector comercial sean empresas de servicios, distribuidores,

constructoras etc. estarán beneficiadas con el desarrollo de este proyecto,

la investigación y el trabajo a realizar sin duda captará el interés de otras

compañías que deseen cambiar su modelo de negocios e incrementar sus

utilidades, otros beneficiarios indirectos son los clientes que requerían las

facilidades de pago sin financiamiento intermedio y por lo cual surgió la

idea.

Hoy por hoy en nuestro medio, ofrecer créditos constituye un

instrumento muy importante a la hora de impulsar el desarrollo de nuestra

economía, satisfaciendo una necesidad brindando las facilidades de pago

al consumidor y gracias a eso se persiguen los objetivos de la empresa,

creciendo y posicionándose en el mercado, alcanzando sus metas y la de

los colaboradores. Incorporar estas necesidades a empresas de servicios

como “MAINT S.A.” que aportan conocimiento e innovación en temas

tecnológicos y de consultoría son parte de las políticas del Plan

Nacional del Buen Vivir:

a. (Plan Nacional, 2013) “10.1 Diversificar y generar mayor valor

agregado en la producción nacional.”

Introducción 9

b. (Plan Nacional, 2013) “10.2 Promover la intensidad tecnológica en la

producción primaria, de bienes intermedios y finales.”

c. (Plan Nacional, 2013) “10.3 Diversificar y generar mayor valor

agregado en los sectores prioritarios que proveen servicios.”

d. (Plan Nacional, 2013) “10.5 Fortalecer la economía popular y solidaria

EPS–, y las micro, pequeñas y medianas empresas –Mipymes– en la

estructura productiva.”

“Ampliar la capacidad innovadora, fomentar el desarrollo científico y

tecnológico, y la capacitación especializada, para mejorar la

diversificación y los niveles de inclusión y competitividad.”

e. (Plan Nacional, 2013) “Se busca cimentar una evolución creciente de

producción industrial y de servicios con valor agregado, a través de la

expansión del conocimiento científico y tecnológico.”

f. (Plan Nacional, 2013) “Generar mecanismos de incentivo y acceso a

financiamiento de programas y proyectos de investigación científica y

desarrollo tecnológico, promoviendo su implementación con criterios

de priorización para el desarrollo del país.”

Sin duda existe carencia en ciertos procesos complejos pero

necesarios para diferentes modelos de negocios que requieren más

atención por parte de los fabricantes de ERP y por la premura de sacar

nuevas versiones en fechas previstas; se basan en el estudio universal de

los diferentes temas realizando mejoras de forma o en procesos

existentes el cual hace complicado llegar a un nivel personalizado a

detalle de cada compañía; lo cual conlleva a realizarse las siguientes

preguntas ¿Qué puedo hacer para mejorar mi operativa interna?, ¿Qué

planes debo analizar para captar nuevos clientes?, ¿Es posible abarcar

más con los recursos que contamos actualmente?.

La compañía que cuenta con toda esa información es capaz de

tomar decisiones a fin de expandir aún más en el mercado empezando

desde el interior de la organización.

Introducción 10

Los sistemas de recursos empresariales poseen una fuerte

estructura tecnológica en la que grandes organizaciones pueden integrar

y coordinar sus principales procesos internos de negocio. Lo principal es

entender que cada organización tiene necesidades distintas y que la

configuración y los nuevos alcances a desarrollar dependerán del modelo

organizacional.

Siendo MAINT S.A. una empresa de servicios que brinda asesoría,

las nuevas ideas que pongamos en práctica al interno de la compañía, se

las transmitimos a nuestros clientes consiguiendo un efecto multiplicador

el plantear nuevas soluciones a los diferentes modelos de negocio.

1.5 Objetivos

1.5.1 Objetivos generales

Implementar una solución de flujos de trabajo, que controle los

procesos crediticios de la compañía en el ERP Dynamics AX

personalizando el módulo de cuentas por cobrar.

1.5.2 Objetivos específicos

Entre los objetivos específicos del análisis del proceso tenemos los

siguientes:

Consolidar toda la información de clientes de la compañía según su

clasificación (clientes fidelizados, clientes potenciales, futuros clientes,

etc).

Elaborar la matriz de riesgos en base al cambio del proceso del

módulo de cuentas por cobrar.

Diseñar conforme a lo relevado las definiciones que conlleva el flujo de

ventas en un formato estandarizado de la compañía.

Introducción 11

Determinar roles y responsabilidades en la nueva forma de operar el

módulo.

Analizar los alcances del ERP a nivel técnico, investigar posibles

integraciones con otras herramientas del mismo fabricante o

fabricantes externos a fin de desarrollar nuevos proyectos sin que

afecte la estabilidad y funcionamiento actual.

Dimensionar el incremento de recursos técnicos para la

implementación del flujo de ventas.

Diseñar el esquema (diagramas de flujo, casos de uso, diagramas

clases) del flujo de trabajo aplicado a procesos de crédito que va a

llevar la compañía en esta nueva implementación.

Ofrecer análisis de calidad a través de la información que se obtenga

de los nuevos proyectos a implementarse.

Salvaguardar la información a través del sistema.

CAPÍTULO II

MARCO TEÓRICO

A simple vista la tecnología se ha convertido en un activo muy

valioso para la mayoría de las organizaciones que son muy dependientes

de ella, las herramientas tecnológicas nos facilitan la vida, reduciendo

carga operativa, realizando cálculos y procesos complejos de forma

automática, brindando resultados que son el éxito comercial de las

empresas que poseen dichas herramientas.

“Desde sus inicios, la tecnología ha estado en constante

evolución, y la velocidad con la que esto ocurre es casi

increíble” (Stephen Hawking, 2004)

Nótese que con el pasar del tiempo la tecnología ha sufrido

grandes avances que han explotado el crecimiento de muchas empresas

alrededor del mundo, y esto se debe a que el hombre desde sus inicios ha

utilizado sus conocimientos para fabricar herramientas que sirven a sus

propósitos; en los momentos actuales se venera la tecnología como

fundamento de prosperidad empresarial.

El cambio que se refleja en el mundo actual, más que deberse al

avance tecnológico, se debe al descubrimiento que ha hecho el hombre

para hacer cambiar la tecnología ya que las innovaciones se basan en

necesidades que aún son desconocidas para cierto sector de la sociedad.

Dicho de otra manera el investigador debe hacerse éstas dos preguntas:

¿Para qué necesito tecnología?, ¿Quién necesita tecnología?, las

respuestas dan paso al diseño y construcción de nuevas ideas.

Marco teórico 13

“Los avances tecnológicos han sido tan grandes que, a

ese paso, pronto veremos un verdadero hombre

maquina” (Sidney Perkowitz, 2001)

La generación de empleos es una de las ventajas del avance

tecnológico, empresas como MAINT S.A. que permanece en el mercado

desde 1984 apuesta por el talento humano y provee a sus clientes

soluciones tecnológicas de negocios manteniendo alianzas con marcas

reconocidas mundialmente.

Entre los valores organizacionales que posee la empresa resaltaré

la mejora continua, y es precisamente de mejorar se trata el tema de éste

proyecto, utilizar los recursos existentes y mejorarlo de acuerdo a las

nuevas necesidades que surgieron bajo ciertos escenarios.

“El uso de tecnología, la innovación tecnológica y el

mejoramiento de la calidad son factores que contribuyen

a mejorar la competitividad local e internacional de las

MIPYMES, sin embargo, en el Ecuador sólo el 30% de las

MIPYMES utiliza las ventajas tecnológicas de

información y comunicación (TIC), cifra muy baja en

relación al 50% registrado en otros países de América

Latina” (Hugo Jácome, 2012)

La empresa tiene como una de sus líneas de negocio la

implementación y consultoría del ERP Dynamics AX que actualmente

pertenece al gigante tecnológico Microsoft. El sistema también está

implementado en MAINT como herramienta principal para la

administración de las diferentes áreas de la organización, entre ellas el

departamento comercial, de donde surgió la idea de realizar una mejora

en los procesos funcionales en cual consiste en activar un flujo de ventas

para ciertos clientes que no cumplen los controles comerciales o no

Marco Teórico 14

cuentan con el capital inmediato para iniciar un proyecto y requieren

financiación.

Dynamics AX un sistema flexible y versátil permite una mejor

manipulación de los recursos, siempre pensando en un futuro

mejoramiento sin necesidad de re implementar, modificando procesos

planificados, manteniendo la integridad de los datos suma importancia a

la creciente demanda que exigen las organizaciones cuando adquieren un

software.

“La versatilidad respecto a formas de producción. El

establecimiento de rutas y la posibilidad de modificarlas en

función de la planificación de necesidades de capacidad

revelan la importancia de un sistema flexible que permita

contemplar varias formas de producción alternativas”

(Delgado J, 2000)

“Los Sistemas ERP (Enterprise Resource Planning) han

recibido una enorme atención dentro del ámbito

empresarial en estos últimos años. Sus innumerables

ventajas han hecho que se conviertan en unas

herramientas de gran utilidad en las labores de gestión de

cualquier empresa. Esta publicación, tienen por misión

introducir al lector en el manejo de un sistema ERP, similar

al que pudieran encontrarse en cualquier empresa”

(Miguel, 2009)

La adhesión de nuevos proyectos dentro de un sistema

implementado abarca nuevos campos incrementando las capacidades de

los recursos actuales, investigando y evaluando las funcionalidades del

ERP para alcanzar los objetivos deseados. Replantear las funciones

departamentales a fin de optimizar operaciones que causan reproceso, es

Marco Teórico 15

otro de los beneficios que implica la implementación de nuevas

funcionalidades dentro de un mismo sistema.

“Un sistema abierto con varios subsistemas en interacción

que a partir de insumos de energía, información y

materiales del medio, los transforma y salen como

productos y/o servicios. Mediante la realimentación, el

sistema recibe continuamente información, lo que permite

adaptarse y alcanzar sus objetivos de estabilidad y

supervivencia” (Lopez Marcelo & Correa José, 2007)

Dynamics AX es un ERP que tiene como característica principal

poseer varios módulos funcionales, el cual integra las operaciones

departamentales de una compañía, entre esos módulos también se

encuentra el módulo de desarrollo que tienen diferentes tipos de

tecnología integrada. El software fue desarrollado originalmente por la

compañía danesa DAMGAARD DATA junto con IBM (USA), su nombre

original fue AXAPTA lanzando como primera versión la 2.5

CUADRO N° 1

VERSIONES DYNAMICS AX

Fuente: (Microsoft, Versiones Dynamics AX, 2012) Elaborado por: Tomalá García Edgar Jesús

MorphX es un entorno de desarrollo integrado que permite al ERP

diseñar gráficamente tipos de datos, enumeraciones, tablas, consultas,

formularios, menús, reportes. Además de la manipulación de objetos,

todas las versiones de Dynamics AX proporcionan acceso al código

fuente, cuyo lenguaje de programación es X++. A través de MorphX

Marco Teórico 16

puedo agregar referencias, vincular objetos, integrarme con otras

aplicaciones (SOA). Por otra parte los cambios que se realicen en el

sistema se reflejan automáticamente después de la compilación. X++ es

un lenguaje de programación de expedición única basada en clases

orientadas a objetos. X++ se deriva de C++

GRÁFICO N° 1

ARQUITECTURA DE TRES NIVELES DYNAMICS AX

Fuente: Instalación y Configuración Microsoft Dynamics Elaborado por: Tomalá García Edgar Jesús

Dynamics AX se compone de una arquitectura de tres niveles:

Almacén de base de datos

Servidor de aplicación que ejecuta la lógica de negocios

La aplicación cliente permite a los usuarios conectarse al servidor

para el acceso a la lógica de negocio y utilizar la información alojada en la

base de datos.

La arquitectura de tres nieves son los componentes básicos para el

funcionamiento preliminar de la aplicación. Su tecnología incluye la

instalación de nuevos componentes que habilitan más funciones del

Marco Teórico 17

sistema, entre ellos están la reportería en SQL Reporting Services,

componentes de procesamiento analítico en línea (OLAP), la navegación

web a través del portal empresarial, integración con la ofimática. La

siguiente imagen describe una arquitectura de sistema típico que incluye

otros componentes de pila de la tecnología de Microsoft.

GRÁFICO N° 2

GRÁFICO DE ARQUITECTURA EXTENDIDA

Fuente: Instalación y Configuración Microsoft Dynamics AX Elaborado por: Tomalá García Edgar Jesús

CAPÍTULO III

METODOLOGÍA

En el presente trabajo de investigación se tomaron diferentes

acciones destinadas a describir y analizar a fondo la situación actual de

MAINT S.A. para responder en sí al problema planteado, abarcando el

diseño y los tipos de investigación que se aplicaron en diferentes

escenarios.

3.1. Metodología Descriptiva

Este tipo de metodología descriptiva es un conjunto de

procedimientos lógicos y prácticos que permiten identificar las

características de una población o lugar, además plantea relaciones

complejas entre los factores y/o actores identificados en torno a un

problema de investigación.

Tiene como principal objetivo llegar a conocer todo lo observado en

las situaciones, costumbres y actitudes predominantes a través de la

descripción exacta de las actividades, objetos, procesos y personas.

La metodología descriptiva se aplicó en MAINT S.A. en el

levantamiento de información, específicamente en las áreas que forman

parte del proceso conversando con los responsables involucrados.

La primera tarea realiza fue la descripción detallada de los

problemas causas y efectos.

Metodología 19

Etapas de la metodología descriptiva

Entre las diferentes etapas que componen la metodología

descriptiva se usaron las siguientes:

1. Examinar características del problema escogido.

2. Seleccionar o elaborar técnicas para la recolección de datos.

3. Informar resultados.

Para esta fase se utilizaron las siguientes herramientas que

permitieron visualizar con mejor detalle el panorama general de la

situación actual.

Diagrama Ishikawa.

Encuestas para la recolección de datos.

3.2. Examinar características del problema escogido

Se mantuvo una reunión con los responsables directos en el

proceso actual, cada involucrado detalló su trabajo desde su propia

perspectiva y se enfatizaron en los problemas que se les presentan bajo

distintos escenarios.

El cual de documentó para ser reflejados en el diagrama

problemas, causas y efectos Ishikawa.

A continuación en el diagrama N° 1 se observa el diagrama de

Ishikawa.

Metodología 20

DIAGRAMA N° 1

DIAGRAMA ISHIKAWA

Fuente: Reunión con los actores responsables. Elaborado por: Tomalá García Edgar Jesús

Ger

ente

de

pro

duct

o (

vent

as)

Asi

sten

te

Ad

min

istr

ativ

o

-En

vía

el p

edid

o al

sis

tem

a.

-A

naliz

a lo

s al

canc

es d

el p

roye

cto

vend

ido

para

est

able

cer

un p

reci

o de

vent

a.

-El

abor

a co

ntra

to c

on d

e ac

uerd

o al

dim

ensi

onam

ient

o y

expe

ctat

iva

del

clie

nte.

-El

clie

nte

dese

a ca

ncel

ar e

l

proy

ecto

apl

ican

do la

form

a de

pag

o de

mul

tiven

cim

ient

os.

-N

o se

tie

nen

cont

role

s

cred

itici

os.

No

co

ntar

co

n lo

s

cont

role

s ne

cesa

rio

s

par

a o

torg

ar c

réd

ito

-In

cum

plir

con

las

plan

ifica

cion

es

anua

les

por

falta

de

flujo

de

efec

tivo.

-Er

rore

s en

los

regi

stro

s de

cob

ros.

Ap

ertu

ra d

e la

No

ta d

e p

edid

o

(Clie

nte)

Ger

ente

de

Pro

yect

o

Teso

rerí

a y

Co

bra

nza

s

-N

o te

ner

defin

ido

las

fech

as lí

mite

por

cada

fase

par

a fa

ctur

ar.

-N

o po

seer

en

el s

iste

ma

el c

ontr

ol d

e

cobr

os in

tegr

ado

con

el c

rono

gram

a.

-A

sign

ar a

los

espe

cial

ista

s pa

ra e

l

proy

ecto

con

sus

res

pect

ivas

herr

amie

ntas

de

trab

ajo.

-In

gres

ar e

l pre

supu

esto

del

pro

yect

o

en e

l sis

tem

a de

acu

erdo

al

cron

ogra

ma

de t

raba

jo.

-La

con

trat

ació

n de

rec

urso

s hu

man

os

varía

de

acue

rdo

al m

onto

tot

al d

el

proy

ecto

y a

su

alca

nce.

-Si

la fo

rma

de p

ago

es a

cré

dito

con

mul

tiven

cim

ient

os e

l pre

supu

esto

qued

a in

cons

iste

nte

a la

not

a de

pedi

do.

-H

ace

efec

tiva

la n

ota

de p

edid

o ba

jo

los

pará

met

ros

del g

eren

te d

e

prod

ucto

.

-Es

tabl

ecer

las

form

as d

e pa

go

habi

litad

as e

n el

pro

ceso

act

ual

(efe

ctiv

o, c

hequ

e, p

lazo

s).

-N

o po

seer

his

toria

l cre

ditic

io, d

el

clie

nte

que

gene

ró u

na t

rans

acci

ón e

n

el s

iste

ma.

-N

o te

ner

habi

litad

o lo

s di

vide

ndos

de

pago

par

a el

esc

enar

io d

e co

bros

a

créd

ito (p

ago

del d

ivid

endo

)

Fu

ente

: R

euni

ón c

on lo

s ac

tore

s re

spon

sabl

es.

Au

tor:

E

dgar

Tom

alá

Gar

cía

Metodología 21

Seleccionar o elaborar técnicas para la recolección de datos

Una de las técnicas más usadas en una investigación es la

encuesta ya que permite recopilar datos de modo eficaz y eficiente.

“Los análisis de encuesta son un tipo de estudio

descriptivo y, por lo tanto, su objetivo será el de ayudar a

describir un fenómeno dado independientemente de la

modalidad, es muy importante que los objetivos estén muy

claros ya que deben llevar a establecer cuál es la

información necesaria que se debe recoger en el

instrumento con el que se recojan los datos; deben ser

verbos que reflejen resultados y que sirvan para adquirir

conocimiento”. (González, 2010)

Para la compañía MAINT S.A. se realizó una serie de preguntas

estructuradas con el objetivo de obtener información relacionada con las

variables encontradas en el problema inicial.

Una de las ventajas por la cual se eligió usar ésta técnica es

conocer la población involucrada en el proceso del flujo de ventas, que

es la que va a definir los, alcances y controles a implementar. Por lo tanto

teniendo contacto con los involucrados la encuesta se realizó al 100% de

mi población que lo conforma el departamento comercial de la compañía

divididos de la siguiente manera:

CUADRO N° 2

NÚMERO DE USUARIOS DE LA COMPANÍA

Departamento Número de Ingenieros Ciudad

Dpto. Comercial 30 Guayaquil

Dpto. Comercial 12 Quito

Fuente: Departamento de Recursos Humanos. Elaborado por: Tomalá García Edgar Jesús

Metodología 22

La encuesta nos permitió obtener resultados cuantitativos que se

verán reflejados en la propuesta. Hay que tener en cuenta que la

población que será beneficiada con el proyecto directamente será el

departamento comercial, e indirectamente los clientes.

Por tanto la encuesta va dirigida los beneficiarios directos quien

tendrán el control de los alcances definidos.

La fórmula a utilizar es:

n 2NPQ

E2(N 1) 2PQ

En donde:

n = Tamaño de la muestra

N = Tamaño de la población

E = Error admisible permitido

P = Probabilidad de que el evento ocurra

Q = Probabilidad de que el evento no ocurra

N = 42 (Dpto.Comercial)

Z2 = 1.96

P = 0.5

Q = 0.5

e2 = 0%

Con lo cual tenemos como resultado 42 cuestionarios a tomar lo

cual representa el 100% de la población a encuestar.

Metodología 23

3.3. Cuestionario y guía de pautas

El cuestionario y guía de pautas utilizados se diseñaron para

cumplir con los objetivos que espera el Departamento comercial en la

gestión del flujo de ventas. El tipo de encuesta que se utilizó fue

electrónica, se les envió por correo un enlace que lo direcciona a un

cuestionario publicado en la web.

GRÁFICO N° 3

FORMATO DE ENCUESTA

Fuente: Interfaz web del cuestionario de encuesta Elaborado por: Tomalá García Edgar Jesús

Metodología 24

3.4. Informar Resultados

La recolección de la información para la investigación cuantitativa

se la realizó en el sector comercial dentro de la compañía, las encuestas

realizadas se revisaron en su totalidad para minimizar los posibles

errores, omisiones o inconsistencias antes de su proceso. A continuación

mostrarán los resultados del estudio cuantitativo:

Perfil del encuestado

Para obtener un mejor análisis del perfil del encuestado se les

consultó su título académico, entre la población tenemos:

Ingeniero en Sistemas

Licenciado en Marketing y Publicidad

Ingeniero Comercial

Ingeniero en Finanzas

Se tomaron datos del cargo que ocupan en la empresa, del cual

tenemos los siguientes resultados en el Departamento Comercial:

Gerentes de producto

Gerentes de cuenta

El tiempo de antigüedad en la empresa es un dato importante a

tener en cuenta entre los datos del perfil del encuestado, se consideraron

los siguientes rangos:

0 – 5 años

6 – 10 años

11 – 20 años

21 – 30 años

Metodología 25

GRÁFICO N° 4

ANTIGÜEDAD EN LA EMPRESA

Fuente: Resultados de la encuesta Elaborado por: Tomalá García Edgar Jesús

Alcances, controles y validaciones

En el nuevo proceso de flujo de ventas se tuvieron en cuenta varios

factores que determinarán impacto durante la ejecución, por ese motivo

en la construcción del cuestionario se especificaron detalles a tener en

cuenta para el desarrollo de la propuesta, entre ellos tenemos:

Formas de pago

Pregunta 1: En el nuevo proceso crediticio a implementar

establezca las formas de pagos que usted considere que se debería

manejar en las cuotas de los clientes.

GRÁFICO N° 5

RESULTADO FORMAS DE PAGO

Fuente: Resultados de la encuesta de formas de pago

Elaborado por: Tomalá García Edgar Jesús

Metodología 26

Aunque la forma de pago Cheque certificado lidera la encuesta con

un 88.1 %, hay que considerar habilitar letra de cambio y pagaré entre las

funcionalidades que debe tener el flujo de ventas.

Número de aprobadores por monto de crédito

Pregunta 2: Basados en los parámetros de control de los límites de

crédito definidos en la compañía, establezca los roles que deberían

realizar las aprobaciones del crédito.

Rango: $ 90.000 - $ 200.000

GRÁFICO N° 6

RESULTADO NÚMERO DE APROBADORES EN EL RANGO

$ 90.000 - $200.000

Fuente: Resultados de la encuesta número de aprobadores Elaborado por: Tomalá García Edgar Jesús

En los resultados de esta encuesta cabe mencionar que valores

inferiores a $ 90.000 se aprobaran automáticamente sin necesidad de la

revisión de un funcionario. El oficial de crédito que lleva el 95.2% tiene el

perfil para el analizar toda la información crediticia del cliente, históricos

de cartera con otra institución, etc. y darle el seguimiento respectivo

después de su aprobación. No se estima necesaria la revisión por parte

del gerente de producto pese a estar en segundo lugar no llega ni al 50%

de aprobación en las encuestas.

Metodología 27

Rango: $ 200.000 - $ 500.000

GRÁFICO N° 7

RESULTADO NÚMERO DE APROBADORES EN EL RANGO

$ 200.000 - $500.000


Debido a la fuerte cantidad del monto a revisar, los resultados

inclinan a una segunda aprobación, el 76.2% de preferencia que tiene el

Gerente comercial indica que debe revisarse en primera instancia por el

Gerente de producto y la acción será completada por la aprobación final

del Gerente comercial de acuerdo a la jerarquía organizacional, lo que

indica que los pedidos cuyos totales estén entre éste rango no llegaran a

la bandeja de aprobación del oficial de crédito.

Rango: $ 500.000 – superior

GRÁFICO N° 8

RESULTADO NÚMERO DE APROBADORES

EN EL RANGO $ 500.000 - SUPERIOR


Metodología 28

Indiscutiblemente éstas cifras debe estar sujeta a aprobación, debe

ser un perfil de alto rango tal como lo señalan los resultados, aunque

estuvo sujeta a debate durante las reuniones que se mantuvo con los

responsables involucrados, los porcentajes deducen que con un 100%

sólo será revisada por el Gerente General de la compañía.

Reenvío de pedido al Flujo

Pregunta 3: En caso de que el cliente no cumpla una de las

validaciones de control establecidas por la gerencia comercial ¿Considera

que deba volver a revisarse todo el proceso de la nota de pedido?

GRÁFICO N° 9

REENVÍO DE PEDIDO AL FLUJO

Fuente: Resultados de la encuesta Reingreso del flujo Elaborado por: Tomalá García Edgar Jesús

Éste resultado que da un 53% a favor del SÍ, sostiene que se

requiere una nueva revisión del pedido para casos excepcionales;

resultado a tener en cuenta cuando se consulten reportes del historial del

flujo.

Metodología 29

Envío de notificaciones

Pregunta 4: En el caso de ser rechazado el crédito por parte de

uno de los funcionarios de seguimiento, entre los involucrados ¿A quién

se debería notificar la acción?

GRÁFICO # 10

ENVÍO DE NOTIFICACIONES

Fuente: Resultados de la encuesta Envío de notificaciones Elaborado por: Tomalá García Edgar Jesús

El envío de notificaciones en un proceso de crédito es importante,

los resultados arrojados por la encuesta indican un 69% al envío de las

notificaciones a todos los involucrados, tarea que afecta funcionalmente

en el diseño de los parámetros generales del flujo.

Metodología 30

Resumen

Herramienta para las notificaciones

Pregunta 5: Establezca la forma de notificación de eventos durante

el flujo de aprobación de crédito.

GRÁFICO N° 11

NOTIFICACIONES

Fuente: Resultados de la encuesta Notificaciones Elaborado por: Tomalá García Edgar Jesús

Según estos resultados la herramienta deberá remitir correos

electrónicos automáticos por cada ejecución de las acciones que tenga el

flujo de ventas.

Descuentos

Pregunta 6: Basados en los parámetros de control en los límites de

descuento en ventas, establezca los roles que deberían realizar las

aprobaciones de descuento.

Metodología 31

Rango: 10% - 20%

GRÁFICO N° 12

NÚMERO DE APROBADORES DE DESCUENTOS

ENTRE 10% - 20%

Fuente: Resultados de la encuesta Descuentos Elaborado por: Tomalá García Edgar Jesús

De igual manera que el caso anterior, para este caso inicial los

porcentajes de descuentos otorgados inferiores al 10% se aprobaran

automáticamente sin la necesidad de la revisión de un funcionario. En el

caso de entrar a ésta categoría el pedido entrará a la bandeja de

aprobación de descuentos del Gerente comercial tal como lo indican los

resultados de la encuesta.

Rango: 20% - superior

GRÁFICO N° 13

NÚMERO DE APROBADORES DE DESCUENTOS

ENTRE 20% - SUPERIOR

Fuente: Resultados de la encuesta Descuentos


Metodología 32

Para este caso teniendo en cuenta que el Gerente Regional llegar

al 50% en la encuesta se lo designará como el primer aprobador

completando la tarea el Gerente general.

Beneficios por puntualidad.

Pregunta 7: Estima usted necesario darle algún tipo de beneficio o

descuento en una próxima venta al cliente que anticipe sus cuotas

pendientes.

GRÁFICO N° 14

BENEFICIOS POR PUNTUALIDAD

Fuente: Resultados de la encuesta Beneficios por puntualidad Elaborado por: Tomalá García Edgar Jesús

Los resultados de la encuesta reflejan la necesidad de validar algún

tipo de beneficio en una próxima venta lo cual quedará registrada en las

transacciones del cliente.

Líneas de Negocio

Pregunta 8: Entre los productos y servicios que ofrece MAINT S.A.

a sus clientes, ¿cuáles de las líneas de negocio debería activar el flujo de

crédito?

Metodología 33

GRÁFICO N° 15

LÍNEAS DE NEGOCIO

Fuente: Resultados de la encuesta Líneas de negocio Elaborado por: Tomalá García Edgar Jesús

No todas las líneas de negocio que ofrece Maint a sus clientes

producen la rentabilidad suficiente para otorgar un crédito directo en una

venta, dejamos a consideración del departamento comercial cuales de las

líneas entrarán en el flujo de ventas.

3.5. Metodología ICONIX

Este tipo de metodología es utilizada para la ingeniería de software

que implica un proceso eficiente y de calidad para obtener una solución

informática estable.

Metodología 34

Es indispensable el uso de una metodología para el desarrollo de

sistemas, logrando que la aplicación cumpla con todos los requerimientos

del usuario.

Para el caso de Maint S.A. que se realizó un lenguaje de

modelamiento en notación gráfica que incluye diferentes tipos de

diagramas en este caso el UML (Lenguaje Unificado de Modelado) cuyo

proceso define quien debe de hacer qué, cuándo y cómo alcanzar el

objetivo.

3.5.1. Fases de la metodología Iconix

La fase que se implementó de esta tecnología en Maint S.A. es:

Análisis de requisitos

Modelo de dominio

3.5.2. Análisis de Requisitos

En esta fase de la metodología definida como análisis de requisitos

se define como el proceso de estudio de las necesidades de los usuarios

para llegar a formalizar los requisitos del sistema a nivel funcional.

Para esta fase se utilizó la siguiente herramienta:

Modelo de casos de uso

Para el modelo de casos de uso es necesaria la descripción de la

situación actual que está reflejada en el Diagrama #1 de Ishikawa de la

metodología descriptiva.

Metodología 35

3.5.3 Listado de actores y funciones

CUADRO N° 3

ACTORES DEL PROCESO

Gerente de producto

Responsable de las ventas, maneja

directamente la gestión con el cliente,

responsable de configurar los datos

demográficos de los clientes y responsable

de conseguir los recursos humanos y

tecnológicos para un proyecto.

Oficial de crédito

Manejo de cartera, responsable de todo el

seguimiento de las notas de pedido,

encargado del análisis y supervisión de los

clientes que tengan vigente una

financiación y encargado de las

aprobaciones de crédito.

Administrador del módulo

de ventas

Usuario funcional senior, responsable de

toda la administración del módulo también

de la configuración de los acuerdos

comerciales.

Gerente de Operaciones

Jefe del área de servicios, quien realiza la

asignación de recursos humanos y

tecnológicos.

Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús

3.5.4 Especificaciones funcionales

Las especificaciones funcionales van a detallar la interacción entre

el usuario final y el sistema, los procesos que día a día va a manejar el

usuario estará conectado con una interfaz que va a permitir realizar sus

actividades de forma ágil.

Metodología 36

CUADRO N° 4

ESPECIFICACIONES FUNCIONALES A

Código Especificación funcional

VM001 Creación y Mantenimiento de clientes

VM002 Orden de venta

VM003 Mantenimiento de condiciones de pago

VM004 Mantenimiento de formas de pago

VM005 Configuración de Multivencimientos

VM006 Asignación grupos de clientes

VM007 Acuerdos comerciales

VM008 Cotización de ventas

VM009 Facturación

VM010 Notas de crédito

VM0011 Reportería

Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús

3.5.5 Especificaciones no funcionales

Las especificaciones no funcionales en la ingeniería de software

especifican criterios que pueden usarse para juzgar algún tipo de

operación.

CUADRO N° 5

ESPECIFICACIONES FUNCIONALES B

Código Especificación funcional

ENF001 Garantizar estabilidad en la operación

ENF002 Interfaz atractiva a la vista del usuario

ENF003 Operativo 24/7


Metodología 37

Gerente de producto

Creación y Mantenimiento en el Maestro de clientes

Configuraciones generales

Definir acuerdos comerciales

Administrador módulo de ventas

Creación Orden de venta

Asignación de recursos

Jefe de Operaciones

3.5.6 Diagrama de casos de uso

Se utilizará esta herramienta con el objetivo documentar todo el

análisis realizado con los usuarios (actores) involucrados en un diagrama

UML que detalla el comportamiento operacional y funcional de los

diferentes procesos cotidianos.

DIAGRAMA N° 2

DIAGRAMA DE CASO DE USO GENERAL

Fuente: Definición de la reunión con los actores


Caso de uso registro de clientes

El siguiente caso de uso nos va a permitir visualizar en mejor

panorama la creación de un cliente con todas las acotaciones que dicho

proceso implica.

Metodología 38

Gerente de producto

Crear Cliente

Configurar Datos demográficos

Direcciones, Telefono

Información de contacto

Valores predeterminados para el pago

Administradordel módulo de ventas

DIAGRAMA N° 3

DIAGRAMA DE CASO DE USO REGISTRO DE CLIENTES


CUADRO N° 6

REGISTRO DE CLIENTES

Código: AX001

Nombre: Registro de clientes

Actores: Gerente de producto, Administrador del

módulo de ventas

Fecha:

28/01/2016

Descripción:

Proceso de mantenimiento del fichero de clientes.

Precondición:

Deben estar configurados previamente las funciones de:

1. Formas de pagos

Metodología 39

2. Códigos de impuestos

3. Condiciones de pagos

Flujo de eventos:

Acción Actor:

1. El Gerente de producto

crea el cliente en el sistema

seleccionando el tipo de

cliente (Organización o

persona natural)

2. El administrador del módulo

completa la información en

el fichero del cliente

configurando y asignando

las direcciones y datos

demográficos del cliente.

3. Tanto el gerente de

producto como el


vinculan la información de

contacto del cliente.

4. El administrador del módulo

configura los valores

predeterminados de pagos.

Sistema:

5. El sistema registra en la

base de datos y presenta

en la interfaz el cliente

creado.

6. El sistema

automáticamente deja

predeterminado al cliente

con información fiscal,

datos de ubicación para la

guía de remisión, así

también para las formas

de pagos y

Post condición:

Información y configuración del cliente almacenada en las tablas

maestras de la base de datos.


Metodología 40

Administrador del módulo de ventas

Configurar grupos de clientes

Configurar tipo de pagos multivencimientos

Configurar motivosde devolución

Crear Motivos de Aceptación y rechazo para una Cotización

Código de motivos

<<include>>

<<include>>

Caso de uso configuraciones generales para la venta

DIAGRAMA N° 4

DIAGRAMA DE CASO DE USO CONFIGURACIONES

GENERALES DE VENTAS


CUADRO N° 7

CONFIGURACIONES GENERALES PARA LA VENTA

Código: AX002 Nombre: Configuraciones

generales para la venta

Actores: Administrador del módulo de ventas Fecha:

28/01/2016

Descripción:

Proceso previo a la venta en que se realiza sobre el fichero del

cliente.

Precondición:


Metodología 41

1. El cliente debe estar creado en el sistema.

2. El cliente debe tener configurados los valores predeterminados

del pago.

3. Haber registrado grupos de clientes en la interfaz maestra.

Flujo de eventos:

Acción Actor:

1. Se configura el grupo de

clientes en el fichero de

clientes.

2. Se establecen los pagos

multivencimientos en el

fichero de clientes.

4. Se crea los códigos de razón

genérica para las

devoluciones en caso de

notas de crédito.

6. En los parámetros del

módulo de ventas se

configura los motivos de

aceptación y rechazo de las

cotizaciones que emita el

cliente para la gestión interna

que realizan los usuarios.

Sistema:

3. El sistema calendariza

automáticamente los plazos

en la cartera del cliente.

5. Para futuros casos el

sistema asignará

automáticamente la razón de

devolución en las notas de

crédito que el cliente desea

emitir.

Postcondición:

Las configuraciones en el fichero de clientes se verán reflejadas en la

facturación.


Metodología 42


Categorizar la maestra de clientes en los diferentes grupos

Crear grupos descuento de clientes

Definir porcentaje de descuento para grupos

de descuento

Gerente de producto

Editar o descontinuar acuerdos comerciales

vigentes

Caso de uso para Acuerdos comerciales

DIAGRAMA N° 5

DIAGRAMA DE CASO DE USO DE ACUERDOS COMERCIALES


CUADRO N° 8

ACUERDOS COMERCIALES

Código: AX003 Nombre: Acuerdos comerciales

Actores: Administrador del módulo de

ventas, gerente de producto.

Fecha:

28/01/2016

Descripción:

Establecer descuentos definidos mediante el uso de acuerdos

comerciales.

Precondición:


1. El cliente debe estar creado en el sistema.

Metodología 43

2. Los clientes deben estar asignados a un grupo.

Flujo de eventos:

Acción Actor:

1. El administrador del

módulo asigna grupos a

los diferentes clientes.

2. Se configuran los grupos

de descuento que

servirán para la

vinculación del acuerdo

comercial con el grupo

de clientes.

3. Se crea un diario de

acuerdo comercial

estableciendo

porcentajes de

descuentos para cada

grupo de clientes con

fechas de vigencia.

4. El Gerente de producto

puede editar la vigencia y

porcentaje del descuento

comercial cuando estime

conveniente de acuerdo

a la situación económica

actual del país.

Sistema:

5. El sistema aplicará los

descuentos establecidos en

el acuerdo comercial

automáticamente durante la

facturación si coinciden entre

el grupo de clientes.

6. Los cambios que se hagan

sobre los acuerdos

comerciales, el sistema

internamente crea un nuevo

diario de lote registrando la

auditoria de su edición.

Postcondición:

La orden de venta no permitirá la asignación manual de

descuentos.


Metodología 44

3.6. Prototipo

3.6.1 Interfaz de configuración de Grupo de descuentos

Teniendo en cuenta que se va a realizar una mejora al ERP

Dynamics AX se presentan las interfaces principales con las que va a

interactuar el usuario en el nuevo proceso.

Ruta: Ventas y Marketing Configurar Descuento en precio.

GRÁFICO N° 16

INTERFAZ DE ACUERDOS COMERCIALES


Metodología 45

Interfaz de configuración Flujo de ventas

Esta interfaz va a permitir la asignación de los usuarios

aprobadores en el flujo.

GRÁFICO N° 17

INTERFAZ DE CONFIGURACIÓN DEL FLUJO DE VENTAS


Cabe indicar que esta configuración estará en el módulo de Ventas

y Marketing Configurar parámetros del flujo de trabajo de ventas y

marketing.

Metodología 46

Interfaz de notificaciones del Flujo de ventas

GRÁFICO N° 18

INTERFAZ DE NOTIFICACIONES DEL FLUJO DE VENTAS


3.7 Diagrama de actividades

El diagrama de actividades muestra el flujo de las tareas desde el

punto de inicio hasta el punto final detallando las rutas de decisiones que

existen en el progreso de eventos contenidos en la actividad.

Todas estas actividades o acciones mostrarán la secuencia entre la

interfaz del sistema y el usuario final.

Metodología 47

Diagrama de actividades del caso de uso AX001 correspondiente al

registro de clientes

DIAGRAMA N° 6

DIAGRAMA DE ACTIVIDAD REGISTRO DE CLIENTES

Usuario Sistema

Fuente: Análisis de requerimientos Elaborado por: Tomalá García Edgar Jesús

Inicio

Crea el cliente especificando su tipo

Completar registro con datos demográficos y libreta de direcciones

Se presenta la interfaz con toda la

información.

Vincular información de contacto al

cliente

Configurar valores predeterminados de

pago Verificar parámetros de condiciones de pago y formas de

pago

Predeterminar las configuraciones en

cada transacción del cliente

Configuración manual en formulario

de transacciones

Correcto

Incorrecto

Metodología 48

Diagrama de actividades del caso de uso AX002 correspondiente a

configuraciones generales de ventas

DIAGRAMA N° 7

DIAGRAMA DE ACTIVIDAD CONFIGURACIONES

GENERALES DE VENTAS

Usuario Sistema


Inicio

Configurar grupo de clientes

Configurar multivencimientos

Crear códigos de razón para notas de

crédito

Configurar valores predeterminados de

pago

Configurar motivos de aceptación y

rechazo de cotizaciones de

venta

Calendarizar los plazos

automáticamente

Metodología 49

Diagrama de actividades del caso de uso AX003 correspondiente a

acuerdos comerciales.

DIAGRAMA N° 8

DIAGRAMA DE ACTIVIDAD ACUERDOS COMERCIALES

Usuario Sistema


Inicio

Asignación de grupos a clientes

Configurar grupos de descuentos

Configurar diarios de acuerdos

comerciales vigentes

Editar acuerdos comerciales por

parte de gerente de producto

Establecer descuentos

automáticos según acuerdo comercial

vigente

Ediciones de acuerdos

comerciales se graban en un nuevo

lote

CAPÍTULO IV

PROPUESTA

4.1. Tema de la propuesta

Modelamiento del flujo de ventas en el ERP Dynamics AX para la

empresa MAINT S.A.

4.2. Objetivos

Proponer un diseño técnico sobre el flujo de ventas y desarrollar la

funcionalidad en el sistema actual con los parámetros y controles que la

empresa requiere.

4.3. Entorno del Software

4.3.1. Arquitectura

Se propone trabajar sobre la arquitectura Cliente-Servidor, misma

sobre el cual está soportado el ERP Dynamics AX, desarrollando bajo la

capa VAR.

A continuación se observa el gráfico N° 19 acerca de la

arquitectura Dynamics Ax.

Propuesta 51

GRÁFICO N° 19

ARQUITECTURA DYNAMICS AX

Fuente: Desarrollo en Microsoft Dynamics Ax 2012 Elaborado por: Tomalá García Edgar Jesús

4.3.2. Capas de desarrollo

Las capas de desarrollo en Dynamics AX son una jerarquía de

niveles en la aplicación que se puede utilizar para realizar modificaciones

a elementos estándares o adicionales del ERP, sin interferir o eliminar

elementos de una capa superior; lo que significa que al compilar la

personalización de los cambios se verán reflejados sin alterar el

funcionamiento estándar protegido en una capa superior que es la del

fabricante.

Las capas que van a ser visibles durante el desarrollo y la

implementación del flujo de ventas en el ERP Dynamics AX son las

siguientes:

Propuesta 52

CUADRO N° 9

CAPAS DE DESARROLLO

Capa Propietario Licencia Adicional

SYS Fabricante (Microsoft) N/A

SYP Fabricante (Microsoft) N/A

VAR Partner (MAINT S.A.) Sí

VAP Partner (MAINT S.A.) Sí

USR Usuario final(Responsable) No

USP Usuario final (Responsable) No

Fuente: Desarrollo en Microsoft Dynamics Ax 2012 Elaborado por: Tomalá García Edgar Jesús

GRÁFICO N° 20

PRESENTACIÓN DEL NIVEL DE JERARQUÍA DE LAS CAPAS

Fuente: http://www.dynamicfit.com.au/ Elaborado por: Tomalá García Edgar Jesús

4.4. Diagrama de clases

Los diagramas de clases son una estructura estática del modelo de

datos en el cual se detallan todos los objetos encapsulados e

interrelacionados, también se usa para generar una estructura base del

código en el lenguaje escogido, información de estados y actividad que

pueden ofrecer detalles de parte procedimental del código de

implementación.

http://www.dynamicfit.com.au/

Propuesta 53

Rut

inaW

ork

flow

-Cre

arW

ork

flo

w-C

arga

rWo

rkfl

ow

-In

voca

rSe

rvic

io-I

nvo

carW

ork

flo

w-I

nic

iarR

uti

na

-De

ten

erR

uti

na

+Ab

ort

ar()

+Co

mp

leta

r()

+Cre

ar(

)+C

arga

r()

+In

icia

r()

Res

pons

able

Ven

tas

-Id

PM

-No

mb

resP

M

Gru

poCl

ient

es

-Id

Gru

po

-No

mb

reG

rup

o

Tien

e

Clie

ntes

-Id

Cli

ente

-No

mb

reC

lien

te-D

ire

cció

n-D

ato

sDem

ogr

áfic

os

-Co

nd

icio

ne

sPag

o

+Co

nsu

ltar

()

Form

ad

a p

or

Ord

en d

e V

enta

(Cab

ecer

a)

-Id

OV

-Co

nfi

gu

raci

on

esC

ab

ece

ra-F

orm

aP

ago

-Co

nd

icio

ne

sEn

tre

ga-F

ech

aEn

tre

ga

+In

voca

rDa

tosC

lien

te()

+In

voca

rAcu

erd

osC

om

erci

ale

s()

Ord

en d

e V

enta

(D

etal

le)

-Ite

mId

-No

mb

reIt

em

-Pre

cio

-Can

tid

ad-P

orc

en

taje

Des

cue

nto

-To

talL

ine

a

#In

voca

rDa

tosC

abe

cera

()-C

on

sult

arIn

form

acio

nSe

rvic

ios(

)+V

alid

arA

cue

rdo

sCo

mer

cial

es(

)

Tien

e

0..*

Agr

ega

Acu

erdo

s Co

mer

cial

es

-Id

Acu

erd

oC

om

erci

al-N

um

ero

Dia

rio

-Po

rce

nta

jeD

escu

en

tos(

)#R

an

gos(

)-+

ech

aV

igen

cia(

)-+

esc

ue

nto

Mu

ltili

nea

()

Esta

ble

ce

Con

tien

e

1

*

1

0..*

1

1

*

1 0..*

0..*

Wo

rkflo

wD

ocum

ent

+In

voca

rCo

nsu

lta(

)#I

nvo

carN

om

bre

()+A

dm

inis

trar

Esta

do

s()

Wo

rkflo

wEv

entH

andl

er

+Ap

rob

ar(

)+R

ech

aza

r()

+Co

mp

leta

r()

+Re

en

viar

()

Usu

ario

-Id

Usu

ari

o-N

om

bre

Usu

ari

o

+val

idar

Car

go()

Se propone el siguiente diagrama de clases donde se detallan

todos los objetos que van a conformar el desarrollo del flujo de ventas.

DIAGRAMA N° 9

DIAGRAMA DE CLASES

Fuente: Propuesta de diseño técnico


Propuesta 54

4.5. Modelo Entidad Relación

En el presente modelo entidad relación se propone definir las

tablas a utilizar con sus respectivas relaciones y claves primarias

adicionando las nuevas entidades que van a formar parte del desarrollo e

implementación del flujo de ventas, siguiendo el mismo estándar sugerido

por el fabricante del ERP, usando nombres descriptivos en el idioma

inglés.

DIAGRAMA N° 10

DIAGRAMA MODELO ENTIDAD RELACIÓN

Propuesta 55

Fuente: Propuesta de diseño técnico Elaborado por: Tomalá García Edgar Jesús

Propuesta 56

4.6. Diccionario de la Base de datos

CUADRO N° 10

CUADRO DICCIONARIO DE BASE DE DATOS

Tabla Descripción

CustGroup Tabla cabecera que me va a almacenar los grupos

de clientes.

CustTable Tabla que va a contener toda la información maestra

de todos los clientes de la compañía

PaymTerm

Esta tabla va a contener las configuraciones de las

condiciones de pago que se van a considerar en la

orden de ventas antes de su facturación.

DLVTerm

En esta tabla se registran las condiciones de entrega

que van atada a la orden de venta y será tomada en

cuenta al momento de generar la guía de remisión,

si se diera el caso.

SalesTable

En esta tabla se va a guardar la información

concerniente a la cabecera de la orden de venta

atada a sus diferentes configuraciones.

SalesLine

Tabla que va a registrar las líneas de la orden venta

trayendo consigo la información de productos y/o

servicios a vender.

InventTable Maestra de productos y/o servicios disponibles para

la venta.

InvenTableModule

Tabla de configuración para los productos que

tengan movimientos de módulos diferentes al de

ventas.

HCMWorker

Tabla que contiene la información de los empleados

de la compañía con sus respectivos cargos,

importante para las asignaciones en el flujo.

SysEmailTable Tabla de configuración para el servicio de correo

electrónico, que servirá en las notificaciones.

WorkflowParameters Tabla de parámetros del flujo para las notificaciones

WorkflowTable Tabla transaccional que contiene los datos de los

flujos activados.

WorkflowAssociation

En esta tabla se registra la relación de los

flujos activos con las órdenes de venta

DataArea

Tabla información de la compañía activa en el ERP.


Propuesta 57

4.7. Lenguaje de programación

X++ es el lenguaje de programación propio del ERP Dynamics AX

debido a que el desarrollo y modificación del software se realiza mediante

su propio entorno de desarrollo integrado bajo el IDE Morph X.

El entorno de desarrollo permanece en la misma aplicación del

cliente, permitiendo de esta forma tener acceso a dichas herramientas

desde la aplicación del usuario final, el lenguaje x++ es similar a C++ o

Java.

El lenguaje X++ está orientado a objetos, e incluye sentencias SQL

y características específicas para construir complejos sistemas de gestión

contable y de negocio.

Se accede al complejo sistemas de clases de Microsoft Dynamics

AX, que proporcionan funcionalidad desde la transferencia de

información, entradas y salidas básicas, o la modificación de controles en

tiempo de ejecución. La funcionalidad de estas clases es extensible.

X++ proporciona una extensiva comprobación en tiempo de

compilación, seguida de una segunda comprobación en tiempo de

ejecución. También existe un recolector de basura, que funciona

automáticamente en cuanto un objeto deja de estar referenciado.

4.7.1 Diagramas de secuencia

Un diagrama de secuencia muestra una interacción, que

representa la secuencia de mensajes entre las instancias de clases,

componentes, subsistemas o actores. La interacción de mensaje que

existe en el diagrama de secuencia la conforman dos actores que son el

sistema y el usuario.

Propuesta 58

RE

SP

ON

SA

BLE

DE

V

EN

TA

S

Gru

po

de

cli

en

tes

y

art

ícu

los

Inte

rfa

z d

e

acu

erd

o

co

me

rcia

l

En

tid

ad

Pre

cio

y

de

scu

en

to

Ing

resa

co

mb

ina

cio

ne

s

de

de

scu

en

tos

Ing

reso

de

la

tr

an

sacci

ón

Acti

va

un

a

cue

rdo

co

me

rcia

l

Se

vin

cu

lan

lo

s d

escu

en

tos

co

n

la f

actu

ració

n

Mo

stra

r a

cue

rdo

s co

me

rcia

les

vig

en

tes

DIAGRAMA N° 11

DIAGRAMA DE SECUENCIA ACUERDO COMERCIAL


Propuesta 59

SistemaOficial de Crédito

1: TransaccionesAbiertas()

2: IngresaPeriodo()

3: CupoDisponible()

4: SolicitaAumentoCupo()

5: IngresaMontoCrédito()

7: ApruebaAumento()

9: ProcesarConsulta()

6: RegistraMonto()

10: EjecutaConsulta()

11: ImprimeReporte()

12: ResultadosConsulta()

DIAGRAMA N° 12

DIAGRAMA DE SECUENCIA TRANSACCIONES DE CLIENTE



Propuesta 60

4.8. Infraestructura del Flujo de trabajo

Fundamentalmente, un flujo de trabajo consiste en una o más de

las actividades que representan los elementos de trabajo a realizar.

Además, el concepto de los flujos de trabajo que se conectan las

actividades y gobiernan la secuencia de ejecución (referido como la

estructura de un flujo de trabajo) es la clave. El comportamiento de un

flujo de trabajo está determinada por su tipo.

GRÁFICO N° 21

ESTRUCTURA DE TIPOS DE FLUJO DE TRABAJO


La tecnología a utilizar en esta implementación soporta tanto los flujos

de trabajo humanos y los flujos de trabajado de sistema.

Propuesta 61

4.8.1. Windows Workflow Foundation

Para el desarrollo e implementación del flujo de ventas se propone

la siguiente infraestructura de flujo de trabajo en Dynamics AX que está

relacionado con Windows Workflow Foundation (WF), que es parte del

Microsoft .NET Framework 4. WF proporciona muchas capacidades

fundamentales que son utilizados por la infraestructura de flujo de trabajo

en Dynamics AX, sin embargo, WF no tiene conciencia directa de la

integración con Dynamics AX.

En la gráfico 34, la infraestructura de flujo de trabajo (A) es una

capa de abstracción que se encuentra por encima de WF (B) y permite

flujos de trabajo que son específicos a Dynamics AX que ser diseñado,

implementado y configurado en Dynamics AX y luego ejecutado mediante

el uso de WF.

GRÁFICO N° 22

RELACIÓN ENTRE LA INFRAESTRUCTURA DE FLUJO DE

TRABAJO DYNAMICS AX Y WINDOWS WORKFLOW FOUNDATION



Propuesta 62

4.8.2. Diagrama de Flujo de aprobación de descuentos

Teniendo en cuenta los resultados de la encuesta número 6 sobre

los límites de descuento y el número 4 sobre el reingreso del flujo se

propone el siguiente esquema para la aprobación de los descuentos.

DIAGRAMA N° 13

DIAGRAMA DE FLUJO DE APROBACIÓN DE DESCUENTOS


Dar click en botón “C

ancelar”, se

actu

aliz

arán

los

esta

dos:

Estado Com

ercial “A

nulado”

Estado Crédito “A

nulado”

Inic

io

¿Ofre

ció

desc

uent

o gere

ncia

l

Esta

do C

omer

cial

=

“Autom

ático”

N O

Esta

do C

omer

cial

=

“Autorizar

Descuento”

SI

Acci

ón

= Apro

bar

- Ac

cion

es: A

prob

ar, R

echa

zar,

Can

cela

r. -

Botó

n: C

ance

lar

- S

e debe habilitar el Botón “Grabar”

(Per

sona

lizad

o), t

endr

á la

func

ión

de

reca

lcul

ar d

escu

ento

s y

calc

ular

el B

O

Esta

do C

omer

cial

=

“Aprobado”

SI

N O

Acci

ón

= Can

cela

SI

N O

Acci

ón

= Rec

haz

Esta

do C

omer

cial

=

“Revisión Descuento”

SI

-Acc

ión:

Rea

ctiv

ar

-Env

ía c

orre

o de

man

era

auto

mát

ico

- S

e de

be

habilitar el Bo

tón “Grabar”

(Per

sona

lizad

o), t

endr

á la

func

ión

de re

calc

ular

des

cuen

tos

y

Acci

ón

= Rea

ctiv

-Se

debe

tene

r pre

sent

e, q

ue s

i el

usuario “X

XX”, mando a rechazar la

OV,

al m

omen

to d

e re

activ

arlo

y p

asar

a estado “A

utorizar descuento”, el

será

el ú

nico

qui

en p

odrá

ver

las

acciones y un “Súper usuario”.

SI

N O

Fin

Propuesta 63

In

icio

¿For

ma

de P

ago

Cred

ito?

Pago

en

efec

tivo:

de

smar

cado

Clie

nte

rela

ciona

do

Cond

ición

:-

Conj

unto

de

Cl

ient

e =

Rel

acio

nado

.- P

ago

en e

fect

ivo m

arca

do

Cupo

Dis

poni

ble

Cond

ición

:

Valo

r de

la O

rden

de

Vent

a

Fact

uras

sin

resp

aldo

.

Cond

ición

:Fe

cha

venc

imie

nto

8 dí

asSa

ldo

$ 10

0

Cheq

ues

prot

esta

dos

Cond

ición

:- R

espa

ldad

o

$ 0

- No

Resp

alda

do

$ 0

Not

a de

Deb

ito

Cond

ición

:Sa

ldo

> $0

Fe

cha

venc

imie

nto

> 0

Cheq

ue p

oste

rgad

o

Cond

ición

:

0

Cond

ició

n de

pa

go d

e la

OV

= Fi

cher

o de

l cl

ient

e

Fact

uras

sin

resp

aldo

.

Cond

ición

:

60 d

ías

$

100

Bloq

ueo

de cl

ient

e

Cond

ición

:- M

otiv

o de

Cie

rre:

Blo

quea

do- M

otiv

o de

Can

cela

ción

: Blo

quea

do

SiNo

Esta

do C

redi

to:

Cont

ado

Esta

do C

rédi

to:

Auto

mát

icoEs

tado

de

Créd

ito:

Rech

azad

o¿C

umpl

e co

n va

lidac

ione

s?N

OSI

Even

to o

Acc

ión:

Apr

obad

o

Acci

ón A

utom

átic

a

Esta

do C

omer

cial:

Apro

bado

o

Auto

mát

ico

Even

tos

o Ac

cione

s:- A

prob

ado

- Neg

ar- A

nula

r- R

evisa

r en

fact

urac

ión

APRO

BACI

ÓN

MAN

UAL

Even

tos

o Ac

cione

s:- A

prob

ado

- Neg

ar- A

nula

r- R

evisa

r en

fact

urac

ión

B

Even

to o

Acc

ión:

Neg

ar

Even

to o

Acc

ión:

Anu

lar

Even

to o

Acc

ión:

Rev

isar e

n fa

ctur

ació

n

Esta

do d

e Cr

édito

: Apr

obad

o

Esta

do d

e Cr

édito

: Neg

ado

Esta

do d

e Cr

édito

: Ca

ncel

ado

Esta

do d

e Cr

édito

: Rev

isar

en fa

ctur

ació

n

4.8.3. Diagrama de actividad validación de crédito

Teniendo en cuenta los resultados de la encuesta número 6 sobre

los límites de descuento y el número 4 sobre el reingreso del flujo se

propone el siguiente esquema para la aprobación de los descuentos.

DIAGRAMA N° 14

DIAGRAMA DE ACTIVIDAD VALIDACIÓN DE CRÉDITO

Fuente: Investigación de campo


Propuesta 64

4.8.4. Dimensionamiento de Hardware

Para la implementación del flujo de ventas se requiere reforzar el

hardware actual para soportar y garantizar el funcionamiento eficiente del

proceso.

Dynamics AX 2012 se compone de diferentes componentes y

extensiones que se asocian a las siguientes herramientas:

Controlador de Dominio.

Conexión a Base de Datos

Extensiones de SQL Server Reporting Services (Reportes Dynamics

AX)

Extensiones de SQL Server Analysis Services (Cubos de Información)

Se recomienda separar los diferentes motores que se asocian a la

aplicación en diferentes servidores para optimizar el rendimiento de la

misma garantizando efectividad y seguridad en los datos y

configuraciones.

Propósito

El propósito del dimensionamiento es asegurarnos que la solución

será implementada de una manera soportada y usable de acuerdo a los

lineamientos de infraestructura y expectativas del negocio de MAINT S.A.

4.8.4.1. Requerimientos de red

Microsoft Dynamics AX 2012 puede operar en redes que utilizan

Protocolo de Internet versión 4(IPv4) o Protocolo de Internet versión 6

(IPv6).

Propuesta 65

Importante

Se recomienda que en todos los servidores se configuren el Protocolo

de Internet versión 4 (IPv4), configurar la red con IP fija (no

recomendable con DHCP).

Tiempo de respuesta de red

En la siguiente tabla se enumeran los requisitos mínimos de la red

para la conexión entre el cliente y el servidor de objetos de aplicación

(AOS) y la conexión entre la AOS y la base de datos en un sistema

Dynamics AX:

CUADRO N° 11

TIEMPO DE RESPUESTA DE RED

Valor Cliente AOS AOS a Base de Datos

Banda Ancha. 100 megabits por segundo

(Mbps) o superior.

100 Mbps o superior.


4.8.4.2. Requerimientos de dominio

Tenga en cuenta los siguientes requisitos de dominio al instalar

Microsoft Dynamics AX:

Los servidores de Base de datos, motores de Reporting Services,

Analysis Services, SharePoint, servidor de Dynamics AX 2012 (AOS),

y Clientes AX deben pertenecer a un dominio de Active Directory, y el

servidor de Active Directory debe estar configurado en modo nativo.

Los equipos que ejecutan los componentes de Microsoft Dynamics AX

deben tener acceso a otros equipos de Active Directory. Estos equipos

Propuesta 66

pueden ser ya sea en el mismo dominio o en otro dominio de

confianza.

El controlador de dominio se debe ejecutar en el modo de Windows

2008 o superior.

Para apoyar a las alertas de correo electrónico en Microsoft Dynamics

AX, un servidor SMTP (Simple Mail Transfer Protocol) debe estar

presente en el medio ambiente.

4.8.4.3. Dimensionamiento de hardware servidor base de datos

Servidor de Base de Datos

Motor: Microsoft SQL Server 2008 R2, Standard Edition, x64 SP1 o

superior. El servidor de Base de Datos alojará las bases de datos que

genere Microsoft Dynamics AX 2012 (Pruebas / Producción), también la

base de datos que genere el motor de Reporting Services y el motor de

SharePoint.

Para ello en el servidor se deben crear 3 instancias de bases de

datos para el siguiente detalle:

Nombreserver\axpruebas (BD del ambiente AX pruebas y BD de

Reporting Services pruebas)

Nombreserver\axproduccion (BD del ambiente AX producción y BD

de Reporting Services producción)

CUADRO N° 12

SERVIDOR DE BASE DE DATOS DE AX

Servidor de Base de Datos de AX

Procesador

Recomendado: Arquitectura SIX-CORE x64 architecture 2.9 GHz CPU o superior como Intel Opteron o Intel Xeon systems.

Memoria Recomendado: 32-GB RAM o más

Propuesta 67

Disco

RAID 1 hard disk array (la configuración de arreglos de disco depende del nivel de transacciones que operen los usuario)

Disco: 1 TB o superior

El disco debe estar particionado en 3 unidades:

o Unidad C 200 GB (Archivos de la aplicación)

o Unidad D 600 GB (Data)

o Unidad E 200 GB (Logs y Temporales)

Monitor Configuración de paleta de color al menos 256 colores (recomendado 32,000 colores).

Sistema Operativo

Windows Server 2008 R2 SP1 Standard Edition o superior

Requisitos de las Cuentas de los Servicios del Software Principal

SQL word breakers

Debe ser iniciado y automático

Servicio con Cuenta de dominio, puede correr igualmente con NETWORK SERVICE o LOCAL SYSTEM.

SQL Server Agent service



SQL Server Full Text Indexing

Debe ser iniciado y automático.


Cuenta del servicio de SQL Server


Cuenta debe ser: Cuenta del usuario en el dominio.

O Network Service Account

Nota: AX fallará si esta cuenta es el administrador local o una cuenta de usuario local.

Servicio SQL Server Reporting Service y Analysis Service

Debe ser iniciado y automático.


RED

Protocolo TCP/IP

Puertos Si el firewall se encuentra activo, abrir los puertos 1433, 1434

Nota AX y SQL Server deben estar en la misma LAN.

Lenguaje

Lenguaje de instalación del SQL 2008

Español

Instancias

Propuesta 68


4.8.4.4. Dimensionamiento de hardware servidor dynamics ax

Servidor Dynamics AX – AOS PRUEBAS

Si es posible crear ambientes virtuales para Microsoft Dynamics AX

2012 pruebas.

CUADRO N° 13

SERVIDOR DYNAMICS AX 2012- AOS (A)

Nombre de la

instancia

AX Server Setup acepta la instancia por default o una instancia con nombre. NOMBRESERVER\AXPRUEBAS NOMBRESERVER\AXPRODUCCION NOMBRESERVER\AXSHAREPOINT

Número de BD en la Instancia

3

Bases de Datos

Bases de

Datos que se crearán

MicrosoftDynamicsAX

MicrosoftDynamicsAXBaseLine

MicrosftDynamicsAX_model

ReportServer

ReportServerTempdb

Data Files Unidad D

Log Files Unidad E

Modo de Virtualización

Este servidor es

virtualizado?

NO SE RECOMIENDA VIRTUALIZAR BASE DE DATOS

Modo de Acceso

Autenticación Mixed-mode. El usado por AX es Windows Authentication.

Modo remoto?

SI

Servidor Dynamics AX 2012 - AOS

Procesadores

Recomendado: Arquitectura SIX-CORE x64 2.9 GHz CPU o superior

Memoria Recomendado: 12 GB o más.

Propuesta 69

Disco Recomendado: 300 GB o más


Sistema Operativo

Windows Server 2008 R2 (x64 versions) SP1 o Superior

Software Requisito

Servidor Web IIS 7.0 o superior en modo Nativo. Si no está instalado, el AX Server Setup lo instalará.

Navegador Web Internet Explorer 8 o superior

Internet Explorer 9 o superior

Otros servicios

Indexing Service: Para instalar este servicio, ver la documentación Windows Server.(Como un servicio del File Services Role)

IIS Admin

Microsoft .NET Framework 4

Windows Installer 3.1

Microsoft ADOMD.NET

Windows SDK for W2k8 y .net framework

Analysis Services AMO

MS WINDOWS 2008 SOFTWARE DEVELOPMENT KIT

VISUAL STUDIO ISOLATED MODE

Software Principal

Software Microsoft Dynamics AX 2012 R2


Microsoft Dynamics AX Object Server

Service

Las cuentas de los servicios de AOS de AX son usuarios del dominio con las características: clave no caduca, Cuenta para servicio dedicado, Minimo acceso a los recursos de red. Sugerido: Adm_Aos: Usuario miembro de las cuentas del dominio o cuentas de servicio de red, este usuario se debe colocar al momento de instalar el AOS del AX, dicho servicio permite conectar la BD con la aplicación AX “Dynamics AX Object Server” La base de datos debe estar previamente creada Se instalará Reporting Services para lo cual se requiere crear la URL para accesar al web site asociado. Cuenta: Business Connector Proxy, No debe ser un usuario de AX. Cuenta usada para la instalación y configuración del Reporting Services, Workflow, Portal y Rol Centers. Sugerido: uadm_bcproxy Para el servicio de WorkFlow, se puede usar un usuario del dominio o un usuario de AX, permitirá la conexión entre workflow y AX. Sugerido: uadm_wrkf

Propuesta 70


4.8.4.5. Servidor Dynamics AX – AOS PRODUCCIÓN

Si es posible crear ambientes virtuales para Microsoft Dynamics AX

2012 producción.

CUADRO N° 14

SERVIDOR DYNAMICS AX 2012-AOS (B)

RED

Protocolo TCP/IP (IPv4) Configurar IP FIJA

Puertos Si el firewall está levantado, abrir el puerto 2712 o superior de acuerdo a las instancias creadas.


Lenguaje

Moneda USD.

MS OFFICE Instalar el Office 2007 SP2 o Office 2010. Se recomienda instalarlo en el Server para poder ver reports exportados a Excel


Este servidor es virtualizado?

Si se acepta la virtualización

Virtualización Solo es soportado por Hyper-V si se desea instalar AX en una ambiente virtual.

Servidor Dynamics AX 2012 - AOS

Procesadores

Recomendado: Arquitectura SIX-CORE x64 2.9 GHz CPU o superior




Sistema Operativo

Windows Server 2008 R2 (x64 versions) SP1 o Superior

Tipo de Instalación SO

SO modo gráfico el Win 2k8 instalado como “Server Core” no es soportado para AX 2012.

Software Requisito

Servidor Web IIS 7.0 o superior en modo Nativo. Si no está instalado, el AX Server Setup lo instalará.

Navegador Web Internet Explorer 8 o superior

Internet Explorer 9 o superior

Propuesta 71

Otros servicios

Indexing Service: Para instalar este servicio, ver la documentación Windows Server.(Como un servicio del File Services Role)

IIS Admin

Microsoft .NET Framework 4

Windows Installer 3.1

Microsoft ADOMD.NET

Windows SDK for W2k8 y .net framework

Analysis Services AMO

MS WINDOWS 2008 SOFTWARE DEVELOPMENT KIT

VISUAL STUDIO ISOLATED MODE

Software Principal

Software Microsoft Dynamics AX 2012 R2


Microsoft Dynamics AX Object Server Service

Las cuentas de los servicios de AOS de AX son usuarios del dominio con las características: clave no caduca, Cuenta para servicio dedicado, Minimo acceso a los recursos de red. Sugerido: Adm_Aos: Usuario miembro de las cuentas del dominio o cuentas de servicio de red, este usuario se debe colocar al momento de instalar el AOS del AX, dicho servicio permite conectar la BD con la aplicación AX “Dynamics AX Object Server”

La base de datos debe estar previamente creada

Se instalará Reporting Services para lo cual se requiere crear la URL para accesar al web site asociado. Cuenta: Business Connector Proxy, No debe ser un usuario de AX. Cuenta usada para la instalación y configuración del Reporting Services, Workflow, Portal y Rol Centers. Sugerido: uadm_bcproxy Para el servicio de WorkFlow, se puede usar un usuario del dominio o un usuario de AX, permitirá la conexión entre workflow y AX. Sugerido: uadm_wrkf

RED


Puertos Si el firewall está levantado, abrir el puerto 2712 o superior de acuerdo a las instancias creadas.


Lenguaje

Moneda USD.

MS OFFICE Instalar el Office 2007 SP2 o Office 2010. Se recomienda instalarlo en el

Propuesta 72


4.8.4.6. Dimensionamiento de hardware motores SSRS, SSAS

En éste servidor se van a alojar los motores de SQL Server

Reporting Services dividido en 2 instancias:

Nombreserver\ssrspruebas

Nombreserver\ssrsproduccion

Los motores de SQL Server Analysis Services y SharePoint son

exclusivamente para la instalación y configuración de Rol Center y

Enterprise Portal que se implementarán en el servidor de producción.

Nota: Si es posible crear ambientes virtuales para los motores

adicionales con el que interactúa el AX.

CUADRO N° 15

SSR, SSAS

Server para poder ver reports exportados a Excel




Virtualización

Solo es soportado por Hyper-V si se desea instalar AX en una ambiente virtual.

SSRS, SSAS

Procesadores

Mínimo: Arquitectura x64 bits architecture o compatible DUAL-CORE 2.9 GHz processor

Recomendado: Arquitectura Quad-CORE x64 2.9 GHz CPU o superior




Sistema Windows Server 2008 R2 (x64 versions) SP1 o Superior

Propuesta 73


4.8.4.7. Características de hardware estaciones clientes

En éste servidor se van a alojar los motores de SQL Server

Reporting Services dividido en 2 instancias:

CUADRO N° 16

ESTACIONES CLIENTES

Operativo

Software Principal a Instalar

Software

SQL SERVER REPORTING SERVICES 2008 R2 STANDARD EDITION

SQL SERVER ANALYSIS SERVICES 2008 R2 STANDARD EDITION

SHAREPOINT FOUNDATION (Gratis) o SHAREDPOINT STANDARD EDITION (con licencia).


RED


Puertos Si el firewall está levantado, abrir el puerto 2712 o

superior de acuerdo a las instancias creadas.




Virtualización Solo es soportado por Hyper-V si se desea instalar AX en una

ambiente virtual.

ESTACIONES CLIENTES

Procesadores

Mínimo: Arquitectura x64 bits architecture o compatible dual-CORE 2.9 GHz processor

Recomendado: Arquitectura CORE i 3 x64 2.9 GHz CPU o superior

Memoria

Mínimo: 3 GB o más (depende de la cantidad de otras aplicaciones que utilice el cliente)

Recomendado: 4 GB o más (depende de la cantidad de otras aplicaciones que utilice el cliente)

Disco

Recomendado: 80 GB o más

Propuesta 74

Data Base AOS

Cliente

SSRS / MMR

SSAS y Sharepoint

Terminal Service(Opcional)

Dev/Test

Cliente Cliente Cliente

CONTROLADOR DE DOMINIO


GRÁFICO N° 23

ARQUITECTURA DE DIMENSIONAMIENTO


Monitor

Configuración de paleta de color al menos 256 colores (recomendado 32,000 colores).

Sistema Operativo

Windows 7 (x64 versions) SP1 o superior.

Software Principal a Instalar

Software

Microsoft Dynamics Ax 2012 Cliente


RED

Protocolo

TCP/IP (IPv4) Configurar IP FIJA

Puertos

Si el firewall está levantado, abrir el puerto 2712 o superior de acuerdo a las instancias creadas.

Propuesta 75

4.8.4.8. Resumen de licencias

CUADRO N° 17

SERVIDOR BASE DE DATOS (FÍSICO)

# Ítem

1 Microsoft SQL Server 2008 R2 Standard Edition

1 Windows Server 2008 R2 Standard Edition Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús

Servidores ax pruebas, producción, motores (virtuales)

Para mejor administración de los recursos en los ambientes

virtuales se recomienda para el HOST el sistema operativo Windows

Server 2012 (hyper-v).

CUADRO N° 18

SERVIDORES AX PRUEBAS, PRODUCCIÓN, MOTORES VIRTUALES

# Ítem DETALLE

1 Windows Server 2012 Standard Edition

HOST

2 Windows Server 2008 R2 AX Pruebas, AX Producción, Motores SSRS-SSAS-SharePoint

10 Enterprise User CAL

Usuario Nombrado

10 Funcional User CAL Usuario Nombrado


4.8.5. Estructura del equipo de proyecto

Todo proceso de implementación requiere la conformación de un

equipo de trabajo con diferentes responsabilidades delegadas según de

acuerdo a sus funciones. Se propone la siguiente estructura:

Propuesta 76

Equipo funcional Equipo Técnico

GG – Gerente General GPM – Gerente de proyecto DP – Dueño del proceso UC – Usuario clave UF – Usuario final

GP - Gerente de procesos CO – Consultor ET – Especialista técnico

GRÁFICO N° 24

ESTRUCTURA DEL EQUIPO DE TRABAJO


4.9. Estudio de Factibilidad

Definir la factibilidad del desarrollo de este proyecto es la principal

forma de sustentar su implementación, en este estudio se detalla los

diferentes aspectos donde se analiza su viabilidad y se utilizará para

recopilar datos más generales para el comité ejecutivo de MAINT S.A. lo

cual les permitirá tomar una decisión en cuanto a si deben continuar o no

con el desarrollo e implementación de éste proyecto.

Se determinará la viabilidad de tres principales formas: técnica,

económica y operativa.

Propuesta 77

4.9.1. Factibilidad técnica

La solución a implementar requiere de un fuerte equipamiento

técnico de hardware para poder instalar el software y poner la

funcionalidad en marcha.

Estos equipos de acuerdo al dimensionamiento previamente

expuesto, son de fácil acceso en Ecuador, ya que es posible modelar una

arquitectura de virtualización de fácil administración de recursos. Bajo

este esquema podemos considerar que es posible conseguir el hardware

negociando con las siguientes empresas ecuatorianas:

CUADRO N° 19

FACTIBILIDAD TÉCNICA

EMPRESA CIUDAD MATRIZ LOGO

COMPUEQUIP D.O.S Quito

INTERGRUPO Quito

MAINT S.A. Guayaquil


MAINT S.A. siendo socio de negocio de la multinacional Hewlett

Packard Enterprise puede proveer con facilidad la infraestructura

necesaria para la implementación de Dynamics AX. Actualmente MAINT

S.A. ya tiene implementado el ERP y cuenta con algunos de los

servidores y servicios de sistema operativo requeridos en la cuantificación

técnica. La empresa cuenta con los siguientes servidores:

Servidor de dominio

Servidor de AOS

Servidor de base de datos (repotenciar)

Propuesta 78

Financiado a Microsoft de la siguiente manera:

Servidor de pruebas (repotenciar)

4.9.2. Factibilidad económica

Teniendo en cuenta que MAINT S.A. tiene actualmente

implementado el ERP Dynamics AX y entre sus valores corporativos está

la mejora continua, hay que considerar un logro económico la

implementación inicial del ERP ya que realizar un cambio drástico a la

herramienta para cambiar todo un proceso de negocio requiere en otro

tipo de software una re-implementación, o adquirir otro software que llene

las expectativas de cambio en la organización.

Sin embargo hay que considerar el valor a invertir de los recursos

humanos implicados en el equipo de proyecto que tendrán que

desprenderse por corto tiempo de sus obligaciones diarias para realizar

los trabajos requeridos en el avance del desarrollo del flujo de ventas. A

dos años del primer arranque de ERP se exponen las cifras de la

inversión de licencias adquiridas en la primera salida a producción con

Dynamics AX:

CUADRO N° 20

FACTIBILIDAD ECONÓMICA


Propuesta 79

Dando a conocer éstas cifras se puede recalcar que estos valores

cubren el mantenimiento y soporte de la herramienta en todos los

módulos incluido el de desarrollo, razón por la cual es viable la

implementación del flujo de ventas, ya que bajo estas consideraciones y

gracias a los servicios invertidos tenemos el respaldo y garantía del

fabricante.

GRÁFICO N° 25

EL OBJETIVO

Fuente: Investigación de campo


4.9.3. Factibilidad Operativa

A nivel operacional, el desarrollo e implementación del flujo de

ventas contará con el compromiso de los usuarios que están dispuestos a

cooperar y a proveer la información necesaria que se requiera en la carga

inicial de los datos al sistema y de realizar las pruebas integrales a fin

entregar un producto de calidad respaldado por la carta de aprobación del

comité ejecutivo.

La implementación del flujo de ventas en el ERP Dynamics AX

enriquecerá funcionalmente la herramienta, poseerá los controles debidos

Propuesta 80

en la aprobación de un crédito, permitirá manipular información más

detallada de los clientes, habilitará los procesos de control de cartera,

proveerá información gerencial para la toma de decisiones, será utilizado

desde el arranque de toda la operación por lo que se estima viable desde

la salida a producción.

4.9.4. Impacto

El desarrollo de este proyecto influirá positivamente en las

utilidades de la compañía debido a que se acapara un nuevo nicho de

mercado permitiendo generar nuevos ingresos, no solo por captar nuevos

clientes sino también porque poseer éste tipo de controles sistematizados

para otorgar crédito te permite registrar nuevas ganancias a través de los

intereses.

Una forma más de mejorar el servicio que MAINT S.A. le ofrece a

sus clientes, sin duda alguna, éste cambio mejorará también la posición

de la empresa en el mercado local y logrará múltiples ventajas frente a los

competidores. El siguiente indicador muestra con mejor detalle el impacto

que ganan las empresas que deciden buscar la mejora continua haciendo

notoriamente visible ese valor agregado que buscan los consumidores y

marca la diferencia.

CUADRO N° 21

INDICADOR DE IMPACTO SOBRE IMPLEMENTACIÓN

DEL FLUJO DE VENTAS

Nivel de

Impacto

Indicador

-3 -2 -1 0 1 2 3 Total

Hábitos de negociación 3

Manejo ordenado de procesos 3

Propuesta 81

Fidelización de Clientes 3

Flexibilidad al cambio 2

Generación de nuevas ofertas 3

Total 2 12 14

Fuente: Propuesta Nivel de impacto Elaborado por: Tomalá García Edgar Jesús

Haciendo un breve análisis al impacto se pueden apreciar aspectos

positivos a corto plazo desde el arranque y salida en vivo que se

reflejaran inmediatamente a los consumidores, ganando un mejor

posicionamiento en el mercado y mas expertiz para sostener los

negocios, brindando nuevos sevicios y flexibilizando las exigencias del

cliente.

Un valor agregado que aprovechará el departamento comercial

para alcanzar sus metas de ventas anuales, incluso superarlas ya que

estarán mejor motivados en la busca de nuevos mercados.

4.9.5. Conclusiones

De esta implementación del flujo de ventas podemos resaltar las

siguientes concluciones:

Al reestructurar un proceso que tiene dos años implementado se

abren ventanas de tiempo para replantear el orden de ejecutar las tareas,

salen a la luz problemáticas que de alguna forma evidencian ciertos

inconvenientes que impiden operar con normalidad; toda esta recopilacion

de datos y anecdotas del trabajo usuario es documentada con el fin de

corregir y mejorar cumpliendo objetivo de elaborar la matriz de riesgos en

base al cambio del proceso del módulo de ventas.

Propuesta 82

Las tareas iniciales de levantamiento de información, casos de uso,

descripción de eventos, refleja una organización en el trabajo realizado y

obliga a dejar documentado los futuros procesos, y controles de cambio

que se realicen en la organización, logrando el objetivo de diseñar

conforme a lo relevado las definiciones que conlleva el flujo de ventas en

un formato estandarizado de la compañía.

El flujo de ventas aumenta en gran detalle el volumen de

información de clientes que va a estar debidamente organizada en el

sistema, con esto podemos tener un reporte consolidado sobre estos

datos el cual es uno de los objetivos de ésta implementación el cual es la

consolidación de toda la información de clientes de la compañía según su

clasificación.

Proponer un cambio del proceso de ventas utilizando las

herramientas existentes, marca otro objetivo alcanzado en el análisis y

estudio de los alcances del ERP a nivel técnico, investigar posibles

integraciones con otras herramientas del mismo fabricante o fabricantes

externos a fin de desarrollar nuevos proyectos sin que afecte la

estabilidad y funcionamiento actual.

4.9.6. Recomendaciones

Posterior a la finalización de todos los estudios realizados en ésta

investigación se recomienda adoptar el mismo interes de cambio en otras

áeras de la empresa que usen el ERP Dynamics AX con el objetivo de

innovar y buscar mejor eficiencia explorando nuevas funcionalidades que

ofrece la herramienta optimizando procesos, reduciendo la carga

operativa, aprovechando todas las bondades que nos brinda la tecnología

actual, obteniendo mejores controles que permitan dar mayor seguimiento

al cumplimiento de las tareas diarias.

Propuesta 83

Dynamics AX es altamente personalizable en todos los módulos del

sistema, con un estudio previo se pueden evaluar todas las alternativas

de cambio utilizando las herramientas de desarrollo que el ERP te ofrece.

GLOSARIO DE TÉRMINOS

Arquitectuta: En el desarrollo de software el término arquuitectura

se compone de diferentes componentes que componen una solución.

Backorder: Se define como backorder cuando realizas un pedido

de un producto o servicio y no cuentas con cuentas con stock o recursos.

Dynamics AX: es uno de los productos de software de

planificación de recursos empresariales (ERP) de Microsoft, perteneciente

a la familia Microsoft Dynamics.

ERP (Enterprise Resource Planning): Son sistemas de información

gerenciales que integran y manejan muchos de los negocios asociados

con las operaciones de producción y de los aspectos de distribución de

una compañía en la producción de bienes o servicios.

Flujo: Estudio de secuencia de los aspectos operacionales de una

actividad de trabajo.

Foundation: En esta sección se describe el modelo de

programación, ejemplos y herramientas de Windows Workflow Foundation

(WF).

Framework: Infraestructura digital, es una estructura conceptual y

tecnológica de soporte definido, normalmente con artefactos o módulos

concretos de software.

Glosario de términos 85

GB (Gigabyte): una unidad de almacenamiento de información

cuyo símbolo es el GB, equivalente a 109 (1.000.000.000 -mil millones-)

de bytes

Ishikawa: Nombre que se le da al diagrama de problemas causas

y efectos o espina de pescado.

Iconix: Nombre que se le da a la metodología de desarrollo de

software para simplificar los procesos a automatizar a través de

diagramas.

Maint S.A.: Empresa dedicada a brindar servicios tecnológicos

donde se va a implementar el proyecto de investigación.

Modelamiento: Un modelo es una representación de una realidad.

Modelar es desarrollar una descripción lo suficientemente buena de un

sistema y de las actividades llevadas a cabo en él.

Open Source: Código abierto, tipo de software que no requiere

licenciamiento y que pone su código fuente a disposición del público sin

restricciones.

Usuario: Usuario adecuado para la implementación porque conoce

todo el proceso.

Workflow: Flujo de Trabajo.

Windows: Sistema Operativo del fabricante Microsoft.

ANEXOS

Anexos 87

ANEXO N° 1

CRONOGRAMA

Nombre de tarea Duración Comienzo Fin

Proyecto de Tesis 84 días mar

01/12/15 vie

25/03/16

Fase de análisis 32 días mar

01/12/15 mié

13/01/16

Documentación de procesos actuales 6 días mar

01/12/15 mar

08/12/15

Elaboración de los casos de uso 1 día mié

09/12/15 mié

09/12/15

Entrevista con el Jefe del departamento comercial

2 días jue

10/12/15 vie

11/12/15

Encuestas a usuarios claves 6 días lun

14/12/15 lun

21/12/15

Definir alcance del proyecto 1 día mar

22/12/15 mar

22/12/15

Definir estandares técnicos y funcionales 7 días mié

23/12/15 jue

31/12/15

Plaificación de recursos 3 días lun

04/01/16 mié

06/01/16

Definir metodologia de trabajo 5 días jue

07/01/16 mié

13/01/16

Fase de diseño 26 días jue

14/01/16 jue

18/02/16

Elaboración diseño funcional parámetros de aprobación

7 días jue

14/01/16 vie

22/01/16

Elaborar diseño funcional de control comercial

8 días lun

25/01/16 mié

03/02/16

Elaborar diseño funcional del flujo de aprobación

7 días jue

04/02/16 vie

12/02/16

Elaboración del diseño de base de datos 4 días lun

15/02/16 jue

18/02/16

Fase de construcción 22 días vie 19/02/16 lun

21/03/16

Construcción de la estructura de base de datos

6 días vie 19/02/16 vie

26/02/16

Diseño de interfaz de usuario (pantallas del sistema)

5 días lun

29/02/16 vie

04/03/16

Desarrollo de funcionalidad (prototipo) 5 días lun

07/03/16

vie 11/03/16

Anexos 88

Fase de pruebas integrales 3 días lun

14/03/16 mié

16/03/16

Pruebas funcionales en ambiente de pruebas

2 días lun

14/03/16 mar

15/03/16

Pruebas funcionales en ambiente piloto 1 día mié

16/03/16 mié

16/03/16

Fase de Implementación 3 días jue

17/03/16 lun

21/03/16

Carga de datos previos 2 días jue

17/03/16 vie

18/03/16

Cofiguración preliminar pre-producción 1 día lun

21/03/16 lun

21/03/16

Fase de capacitación 4 días mar

22/03/16 vie

25/03/16

Capacitar usuarios claves 1 día mar

22/03/16 mar

22/03/16

Capacitar usuarios finales 1 día mié

23/03/16 mié

23/03/16

Capacitar propietarios 1 día jue

24/03/16 jue

24/03/16

Soporte salida en vivo 1 día vie 25/03/16 vie

25/03/16 Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús

Anexos 89

ANEXO N° 2

DIAGRAMA DE GANTT

Anexos 90


BIBLIOGRAFÍA

Delgado J, M. F. (2000). Evolución de los sistemas de gestión MRP a

ERP. Economía industrial.

Figueroa, P. (s.f.) obtenido de: www.ebdocs.cs.ualberta.ca/~pfiguero/soo/uml/estados01.html

González, A. (2010). Métodos de Investigación en Educación Especial.

Madrid: Universidad Autónoma de Madrid.

Hugo Jácome, K. K. (2012). Estudios industriales de la micro, pequeña y

mediana empresa. Ministerio de Industrias, 154.

José Vicente Tómas Miquel. (2009). Los Sistemas ERP en práctica.

Universidad Politécnica De Valencia.

Lopez Marcelo & Correa José. (2007). Planeación estratégica de

tecnologías informáticas y sistemas de información . Manizales,

Colombia: Universidad de Caldas.

Microsoft. (2012). Instalación y Configuración Microsoft Dynamics AX

2012. En Microsoft, Instalación y Configuración Microsoft Dynamics

AX 2012.

Microsoft. (2012). Versiones Dynamics AX.

https://blogs.msdn.microsoft.com/axsupport/2012/03/29/overview-

of-microsoft-dynami cs-ax-build-numbers/.

Bibliografía 92

Microsoft. (s.f.). Microsoft. Obtenido de Microsoft:

http://msdn.microsoft.com/es-

es/library/2x7h1hfk%28v=vs.100%29.aspx

Plan Nacional, d. b. (2013). Plan Nacional del buen vivir. Quito.

Sidney Perkowitz. (2001). Digital people. Editorial Siruela.

Slideshare. (s.f.). Obtenido de:

http://es.slideshare.net/nedowwhaw/diagrama-de-clases-16208245

Stephen Hawking. (2004). Brevísima historia del tiempo. Ed Bolsillo.

Microsoft. (2012). Microsoft Dynamics AX 2012 Development Cookbook. Birmingham: Packt Publishing Ltd.

Microsft. (2012). Inside Microsoft Dynamics AX 2012. Redmond, Washington, EE.UU.: Microsoft Press.

Microsoft. (2012). Microsoft Dynamics AX 2012 Services. Birmingham: Packt Publishing Ltd.

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE INGENIERÍA …repositorio.ug.edu.ec/bitstream/redug/19774/1/TESIS TOMALÁ GARCÍA... · herramientas tecnológicas implementadas en otro tipo

Documents