Estrategias ECM en las compañías

A continuación, vamos a hacer un breve repaso sobre las aproximaciones más comunes que realizan las empresas a la hora de implementar ECM en sus organizaciones, así mismo, haremos recomendaciones sobre las mismas.

Un único sistema ECM para toda la compañía

Este es sin duda una estrategia recomendada. Tener diferentes sistemas ECM da lugar a los silos de información y estos, a su vez, impiden la explotación transversal de la información de la organización. Ahora bien, hay que hacer claridad en que cuando se implemente por primera vez un software ECM o de gestión documental, tendremos que ser cuidadosos a la hora de abordar el proyecto. A veces, quienes dirigen los proyectos tienden a ser muy ambiciosos y pretenden abarcar al mismo tiempo el paso al uso del nuevo sistema. Estos líderes de proyecto suelen encontrarse con mucha reticencia al cambio y grandes obstáculos. Nuestra recomendación es un único ECM para la organización, pero una adopción gradual y planificada que vaya teniendo en cuenta las necesidades de cada área. ¿Por dónde empezar? Mi recomendación es empezar por los procesos más dolorosos y en los que puede verse mayor beneficio con la implementación del gestor documental: Si el proyecto va bien será un testimonio interno fantástico de la valía del software, además estos usuarios estarán más prestos al cambio pues conocen las ineficiencias del proceso actual.

Un único sistema ECM como respaldo al sistema de información de la compañía

Este es un escenario igual que el anterior, pero bastante más ambicioso, porque implica que todas las herramientas tecnológicas de la organización delegan en el ECM la función de repositorio centralizado de documentos. Es decir, estamos hablando de un escenario de integración entre el gestor documental y las aplicaciones de negocio de la empresa.

Este escenario cobra cada vez más fuerza. Algunos de nuestros clientes como Páginas Amarillas cuentan con más de una decena de aplicaciones en constante interacción con el gestor documental.

¿Qué ventajas tiene esta estrategia?

• Facilita la explotación de la información porque está toda centralizada
• Simplifica la gestión de múltiples repositorios
• Permite la trazabilidad de negocio de los documentos
• Facilita la gestión de copias de seguridad y manejo de contingencias
• Evita la redundancia de datos
• Permite la normalización de la información
• Permite establecer y consolidar políticas de retención globales para la organización
• Facilita el trabajo a los usuarios, dado que sólo tienen que trabajar con una única solución.

Qué retos tiene este enfoque?

• La disponibilidad del gestor documental se vuelve crítica
• Hay una mayor exigencia del sistema a nivel de rendimiento y consumo de recursos
• Requiere un buen diseño de las integraciones.

Un sistema ECM para resolver un proceso de negocio

Este es un enfoque que suelen seguir muchas compañías. Se trata normalmente de digitalizar un proceso de negocio concreto que es intensivo en gestión de documentos. Por ejemplo, empresas como Barclays o Equifax gestionan en Athento el proceso de Customer Onboarding o Captación de Clientes, y FCC gestiona procedimientos legales.  Usualmente, en estos casos, el beneficio es percibido de forma más clara porque es más fácil medir el problema y su solución. Estos proyectos suelen requerir bastante customización para adaptar el gestor documental a las necesidades del proceso y en bastantes casos, requiere a las personas adaptar su forma de trabajar, por lo que hay que hacer un esfuerzo importante en formación. Lo positivo de usar el gestor documental en procesos de negocios concretos es que los cambios y eficiencias suelen ser muy notorios en cuanto a:

• Duración del proceso
•  Costes del proceso
•  Explotación de la información

La recomendación aquí es hacer un muy buen diseño de la solución y poner mucho esfuerzo en soporte y formación de usuarios.

Un sistema ECM gestionado a nivel de departamento o unidad

Este enfoque puede llevar a las empresas a terminar con diversos sistemas de gestión documental en uso. La gestión documental no se suele considerar a nivel global de la organización, sino que cada unidad o departamento trata de resolver su problema de gestión documental conforme sus tiempos y urgencias. No recomendamos el uso de esta estrategia.

Un sistema compartido por las diferentes sedes, pero al mismo tiempo diferenciado

