Por qué la seguridad no es el principal motor de la implantación de ECM en la actualidad

En el artículo I've seen the future of ECM, and it's not ECM, Joe Shepley -Vice Presidente en Doculabs - recoge su experiencia e impresiones acerca de cómo en el mundo de la Gestión de Contenidos Empresariales (ECM en sus siglas en inglés) la balanza se está desplazando desde la tecnología de la información y la gestión de documentos hacia la seguridad de la información.

Según Shepley, la seguridad de la información es la clave -por encima de la gestión de registros, la automatización de procesos o la gestión de documentos legales - que puede lograr el apoyo necesario a nivel de la organización para propiciar un cambio organizacional realmente significativo que permita florecer la industria del ECM.

En nuestra opinión, aunque es cierto que la seguridad sigue siendo una de las preocupaciones claves de los CTO y de los departamentos de IT, las empresas no adquieren software ECM en la mayoría de los casos para paliar los posibles riesgos de leaks, o pérdidas de información. 

De hecho, la seguridad sólo es el motivo principal de implantación de software ECM para empresas cuya política de gestión documental está muy poco desarrollada y no cuentan con políticas y tecnologías para la gestión de documentos.

De acuerdo con nuestra experiencia, los motivos que mueven a las empresas a implantar software de gestión documental y captura de documentos en su mayor parte están relacionados con la mejora o sitematización de procesos de negocio: customer onboarding, aprobación de presupuestos,  aprobación de facturas de proveedores, etc.

