 Anuncio de la publicación de Moreq2010- – MCR “Moreq2010 Compliant Record System”
Especificación europea para los proveedores de software y aplicaciones de negocios que gestionen documentos
Dña. María del Valle Palma Villalón
Directora de Docugrupo
El DLM MoReq Governance Board (MGB) acaba de publicar la nueva norma MOREQ2010, especificación que define las aplicaciones de gestión de records (documentos) como un conjunto modular de requisitos.
La Comisión Europea apoya al MGB mediante el Expert Review Group, con sus representantes internacionales en Europa, Estados Unidos, Canadá y Australia.
Esta especificación incorpora un nuevo acrónimo, MCRS, “MoReq2010 Compliant Records System” que es más específico que ERMS (Electronic Records Management System) o EDMS (Electronic Document Management Systems) o ECM (Enterprise Content Management).
MCRS significa que el producto es conforme con Moreq2010, que ha superado la certificación realizada por un centro de testeo independiente acreditado por el DLM FORUM y que la empresa puede publicar el certificado del DLM FORUM.
Los fabricantes de software de gestión documental podrán presentar sus productos para ser certificados a nivel europeo e internacional con respecto a esta norma. En estos momentos se está creando la infraestructura necesaria para facilitar esta certificación.
Además de ser un elemento diferencial y competitivo para aquellos productos que se certifiquen, en nuestro sector esta norma puede servir de guía para los servicios de consultoría tanto para la implementación de sistemas de gestión de records (documentos) o como para su integración en los sistemas de negocios.
También puede utilizarse para otros fines: empresas e instituciones que estén iniciando procesos de implantación o ya tienen funcionando aplicaciones de negocio y sistemas de gestión de documentos para autoevaluarlos, por los expertos como un documento de referencia para la formación, para los usuarios como fuente para entender un sistema de gestión de records etc.
La mayor innovación del MoReq2010 es la sustitución del concepto de Modelo de Requisitos por Requisitos Modulares que permite adaptarlo a necesidades específicas de los proveedores y usuarios, seleccionando y combinando los módulos que aparecerán posteriormente.
Moreq2 se basaba en un central y único repositorio, el Moreq2010 reconoce que existen más tipos de estructuras: sistemas de gestión de records (documentos) que se encuentran integrados en aplicaciones de negocios o las mismas aplicaciones de negocios que gestionan documentos.
Es necesario advertir que previamente a su implantación las entidades deberían planificar sus sistemas de gestión de records, es decir, establecer sus políticas, estrategias y procedimientos tomando en consideración las normativas internacionales. La adquisición del software certificado conforme a esta norma le asegurará que podrá implementarlos adecuadamente.
La estructura de Moreq2010 es más flexible que la del Moreq2, presenta un conjunto de servicios centrales y comunes que comparten la mayoría de los tipos de sistemas de gestión de records (documentos). Estos servicios son modulares y escalables y facilitan su incorporación en otras aplicaciones altamente especializadas y dedicadas (a las que no se las suele conocer como propiamente de gestión de records).
La gran ventaja que presenta esta especificación es su gran flexibilidad y escalabilidad para la implementación de sistemas de gestión de records (documentos) en entidades de diversos tipos - grandes o pymes o con estructuras organizativas simples, complejas y cambiantes - ya que posee una mayor capacidad de adaptación a sus necesidades específicas.
La arquitectura de Moreq2010 se basa en servicios. El núcleo central de servicios se compone de 9 servicios definidos con un conjunto de requisitos funcionales:
- Servicios de sistemas
- Servicios de usuarios y grupos
- Servicios de modelo de roles
- Servicios de clasificación
- Servicios de records (documentos)
- Servicios de metadatos
- Servicios de calendarios de disposición (conservación, eliminación)
- Servicios de búsqueda e informes
- Servicios de exportación
Tomados en su conjunto definen las funcionalidades de un MCRS. Moreq2010 no pretende que los proveedores de software desarrollen soluciones que cumplan todas las funcionalidades de todos o cada servicio del núcleo juntos y distribuirlas mediante una única aplicación, facilita que en un futuro se puedan desarrollar sistemas de gestión de records en los que cada servicio se desacople de otros y pueda compartirse entre varios MCRS. Por ejemplo, compartir el mismo servicio de clasificación o de disposición, o también construir un MCRS con diferentes servicios de diferentes proveedores integrados juntos. El servicio de records es el único que no podrá compartirse entre diferentes MCRS.
Estos servicios gestionan entidades, por ejemplo:
-
El servicio de clasificación gestiona unas entidades que son las clases (series de un cuadro de clasificación jerárquico o las palabras clave de un lenguaje controlado o los descriptores de un tesauro)
-
El servicio de records (documentos) gestiona los records y sus agregaciones (agrupaciones de documentos)
-
El servicio de metadatos gestiona metadatos
- El servicio de disposición los calendarios de conservación o eliminación
Algunos servicios no gestionan entidades como los de exportación e informes o búsquedas.
Dos de los servicios del Moreq2010 son servicios modelo (4. Model Role Service y 7.Model Metadata Service). El Model Rol Service representa sólo un posible acercamiento al control de acceso, ya que se reconoce que existen modelos preexistentes de sistemas de gestión de records que pueden ser conformes. Esto significa que aunque la especificación proporciona un conjunto de requisitos funcionales por defecto, no requiere que los proveedores implementen estos servicios exactamente como están especificados, excepto si desean soportar módulos avanzados, tales como el módulo de importación.
La segunda parte de Moreq2010 se dedica a las tres áreas dónde se especifica la funcionalidad de los módulos plug-in: 100. INTERFACE SERIES (Graphical Users interface) 200. CLASSIFICATION SERIES, 300. COMPONENT SERIES (electronic components).
Estos módulos plug-in representan una alternativa, pero igualmente válida. Están formados por un conjunto de funcionalidades que logran el mismo objetivo pero de diferente forma, los proveedores pueden elegir el enfoque que deseen, cada MCRS debe proporcionar y ser certificado, contra, al menos una implementación de funcionalidad.
Las interfaces gráficas de los MCRS son ejemplos de las áreas en las que se especifican las funcionalidades de los módulos plug-in. Los usuarios no necesariamente deben interactuar con las interfaces de los MCRS, podrían interactuar con las de los sistemas de negocios, y éstos a su vez, mediante una API con la del sistema de gestión de records.
El núcleo de servicios se podrá ampliar con nuevos módulos cuando se necesite. En un futuro el MoReq Governance Board se propone desarrollar otras series de módulos que cubrirán otros tópicos tanto genéricos como específicos (salud, finanzas, etc).
Aunque esta norma describe fundamentalmente los requisitos funcionales, también dedica un apartado a los requisitos no funcionales: desempeño o rendimiento, escalabilidad, gestionabilidad, disponibilidad, fiabilidad, recuperabilidad (en el sentido de copias de seguridad).
La interoperabilidad es esencial ya que estos sistemas deben conservar y preservar documentos a largo plazo, uno de los principales problemas a resolver es la obsolescencia de la tecnología que obliga a refrescar los sistemas cada tres o cinco años, o a cambiarlos cada 15 o 25 años.
La exportación de Moreq2010 es más consistente que en Moreq2. Esta exportación requiere un alto nivel de sofisticación, ya que estos sistemas deben migrarse periódicamente (y no sólo los documentos) en formatos XML, a otras versiones o a otros productos MCR. La interoperabilidad en un futuro no se confinará a la transferencia de los records sino en la exportación de los servicios que comparten los records. Asimismo, cada entidad es autocontenida o atómica, esta característica permite su transferencia a otros MCR.
La conformidad de un producto con Moreq12010 supone una muy alta cualificación porque significa que será interoperable con cualquier otra solución MCRS, por tanto, podrá compartir un lenguaje común. En general, los sistemas de gestión de records (documentos) sólo entienden su lenguaje propietario.
Moreq2010 facilita la implementación de diferentes tipos de sistemas de clasificación. El servicio de clasificación es el responsable de gestionar y mantener cada sistema de clasificación, en este servicio las clases son las entidades. Si este mismo cuadro de clasificación se comparte a través de distintos sistemas de negocios, la entidad sólo gestionará uno central y único. En el caso de que se necesiten gestionar varios sistemas de clasificación se aconseja para una mayor consistencia que se cree un servicio por cada sistema de clasificación.
Los sistemas de clasificación que presenta esta especificación son más flexibles, ya que no obligan al uso de un sistema de clasificación jerárquico, aceptan también, otros como el Keyword AAA, un sistema de clasificación funcional expresado en una estructura polijerárquica derivada de la ISO 2788 –Tesauros monoligües. Cada MCRS puede implementar los requisitos del capítulo 5.4 y al menos uno de los módulos de los plug-in 200 Classification Series.Todos los sistemas de gestión de records (documentos) deben disponer de al menos un sistema de clasificación. Todos los records deben ser clasificados desde el momento de su creación, por tanto se les debe asignar a una clase. Los calendarios de disposición (conservación y eliminación) son obligatorios para cada clase.
Resaltar la gran flexibilidad que presenta Moreq2010 (en relación con Moreq2) con respecto a la agregaciones de records (documentos). El servicio de records (documentos) es el de mayor nivel. Los records (documentos) se pueden agrupar en agregaciones heterogéneas, que pueden ser de cualquier tipo, para diferentes propósitos, según necesidades operativas o por limitaciones técnicas. Por ejemplo, una agregación por cliente, o una agregación que se visualizará de la misma forma en una sede web (biblioteca online). Cuando la agregación comparte el mismo contexto de negocios, entonces se le podrá asignar directamente una clase del cuadro de clasificación y heredará por tanto su calendario de disposición y sus metadatos (es aconsejable para agregaciones con un gran volumen de records). Las agregaciones pueden, además, estructurarse en otras agregaciones.
Los records se definen mediante metadatos, su historia de eventos, sus componentes y sus listas de control de acceso (o equivalentes). Las historias de eventos registran las claves de los eventos acaecidos desde que se creó por primera vez el record, proporcionan la procedencia y son parte esencial para establecer su autenticidad.
Si dentro de un MCR, un record se copia a otro sin duplicar su historia de eventos, no representa un record completo. El proceso de duplicación, por tanto, es más complejo, porque además, debe especificar cuál es el original y cuál la copia. En general, las entidades necesitan que se dupliquen los records para agruparlos en más de una agregación, cuando esto ocurre cada apariencia semejante debe aparecer como un duplicado con: su clasificación, sus derechos, su calendario de disposición, su agregación padre, sus entidades componentes, controles de acceso, historia de eventos, título, descripción y otros metadatos. El MCRS podrá decidir si el contenido se duplica y si se mantiene mediante un sistema de punteros.
En relación a la gestión del calendario de disposición de los records, el MCR pretende eliminar los conflictos que se pueden producir cuando coinciden dos tipos de plazos para la eliminación de un mismo record (según el Moreq2). A los records sólo se les puede asignar un único calendario de conservación y eliminación, sin ambigüedad.
El modelo de información normalizado:
- Cada entidad se describe con la siguiente estructura: System Identifier, Title, Description, Service, System y functions y Metadata
- Los tipos de entidades: Aggregation, Class, Component, Contextual Metadata Element Definition, Disposal Hold, Disposal Schedule, Entity Type, Event, Function Definition, Group, Metadata Element Definition, Record, Role, Service, Template y User.
- Cada estructura de datos se describe con la siguiente estructura: System Identifier, Title, Description, Entity Type, System Metadata, Min Occurs y Max Occurs
- Las estructuras de datos: Access Control Entry, Access Control List y Metadata Change Entry.
- Cada elemento de metadatos se describe con la siguiente estructura: System Identifier, Title, Description, Entity Type, Min Occurs, Max Occurs, Modifiable?, Entity Reference? Y Data Type.
- Los elementos de metadatos: se describen un total de 107. Ejemplos: M14.4.86 Record Identifier, M14.4.55 Metadata Element Definition Identifier, F14.5.27 Class – Delete Residual Metadata
- Cada función se describe con la siguiente estructura: System Identifier, Title, Description, Entity Metadata, From Functional Requirements, Purpose, Additional Event Metadata, Usage Notes
- Las definiciones de funciones: se describe un total de 196. Ejemplos: F14.5.2 Aggregation – Add Contextual Metadata, F14.5.24 Class – Create, F14.5.43 Component – Exported
La transmisión de datos entre dos MCRS significa que las entidades pueden migrar sus datos y records para preservar su integridad y contexto. Este objetivo se consigue si cada entidad y sus elementos de metadatos son reconocibles e interpretados universalmente.
Moreq2010 facilita la incorporación metadatos contextuales y otros adicionales para las implementaciones específicas. Los metadatos contextuales se predefinen en un conjunto de elementos de metadatos que se añaden simultáneamente a una entidad y se definen en plantillas de metadatos.
El DLM Forum permite aproximaciones posibles para la testificación y certificación de los metadatos:
- Se implementa y se audita el modelo de servicios de metadatos completo, que se testea y certifica con respecto a los requisitos del módulo de esta especificación
- O se implementa en su modelo nativo de metadatos, en este caso la aplicación debe satisfacer los criterios siguientes:
- Debe demostrar que su modelo nativo es equivalente en la captura en flexibilidad, funcionalidad y consistencia al modelo de servicios de metadatos de Moreq2010.
- Debe soportar la interoperabilidad, exportando y convirtiendo sus metadatos nativos al mismo formato XML utilizado por el servicio de metadatos modelo: mismos datos, interpretación semántica y usando los mismos identificadores y códigos, cuando los datos se transfieren a otro MCRS.
La norma se puede obtener en la sede web del DLM Forum: MoReq2010-Core+Plugin(v1-0).pdf
|
