Modelo de clientes enMDMs, CRMs
y ERPs
Incluye clientes, proveedores, empleados, contactos, agencias,
asociaciones, y cual...
2
Índice
1 INTRODUCCIÓN. 4
1.1 METODOLOGÍA. 4
1.2 MÓDULOS PREVISTOS DEL ERP 5
1.3 CONVENCIONES 5
1.4 REPRESENTACIÓN DE ENT...
3
4
Introducción.
El presente documento recoge un análisis/diseño genéricode modelo de clientes
para implementar en aplicaci...
5
1.2 Módulos previstos
El desarrollo de este ejercicio se divide en 9 módulos funcionales más una
introducción del cual s...
6
La representación gráfica de una entidad se denota con un rectángulo redondeado
con borde azul sólido para la línea y re...
7
Ejemplo
PEDIDO
Representación de una Entidad
Nombre de una entidad
Número de pedido
Nombre de un atributo
PUNTO
Represen...
8
Con este enfoque una taxonomía como la de organización que tradicionalmente se
representaría de la siguiente manera:
Org...
9
1.6 Mapeado de herencia, discriminante de herencia
Los discriminantes de herencia se utilizan profusamente para realizar...
10
1.8.2 Agregación
1.8.3 Composición
Se mantiene la notación de UML para la relación de composición con el rombo
solido a...
11
// La composición usa instancias de objetos que se han creado
// como parte del objeto
protectedPuerta[] lasPuertas;
pr...
12
Esta ampliación del molde propuesto para obtener el modelo final debe hacerse de
forma simultánea al mapeado del nuevo ...
13
2 MÓDULO 1 PERSONAS Y ORGANIZACIONES (PLAYERS)
2.1 Preguntas relacionadas.
Nota metodológica:
Este primer apartado dete...
14
• ¿Qué mecanismos de contacto necesitamos entre las partes?
• ¿Qué recursos intervienen, recursos físicos, humanos, int...
15
2.2 Entidades principales del módulo de personas y organizaciones
Resulta evidente que este módulo ha de contar con est...
16
Un listado de la entidad organización se reflejaría de la siguiente manera.
Id Tipo Subtipo Nombre
1 Legal Empresa Veo
...
17
Esto nos permite introducir un concepto más abstracto de Player que se
especialize en Personas Físicas y Organizaciones...
18
PLAYERS
# Id PLAYER
CLASIFICACIÓN DE PLAYERS
# Desde la fecha
o Hasta la fecha
Clasificado por
Agrupa
ACTIVIDAD
SECTOR
...
19
Una de las características de los Roles es que simultáneamente se pueden tener
varios como ya hemos dicho pero también ...
20
2.5.1 Tipos de roles
La taxonomía de roles de la que partimos presenta un primer nivel con los
siguientes roles.
ROL DE...
21
Cliente, Después del rol de organización interna o de referencia este es el
segundo rol más importante. Las partes bajo...
22
2.7 Ejemplo de "Player Rol"
A continuación incluimos un ejemplo de listado de Players con su "Player rol",
observar que...
23
Lo que supone la introducción de una nueva entidad que modele las relaciones
entre partes. Esta entidad la llamaremos "...
24
ROL DE ORGANIZACIÓN
RELACIONES ENTRE PLAYERS
RELACIÓN CLIENTE
hastadesde
involucrado
# Desde Fecha
o Hasta Fecha
ORGANI...
25
Esto queda más claro en el siguiente diagrama.
RELACIONES ENTRE PLAYERS
TIPO DE ROL
Descrito
por
Describe a
# Id Tipo d...
26
Prioridad. con la que calificamos la importancia de esta relación.
Estado. Con el "estado" calificamos la calidad actua...
27
TIPO DE ESTADO
EVENTO DE COMUNICACIÓN
PLAYER ROL
# ID PLAYER ROL
RELACION ENTRE PLAYERS
CONTACTO
REL. PROVEEDOR
HASTA D...
28
Dirección de entrega, vivienda, vivienda habitual, sede social, facturación etc.
También es evidente que estas direccio...
29
2.11.1 País
La estructura de la dirección es un elemento que cambia por completo de un país a
otro incluso dentro de un...
30
Nombre tipo null unic indx ref filter sort
Id id s s s
Nombre s s s s s
Nombre Oficial s s
ISO Código 2 C2 s
ISO Código...
31
TIPO DE DELIMITACIÓN GEOGRAFICA
# ID TIPO DE DELIMITACIÓN GEOGRAFICA
o DESCRIPCION
DELIMITACIÓN GEOGRÁFICA
# GEO ID
o G...
32
TIPO DE DELIMITACIÓN GEOGRAFICA
# ID TIPO DE DELIMITACIÓN GEOGRAFICA
o DESCRIPCION
DELIMITACIÓN GEOGRÁFICA
# GEO ID
o G...
Próxima SlideShare
Cargando en…5
×

Modelo de clientes en MDM s, CRMs y ERPs

727 visualizaciones

Publicado el

