Migración de datos

De SinergiaCRM
Saltar a: navegación, buscar

Introducción

El CRM está formado por varios módulos, cada uno de los cuales aloja información relacionada con un tema determinado (personas, organizaciones, proyectos, etc.). Cada módulo dispone de una ficha (llamada formalmente Vista de detalle) en la que se muestran los datos (los campos) que describen un elemento concreto (un registro) del módulo en cuestión.

Por otra parte los módulos pueden estar relacionados entre sí, de modo que la información asociada a un determinado elemento de un módulo va mucho más allá de su información directa, contenida en el propio módulo. En la ficha a la que se ha hecho mención en el párrafo anterior, esta información relativa a los módulos asociados se visualiza en los subpaneles que aparecen después de los datos propios del módulo.

Conocer la estructura de módulos y relaciones del CRM es fundamental para realizar una migración de datos correcta, es decir, para ubicar cada dato en el módulo adecuado y, a su vez, relacionarlo apropiadamente con datos de otros módulos.

Antes de describir con detalle y paso a paso el trabajo a realizar, comentaremos cualitativamente un ejemplo habitual.

Supongamos que tenemos dos listas con personas que han participado en dos eventos distintos que en algún momento del pasado ha organizado la entidad. Cada lista tiene una estructura similar donde consta el nombre de la persona, su correo electrónico y su teléfono móvil.

De estas listas se desprende información relativa a las Personas (nombre, teléfono, correo), a los Eventos (nombre del evento, fecha en que se ha realizado) y a la participación de las personas en los eventos, concepto que en el CRM denominamos como Inscripciones (puede ser que haya personas que hayan participado en uno, en el otro o en ambos).

Con las dos listas se deberá hacer un proceso como el siguiente:

- Unirlas en un solo listado haciendo coincidir por columnas los campos equivalentes.

- Ordenar el listado resultante por las columnas que permitan encontrar personas duplicadas (nombre, correo, teléfono).

- Combinar los datos de los duplicados detectados de manera que quede una persona lo más completa posible (ya que para una misma persona en un listado podría aparecer el teléfono y en el otro, el correo).

- Marcar en cada fila o registro en cuáles de los dos eventos ha participado una persona.

- Importar los datos correspondientes a las personas.

- Importar los datos correspondientes a los eventos (en este caso, como se trata sólo de dos, se podrían introducir directamente en el CRM manualmente sin necesidad de realizar el proceso de importación).

- Importar los datos correspondientes a participación de las personas en las eventos, es decir, las inscripciones.

En los apartados siguientes se analizará este proceso con más detalle.


Análisis de fuentes

La migración al nuevo sistema CRM de los datos que históricamente pueda haber acumulado una entidad es una de las partes más complejas y pesadas del proceso de implantación de la herramienta.

En este sentido, antes de determinar el alcance funcional que deberá ofrecer el CRM a una entidad concreta, conviene hacer una exhaustiva recopilación de todas las fuentes de datos existentes que se querrán integrar. Quien más, quien menos, toda persona y todo departamento de cualquier organización acaba teniendo sus "listas" (hojas de cálculo, agendas los programas de correo electrónico, etc.). Aparte de eso, pueden existir también "aplicaciones corporativas" (bases de datos, etc.). Todos estos depósitos deben ser debidamente analizados e inventariados.

El análisis implicará determinar qué datos actualmente disponibles deberán ser incorporados al CRM y cuáles podrán ser obviados. A lo largo de su vida una entidad acumula información que en un determinado momento se ha considerado relevante pero que posteriormente no ha tenido utilidad. El proceso de migración al CRM es un buen momento para deshacerse de ella.

De la información que sea necesario traspasar al CRM, habrá que decidir, lista por lista, a qué módulo y campo del CRM irá a parar cada columna disponible. De alguna manera, hay que establecer correspondencias entre la estructura (o estructuras) actual de información y la del CRM. Todo ello permitirá saber qué módulos del CRM deberán usarse y si habrá que crear otros nuevos o adaptar en cierta medida los existentes.


