Este documento presenta un análisis y diseño genérico de un modelo de clientes para su implementación en aplicaciones de gestión como ERP, CRM o MDM. Incluye una introducción con convenciones y una descripción del Módulo 1 sobre Personas y Organizaciones, que gestionará entidades como empresas, personas, organismos gubernamentales y el seguimiento de las relaciones entre ellos.

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
Í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

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
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
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
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
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
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
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
// 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
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
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
• ¿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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.