De hecho, si nos fijamos en la siguiente gráfica, de la AIIM, los motivos de seguridad (que podríamos englobarlos en el motivo Mitigación del Riesgo (Mitigate Risk), se encuentran en el 5to puesto cuando consideramos los principales factores que llevan a la implantación de software ECM.

 

El artículo hace una reflexiones interesantes sobre las dificultades que experimentan los proyectos de implantación de software ECM y de gestión documental para salir adelante en las empresas.

Shepley recalca que, sin el apoyo de la Dirección y los recursos financieros necesarios, la tecnología ECM queda relegada al tercer o cuarto puesto en las prioridades de las empresas, cuando las principales prioridades cambian cada año. Hay muchas razones para que esto sea así, una de ellas y no es que la mayoría de la gente no sabe lo que significa o lo que es ECM. 

En opinión de Shepley, "la industria del ECM tiene problemas para conseguir mayor financiación y el apoyo de los decision makers porque no se han construido suficientes casos de uso de negocio para ello. En muchos casos se han centrado sólo en ventajas como el ahorro de tiempo o el trabajo colaborativo con documentos usando términos difusos que los ejecutivos que toman las decisiones no compran. En otros, el valor de la tecnología se ha vinculado a mejoras tangibles para la empresa pero "asustando" a los tomadores de la decisión por la complejidad del cambio organizativo requerido. Los ejecutivos prefieren poner sus recursos financieros disponibles en iniciativas más directas que les ayuden a hacer más de lo que ya hacen en lugar de embarcarse en grandes transformaciones."

Este análisis del propio Shepley refuerza la idea de que es precisamente en los procesos de negocio en donde las empresas encuentran el mayor valor de las tecnologías ECM.

Sin embargo, Shepley insiste en que en la mayoría de las organizaciones, son los responsables de la seguridad de la información quienes cuentan con apoyo organizacional y la financiación necesaria que buscan destinar a la gestión de la información para mantenerla segura. Afirma Shepley que en los último 12-18 meses ha observado como esos responsables de la seguridad de la información han cambiado su punto de vista para incluir la gestión de la información de una forma más eficaz como un recurso para reducir la gravedad y el impacto de las incidencias cuando éstas suceden. 

El peso de la seguridad de la información dentro de la organización

Shepley bromea en su artículo acerca de que "ningún CEO ha ido nunca a la cárcel porque sus empleados no encontrasen lo suficientemente rápido los documentos" para poder de manifiesto que cuando las directrices las marca el responsable de la seguridad de la información de la empresa (CISO) tienen mayor probabilidad de llevarse a cabo -por el impacto que puede tener una pérdida o robo de información - que cuando vienen de los responsables de la gestión de los documentos. 

En cualquier organización que cuente con datos sensibles, el esfuerzo del responsable de seguridad de la información para proteger la información corporativa tiene dos líneas de acción: defender y minimizar el impacto. De acuerdo con el VP de Doculabs, es en esta segunda tarea donde la industria del ECM puede ser de gran ayuda a las organizaciones ya que la mejor manera de reducir el impacto de una brecha de seguridad o fuga de información es tener menos datos sensibles y, por supuesto, saber lo que se tiene y dónde para conocer el alcance de la incidencia cuanto antes.  Teniendo esto en cuenta, a los responsables de la seguridad de la información les preocupa determinar dónde almacenar los datos sensibles para gestionarlos mejor donde se encuentren almacenados. Además de poder eliminar la información redundante, obsoleta o transitoria ya que cuanta más información confidencial tengan que gestionar, más difícil es su trabajo. 

Tradicionalmente. la gestión de los datos sensibles ha significado construir accesos muy seguros alineado a una política de gestión de derechos de la información y de prevención de pérdida de datos. Pero también puede significar ofrecer a los usuarios una mejor interfaz con capacidades más robustas para que utilicen el sistema adecuado en lugar de soluciones provisionales y que una plataforma ECM puede proveer.

Necesidades de Negocio Frente a Motivos de Seguridad

Aunque la seguridad continua siendo una de las preocupaciones de los CTO y puede que estos consigan los recursos financieros necesarios para implementar software ECM abanderando el motivo de la seguridad, este motivo NO es la clave para ayudar a las empresas a competir en su mercado y, por tanto, a nivel estratégico y de negocio, abandona el papel protagonista. Por poneros un ejemplo, no es lo mismo justificar una inversión en un banco para que mediante software ECM la aprobación de créditos pase de tardar 20 días a tardar 2, que justificar que hay que hacer una inversión porque se traspapelan documentos.

Estos casos de uso de negocio te pueden resultar de interés: 

Caso de Uso: Clasificación automática de Documentos Legales

El Reto Tecnológico de la Gestión de Facturas

Los Retos de la Banca en Gestión Documental

Caso de Uso: Clasificación automática de Documentos Legales

La clasificación de documentos es una tarea que resulta compleja para muchas industrias por el volumen y complejidad de los documentos con los que trabajan. Si bien, una clasificación eficiente de esos documentos resulta clave para poder organizarlos y explotar la información que contienen. 

Un ejemplo de compañías para las que clasificar documentos es una tarea problemática son aquellas que realizan actividades dentro del sector legal, relacionadas con la justicia, la regulación u otros. 

Estas empresas se encuentran con importantes retos a la hora de clasificar sus documentos incluso  si lo llevan a cabo de forma manual: 

• Sus documentos contienen textos que son difíciles de catalogar. 
• Suelen ser documentos no estructurados. 
• La identificación de cada tipo de documento implica tener cierto conocimiento de la materia. 

Clasificación automática de documentos legales

La buena noticia para este sector es que es posible automatizar la clasificación de documentos legales. Athento Smart Engine - la herramienta de captura de documentos de Athento - es capaz de clasificar documentos de forma automática. 

Para el caso concreto de los documentos de juicios como mociones, escritos, órdenes o alegatos es posible configurar expresiones regulares (patrones de texto que aparecen frecuentemente en los documentos catalogados dentro de un determinado tipo documental) que Athento SE analiza para clasificar los documentos de forma inteligente, con una tasa de éxito en la clasificación de más del 90%. Además, la configuración de esas expresiones regulares se realiza desde la propia interfaz de Athento con un manejo sencillo e intuitivo.

Para explicar este Caso de Uso de clasificación automática de Documentos Legales hemos preparado un paper en el que os contamos:

• La clasificación automática basada en expresiones regulares.
• Ejemplos de clasificación automática de documentos de juicios en función de su tipo documental y de su relevancia para el caso/expediente.
• Cómo configurar la clasificación en la interfaz de Athento.

Puedes descargar ya el caso de uso desde el siguiente enlace: Clasificación Automática de Documentos Legales

Recogida de Requisitos de Proyecto: 3 Lecciones Aprendidas

En esta entrada quiero hacer una reflexión sobre el proceso de recogida de requisitos para proyectos software. Sobra señalar la importancia de esta fase, que bien puede definir el éxito o el fracaso de un proyecto.

“La recogida de requerimientos puede definir el éxito o el fracaso de un proyecto software”

El perfil o rol de la persona que lleva a cabo esta recogida de requisitos suele variar. Puede ser un ingeniero pre-venta, en muchos casos el mismo comercial, y en otros, un analista o consultor. En cualquier caso, el objetivo es el mismo: Entender lo que el cliente busca y necesita, para poder plantear un diseño técnico que satisfaga sus expectativas.

Aunque fácil de definir, el objeto de la fase de recogida de requisitos es complejo de alcanzar. Por múltiples razones, parece a veces un abismo insalvable entre los que trabajamos en la industria del software y nuestros clientes. El reto pues de quien asume el rol de recoger los requisitos es salvar a toda costa ese abismo y conseguir entender de verdad lo que el cliente necesita. 

A continuación, quiero compartir con vosotros algunas de las lecciones que yo he aprendido y que son fundamentales a la hora de construir puentes de entendimiento con el cliente y alcanzar recoger toda la información que se necesita para garantizar que el diseño no esté construido sobre falsas premisas o vacíos de información:

El lenguaje del cliente y del especialista no tienen por qué coincidir

Hace poco, en un proceso de venta complejo, nos encontramos con un cliente pidiéndonos ser exhaustivos con la trazabilidad en el diseño de la solución. Teniendo un concepto claro de la trazabilidad en nuestro ámbito, respondimos al RFP aportando pruebas sobre cómo nuestro software permite mantener una trazabilidad de los documentos. Para nuestra sorpresa, el posible cliente no quedó satisfecho con lo que le decíamos. Insistía con la trazabilidad y se hizo patente que cuando hablábamos de trazabilidad, el cliente hablaba de una cosa y nosotros de otra. No cuestionamos nuestro concepto de trazabilidad porque lo conocemos bien, pero lo que debimos preguntarnos antes fue: ¿estamos hablando de la misma cosa? El cliente no tiene por qué conocer la jerga técnica de nuestro negocio. No podemos esperar que entienda los conceptos con los que nosotros trabajamos todos los días, porque a nosotros también nos cuesta entender los conceptos de su negocio. No hablamos el mismo idioma, nos guste o no, y nuestro reto está en sacar el mensaje claro más allá de las dificultades del idioma. La recomendación aquí es aparcar los tecnicismos y hablar en un lenguaje plano que las dos partes entendamos perfectamente.


Entender la importancia que ha de tener cada hito desde el punto de vista de negocio tanto como desde el punto de vista técnico.

Cada hito del proyecto tiene un impacto y una importancia diferente en relación con el negocio del cliente. Pero esto va más allá del aspecto técnico. La importancia de la que hablo no se refiere a que algunas tareas tienen otras dependientes y de allí su importancia. No. Estoy hablando de la importancia que la tarea tiene para los procesos del cliente. Con base en esa importancia deberemos ajustar la planificación más allá de un orden puramente limitado por el componente técnico. Si para el cliente hay una funcionalidad que es crítica para uno de sus procesos más importantes, deberemos priorizarla frente a otras que no lo son tanto y que, tal vez, nos resultan más cómodas y fáciles de realizar primero. Esto hace parte de entender las necesidades del cliente, su negocio y lo que espera de nosotros como proveedor tecnológico. La clave está pues en identificar cuáles de los hitos tienen mayor importancia para el negocio del cliente.
  
La importancia de los procesos de consultoría y su relación con la tecnología.

Muchas veces nos presentamos a licitaciones o concursos privados para ofertar soluciones tecnológicas complejas. Cuando nos presentamos, conocemos sólo la punta del iceberg de lo que el cliente realmente necesita. Nuestras estimaciones y propuestas están supeditadas a qué tan exhaustivo fue el cliente en la descripción de su situación actual, necesidades y expectativas en un RFP. El problema es que muchas veces el cliente en sí mismo desconoce buena parte de la información. Por ejemplo, no sabe cuántos usuarios van a interactuar finalmente con el sistema o cuál es la mejor manera de resolver un cuello de botella que tienen en un proceso. Aquí es importante entender que los clientes no nos contratan como vendedores de software, sino con expertos en el software que vendemos. Esperan que tengamos experiencia con empresas como la suya y que nos podamos anticipar a darles las respuestas con las que ellos ahora mismo no cuentan. Para nosotros, llegados al punto de responder a un RFP es una situación dura en la que nos toca todo el tiempo suponer, en base a nuestra experiencia qué solución podría funcionar para el cliente. Sin embargo, entre más complejo el problema o proceso, menos nos podemos permitir tener vacíos de información. Es aquí donde los procesos de consultoría cobran un valor fundamental. La consultoría nos ayuda a entender lo que el cliente necesita, a averiguar detalles que el cliente desconoce, detectar riesgos, y contar con un escenario detallado sobre el que los clientes y nosotros como proveedores estemos de acuerdo antes de enfrentarnos a la fase de desarrollo y customizaciones.