Post on 29-Aug-2019
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
No. Descripción Pág.
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
No. Descripción Pág.
2. Marco Teórico 12
CAPÍTULO III
METODOLOGÍA
No. Descripción Pág.
3.1 Metodología descriptiva 18
vi
No. Descripción Pág.
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
No. Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
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
Fuente: Resultados de la encuesta número de aprobadores Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Resultados de la encuesta número de aprobadores Elaborado por: Tomalá García Edgar Jesús
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
Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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
Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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
Administrador del módulo
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.
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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:
Deben estar configurados previamente las funciones de:
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.
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
Metodología 42
Administrador del módulo
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
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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:
Deben estar configurados previamente las funciones de:
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.
Fuente: Definición de la reunión con los actores Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Análisis de requerimientos Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Análisis de requerimientos Elaborado por: Tomalá García Edgar Jesús
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.
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
Elaborado por: Tomalá García Edgar Jesús
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 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.
Fuente: Propuesta de diseño técnico Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Propuesta de diseño técnico Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Propuesta de diseño técnico
Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Propuesta de diseño técnico Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Propuesta de diseño técnico
Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Elaborado por: Tomalá García Edgar Jesús
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.
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Debe ser iniciado y automático
Servicio con Cuenta de dominio, puede correr igualmente con NETWORK SERVICE o LOCAL SYSTEM.
SQL Server Full Text Indexing
Debe ser iniciado y automático.
Servicio con Cuenta de dominio, puede correr igualmente con NETWORK SERVICE o LOCAL SYSTEM.
Cuenta del servicio de SQL Server
Debe ser iniciado y automático
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.
Servicio con Cuenta de dominio, puede correr igualmente con NETWORK SERVICE o LOCAL SYSTEM.
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Monitor Configuración de paleta de color al menos 256 colores (recomendado 32,000 colores).
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
Requisitos de las Cuentas de los Servicios del Software Principal
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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.
Nota AX y SQL Server deben estar en la misma LAN.
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
Modo de Virtualización
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
Memoria Recomendado: 16 GB o más.
Disco Recomendado: 500 GB o más
Monitor Configuración de paleta de color al menos 256 colores (recomendado 32,000 colores).
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
Requisitos de las Cuentas de los Servicios del Software Principal
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
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.
Nota AX y SQL Server deben estar en la misma LAN.
Lenguaje
Moneda USD.
MS OFFICE Instalar el Office 2007 SP2 o Office 2010. Se recomienda instalarlo en el
Propuesta 72
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Modo de Virtualización
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.
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
Memoria Recomendado: 16 GB o más.
Disco Recomendado: 300 GB o más
Monitor Configuración de paleta de color al menos 256 colores (recomendado 32,000 colores).
Sistema Windows Server 2008 R2 (x64 versions) SP1 o Superior
Propuesta 73
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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).
Requisitos de las Cuentas de los Servicios del Software Principal
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.
Modo de Virtualización
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.
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
GRÁFICO N° 23
ARQUITECTURA DE DIMENSIONAMIENTO
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Requisitos de las Cuentas de los Servicios del Software Principal
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Fuente: Investigación de campo Elaborado por: Tomalá García Edgar Jesús
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
Elaborado por: Tomalá García Edgar Jesús
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 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
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.