Traspaso de datos de las fuentes originales en hojas de cálculo

Tal y como ya se ha indicado, el CRM consta de una serie de módulos, cada uno de los cuales almacena información de una determinada tipología (organizaciones, personas, proyectos, actividades, etc.).

La importación de datos en el CRM se realiza módulo a módulo. Inicialmente, los datos se extraen de sus ubicaciones originales y se depositan en hojas de cálculo que luego son fácilmente importables sobre el CRM. A partir de las fuentes recopiladas habrá que generar una o más de estas hojas de cálculo para cada módulo de destino. Veamos un ejemplo.

Supongamos que la entidad tiene una base de datos de empresas con las que ha mantenido relación y por otro lado tiene una lista de escuelas en las que ha hecho actividades. Ambas listas, tanto la de empresas como la de escuelas, irán a parar al mismo módulo del CRM, el de Organizaciones. Como es de esperar que ambas listas tengan intersección nula (difícilmente una escuela aparecerá también en la lista de empresas y viceversa), cada conjunto de datos se puede depositar en una hoja de cálculo independiente y después importar por separado. Por el contrario, si entre dos listados hay una intersección relevante (por ejemplo, un listado de escuelas públicas de Cataluña y un listado de escuelas de todo tipo de la provincia de Barcelona), convendrá fusionar ambos listados en una sola hoja de cálculo para facilitar la detección, combinación y eliminación de duplicados antes de la importación, tal y como se explicará en un apartado posterior.

Como paso final de este proceso inicial de traspaso de datos de sus fuentes originales a las hojas de cálculo se realizará una copia de seguridad de los archivos generados, de manera que si en las actuaciones posteriores de limpieza, homogeneización y demás se produce alguna incidencia, siempre sea posible rehacer el proceso o comparar datos con facilidad.


Selección de los campos y los registros

Una vez todos los datos de un determinado módulo ya están todos juntos en un mismo archivo, procedemos a la eliminación de las columnas que no queremos importar al módulo en el que estamos trabajando (campos que han dejado de tener interés, que se gestionarán de una manera diferente, que son redundantes con otros, etc.).

Este proceso, sencillo en el caso de los campos, se puede aplicar también a nivel de registros. En este caso no es tan evidente ni rápido, pero eliminar información que no es útil ni a efectos de memoria histórica hará más valioso el resultado final. Por ejemplo, imaginemos que en un archivo de organizaciones aparece un conjunto de empresas procedente de un listado que hace años apareció de no se sabe muy bien dónde y con el que nunca se ha hecho ninguna acción de ningún tipo. Si además sospechamos que la calidad, la completitud o la vigencia de los datos hace que este conjunto de registros sea de poco valor, quizás mejor no incorporarlos al CRM y, por tanto, eliminarlos del listado de importación.


Formato de los campos a importar

Algunos tipos de campos pueden presentar particularidades que conviene tener en cuenta. Entre otros:

- Booleanos (verdadero/falso). Se utiliza 1 para valores de tipo cierto (o ) y 0 para los de tipo falso (o no).

- Correos electrónicos. Cuando en una misma casilla encontramos más de una dirección de correo, conviene separarlas en varias columnas. Igualmente, hay que comprobar que tienen una estructura válida. Tanto si en una casilla hay más de una dirección como si sólo hay una pero no es válida (por ejemplo, no contiene el símbolo @ o incumple cualquier otra de las normas de construcción de direcciones de correo) el CRM no importará el registro en cuestión.

- Códigos postales (y otros campos de texto con casuística similar). Conviene tener cuidado con los que empiezan por 0, ya que es fácil que en algunos casos este 0 inicial desaparezca al manipular el campo en una hoja de cálculo. En este sentido, suele ser útil dar formato explícito de texto a las celdas que deberán contener códigos postales o datos similares (números de teléfono, cuentas bancarias, etc.).