En el desarrollo de aplicaciones de línea de negocio, se trate de un MDM, de un ERP o de un CRM siempre tienen en su núcleo la necesidad de implementar un modelo de clientes y otros tipos de entidades. En este documento se realiza un propuesta de modelado genérico adaptable a necesidades concretas de cualquier tipo de sector.

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
727
En SlideShare
0
De insertados
0
Número de insertados
6
Acciones
Compartido
0
Descargas
21
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Modelo de clientes en MDM s, CRMs y ERPs

  1. 1. Modelo de clientes enMDMs, CRMs y ERPs Incluye clientes, proveedores, empleados, contactos, agencias, asociaciones, y cualquier tipo de entidad con la que se mantiene o pudiera mantenerse una relación contractual. Draft v.06
  2. 2. 2 Índice 1 INTRODUCCIÓN. 4 1.1 METODOLOGÍA. 4 1.2 MÓDULOS PREVISTOS DEL ERP 5 1.3 CONVENCIONES 5 1.4 REPRESENTACIÓN DE ENTIDADES Y OBJETOS VALOR 5 1.5 HERENCIA PROPORCIONADA POR EL COMPILADOR Y HERENCIA SIMULADA 7 1.6 DISCRIMINANTE DE HERENCIA 9 1.7 ATRIBUTOS / MIEMBROS / PROPIEDADES 9 1.8 TIPOS DE RELACIONES Y SU MAPEADO CON BASE DE DATOS. 9 1.8.1 Asociación 9 1.8.2 Agregación 10 1.8.3 Composición 10 1.8.4 M:N 11 1.8.5 Doble Asociación con exclusión 11 1.8.6 Recursividad Error! Bookmark not defined. 1.9 PLANIFICACIÓN DE LA CONVIVENCIA CON EL SISTEMA LEGADO. 11 1.9.1 Mapeado del nuevo sistema con el sistema anterior 12 2 MÓDULO 1 PERSONAS Y ORGANIZACIONES (PLAYERS) 13 2.1 PREGUNTAS RELACIONADAS. 13 2.2 ENTIDADES PRINCIPALES DEL MODULO DE PERSONAS Y ORGANIZACIONES 15 2.3 EL CONCEPTO DE PLAYERS 16 2.4 CLASIFICACIÓN DE PLAYERS 17 2.5 RESPONSABILIDADES DE LAS PARTES (PLAYER ROLES). 18 2.5.1 Tipos de roles 20 2.6 ¿DEBERÍAN DEFINIRSE LOS ROLES AL PRODUCIRSE UNA TRANSACCIÓN.? 21 2.7 EJEMPLO DE "PLAYER ROL" 22 2.8 RELACIONES ENTRE PARTES. 22 2.9 EJEMPLOS DE RELACIONES Y TIPOS DE RELACIONES. 25 2.10 INFORMACIÓN RELATIVA A LAS RELACIONES. 25
  3. 3. 3
  4. 4. 4 Introducción. El presente documento recoge un análisis/diseño genéricode modelo de clientes para implementar en aplicaciones de gestión tales como ERP, CRM o MDM, es decir se trata de un modelo agnóstico de la organización o de un sector concreto, pero incluye preguntas con el cual poder finalizar y adaptar dicho modelo a situaciones concretas. La razón que subyace a este tipo de modelo es sentar las bases de un domino concreto de forma que sea posible utilizar posteriormente Lenguajes específicos de dominio para acelerar los procesos de desarrollo. En este sentido es conveniente destacar que no se debería acometer la construcción de un lenguaje específico de dominio sin tener previamente muy claro cuál es el dominio para el cual se desea construir dicho Lenguaje. Clarificar el CoreDomain (Eric Evans) de cualquier tipo de aplicación de tipo ERP, CRM o MDM es el objetivo de este documento, en el que de forma inevitable encontraremos siempre a los clientes, proveedores y empleados como parte integrante del mismo. Este documento no plantea un diseño exhaustivo de un módulo de clientes sino un punto de partida a partir del cual podamos plantear cuales son las necesidades específicas para una empresa o grupo de empresas concreto. Estas necesidades se trasladaran en forma de propiedades de las clases planteadas así como métodos, o eventos de dominio. 1.1 Metodología de presentación. Tal y como se ha especificado el principal objetivo de este ejercicio es modelar una aplicación de tipo ERP, pero no menos importante es el hecho de que el modelo sea suficientemente comprensible para ser entendido, no solo por los equipos de desarrollo sino también por la gente de negocio. Con este objetivo la comunicación y presentación de este diseño va a seguir un método constructivista. Desde el punto de vista de la escuela constructivista el aprendizaje se lleva a cabo de forma escalonada apoyándose siempre en pasos anteriores, más simples para ir encapsulando la complejidad final. Por eso el modelado de cada módulo (boundedcontext: Eric Evans ) se mostrara desde la presentación de un concepto nuclear al módulo y se le ira añadiendo complejidad justificada en requerimientos genéricos. De forma previa al inicio del modelado se establecerá una serie de fundamentos y convenciones de notación y lenguaje ubicuo que permitan simplificar el proceso de modelado. El modelo de un módulo consistirá en un texto narrativo pero sistematizado que se apoyara en diagramas estáticos y en pantallas con objeto de hacer el texto accesible a personal no especializado. Esto no impide que posteriormente se complete con otros diagramas UML, el diseño final de la aplicación. Si bien la notación que se va a obtener podría considerarse como una Notación de Lenguaje Especifico para el Dominio de aplicaciones ERP, CRM y MDM.
  5. 5. 5 1.2 Módulos previstos El desarrollo de este ejercicio se divide en 9 módulos funcionales más una introducción del cual solo se desarrollara en este documento el primer módulo. Personas y Organizaciones (Players), gestionara las entidades desde un punto de vista unificado empresas, personas organismos gubernamentales y el seguimiento de los diferentes tipos de comunicación entre ellos. Este módulo es la base para un ERP multiempresa y multinacional. Productos, Gestión de bienes y servicios, sus configuradores, periodos de validez etc. Ventas, procesos de ventas Entregas y condiciones de los contratos, seguimiento y trazabilidad. Esfuerzos, consumo de recursos y tiempos de dedicados a los proyectos. Pedidos, procesos de gestión de los pedidos. Contabilidad y financiero, generación de información contable RRHH, generación de información para RRHH BI, alimentación de los sistemas de BI. 1.3 Convenciones Este primer capítulo recoge la totalidad de convenciones que se van a usar dentro del documento, quedando prohibido de forma explícita la declaración de convenciones dentro del resto de los capítulos. En todo caso si el uso de una convención no aparece hasta que se produce una situación que lo necesita se recomienda referenciar la convención en al menos el primer sitio donde aparece. 1.4 Representación de Entidades y objetos valor Según DDD la aplicación se divide en contextos limitados. Cada contexto limitado se divide en agregados Cada agregado tiene una entidad Raíz. Una entidad es una clase que tiene un identificador. Una entidad Raíz es el punto de entrada desde el que se comienza a navegar por el agregado para obtener un valor de una entidad agregada. La entidad raíz conforma el Api de acceso a cualquier elemento del agregado de la cual es entidad raíz. El framework proporciona una ayuda mediante la interfaz de “IEntidad” que obliga a implementar en una clase un campo privado y su propiedad pública de Identificación llamados “id” para el campo privado e “Id” para la propiedad pública correspondiente.
  6. 6. 6 La representación gráfica de una entidad se denota con un rectángulo redondeado con borde azul sólido para la línea y relleno azul con transparencia al 70% . Se utilizan colores para diferenciar el grado de importancia entre entidades (UML Color). Los objetos valor no tienen campo de identificación y se utilizara un rectángulo redondeado con fondo blancosólido y borde azul. El color de las entidades podrá variar para denotar bien el grado de importancia de determinadas entidades o bien un tipo de uso o estereotipo.
  7. 7. 7 Ejemplo PEDIDO Representación de una Entidad Nombre de una entidad Número de pedido Nombre de un atributo PUNTO Representación de un Objeto Valor Nombre de un Objeto Valor Coordenada x Nombre un atributo 1.5 Herencia proporcionada por el compilador y herencia por composición y delegación. La herencia se suele representar como una flecha del tipo. Sin embargo existen dos mecanismos de herencia en .Net y java. El proporcionado por el lenguaje y el obtenido por delegación y composición. Por lo que vamos introducir una representación adicional para el mecanismo de delegación y composición consistente en utilizar el anidamiento de entidades.Mientras que seguiremos utilizando el mecanismo de flecha para cuando se implemente por proporcionado por el.mecanismo proporcionado por el compilador. La justificación de esta propuesta de notación en este documento reside en que el mecanismo de herencia de los lenguajes c# y java no proporciona herencia múltiple, pero el mecanismo de modelado por flechas si permite modelarla. Por otra parte este mecanismo nos permite cambiar la interpretación del modelo para las entidades anidadas por la de relaciones de composición es decir podemos hacer que un modelo concreto prevalezca la composición frente a la herencia con solo cambiar la opción de interpretación.
  8. 8. 8 Con este enfoque una taxonomía como la de organización que tradicionalmente se representaría de la siguiente manera: Organización Legal Informal Empresa Agencia gubernamental Equipo Club la representaremos con el siguiente esquema. Organización * Nombre ORGANIZACIÓN LEGAL ó PERSONA JURIDICA o Identificación fiscal Coorporación Organismo Gubernamental EQUIPO CLUB OTRAS ORGANIZACIONES INFORMALES ORGANIZACIÓN INFORMAL Una ventaja de este esquema es que no solo hemos eliminado una gran cantidad de flechas sino que además los flechas que quedan solo denotan asociación, agregación y composición. Para eventos, notificaciones, mensajes y comandos incluiremos notaciones basadas en conectores diferenciados de las flechas. Para la implementación de interfaces conectores de componentes o se especificaran en las tablas de metadatos que complementen la información recogida en los diagramas.
  9. 9. 9 1.6 Mapeado de herencia, discriminante de herencia Los discriminantes de herencia se utilizan profusamente para realizar un mapeado de relaciones de herencia sobre base de datos y también para reflejar en interface la selección de un nodo de la taxonomía. Siendo 3 los métodos existentes para mapear una relación de herencia sobre una base de datos. Método 1) una tabla por cada nodo de la taxonomía de herencia. Método 2 una tabla repitiendo los campos comunes de las superclases sobre cada uno de los nodos. Método 3) una única tabla con la suma de todos los atributos de la taxonomía. Sin embargo también es posible utilizar una clase discriminante para encapsular en un atributo o en una regla como se selecciona un nodo o varios nodos de una taxonomía de herencia. Es posible incluso tener varios discriminantes. Uno por cada nivel de profundidad que tenga el árbol. 1.7 Atributos / miembros / propiedades Los datos que se incluirán en cada entidad son solo los más fundamentales con objeto de añadir posteriormente todos los tipos que se necesiten al concretarlos. Figura 1.4 Atributos. Pedido # Id * FechaPedido o FechaEntrada LEYENDA de atributos: # Identificador único. * Obligatorio o Opcional En la primera versión solo se marcaran las características más importantes de los datos a incorporar tal y como muestra la leyenda. 1.8 Tipos de relaciones y su mapeado con base de datos. 1.8.1 Asociación
  10. 10. 10 1.8.2 Agregación 1.8.3 Composición Se mantiene la notación de UML para la relación de composición con el rombo solido apuntando al padre. Esta relación denota un ciclo de vida por el cual la clase dependiente no tiene sentido sin la existencia previa de la clase que compone. la destrucción de la clase compuesta supone la destrucción de la clase componente. Las cardinalidades especifican cuantas veces pueden aparecer las clases compuestas. por regla general solo variara entre los valores 1 y superior la cardinalidad del segundo término en la clase hija, especificando cuantas veces puede repetirse la composición. Bateria Coche Se compone de 1..1 Puertas Se compone de 1..4 Es Parte de 0..1 Una opción de implementación simple en c# de esta estructura seria: namespaceMiFlota { public class Coche { protected class Bateria { publicintVoltaje; } protected class Puerta { public bolean Automatica; }
  11. 11. 11 // La composición usa instancias de objetos que se han creado // como parte del objeto protectedPuerta[] lasPuertas; protectedBateria laBateria; laBateria = new Bateria(); lasPuertas = new Puerta[4]; }// clase coche }// namespacemiFlota Su correspondiente mapeado en base de datos seria: ~ Carburador Coche Se compone de 1..1 Puertas Se compone de 1..4 Es Parte de 0..1 ~ Es Parte de 0..1 1.8.4 M:N 1.8.5 Doble Asociación con exclusión 1.8.6 Reflexiva 1.9 Planificación de la convivencia con el sistema Legado. La estructura del ERP presentado en este documento es un modelo de un molde de un ERP, no es un ERP. Es un molde diseñado para afrontar el desarrollo de un nuevo ERP para un sector indeterminado a pesar de que se vayan incluyendo algunos detalles de sector de televisión que solo tienen el objetivo de facilitar la comprensión del modelo. Al tratarse de un molde, es por tanto necesario completarlo con los detalles recogidos en el anterior ERP.
  12. 12. 12 Esta ampliación del molde propuesto para obtener el modelo final debe hacerse de forma simultánea al mapeado del nuevo sistema. 1.9.1 Mapeado del nuevo sistema con el sistema anterior En el mapeado del nuevo sistema con respecto al anterior nos encontramos con un problema de "impedancemistmatch" derivado del hecho de que el nuevo sistema se diseña desde una perspectiva de orientación a objetos mientras que el anterior sistema se ha diseñado desde una perspectiva base de datos. Por esta razón, se ha incluido en este capítulo cero como establecemos el mapeado de una estructura básica orientada a objetos contra la base de datos o contra la interface de usuario. Para poder facilitar en cada estructura una tabla con el mapa de conversiones entre ambos conceptos de forma que podamos incorporar los "mecanismos de disparo" que se encarguen de realizar la sincronización con las antiguas estructuras de bases de datos.
  13. 13. 13 2 MÓDULO 1 PERSONAS Y ORGANIZACIONES (PLAYERS) 2.1 Preguntas relacionadas. Nota metodológica: Este primer apartado determina el punto de partida de los requisitos básicos es decir exponer las preguntas que alguien de negocio puede plantear a un sistema de gestión acerca del concepto que trata el módulo. Esta lista ha de ampliarse a la hora de concretar el sistema y exige además la existencia de un lenguaje ubicuo para poder comprender las preguntas planteadas. Es necesario resaltar que el enfoque de la preguntas planteadas parte de un punto de vista de CRM/MDM que puede complementar sensiblemente el punto de vista habitual de un ERP. • ¿Cuáles son los datos de la gente y las organizaciones que vamos a gestionar? • ¿Cuáles son las relaciones entre ellos? • ¿Cuáles son sus mecanismos de control? • ¿Qué tipos de comunicación y comunicados intercambian en su relación? • ¿Cuál es la estructura interna de la organización? • ¿Cuáles son los roles (responsabilidades) de dicha organización proveedor, cliente, referencia, etc.? • ¿Cuáles son las relaciones entre dichos roles? – Relación de cliente. – Relación de proveedor. – Relación empleado. – Relación miembro de … – Relación beneficiario de … – Relación anunciante de … – Relación agencia de ... – Relación central de compras de ... – Relación de contribuyente en ... • ¿Cuáles son los datos de dichas relaciones? • ¿Qué tipo de información postal se necesita? • ¿Qué tipo de límites geográficos necesitamos?
  14. 14. 14 • ¿Qué mecanismos de contacto necesitamos entre las partes? • ¿Qué recursos intervienen, recursos físicos, humanos, intangibles? • ¿Cuáles son los eventos de comunicación a utilizar? teléfono, carta, e-mail, solicitudes, reuniones,… • ¿Se hace seguimiento de dichos eventos de comunicación.? Nota metodológica Completar esta lista a la hora de concretar el modelo definitivo.
  15. 15. 15 2.2 Entidades principales del módulo de personas y organizaciones Resulta evidente que este módulo ha de contar con estas dos entidades. Organización Persona Empecemos por desgranar Organización. Los tipos de organizaciones a su vez serán con toda seguridad un elemento importante siendo en principio 2: 1. De carácter jurídico (sujetas a un contexto Legal) y esta a su vez en: a. Corporación / Grupo b. Empresa c. Agencia gubernamental 2. de carácter informal (no sujetas a un contexto legal) y esta a su vez en: a. Equipo b. Familia c. Etc. El diagrama seria por tanto. ORGANIZACIÓN * NOMBRE ORGANIZACIÓN LEGAL o IDENTIFICADOR FISCAL EQUIPO FAMILIA OTRAS AGRUPACIONES ORGANIZACIONES INFORMALES ORGANIZACIÓN INFORMAL CORPORACIÓN AGENCIA GUBERNAMENTAL EMPRESA
  16. 16. 16 Un listado de la entidad organización se reflejaría de la siguiente manera. Id Tipo Subtipo Nombre 1 Legal Empresa Veo 2 Legal Ag. Gubernamental Agen. 233 Madrid 3 Informal Equipo Base de datos 4 Informal Club Micología de proyectos El problema con la información referida a personas es que las personas suelen cambiar a lo largo del tiempo. Otro problema es que pueden desempeñar varios roles simultáneos y pueden mantener varios mecanismos de contacto. Para evitar redundancias deberíamos extraer todos los elementos que susceptibles de cambiar en el tiempo en entidades separadas y dejar en la entidad solo aquellos datos que le resultan inherentes y más estables, o aquellos de los cuales no nos interesa su histórico. Persona o PrimerApellido o SegundoApellido o Nombre o Tratamiento o NicknameActual o Genero o FechaNacimiento o DNI o EstadoMarital o NumeroSeguridadSocial o FechaExpiraciónPasaporte o Comentarios 2.3 El concepto de Players Las organizaciones y la gente vistas como "entidades" comparten una gran cantidad de similitudes, ambos tienen métodos de contacto, dirección, calificaciones de riesgo etc. no en vano existen los conceptos de persona jurídica y persona física por la gran cantidad de similitudes que comparten. Por otra parte las organizaciones se componen a su vez de personas y cualquiera de ambos puede ser parte o jugador (Player) de un contrato con el significado de "sujeto activo" Igualmente ambos pueden compartir clasificaciones y roles aunque existan roles y clasificaciones exclusivos de cada uno de estos elementos.
  17. 17. 17 Esto nos permite introducir un concepto más abstracto de Player que se especialize en Personas Físicas y Organizaciones de la siguiente manera. Player # Id Player ORGANIZACION * NOMBRE Persona Jurídica o Identificación Fiscal Organización Informal Persona Física o PrimerApellido o SegundoApellido o Nombre o Tratamiento o NicknameActual o Genero o FechaNacimiento o DNI o EstadoMarital o NumeroSeguridadSocial o FechaExpiraciónPasaporte o Comentarios De esta forma podremos gestionar en un único sitio las características comunes que comparten ambas entidades. 2.4 Clasificación de players Una de las primeras necesidades que nos surgen en el momento de contar con un conjunto de players es clasificarlos según diversos criterios. Algunos comunes e independientes del tipo del player que sea por ejemplo una clasificación geográfica se puede utilizar tanto para clientes, competidores como empleados. Mientras que el grado de responsabilidad solo afectaría a empleados el nivel de riesgo en cartera solo afectaría a clientes pero no a proveedores mientras que el sector puede clasificar a ambos. Estos ejemplos ponen de manifiesto además que los criterios de clasificación pueden variar mucho en el tiempo por lo que sistematizar su implementación puede suponernos un ahorro de esfuerzos futuros importante. Para ello el enfoque propuesto consiste en agrupar en una taxonomía todos los sistemas de clasificación que necesitemos y separarlos en aquellos subgrupos que supongan la utilización exclusiva sobre algunos tipos de players de la siguiente manera:
  18. 18. 18 PLAYERS # Id PLAYER CLASIFICACIÓN DE PLAYERS # Desde la fecha o Hasta la fecha Clasificado por Agrupa ACTIVIDAD SECTOR TAMAÑO EMPRESA ORGANIZACION * NOMBRE Persona Jurídica o Identificación Fiscal Organización Informal CLASIFICACIÓN ORGANIZACIÓN SEGMENTO DEMOGRÁFICO POR INGRESOS CLASIFICACIÓN PERSONA Persona Física o PrimerApellido o SegundoApellido o Nombre o Tratamiento o NicknameActual o Genero o FechaNacimiento o DNI o EstadoMarital o NumeroSeguridadSocial o FechaExpiraciónPasaporte o Comentarios 2.5 Responsabilidades de las partes (Player Roles). Tal y como hemos adelantado previamente las partes ya sean organizaciones o personas pueden cumplir simultáneamente diversos roles. Como por ejemplo cliente, empleado, proveedor, abogado, Esto nos introduce una nueva entidad llamada Player Roles. Distinguimos que el rol sea de Player pues más adelante tendremos roles aplicados a otros conceptos. La misión de esta entidad de Player Rol es especificar "como actúa" una parte en concreto, es decir cuál es su papel o la "gorra" con la que se presenta.
  19. 19. 19 Una de las características de los Roles es que simultáneamente se pueden tener varios como ya hemos dicho pero también pueden cambiar a lo largo del tiempo. En este caso suele ser interesante poder extraer el histórico de dichos roles y cuáles son los que en un momento dado están activos. Esto supone que un rol debe tener dos fechas, una de inicio y otra de fin. Con ellas podemos determinar tanto el histórico, como las responsabilidades en un momento dado. Esto Roles pueden segmentar profundamente la información a almacenar por ejemplo: no tiene sentido establecer una calificación de riesgo para una "parte" que no tenga el rol de cliente. Ni hará falta actualizarla si ya no es cliente. El siguiente diagrama nos muestra cómo podemos modelar esta nueva entidad y como plasmamos su relación con partes la cual hemos simplificado en sus subtipos principales. ROL DE PERSONA Persona Entidad PLAYER PLAYER ROLE # Id Player # Id Player Role o Desde la Fecha o Hasta la Fecha Actúa como .. 0..n Papel o responsabilidad asignado a .. 1..1 ROL DE ORGANIZACIÓN AGENCIA DE GESTION DE DERECHOS UNIDAD ORGANIZATIVA DE EMPRESA DEPARTAMENTO DIVISION OTROS TIPOS DE UNIDADES DE ORGANIZACIÓN EMPRESARIAL CANAL DE DISTRIBUCIÓN AGENTE ORGANIZACIÓN MADRE SUBSIDIARIA AUDIENCIA Familiar Empleado Externo Contacto Accionista CLIENTE Cliente Potencial DISTRIBUIDOR PARTNER UNIDAD FAMILIAR PROVEEDOR ASOCIACION COMPETIDOR Anunciante Central de compras Agencia Publicidad
  20. 20. 20 2.5.1 Tipos de roles La taxonomía de roles de la que partimos presenta un primer nivel con los siguientes roles. ROL DE ORGANIZACIÓN INTERNA O DE REFERENCIA. Este es el rol más importante de cuantos tenemos pues identifica la parte o partes que actúan como beneficiarios directos de la funcionalidad del software y para la que se desarrolla el software. Roles de persona, que aglutina roles que solo pueden ser asociados a persona físicas. Como empleado, externo para aquellas personas que trabajan en la empresa pero no están directamente contratadas por la misma. miembro de una familia para controlar aquellos servicios en el que los beneficiarios pueden ser miembros de una misma familia aunque solo se facture a uno de sus miembros. o para saber que empleados están emparentados entre sí. El subtipo de "roles de organización" agrupa roles como por ejemplo: Canal: dividido a su vez en "agentes" y "distribuidores autorizados" aunque la introducción de estos elementos es puramente ilustrativa. Partners: como los que nos proporcionan personal externo u otros servicios de especial confianza. Competidor empresas sobre las cuales nos interesa realizar un seguimiento aunque no existan intercambio comercial ni de otro tipo. Accionista rol que se puede simultanear con otro de persona o organización. Agencia de regulación de derechos: son agencias que actúan como intermediarios sobre los derechos de reproducción de obras sujetas a propiedad intelectual. Las televisiones consumen gran cantidad de estos derechos y también son al tiempo productoras de obras sujetas a dichos derechos. ejemplo la SGAE. Unidad Familiar, agrupación de personas con una relación de parentesco que comparten una misma dirección. A su vez dichos componentes se identifican como miembros de una unidad familiar. Puede resultar de interes en casos como el consumo de servicios de entretenimiento a la carta, Videoclub etc. Asociación, Asociación empresarial a la que se pertenece. Representa aquellas entidades en las la empresa que actúa con el rol de interna o de referencia es miembro de dicha asociación. Estas asociaciones intentan defender los intereses de nuestro sector o promulgan códigos éticos a los que la empresa miembro se suscribe. incluso puede ser fuente de información promocionando estudios que ayuden a tomar decisiones de carácter estratégico dentro del sector al que pertenece la empresa de referencia.
  21. 21. 21 Cliente, Después del rol de organización interna o de referencia este es el segundo rol más importante. Las partes bajo este rol constituyen el motor económico de la organización interna o de referencia con las que dichas entidades mantiene una relación de cliente. Importante: No confundir rol de cliente con relación de cliente. El rol de cliente además se subdivide en otros subroles como: Anunciantes . empresas que utilizan diferentes medios de comunicación para a través de la publicidad en dichos medios dar a conocer sus marcas, objetivos productos servicios con fines comerciales o informativos. Central de compras: empresas especializadas en agrupar para varios clientes la contratación de espacio publicitario con objeto de conseguir mejores precios que si el anunciante va directamente al medio. entre sus servicios se encuentra también la selección de medios en función del publico objetivo al que se dirige una campaña. Agencia de publicidad: Empresa especializada en proporcionar servicios orientados relacionados con diferentes aspectos de las campañas publicitarias. Lenguaje ubicuo: Campaña: conjunto de acciones dirigidas desde un dpto. de marketing de una empresa para conseguir que una determinada audiencia reciba un comunicado a través de una serie de canales de comunicación y que a partir de la recepción del mismo, buscando una reacción de dicha audiencia a dicho comunicado. Publico objetivo: segmento de población con determinadas características que se marca como el objetivo de la comunicación de una campaña de publicidad . 2.6 ¿Deberían definirse los roles al producirse una transacción? Sobre la estructura propuesta puede argumentarse que el rol de una parte no se conoce hasta que se produce una transacción que coloca de forma automática una gorra a dicha parte. Y que por tanto no serian necesarios sin embargo el caso del rol de "cliente potencial" no existe dicha circunstancia, de hecho la información con que se alimenta el conjunto de entidades con el rol de cliente potencial se suele adquirir a empresas especializadas y no supone la existencia de una transacción con ninguna de ellas. Por esta razón se defiende en esta propuesta el uso de la existencia de roles "a priori" es decir modelar los roles antes de modelar las transacciones.
  22. 22. 22 2.7 Ejemplo de "Player Rol" A continuación incluimos un ejemplo de listado de Players con su "Player rol", observar que una misma parte puede tener simultáneamente varios roles. Id Nombre Tipología Tipo de Rol Rol Activo 1 Grupo industrial Grupo Referencia Empresa Madre Si Si 2 Empresa publica Cliente Si 3 Naranjas de la China Empresa privada Referencia Proveedor Cliente Si Si Si 4 Transportes Virgencita Empresa privada Empresa Madre Proveedor Distribuidor Si Si Si 5 Consultora Empresa Privada Proveedor Partner Si Si En este listado podemos empezar a argüir que efectivamente cada una de las empresas tiene dichos roles pero no con respecto a las mismas entidades de referencia. Es en este momento donde necesitamos introducir el concepto de Relaciones entre partes o Player Relationship. Por último comentar simplemente que el campo rol activo es una valor deducido de las fechas y no un miembro de la entidad Player Rol. Igualmente resaltamos que este “molde” de modelo que estamos planteando puede gestionar perfectamente a varias empresas de un mismo grupo simultáneamente. 2.8 Relaciones entre Partes. Hemos visto anteriormente que una parte puede tener simultáneamente varios roles. También hemos observado que algunos roles solo tienen sentido cuando se plantean con respecto a otra parte que además debe tener el rol de referencia o como lo hemos llamado "ORGANIZACION INTERNA DE REFERENCIA" El enfoque que nos proporciona la disciplina del CustomerRelationshipManagment focaliza sobre la importancia de gestionar correctamente las relaciones que mantiene la empresa con el resto de las partes y muy concretamente con aquellas partes con el rol de cliente. Esto supone realizar un seguimiento de los contactos que se mantienen con dichas partes orientadas a fortalecer dicha relación con el cliente. De esta forma introduciremos conceptos como estados, prioridades, notas, reuniones profesionales o informales para descubrir que no se establecen en relación al "contacto" sino la propia relación entre dos partes, entre la parte con el rol de "cliente" y la parte con el rol de "referencia".
  23. 23. 23 Lo que supone la introducción de una nueva entidad que modele las relaciones entre partes. Esta entidad la llamaremos "relación" la cual va a tener su propia taxonomía de herencia, y de la que podemos extraer 3 subtipos directamente, es decir tres tipos de relación entre pares de roles que hasta el momento podemos deducir como. El subtipo derelación de cliente muestra como una parte con el rol de cliente está envuelto como cliente en varias de nuestras organizaciones internas o de referencia y viceversa. En el caso de que necesitáramos no solo controlar los clientes de una organización sino quien es cliente de otras empresas del grupo o departamentos de la empresa. Como por ejemplo, cuales son los clientes de uno de nuestros competidores tendríamos que modelar la relación entre cliente y proveedor y no sólo con la empresa de referencia. El subtipo derelación de empleado establece quienes son los empleados de una organización interna o de referencia. La posibilidad de tener varios roles en este caso posibilita que un empleado lo pueda ser de diferentes organizaciones internas de forma simultánea. El tercer subtipo de relación más inmediato pero no tan evidente es el de "organigrama de la empresa" en el que podemos establecer tanto la foto final del esquema organizativo como la evolución histórica del mismo. o consultar la esquema organizativo de las empresas de referencia en un momento dado. Por otra parte no estamos obligados a seguir un organigrama perfectamente arborescente sino que podemos reflejar cómo algunos departamentos pueden ser dependientes de otras unidades de la organización. Los tres ejemplos expuestos ilustran la existencia de patrones comunes en la estructuración de las relaciones entre partes o players. Cuando se concrete este molde en un modelo final será muy importante establecer todas los posibles “pares de roles” que produzcan un tipo de relación que estemos interesados gestionar. Es importante tener presente que cada relación solo es válida entre un par especifico de roles. En este momento podemos definir esta asociación de dos formas: 1) Como parejas de asociaciones entre los subtipos de los roles que intervienen en una relación. 2) Con un metaesquema que define las relaciones existentes de forma dinámica. En el primer caso simplemente establecemos directamente pares de asociaciones entre los subtipos de los roles contra los subtipos de las relaciones, tal y como muestra el siguiente gráfico.
  24. 24. 24 ROL DE ORGANIZACIÓN RELACIONES ENTRE PLAYERS RELACIÓN CLIENTE hastadesde involucrado # Desde Fecha o Hasta Fecha ORGANIGRAMA ORGANIZACIÓN adesde Aglutina RELACIÓN EMPLEADO Empleadoen desde hasta Persona Entidad Player # Id Player Actúa como .. 1..n Papel o responsabilidad asignado a .. 0..1 TIPO DE ROL Descrito por Describe a # Id Tipo de Rol Player * DESCRIPCIÓN TIPO ROL PLAYER AccionistaCliente Potencial CLIENTE Anunciante Central de compras Agencia Publicidad Final Res. Contenido Facturación # Id Party Role o Desde la Fecha o Hasta la Fecha Player ROL ROL DE PERSONA Empleado Externo Contacto UNIDAD ORGANIZATIVA DE EMPRESA DEPARTAMENTO DIVISION OTROS TIPOS DE UNIDADES DE ORGANIZACIÓN EMPRESARIAL ORGANIZACIÓN MADRE SUBSIDIARIA AGENCIA DE GESTION DE DERECHOS CANAL DE DISTRIBUCIÓN AGENTE DISTRIBUIDOR PARTNER PROVEEDOR ASOCIACION COMPETIDOR ORGANIZACIÓN INTERNA DE REFERENCIA Involucrado Dentrode En el segundo caso este emparejamiento se controla desde una nueva entidad que llamamos "tipo de relación" y que se encarga de definir las diferentes asociaciones de roles así como proporcionar un nombre a dichas relaciones esta entidad nos permitirá igualmente definir un mismo tipo de relación para pares de roles diferentes. El tipo de relación actúa como un discriminante de la entidad relación ya que esta a su vez se compone de una taxonomía de herencia y se definiría igualmente desde un segundo discriminante de roles con dos relaciones que establecerían la dirección de la relación.
  25. 25. 25 Esto queda más claro en el siguiente diagrama. RELACIONES ENTRE PLAYERS TIPO DE ROL Descrito por Describe a # Id Tipo de Rol Player * DESCRIPCIÓN TIPO ROL PLAYER TIPO DE RELACION ENTRE PLAYERS EMPLEADO RELACION DE CANAL DE DISTRIBUCIÓN hasta desde Involucrado en Involucrado en Descrito por Describe a Define desde hasta # ID Tipo Relación Players * Nombre o Descripción ORGANIGRAMA RELACIÓN DE CLIENTE RELACION DE PARTNER RELACIÓN DE PROVEEDOR RELACIÓN DE CONTACTO CON LA ORG. Persona Entidad PLAYER # Id Player Actúa como .. 1..n Papel o responsabilidad asignado a .. 0..1 ROL DE ORGANIZACIÓN AccionistaCliente Potencial CLIENTE Anunciante Central de compras Agencia Publicidad Final Res. Contenido Facturación Player ROL ROL DE PERSONA Empleado Externo Contacto UNIDAD ORGANIZATIVA DE EMPRESA DEPARTAMENTO DIVISION OTROS TIPOS DE UNIDADES DE ORGANIZACIÓN EMPRESARIAL ORGANIZACIÓN MADRE SUBSIDIARIA AGENCIA DE GESTION DE DERECHOS CANAL DE DISTRIBUCIÓN AGENTE DISTRIBUIDOR PARTNER PROVEEDOR ASOCIACION COMPETIDOR ORGANIZACIÓN INTERNA DE REFERENCIA # Desde Fecha o Hasta Fecha 2.9 Ejemplos de relaciones y tipos de relaciones. ejemplo tabulado 2.10 Información relativa a las relaciones. Las relaciones entre partes tienen una serie de información mínima asociada como:
  26. 26. 26 Prioridad. con la que calificamos la importancia de esta relación. Estado. Con el "estado" calificamos la calidad actual de la relación. A lo largo del ERP nos encontraremos con muchos tipos de estado lo que supone que podremos agruparlos a todos bajo una misma taxonomía como en "Tipos de Roles" o "Tipos de discriminantes". Eventos de comunicación. su misión es registrar cualquier tipo de contacto entre partes. Es decir hacemos el seguimiento de los contactos mantenidos, el canal o medio utilizado las fechas las personas involucradas y el contenido de dichos eventos de comunicación. Estos conceptos los reflejamos con nuevas entidades con idéntico nombre cayendo las dos primeras en las entidades de categoría "Tipo" ya que están tipificando a una segunda entidad, en este caso la entidad de relación. Este instante es bueno para introducir un concepto general sobre algunos tipos de entidades que nos vamos a encontrar repetidamente, como son: Roles establecen papeles entre una parte y otro concepto, por ejemplo hemos visto hasta ahora su uso para establecer papeles entre partes pero podemos hacerlo para establecer papeles entre una parte y un pedido, entre una parte y un producto (pagador, beneficiario , receptor, intermediario). Estados Discriminantes Categorías Tipos Todos esto tipos de entidad no solo son entidades DDD son entidades que tienen un nombre único y que se utilizan para clasificar a otras entidades por esta razón podemos agruparlas en su propia taxonomía incluso aunque no detallemos en los diagramas la existencia de este mecanismo de herencia. y hagamos referencia exclusivamente a sus correspondientes subtipos. El siguiente diagrama sugiere una implementación de lo expuesto.
  27. 27. 27 TIPO DE ESTADO EVENTO DE COMUNICACIÓN PLAYER ROL # ID PLAYER ROL RELACION ENTRE PLAYERS CONTACTO REL. PROVEEDOR HASTA DESDE INVOLUCRADO EN Descrito por Describe a # DESDE LA FECHA o HASTA LA FECHA o COMENTARIOS Priorizado por Prioriza a in the context of contacted via # ID EVENTO DE COMUNICACIÓN Definido por Estado de # ID ESTADO * DESCRIPCION EMPLEADO CLIENTE PARTNER ORGANIGRAMA TIPO DE ESTADO DE LA RELACION TIPO DE RELACION ENTRE PLAYERS * DESCRIPCIÓN TIPO DE PRIORIDAD # ID TIPO DE PRIORIDAD * DESCRIPCIÓN # ID TIPO RELACION ENTRE PLAYERS * HORA FECHA DE COMIENZO o NOTAS, CONCLUSIONES ,PROXIMOS PASOS o HORA FECHA DE FINAL INVOLUCRADO EN 2.11 Información Postal, Delimitaciones Geográficas y Países,. Las dos principales dimensiones de referencia que necesitamos prácticamente en cualquier tipo de situación son tiempo y espacio. Las delimitaciones en el tiempo de la información ya estamos controlándolas desde hace unos ejemplos con fechas de inicio y finalización asociadas en determinadas entidades, al igual que podemos añadir horas , periodos etc para lo que los que los lenguajes de programación nos proporcionan un cierto nivel de soporte. Pero para el espacio necesitamos proporcionar nuestra propia estructura de gestión. Para ello vamos a introducir el concepto de delimitación geográfica, una delimitación geográfica establece una jerarquía de agrupación espacial que nos permite localizar y clasificar a nuestros players, lo que nos permite enviarles productos, comunicados, visitarles, o clasificarles por segmentos socioeconómicos o geodemográficos que posteriormente nos permitan inferir predicciones de comportamiento de mercado o de consumidores de nuestros productos o servicios. En un primer acercamiento nos resulta evidente que muchos de nuestros players van a tener una cantidad indeterminada de direcciones cada una con uno o varios roles .por ejemplo.
  28. 28. 28 Dirección de entrega, vivienda, vivienda habitual, sede social, facturación etc. También es evidente que estas direcciones pueden cambiar en el tiempo y que necesitamos guardar el histórico de dichos cambios, pues si hemos enviado un producto a una dirección de un cliente que se ha mudado probablemente nos interese recuperar donde se ha enviado ante una posible reclamación. Esto significa en primer lugar que un player puede tener varias direcciones y que nos interesa saber además cuales están actualizadas y cuáles han sido las anteriores además de determinar para que se usa cada una de dichas direcciones Esto lo moldearíamos en principio de la siguiente manera. PLAYER DIRECCIÓN POSTAL # ID DIRECCION * FECHA DESDE o FECHA HASTA Este esquema nos proporciona una asociación de direcciones postales de un player. pero podemos encontrarnos una situación alternativa en donde nos interese poder analizar cuantos de nuestros players comparten una misma dirección. Esta situación supone modelar una relación de asociación múltiple tipo n:m con la intervención de una clase de tipo cross-reference. PLAYER DIRECCIÓN POSTAL # ID DIRECCION * FECHA DESDE o FECHA HASTA PLAYER DIRECCIÓN POSTAL Sin embargo dado que esta alternativa no es excesivamente común vamos a desarrollar por el momento solo la primera alternativa. En la que la información de dirección no es compartida.
  29. 29. 29 2.11.1 País La estructura de la dirección es un elemento que cambia por completo de un país a otro incluso dentro de una unidad europea. Esto es evidente cuando se realiza envíos entre diferentes países en los que los conceptos que aparecen en una dirección y en otra son completamente diferentes en España existe la comunidad autónoma en Alemania Regiones, en Japon prefecturas etc. Para resolver este problema vamos a guardar en la entidad país una jerarquía de 5 niveles basadas en los sistemas de estadística territorial de la UE pero que podemos aplicar a cualquier país del mundo especificando que elementos intervienen en una dirección y cuáles de ellos son obligatorios. Por ejemplo desde este sistema de clasificación España en el nivel 1 de NUTS tiene un sistema de clasificación en el que se agrupan algunas comunidades autónomas pero este dato no se requiere a la hora de escribir la dirección postal de un player localizado en España. Igualmente en estados unidos tenemos estados, Countys mientras que en Polonia tenemos Voivodatos etc. Lenguaje ubicuo: NUTS (Nomenclature of territorial unitsforstatistics) hace referencia a los nombres de la unidad territorial dentro de cada país. Son colecciones de armonización de estadística utilizadas para realizar análisis socioeconómico. LAU (Local AdministrativeUnit) se dividen en dos niveles el 1 y el 2 que corresponden a los antiguos nuts 4 y 5 el primero se define para una gran mayoría de países per no para todos mientras que el segundo engloba municipalidades. Así en España el nombre de Nuts1 corresponde a áreas regionales que agrupan varias comunidades autónomas. y no es necesario especificarlo en la dirección postal. Nuts 2 corresponde a comunidad autónoma y tampoco es necesario especificarlo en una dirección Nuts 3 Correponde a la provincia y se suele especificar a pesar de ser opcional si tiene código postal. LAU 1 corresponde al municipio y si es necesario especificarlo en españa pero existen países que no tienen equivalente. LAU 2 corresponde a una localización dentro de dicho municipio y su existencia depende de la organización de cada municipio en particular. En Alemania el equivalente de CCAA seria el Estado federado el cual aparecerá además en el idioma local. Por otro lado existen algunos datos adicionales asociados al país que conviene mantener con objeto de permitir la internacionalizacón de nuestras aplicaciones. Estos datos serian:
  30. 30. 30 Nombre tipo null unic indx ref filter sort Id id s s s Nombre s s s s s Nombre Oficial s s ISO Código 2 C2 s ISO Código 3 C3 s ISO Código 3 num N3 s ISO Código 4 num N4 s Código divisa C3 s s s Nombre divisa sing. s Nombre divisa plu. s Fracción divisa sing s Fracción divisa plu s bandera img Husos horarios Nombre NUTS1 s Requiere nuts1 b Nombre NUTS2 s Requiere nuts2 b Nombre NUTS3 s Requiere nuts3 b Nombre LAU1 s Requiere LAU1 b Nombre LAU2 s Requiere LAU2 b Formato CP (reg. expr.) s Fmt. tel. (reg. expr.) Fmt. movil. (reg. expr.) Prefijo tel. país Los nombres se deberían recopilar en el idioma local para que la búsqueda de un concepto coincida con la forma de organización dentro de un país. A estos datos se le puede añadir en función de las necesidades las formas plurales singulares femeninas y masculinas de los gentilicios y formas adjetivadas derivadas del país al que se hacer referencia en un objeto concreto pero que en este caso no se han incluido. El siguiente concepto que interviene en nuestro modelo es el de delimitación geográfica. Este concepto incluye la gestión de datos tanto acerca de la jerarquización geográfica de un país como de las delimitaciones geográficas que una empresa de referencia establece para su gestión particular. Esto incluye tanto áreas geográficas en las que presta servicio como la asignación de territorios comerciales en los que puede dividir su estructura comercial. El concepto de delimitación geográfica no solo interviene dividiendo un país sino que dentro de las compañias internacionales se establecen delimitaciones por encima de los paises por lo que la jerarquización la podemos modelar de la siguiente manera.
  31. 31. 31 TIPO DE DELIMITACIÓN GEOGRAFICA # ID TIPO DE DELIMITACIÓN GEOGRAFICA o DESCRIPCION DELIMITACIÓN GEOGRÁFICA # GEO ID o GEO CODE * NOMBRE o ABREVIATURA PAÍS Descrito por Tipifica la delimitación geográfica Territorios de ventas Territorios de servicio Tipo Limites geográficos PAÍS NUTS1 NUTS2 NUTS3 ALU1 ALU2 CALLEJERO JERARQUIA DELIMITACIÓN La agrupación de límites geográficos se diferencia de las de territorios en que conforma unidades de limitación geográfica estándar mientras que los territorios son una jerarquización específica para cada empresa de referencia. Igualmente el concepto de Callejero se puede desarrollar de dos formas diferentes La primera y más sencilla consistiría en una lista de direcciones cuya estructura depende del país en que se engloba o por el contrario pues incluirse información específica de una estructura de callejero. Esta segunda alternativa no se va a desarrollar por dos razones la primera es que su complejidad no justifica el esfuerzo y segundo existen posibilidades de realizar validaciones contra servicios proporcionados por bing y google que resultan mucho más rentables. y que es el principal objetivo de guardar información de sobre callejeros dentro de una aplicación de ERP esa y el cálculo de rutas de entrega. Necesidad igualmente cubierta por dichos servicios. En consecuencia el diagrama final para almacenar la información referente a países direcciones postales o delimitaciones geográficas se modelaría:
  32. 32. 32 TIPO DE DELIMITACIÓN GEOGRAFICA # ID TIPO DE DELIMITACIÓN GEOGRAFICA o DESCRIPCION DELIMITACIÓN GEOGRÁFICA # GEO ID o GEO CODE * NOMBRE o ABREVIATURA PAÍS Descrito por Tipifica la delimitación geográfica Territorios de ventas Territorios de servicio Tipo Limites geográficos PAÍS NUTS1 NUTS2 NUTS3 ALU1 ALU2 CALLEJERO JERARQUIA DELIMITACIÓN PLAYER Incluir ejemplo de listado sobre esta estructura de información 2.12 Mecanismos de contacto, teléfono, e-mail. Las relaciones entre players se basan en los mecanismos de contacto que se permiten y proporcionan entre ellos. Siendo los mecanismo basados en las telecomunicaciones los más rentables y rápidos por norma general. Sin embargo es necesario tener en cuenta las preferencias y la existencia de permisos explícitos de uso de dichos mecanismos de contacto tanto por razones de efectividad como por razones legales. Un modelado rápido para gestionar la información de estos mecanismos de contacto quedaría de la siguiente manera.

×