Este suele ser un escenario común en multinacionales, grupos de empresas, lobbies, o empresas en general que tengan distintas sedes. Lo positivo de este enfoque es que permite tener toda la información corporativa centralizada, pero al mismo tiempo, sistemas ECM como Athento permiten mantener aislamiento de los datos para que los usuarios de cada sede sólo vean lo que les corresponde. Además, permite a las distintas sedes gozar de los beneficios y funcionalidad que se desarrolle para cada una de ellas. Organismos como Corporinoquia en Colombia tienen dividida su documentación por cada una de sus sedes geográficas en Athento ECM.

Realizar consultas eficientes

Hoy vamos a explicar un poco un tema que suele pasar desapercibido pero que cobra gran importancia cuando queremos poner en valor la información que tiene nuestro sistema. Vamos a verlo con un ejemplo, que siempre es más sencillo.

Cortesía de Pixabay.com

Supongamos que nuestro sistema almacena información sobre facturas. Algunos datos típicos pueden ser:

• Referencia.
• Fecha.
• Emisor.
• Receptor.
• Concepto.
• Importe.
• Descuento.
• Total.

Podríamos tener los siguientes valores de metadatos para unos cuantos documentos.

Referencia	Fecha	Emisor	Receptor	Concepto	Importe	Descuento	Total
12723	12/07/2007	Teleco	Manuel Sánchez	Servicios de ADSL y telefonía	37,86	12,34	25,52
22538	21/09/2010	Teleco	Juan Márquez	Servicios de ADSL y telefonía	52,12	20,00	32,12
49347	17/01/2012	Teleco	María Santos	Servicios de ADSL y telefonía	24,12	5,20	18,92
78122	02/12/2013	Teleco	Luisa Estévez	Servicios de ADSL y telefonía	42,12	9,11	33,01

Consultar el sistema, ¿para qué?

Imaginemos que la dirección de la empresa Teleco, decide fidelizar a aquellos clientes que tengan un descuento superior a 10 EUR. Para ellos, necesitamos conocer saber cuáles facturas tienen en su campo "descuento" un valor superior al indicado. Esto se consigue con una consulta.

Vale, y ¿cómo lo hago?

Cualquier sistema de información dispone de una forma de consulta (todo el mundo conoce la elegida por Google). Este sistema puede ser más o menos sofisticado y permitir consultas más o menos complejas. Athento ofrece un sistema bastante intuitivo, flexible y muy potente para realizar estas consultas. Por ejemplo, para obtener la información que buscábamos en el punto anterior, bastaría escribir algo como esto en la consulta al sistema:

SELECT * FROM Invoice WHERE invoice:discount > 10

Esto nos devolverá todas las facturas cuyo descuento sea superior a 10 EUR. Pero no es suficiente, entre los resultados el sistema nos devolverá también aquellas facturas que hayan sido borradas (traducido al lenguaje de consulta, esto es ecm:currentLifeCycleState = 'deleted').

Por tanto, ya tenemos que añadir alguna cláusula más a la consulta para obtener los datos que realmente queremos. Si además, queremos introducir condiciones presentes en otros esquemas de datos, debemos añadir más información a la consulta.

Por ejemplo, es fácil imaginar que las facturas además de la información vista anteriormente, almacenen datos de contacto del cliente como dirección postal, teléfono de contacto o dirección de correo electrónico. Si quisiéramos incluir en la consulta únicamente aquellas facturas que dispongan de correo electrónico informado para poder hacer una campaña de mailing, la consulta quedaría así:

SELECT * FROM Invoice WHERE invoice:discount > 10 AND ecm:currentLifeCycleState != 'deleted' AND customer:email != null

Luego veremos qué problemas puede tener esta consulta.

Eficiencia en la consulta, motivos para darle importancia

En este ejemplo estamos lanzando la consulta de forma manual, pero esto no se aproxima mucho a un caso real. Lo habitual, es que sean procesos automáticos los que lancen las consultas y procesen los resultados haciendo algo útil con ellos (el envío de correo, envío de SMS, inclusión en informes, etc.).

Cuando el sistema lance esta consulta varias veces por minuto, a la vez que lanza otras tantas de otros procedimientos automáticos, el sistema se volverá lento si no le ayudamos a buscar los datos de forma eficiente. Si además, las consultas obtienen como resultado un número elevado de registros, seguro que estamos perjudicando innecesariamente el rendimiento.