- Teléfonos. De entrada mejor eliminar espacios, puntos, guiones, comas, etc. particularmente en teléfonos estándares (9 dígitos). Cuando se trata de teléfonos con extensiones, del extranjero, etc. determinar un formato y mantenerlo.

- Campos multivalor. Cuando un campo puede tomar varios valores de entre un conjunto pre-establecido (por ejemplo, tipologías de relación entre una persona y nuestra organización, donde una misma persona puede ser a la vez socia y voluntaria), estos valores se dispondrán separados por comas en una misma casilla.


Normalización y compleción de datos

El paso de la normalización es uno de los más importantes del proceso de migración. Se entiende por normalizar garantizar que los valores de un determinado campo siguen una misma estructura y se representan siempre de la misma manera (mayúsculas, minúsculas, acentos, etc.).

Para normalizar una tabla de datos hay que ordenarla sucesivamente por las diferentes columnas normalizables. De esta manera resulta sencillo encontrar valores similares pero no iguales y corregirlos. También puede ser de ayuda utilizar la funcionalidad de filtrado que suelen ofrecer las aplicaciones de hoja de cálculo.

Igualmente, se puede aprovechar este proceso para completar masivamente campos vacíos. A modo de ejemplo, si se ordena una tabla por la columna de Población y se encuentra un conjunto de registros de la ciudad de Barcelona que no tienen provincia asociada, resulta muy sencillo asignarla a todos ellos de una sola vez.


Para ganar en eficiencia en las tareas indicadas en los dos apartados anteriores, se recomienda consultar el artículo Fórmulas de utilidad en las hojas de cálculo.


Eliminación o fusión de duplicados

Aunque el CRM tiene la capacidad de detectar duplicados entre la información ya importada en base a determinados campos clave (nombre, correo electrónico, etc.), es siempre recomendable realizar un primer proceso de depuración de posibles registros duplicados antes de la carga de los datos al sistema.

El método para hacerlo es ordenar por varias columnas (nombre de la entidad, nombre persona, mail, teléfono, web, etc.) y establecer fórmulas para detectar cuándo un valor y el de la fila siguientes son iguales, para que su localización sea sencilla.


Importación de datos

Cada módulo del CRM dispone de una función para importar datos externos sin tener que introducirlos manualmente.

Antes de iniciar el proceso es necesario que el archivo de datos que queremos importar sea convertido a formato CSV (Comma Separated Value, valores separados por comas). Cualquier aplicación de hoja de cálculo puede hacer esta operación de forma sencilla a través de las habituales funciones del tipo Guardar como...

El proceso es igual para todos los módulos:


1) Subir al servidor el archivo con los datos a importar.

- Como paso previo, el CRM permite descargar una plantilla de importación de archivos con las cabeceras apropiadas para facilitar el posterior mapeo (correspondencia) de campos y unos datos de ejemplo. En cualquier caso, no es obligatorio usarla.

- Antes de migrar los datos se deben crear en el módulo aquellos campos que el CRM no ofrece por defecto y que se han considerado necesarios por parte de la entidad (ver Incorporación, modificación y eliminación de campos). Si el módulo entero es nuevo, también habrá que haberlo creado (ver Creación de módulos nuevos).


29.jpg


En principio el sistema permite publicar registros nuevos y también actualizar registros existentes, pero en este caso haremos referencia sólo al primer proceso.


2) Indicar, si es necesario, las características globales de los datos subidos.


30.jpg


En este paso el CRM presenta una muestra de los dos primeros registros leídos del archivo subido, por lo que se puede comprobar que la primera carga se ha hecho bien. A través del botón Mostrar opciones avanzadas podemos fijar las opciones de migración que el CRM debe tener en cuenta: formatos de fecha y hora, de números, de moneda, etc.

