Modelo de clientes en MDM s, CRMs y ERPs

32
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

description

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.

Transcript of Modelo de clientes en MDM s, CRMs y ERPs

Page 1: Modelo de clientes en MDM s, CRMs y ERPs

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

Page 2: Modelo de clientes en MDM s, CRMs y ERPs

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

Page 3: Modelo de clientes en MDM s, CRMs y ERPs

3

Page 4: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 5: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 6: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 7: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 8: Modelo de clientes en MDM s, CRMs y ERPs

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

EmpresaAgencia

gubernamentalEquipo 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.

Page 9: Modelo de clientes en MDM s, CRMs y ERPs

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* FechaPedidoo 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

Page 10: Modelo de clientes en MDM s, CRMs y ERPs

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;

}

Page 11: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 12: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 13: Modelo de clientes en MDM s, CRMs y ERPs

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?

Page 14: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 15: Modelo de clientes en MDM s, CRMs y ERPs

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ÓNAGENCIA

GUBERNAMENTAL

EMPRESA

Page 16: Modelo de clientes en MDM s, CRMs y ERPs

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 PrimerApellidoo SegundoApellido

o Nombreo Tratamiento

o NicknameActualo 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.

Page 17: Modelo de clientes en MDM s, CRMs y ERPs

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 PrimerApellidoo SegundoApellido

o Nombreo Tratamiento

o NicknameActual

o Generoo FechaNacimiento

o DNI

o EstadoMarital

o NumeroSeguridadSocial

o FechaExpiraciónPasaporteo 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:

Page 18: Modelo de clientes en MDM s, CRMs y ERPs

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 PrimerApellidoo SegundoApellido

o Nombreo Tratamiento

o NicknameActual

o Generoo FechaNacimiento

o DNI

o EstadoMarital

o NumeroSeguridadSocial

o FechaExpiraciónPasaporteo 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.

Page 19: Modelo de clientes en MDM s, CRMs y ERPs

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

PROVEEDORASOCIACION

COMPETIDOR

Anunciante

Central de compras

Agencia Publicidad

Page 20: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 21: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 22: Modelo de clientes en MDM s, CRMs y ERPs

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".

Page 23: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 24: Modelo de clientes en MDM s, CRMs y ERPs

24

ROL DE ORGANIZACIÓN

RELACIONES ENTRE PLAYERS

RELACIÓN CLIENTE

hastadesde

invo

lucra

do

# Desde Fecha

o Hasta Fecha

ORGANIGRAMA ORGANIZACIÓN

adesde

Ag

lutin

a

RELACIÓN EMPLEADO

Em

ple

ad

o e

n

desdehasta

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

Invo

lucra

do

De

ntr

o d

e

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.

Page 25: Modelo de clientes en MDM s, CRMs y ERPs

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

De

fin

e

desde

hasta

# ID Tipo Relación Players

* Nombre

o DescripciónORGANIGRAMA

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:

Page 26: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 27: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 28: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 29: Modelo de clientes en MDM s, CRMs y ERPs

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:

Page 30: Modelo de clientes en MDM s, CRMs y ERPs

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.

Page 31: Modelo de clientes en MDM s, CRMs y ERPs

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:

Page 32: Modelo de clientes en MDM s, CRMs y ERPs

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.