Y el tiempo es dinero y nadie quiere un sistema lento, ¿verdad?

Cómo hacer una consulta eficiente

Una consulta en Athento ECM tiene el siguiente formato:

SELECT [metadatos a visualizar]
FROM [tipo documental]
WHERE [[condición de selección] AND|OR [condición de selección] AND|OR [condición de selección]...]
[ ORDER BY [[metadato], [metadato],...]

Podemos establecer unas normas básicas para hacer una consulta:

1. Obtener exactamente los resultados que necesitamos. Si nos interesan 145 resultados, la consulta debe obtener exactamente esos 145 resultados. Volviendo al caso del mailing, si en el resultado incluimos algún registro sin dirección de correo electrónico, no fallará nada (el email no será enviado), pero estaremos desperdiciando el rendimiento del sistema en algo inútil. Por tanto, como norma general, hay que ajustar las cláusulas de la consulta todo lo posible.
   
   
   Algunas cláusulas relevantes para los documentos de Athento, son las siguientes:
   ecm:mixinType != 'HiddenInNavigation' 
   AND ecm:isVersion = 0 
   AND ecm:isProxy = 0 
   AND ecm:currentLifeCycleState != 'deleted'
   
   
   El esquema ecm contiene información relevante sobre el estado del documento como si se trata de una versión o si es un documento oculto o "enlace" (proxy) a otro documento. La cláusula del ciclo de vida también puede ser muy importante para hacer una consulta cuando los documentos siguen un ciclo de vida (aprobado, validado, revisado, publicado, etc.).


2.  Utilizar las condiciones más restrictivas al comienzo. Esto facilitará al sistema la planificación de la consulta. Aunque ya cuenta con planificadores que eligen la mejor estrategia, nunca está de más hacerlo coherente. Además, facilitará su comprensión. Por ejemplo, si el dato más restrictivo es el email (porque hay pocos clientes con valor en el campo email), podríamos filtrar primero por este campo.
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND customer:email != null AND invoice:discount > 10 AND ecm:currentLifeCycleState != 'deleted'
3. Involucrar el menor número de esquemas posible. Cada esquema es almacenado en una tabla de la base de datos y juntarlas es caro en términos de rendimiento. Si hacemos al sistema saltar de una a otra, será más costoso y tardará más. Por ejemplo, si disponemos de alguna información similar en un metadato de un esquema que ya estemos utilizando, es preferible no cambiar de esquema. Supongamos que el email está informado también en el esquema invoice, cambiaríamos la consulta como sigue:
   
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount > 10 AND ecm:currentLifeCycleState != 'deleted'
   
   
   De este modo, no es necesario acceder a los datos del cliente, sino únicamente a los de la factura.
4. No ordenar los datos si no es estrictamente necesario. Por ejemplo, en una consulta para obtener informes sí que nos interesará mantener algún orden, ya que lo va a leer una persona y encontrará más fácilmente los datos si los ordenamos por antigüedad o por orden alfabético. 
   
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount > 10 AND ecm:currentLifeCycleState != 'deleted' ORDER BY invoice:date DESC
   
   Si en el resultado no es importante el orden, mejor excluímos la cláusula ORDER BY.
5. Usar condiciones incluyentes. En una cláusula numérica, esto puede ser más relevante de lo que parece. En nuestro ejemplo, el sistema buscará para todos los documentos, el valor de invoice:discount y comprobará que supere el valor 10. Sin embargo, si sabemos que no hay descuentos entre los 9 y 10 EUR, podemos hacer algo así:
   
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount >= 9 AND ecm:currentLifeCycleState != 'deleted' 
   
   
   Esta consulta le permite al sistema ordenar los resultados por el campo discount y escoger todos los que queden por encima del 9 (que son los de 10 o más EUR de descuento), mejorando el rendimiento de la consulta.
6. Evitar el uso de comodines. Es una práctica habitual cuando uno quiere encontrar rápidamente un registro el uso de comodines. En Athento es posible hacer estas consultas con el carácter '%' y el operador LIKE o ILIKE. Por ejemplo, si queremos únicamente los apellidos que comiencen por A para la campaña de mailing, podríamos hacer esto:
   
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount >= 9 AND ecm:currentLifeCycleState != 'deleted' AND customer:surname1 LIKE 'A%'
   
   
   Esto nos filtrará el resultado dejando únicamente aquellos registros cuyo campo primer apellido comience por A. Sin embargo, es una consulta muy costosa en términos de rendimiento y hay que tratar de evitarla. 
   
   
   Una posible solución, es incluir un nuevo campo que nos ayude a encajar al cliente en un "grupo de mailing". Como además, ya sabemos que hay que evitar los cambios de esquema, podríamos denominar a este campo invoice:mailinggroup y darle un valor inicial al cargar la factura por primera vez en el sistema en función de su primer apellido.  De este modo, transformaríamos la consulta en:
   
   SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount >= 9 AND ecm:currentLifeCycleState != 'deleted' AND invoice:mailinggroup = 'A'
   
   Que resulta mucho más eficiente en términos de rendimiento.
7. Evitar el uso de negaciones. Es mucho más rápido para el sistema determinar una coincidencia que afirmar que no existe coincidencia. Suponiendo que quisiéramos obtener las facturas cuyo importe NO supere los 30 EUR, es mejor decirle al sistema:
   invoice:total <= 30
   que
   NOT (invoice:total > 30)
   
   
   El operador NOT introduce una nueva operación sobre cada resultado. Si existe complementario, hay que hacer lo posible por usarlo. Y si no existe, lo posible por crearlo ;-).
    