Particularmente importante es determinar la [codificación] del archivo subido. Dicho sencillamente, la codificación es el mecanismo por el que las aplicaciones informáticas representan internamente los diferentes caracteres que contiene un texto. Si la codificación indicada en el proceso no coincide con la real (la de la hoja de cálculo que se importará), los caracteres especiales no se mostrarán correctamente en el CRM una vez terminada la importación. Las codificaciones más habituales son ISO-8859-1 y UTF-8 y el error más habitual es tomar una por la otra.

Cuando la codificación no está bien seleccionada, es habitual observar algunas disfunciones en los datos de muestra que aparecen en pantalla. A modo de ejemplo, en vez de leer un texto como este: Ángeles Suriñach, se leería uno como este: Àngeles Suriñach.

Cuando se observa una situación como ésta hay que escoger la codificación correcta a través de la lista desplegable Codificación de archivo que, como se ha indicado, aparece en la sección de Opciones avanzadas de este paso del proceso de importación.

De todos modos, en caso de que finalmente se importen los datos con la codificación errónea, siempre se le podrá indicar al CRM que la importación no ha sido correcta y que la deje sin efecto, pudiendo repetirla corrigiendo las opciones que sea necesario.

También es relevante indicar al CRM que el archivo subido contiene una fila de cabecera con los nombres de los campos, de manera que se pueda facilitar su relación posterior con los campos del CRM.

No es imprescindible que los nombres de los campos del listado subido coincidan exactamente con los del CRM mientras el usuario sea capaz de establecer las equivalencias correspondientes.


3) Relacionar las columnas del archivo subido con los campos del módulo del CRM.


31.jpg


En este paso aparece una columna a la izquierda con todos los campos presentes en el archivo, una columna en el centro con los campos equivalentes del CRM y una tercera columna a la derecha con datos de ejemplo extraídos del primer registro del archivo.

Así pues, habrá que indicar en la columna central sobre qué campos del CRM será necesario depositar los campos del archivo. Si hay coincidencia de nombres, el CRM ya mostrará directamente el campo oportuno. Si no es el caso, el usuario podrá hacer la selección manualmente.

Cabe tener en cuenta que SugarCRM ofrece la posibilidad de importar solamente una dirección de correo electrónico en el caso de las organizaciones y dos en el caso de las personas. La incorporación de direcciones adicionales deberá realizarse manualmente a nivel de cada registro. En última instancia, aunque es una operación que requeriría conocimientos técnicos, se podrían insertar directamente en la base de datos mediante consultas semiautomatizadas.


4) Indicar, opcionalmente, la voluntad de detectar registros duplicados.


32.jpg


En el último paso antes de la importación efectiva, el CRM permite indicar si se desea realizar un proceso de detección de duplicados en base a coincidencias en determinados campos clave (nombres, correos electrónicos, etc.). Si se considera necesario en función de la calidad percibida de los datos que se van a importar, se puede activar esta opción.

En caso de que el CRM detecte duplicados los presentará en pantalla y pedirá al usuario que determine el registro bueno o que genere una combinación de los valores disponibles en ambos registros.

Conviene tener presente que las operaciones de detección y fusión de duplicados se pueden hacer en cualquier momento y en cualquier módulo del CRM.


5) La importación se ha realizado.


33.jpg


Antes de dar por terminado el proceso de importación, el CRM ofrece la posibilidad de validar los datos subidos y dar marcha atrás si se detecta algún tipo de error.

Igualmente, si el CRM detecta directamente algún tipo de problema que impide la importación de determinados registros (direcciones de correo electrónico inválidas, campos requeridos no disponibles, campos normalizados con valores erróneos, etc.), los lista aparte y ofrece la posibilidad de descargar un archivo sólo con estos registros para que el usuario los pueda corregir y volver a importar.


Orden de importación de los datos