8. Tipos de datos. El tipo de valores que puede almacenar un campo es también importante a la hora de tener en cuenta el rendimiento. Por ejemplo, al sistema le cuesta menos manejar números que letras o palabras. Es más rápido decidir que 1 es menor que 2 que decidir que "África" va antes que "Europa". Por ello, a la hora de diseñar el sistema, hay que tener en cuenta estos tipos y usar siempre que sea posible campos numéricos o letras antes que palabras o textos largos (como una descripción) en las consultas. Para ilustrarlo, establecer un filtro por el campo concepto, no tiene mucho sentido y seguramente nos exigiría el uso de comodines desaconsejado como ya hemos visto:
SELECT * FROM Invoice WHERE ecm:mixinType != 'HiddenInNavigation' AND ecm:isVersion = 0 AND ecm:isProxy = 0 AND invoice:email != null AND invoice:discount >= 9 AND ecm:currentLifeCycleState != 'deleted' AND invoice:mailinggroup = 'A' AND invoice:concept = 'Servicios de ADSL y telefonía'


Obligar al sistema a filtrar por este campo hará la consulta más ineficiente puesto que tiene que revisar cada letra de cada palabra de la frase 'Servicios de ADSL y telefonía". Por tanto, en la medida de lo posible, utilizar numéricos o letras.




 Limitar el número de resultados. Es habitual que nuestras consultas obtengan un número elevado de resultados. Si el sistema dispone de algunos millones de documentos, casi con toda seguridad, cualquier consulta con sentido, obtenga unos cientos de miles. Es por ello que, conviene dividir el resultado en bloques que permitan una mejor gestión. Por decirlo en términos sencillos, "mejor pedir 100 veces 1000 resultados que pedir 1 vez 100.000 resultados". Para preparar una respuesta tan grande, el sistema necesitará muchos recursos (CPU, memoria y sobre todo, tiempo).
Las consultas en Athento se pueden hacer de 2 formas:

- Navegando en el sistema, en cuyo caso ya disponemos por defecto de la opción de decidir el tamaño de página.
- Vía API, en cuyo caso es conveniente añadir los siguientes 2 parámetros a la consulta:


/site/api/v1/query?pageSize=1000&currentPageIndex=1&query=SELECT ...


De este modo, podemos pedirle al sistema las páginas de 1 en 1 cambiando el parámetro currentPageIndex.


9. Revisar, revisar y revisar. Y probar las consultas muchas veces con diferentes variantes comparando resultados que permitan establecer cuál es la mejor estrategia para cada caso. Los puntos anteriores son sólo orientativos, es posible que en algún caso concreto saltarse alguno de estos consejos pueda ser beneficioso.

También te puede interesar conocer Cómo Athento ECM aplica la tecnología Elastic Search, una de las principales tecnologías en cuanto a motores de búsqueda, para mejorar el rendimiento de la plataforma y la experiencia de los usuarios cuando necesitan acceder a información.