Como regla general, conviene tener presente que es necesario importar primer aquellos módulos que contienen datos que serán utilizadas posteriormente en otro módulo.

Veamos algunos ejemplos de secuencias de importación:

- Organizaciones -> Personas

- Personas -> Relaciones persona

- Organizaciones -> Relaciones organización

- Personas -> Formas de pago -> Pagos

- Personas / Eventos -> Inscripciones

Las secuencias anteriores pueden combinarse entre sí:

Organizaciones -> Personas -> Formas de pago -> Pagos

En síntesis, los datos se importarán según el orden siguiente:

- En primer lugar, las organizaciones.

- En segundo lugar, las personas.

- A continuación, el resto de módulos, priorizando aquellos cuyos datos van a ser utilizados en importaciones posteriores de otros módulos para la creación de relaciones.


Si al importar datos de módulos relacionados el CRM no encuentra en los módulos correspondientes los registros que esperaría encontrar para generar las relaciones, creará los registros necesarios de forma implícita.

Por ejemplo, si se importa un listado de personas y una de esas personas está asociada a una organización que no aparece en el módulo de Organizaciones, el CRM creará primero la organización (sólo con el nombre, ya que no tendrá otros datos), luego importará la persona y finalmente creará el vínculo entre ambas.


Ejemplos de importación de datos

Personas y Relaciones con personas

1) Supongamos que se dispone de un listado de voluntarios:


Importar ej01 img01 voluntarios.jpg


2) Y también de un listado de patronos:


Importar ej01 img02 patronos.jpg


3) Primero se importarán, por ejemplo, los voluntarios. Tal y como están los datos el listado ya es correcto, no hay que realizar ninguna operación previa especial de preparación; simplemente cargar el listado en el módulo Personas del CRM, mapeando los campos oportunamente según lo explicado en el apartado Importación de datos.

Si, por ejemplo, los campos Nombre y Apellidos estuvieran juntos en una única celda sería aconsejable separarlos en la hoja de cálculo antes de importar los datos al CRM.

Es importante notar que en el listado a importar no se hace referencia alguna a la condición de voluntarios de dichas personas. Esta información se reflejará posteriormente en el módulo de Relaciones con personas.

4) Una vez creadas las personas mediante la importación anterior, deberán crearse las relaciones mediante una importación en el módulo Relaciones con personas. Para ello se define un listado como el siguiente:


Importar ej01 img03 relaciones voluntarios.jpg


Cabe observar que existe un campo Persona resultado de unir los campos Nombre y Apellidos del listado original de voluntarios. Esta unión se puede conseguir fácilmente en Excel mediante una fórmula del tipo =CONCATENAR(A2;" ";B2), donde A2 y B2 serían las celdas que contienen, respectivamente, el nombre y los apellidos de la primera persona de la lista. Entre nombre y apellidos se añade un espacio en blanco para que no queden los textos pegados. Disponer de este campo Persona (con el nombre completo) es necesario para que cuando se realice la importación de las relaciones el CRM sea capaz de vincular adecuadamente cada relación con la persona correspondiente previamente importada.

Igualmente, se incorpora un campo Nombre, que en este caso corresponde al nombre de la relación (recordemos que se desea importar datos al módulo Relaciones con personas). Este campo podría contener cualquier valor (el CRM siempre requiere disponer de un campo Nombre en cualquier módulo), pero para que sea algo representativo se crea mediante una concatenación similar a la anterior, uniendo el nombre completo de la persona (que se ha obtenido en la concatenación anterior) y el Tipo de relación.

Cabe insistir en la idea de que en todos los módulos del CRM debe existir un campo Nombre que el CRM utilizará, por ejemplo, para enlazar a la vista de detalle de cualquier registro desde cualquier punto del sistema. Por esta razón, al crear un registro o al realizar una importación en cualquier módulo siempre debe indicarse un valor para el campo Nombre, aunque semánticamente (como en el caso de las relaciones que estamos describiendo) no sea un dato relevante en cuanto a aporte de información.

5) Se importa el listado anterior cargándolo en el módulo Relaciones con personas y mapeando los campos oportunamente. Como se indicaba en el punto anterior, el campo Persona (equivalente al nombre completo de la persona) es clave en este punto del proceso porque es el dato que va a permitir al CRM vincular la relación que se está creando con la persona adecuada que ha sido creada previamente al importar el listado inicial de voluntarios en el punto 3).

Después de realizar esta operación, en la vista de detalle de una persona debería apreciarse como en el subpanel de relaciones aparece la de voluntariado que se acaba de crear. Igualmente, debería aparecer el valor Voluntario en el campo Tipo de relación de la parte principal de la ficha.

Nota: Por claridad en el ejemplo se han generado dos listados (personas voluntarias y relaciones de voluntariado), pero no hay ninguna necesidad de que sean dos listados separados en dos ficheros distintos. Se podrían haber añadido en el primer listado los campos necesarios para generar el segundo y mantener un único listado. Finalmente, al realizar las importaciones, se habrían elegido en cada caso las columnas relevantes.

6) Se procede a continuación con el listado de patronos. Se observa que en el listado hay una persona, Pedro Fernández, que ya fue dada de alta en el CRM al importar los voluntarios. Cabe eliminar, pues, a esta persona del listado de patronos y proceder a la importación del resto en el módulo de Personas, igual como se hizo con los voluntarios en el punto 3).


Importar ej01 img04 patronos sin duplicados.jpg


7) Finalmente, se importarán las relaciones de tipo patrón de forma análoga a como se importaron las de tipo voluntario en el punto 5), con un listado como el siguiente:


Importar ej01 img05 relaciones patronos.jpg


Cabe observar que en el listado de relaciones sí vuelve a aparecer Pedro Fernández. En el módulo de Personas sólo debe figurar una vez, de ahí que no lo importáramos al importar el listado de patronos, pero en el módulo de Relaciones aparecerán dos a su nombre, una como voluntario y otra como patrón.


Personas, Formas de pago y Pagos

El proceso de importación de formas de pago, muy habitual cuando se traspasan al CRM listados de socios y donantes, es bastante similar al ya descrito para las relaciones con personas.

1) Inicialmente se importarán los datos de las personas, verificando que no se introducen duplicados.

2) A continuación se importarán los datos de las formas de pago. Para vincular las formas de pago con las personas adecuadas es necesario que en el listado de formas de pago aparezca una columna Persona (nombre completo de la persona) tal y como se ha descrito en el ejemplo anterior. También será necesario un campo Nombre para la forma de pago (ver, de nuevo, el ejemplo anterior).

Los campos que como mínimo deberían importarse son los siguientes: Nombre (de la forma de pago), Persona (u Organización), Tipo de pago, Medio de pago, Importe, Frecuencia y Fecha de primer pago. Si el Medio de pago es Domiciliación sera necesario importar también Número de cuenta y Mandato.

3) Cabe tener en cuenta que al importar las formas de pago se van a crear los primeros pagos vinculados a esas formas de pago (ver Pago inicial y estado de los pagos). En este sentido, no será necesario importar pagos futuros de forma explícita, puesto que una vez creada la forma de pago y el primer pago, el CRM se encargará de la generación sucesiva de nuevos pagos (ver Formas de pago, Pagos y Remesas#Planificador y pagos recurrentes).

4) Así pues, sólo es necesario importar pagos cuando sea necesario disponer de un histórico de pagos antiguos en el CRM.

Cabe tener presente que al importar pagos hay que poder relacionarlos tanto con las formas de pago a las que pertenecen como con las personas que los han realizado.

5) En la imagen siguiente se muestra una posible estructura de los datos a importar.

Importar ej02 img01 formas pago.jpg

Volver al índice