En esta entrada vamos a hacer una revisión breve dentro del apartado “ Profile Overview “ del documento “Profile Architecture” perteneciente a los entregables del taller CEN BII. (fase 1)

En el documento se tratan los siguientes puntos:

Propósito del documento:

Definir y describir la arquitectura aplicada en la que se basa el desarrollo   y la especificación de los perfiles que se utilizan en el taller CEN BII.

En el capítulo 2 del documento se proporcionan las definiciones formales y el metamodelo y en el capítulo 3 se elaboran con más detalle los componentes clave y sus relaciones junto con su uso dentro del taller CEN BII.

El metamodelo para describir los perfiles

En la imagen siguiente se ve el metamodelo de los perfiles de CEN BII

Las relaciones clave se expresan en el metamodelo  de la imagen de la siguiente forma:

Un Perfil compromete a dos, y exactamente a dos, Partnes  del  negocio (Partners)
especificando la forma en que implementan uno mas Procesos de Negocio. Un
Perfil especifica, además, una o más Reglas de Negocio que gobiernan la ejecución de las Colaboraciones de Negocios que son parte de los Procesos de Negocio. Un perfil requiere una o más Modelos de Datos de las Transacciones para definir el contenido de información permitido  de cada Transacción de Negocio intercambiada dentro de sus Colaboraciones de Negocio.

Un Partner de negocio actúa en uno o más Roles cuando participa en una Colaboración de negocio. Una Colaboración de Negocio se lleva a cabo exactamente por dos Roles. Un rol en una colaboración de negocio se interpreta por un único partner del negocio.

Un proceso de negocio contiene una o más Colaboraciones de Negocio. Cada colaboración de Negocio define la coreografía de una o más Transacciones de Negocio. La ejecución de cada Colaboración de Negocio puede ser gobernada por varias reglas de Negocio.

Las reglas de negocio pueden tomar la forma de Las reglas de proceso o de restricciones de información. Una restricción de información se aplica a uno o más elementos de información contenidos de información  en uno o más Modelos de Datos de Transacciones.

La información que contienen cada transacción de negocio se define en uno o más Modelos  de datos de Transacción de Negocio.

Cada Modelo de transacción de negocio que se usa en uno o más Perfiles, define los contenidos de información permitidos en una Transacción de Negocio intercambiada dentro de una o mas colaboraciones de negocio.

Cada Modelo de datos de transacción contiene varios elementos de información que pueden ser restringidos por las restricciones de Información

Un modelo de datos de transacción se mapea con una o más sintaxis de mensajes que puede contener una o varias  sintaxis de elementos de datos.

Hemos puesto esta traducción libre del metamodelo para que os acostumbréis a los distintos nombres y relaciones que se van a utilizar en todos los documentos que describen la norma.

Las personas que no vayan a desarrollar o implementar los estándares en tecnologías de la información sólo deben conocer la nomenclatura en inglés, para poder entender los documentos que en cada perfil realizan la descripción del proceso correspondiente.

A continuación vamos simplemente a definir de la forma más sencilla posible los elementos que hemos manejado:

–      Proceso de negocio, es el comportamiento de dos o más Partners de negocio para conseguir un objetivo de negocio acordado.

–      Perfil . es un conjunto de mensajes electrónicos que implementan un proceso de negocio. CEN BII lo define como “Una especificación de cómo uno o más Procesos de negocio especifican las reglas de negocio que gobierna sus colaboraciones de negocio y los contenidos de información (modelos de datos de las transacciones de negocio electrónicas que se intercambian).

–      Reglas de negocio: controlan o influyen en el comportamiento de los Partners de negocio. Tiene dos categorías: las que afectan al flujo de trabajo (procedimiento) y si cambian afectan a la implementación técnica, y aquellas que solo afectan a nivel del negocio y no cambian el procedimiento y por tanto no hay que cambiar la implementación técnica.

–     Restricciones de información: son reglas de negocio que limitan el uso o el valor de un elemento de información.

–      Partner de negocio: es una organización o  una persona que participa en un proceso de negocio proporcionando información o recibiendo información del proceso de negocio.

–      Rol : es un concepto más genérico que el de partner de negocio y permite la reutilización de las colaboraciones mapeando los roles de un partner de negocio en un escenario concreto

–      Colaboración de negocio: describe en detalle los requisitos de la colaboración entre dos o más Partners involucrados, Los Partners toman parte en una colaboración de negocio desempeñando un rol en ella.

–      Transacción de Negocio es una componente básico para definir la coreografía entre roles. Por ejemplo “aceptar un pedido” “rechazar un pedido”.

–      Modelo de datos de la transacción, es el contenido de información que una transacción de negocio intercambia en el contexto de un perfil.

–      Elemento de Información, conjunto de datos que soportar un concepto: “Parte Ofertante”, “Nombre de la Parte Ofertante”

–      Sintaxis de mensaje: Un documento electrónico de negocio definido en una sintaxis particular. Por ejemplo en UBL o en EDIFACT, o en XML—

–      Sintaxis de elemento de datos: la definición de una instancia de un elemento de información expresado con el vocabulario de una sintaxis particular

Para los lectores no técnicos, estas descripciones y metamodelos pueden resultar un poco áridos, pero ya sabéis que todo parece difícil hasta que se vuelve fácil. Y esto es más fácil de lo que a primera vista aparenta. Pero hay que organizarlo, es necesario. Porque sin organización el caos se produce muy rápidamente, y no se obtienen los beneficios esperados. Y la organización mayor, es la de utilizar los mismos nombres para los mismos conceptos. Perfil no es el término más afortunado, en mi opinión, para describir el conjunto de mensajes que se intercambian colaborativamente para realizar un proceso de negocio: Pero esta puede ser la primera enseñanza: los estándares son estándares porque todo el mundo los usa igual, empezando por la nomenclatura.

Si te interesan estos temas únete a la red formal de contratación pública electrónica

• blog de compras pública eficaces
• blog de contratación pública electrónica.
• Wiki de contratación pública
• Comunidad de prácticas de contratación pública
• Grupo en linkedin
• Grupo en Facebook
• Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

En esta entrada vamos a hacer una revisión breve del documento “CWA 16073-1: Profile Overview “ perteneciente a los entregables del taller CEN BII. (fase 1)

En el documento se tratan los siguientes puntos:

El prólogo

Trata sobre el proyecto de normalización y sus participantes. Recordar que el proceso ha tenido las siguientes partes:

• Parte 0: Introduccion
• Parte 1: Visión General de los Perfiles
• Parte 2: Convergencia de los estándares  UBL y UN/CEFACT
• Parte 3: Requisitos de las Herramientas
• Parte 4: Guía de evaluación de pruebas y pilotos

Alcance:

Recuerda principalmente los elementos que van a componer un perfil. (El nombre de perfil es algo que puede ser difícil de asumir al principio).

Un perfil es una descripción de una especificación técnica que se compone de:

–         La coreografía de los procesos de negocio (una descripción detallada de como se relacionan los intervinientes en el negocio  el papel que cada uno interpreta y las responsabilidades que comparten para alcanzar los objetivos que mutuamente han acordado con el suporte de sus respectivos sistemas de información.

–         Las transacciones electrónicas del negocio que se intercambian como parte del proceso de negocio y la secuencia en la que estas transacciones se producen.

–         Las reglas de negocio que controlan la ejecución de los procesos de negocio con sus colaboraciones y transacciones, así como las restricciones de los elementos de información utilizados en los modelos de datos de cada transacción.

–         El contenido de la información de las transacciones de negocio que se intercambian teniendo en cuenta el modelo de datos de cada transacción de negocio.

El concepto de perfil

Un perfil se utiliza para modelar las relaciones entre la administración y el proveedor. La intención es que los sistemas que  soportan la RELACIÓN sean conformes a los tres elementos claves del perfil:

– Coreografía, la conformidad  se mide en función de la secuencia de las colaboraciones y transacciones del perfil. Cada solución que sea conforme a un perfil debe ser capaz de soportar todas las colaboraciones y transacciones de negocio definidas en el perfil.

–Contenidos de Datos ; la conformidad se mide en función de la parte definida como “núcleo” (core) del modelo de datos de la transacción nominada en el perfil. Cada solución de software que se declare conforme debe ser capaz de procesar y entender todos los elementos definidos como núcleo del modelo de datos de la transacción relacionados en el perfil. El concepto de núcleo es importante entender porque hay extensiones a los datos que se pueden producir que no tienen por qué afectar a la conformidad de una solución con los datos del núcleo.

– Reglas de negocio: la conformidad se mide en función de las reglas establecidas en el perfil y en el nivel de transacción y de colaboración del perfil. Cada solución de software que sea conforme con el perfile deberá adherirse a las reglas de negocio establecidas en la descripción del perfil y en el modelo de datos de la transacción.

En los capítulos siguientes se hace una clasificación de los procesos generales de la contratación pública y se separan en dos grandes apartados:  perfiles pre-adjudicación y perfiles post-adjudicación con una parte adicional que denomina perfiles de soporte.

Hay una categoría que está a caballo de las dos (pre y post adjudicación) que se denomina “sourcing” y que nosotros llamaremos gestión de proveedores.

En la imagen siguiente aparece la visión general de los perfiles:

Los  perfiles de soporte.

–         Adjuntar un documento

–         Petición de Estado

–         Recuperar un documento.

Otros conceptos y componentes del perfil

Aunque el documento hace una revisión de elementos tales como roles de los participantes, colaboraciones, transacciones y modelos de datos, creo que en el documento siguiente “Profile Architecture” que veremos en otra entrada se describen mejor estos elementos.

En el documento también se hace una descripción de cómo utilizar estos perfiles y sus componentes en un procedimiento abierto, negociado, restringido, acuerdo marco o sistemas dinámico de adquisición que nos pueden dar una idea, hasta que nos familiaricemos con la nomenclatura de donde y cómo se utilizan estos perfiles y sus componentes.

Anexos

Anexo A (normativo): Glosario de términos:

http://www.cen.eu/cwa/bii/specs/Profiles/IndexWG1.html

Anexo B (normative):  Arquitectura de los perfiles: http://www.cen.eu/cwa/bii/specs/Profiles/IndexWG1.html

Anexo C (normative): Perfiles y modelos de datos de las transacciones:   http://www.cen.eu/cwa/bii/specs/Profiles/IndexWG1.html

Reflexión sobre este documento.

Es una visión general donde empieza a establecer el ámbito y alcance donde podéis encontrar una visión general de los trabajos. Es bueno analizar los conceptos y la nomenclatura con cuidado porque acelararán el entendimiento de estos estándares.

Mi opinión es que los estándares post-adjudicación están más trabajados, porque han recogido la experiencia existente en los países escandinavos, y porque además son perfiles que se pueden utilizar en contratación pública y en contratación entre empresas privadas. Excepto la parte de gestión de proveedores que comentaremos más adelante.

La parte de pre-adjudicación es la más complicada. porque además de ser claramente específica de la administración pública, es en la que  menos experiencias hay  y por tanto la normalización queda más difusa.

Si te interesan estos temas únete a la red formal de contratación pública electrónica

• blog de compras pública eficaces
• blog de contratación pública electrónica.
• Wiki de contratación pública
• Comunidad de prácticas de contratación pública
• Grupo en linkedin
• Grupo en Facebook
• Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

Vamos a iniciar una serie de entradas enfocadas a tratar de aclarar las normas que habilitan la interoperablidad interna y externa de los sistemas de información. Los sistemas de información (tecnología), que son un factor del sistema de negocio (la contratación pública)  junto con las personas que organizadas en diferentes estructuras desarrollan la actividad de la contratación pública electrónica (procedimientos de contratación).

En mi opinión, las normas y los estándares empiezan a ser en el ámbito de las tecnologías de la información lo que las leyes y los reglamentos son en el ámbito jurídico y social: Tal y como expresan las ideas de Lawrence Lessig en su libro Código 2.0, la tecnología de la información cada vez más implementa en código informático las leyes de la sociedad y por tanto,  es conveniente que lo haga siguiendo determinadas normas y estándares que nos permitan tener cierto orden y concierto, y sobre todo transparencia y accesibilidad.

Hemos comentado que existen normas y estándares en los cuatro grandes ámbitos de actuación principal (Archivo, Relación, Tramitación y Explotación).

En ARCHIVO están las normas técnicas del Esquema Nacional de interoperabilidad. Las entradas vendrán nominadas como Normas Técnicas de Interoperablidad aplicadas a la Contratación Pública electrónica (aunque estas normas son horizontales a toda la Administración Electrónica). Trataremos de encontrar la relación con el Marco  de Interoperabilidad Europeo ( EIF European Interoperability Framework).

En RELACION están las normas y estándares que nos permiten que cualquier administración se entienda con todos los proveedores. Son los Estándares que se han generado en CEN y tienen el “apellido” BII (Business interoperable Interfaces). Estas entradas vendrán nombradas con CEN BII y el tema específico que abordemos. Además  trataremos de relacionarlos  con las normas publicadas por la D.G. de Patrimonio que salvo error u omisión serán convergentes con el estándar CEN BII. No sólo hablaremos de estándares técnicos sino de modalidaes y opciones que nos permiten los estándares.

En TRAMITACIÓN Y EXPLOTACIÓN, como ya hemos comentado,  hay estándares y normas pero su conformidad será previsiblemente menos exigente.

Si es importante que entendamos que antes o después habrá exigencia de algún tipo de  conformidad en Expedientes Electrónicos, Archivo Electrónico, Documento Electrónico, Firma Electrónica, Certificados Electrónicos, Evidencias Electrónicas, y todas las transacciones entre una Administración y el mercado y viceversa (Anuncio, Adjudicación, Oferta, Contrato, Pedido, Albarán, Factura..) y esta exigencia de conformidad nos tiene que mover a  seguir las normas y estándares aplicables y ser interoperables desde un primer momento.

También vamos a iniciar una serie de entradas que vayan reflejando otros estándares de la industria que también, desde mi punto de vista, deben ser conocidos e implementados, en mayor o menor grado por administraciones, empresas y proveedores de productos y servicios que tengan relación con la contratación pública electrónica.

Algunos de estos estándares y mejores prácticas son:

• ISO /IEC 38500 del Gobierno Corporativo de las TI.
• ISO 20000 en gestión de servicios de TI
• ISO 27000 (es una serie de normas) sobre seguridad de las TI.
• ITIL V3 sobre buenas prácticas en gestión de servicios de TI.
• COBIT sobre medidas para valorar la adecuación de las prácticas de TI.
• VAL-IT , con las normas que nos permiten tomar decisiones que tienen que ver con la tecnologías en función de beneficios, costes, riesgos y sinergias.

Y seguramente alguna otra norma o estándar habrá que utilizar, por ejemplo,  alrededor de la identificación digital personal y corporativa y algún que otro tema.

La intención de generar estas entradas no es hacer un giro radical en la orientación del blog sino generar, a través del conocimiento,  la conciencia de que necesitamos normas y estándares en el diseño,  desarrollo, implantación y operación de las tecnologías, porque estas inversiones suelen ser suficientes como para intentar que las necesidades sean satisfechas a través de valores útiles, que en el caso del comercio electrónico vienen dados por la concurrencia y la normalización de la información. De esta forma permitiremos que el mercado tenga información casi perfecta y se consiga una productividad y competitividad basadas en los méritos y no en la información disponible.

¿Estáis interesados en tratar alguna otra norma en especial que se nos haya “escapado” en esta relación.?

Si te interesan estos temas únete a la red formal de contratación pública electrónica

• blog de compras pública eficaces
• blog de contratación pública electrónica.
• Wiki de contratación pública
• Comunidad de prácticas de contratación pública
• Grupo en linkedin
• Grupo en Facebook
• Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

De las cuatro grandes áreas que debemos gestionar para realizar la TRASFORMACIÓN a la contratación pública electrónica, y que ya hemos comentado: Archivo, Relación, Tramitación y Explotación, por supuesto todas ellas en formato electrónico, la que representa con mayor la interoperabilidad es el área de RELACIÓN electrónica. Y en menor medida la del Archivo Electrónico. Digo en menor medida porque el ámbito geográfico será normalmente más reducido.

Cuando utilizamos las tecnologías de la información, en este caso para la contratación pública electrónica, el propósito de las tecnologías como herramientas que son, deberá tener algo de cada uno de estos elementos:

–         aumentar la capacidad estratégica: permitir a la organización hacer algo que antes era incapaz de hacer (el formato electrónico)

–         aumentar la capacidad operativa: permitir a la organización   ser mas eficaz y más eficiente (el famoso más con menos)

–         ser conforme con las regulaciones y normas vigentes: permitir a la organización cumplir la ley y los reglamentos en tiempo y forma.

Para conseguir cualquiera de los tres, en el caso de la contratación pública electrónica es necesaria la participación de los proveedores (el mercado). Todo el mercado europeo. Y eso precisa de interoperabilidad.

La interoperabilidad (Marco Europeo de Interoperabilidad) es el elemento clave para conseguir los beneficios esperados de la contratación pública electrónica, que tienen que ver la transparencia, igualdad de trato y la concurrencia (los principios de las Directivas Europeas de Compra).

La interoperabilidad no es una bloque monolítico sino que se consigue a través de manejar variables en diferentes dimensiones

–         Legales: es la más complicada de manejar, y aunque las directivas comunitarias son iguales para todos los estados miembros de la Unión Europea, los reglamentos y leyes de cada estado tienen diferencias entre ellos (recordemos que las directivas se trasponen – bien o mal- y son las leyes traspuestas las que realmente condicionan –su cumplimiento- las actuaciones de cada estado miembro)

–         Organizativa: los procedimientos deben ser homogéneos y entendibles en formato electrónico por todos los agentes que intervienen en las relaciones que se producen en la contratación pública: Un anuncio, una oferta, un pedido, una factura, un catálogo…..

–         Semántica: los mensajes que se intercambian como elementos de dialogo siguiendo un procedimiento, deben tener datos y estructuras que tengan el mismo significado para todos los agentes que intervienen en el proceso.

–         Técnica: los formatos electrónicos tienen que estar basados en especificaciones técnicas abiertas que puedan ser implementadas en cualquier sistema de información, con independencia de sistemas operativos y el resto del software base que una organización utilice.

Pero la interoperabilidad no es sencilla de conseguir porque requiere consenso y estándares.

Para las dimensiones de la interoperabilidad, organizativa, semántica y técnica se están generando los estándares CEN BII. Para la dimensión legal está es un poco más complicada, tanto en cuanto deja de ser un problema que puede ser abordado desde la tecnología y precisa que se aborde desde la traducción de las normas (leyes y reglamentos de cada país) a código informático que garantice la interoperabilidad. Y esto, en mi opinión no es más complejo tecnológicamente sino que requiere de una mayor coordinación y consenso.

En los trabajos que se están llevando a cabo hay algunos problemas que va a costar cerrar en los estándares y aplicar en los proyectos (por ejemplo en PEPPOL). Desde mi punto de vista estos son los problemas que más puede  costar resolver (insisto no es tecnología es coordinación y consenso):

–         Utilizar una Infraestructura de comunicaciones: red pública de contratación electrónica en toda Europa.

–         Conseguir la Confidencialidad de las ofertas con procedimientos comunes (ver el Anexo X de las Directivas)

–         La Identificación de los operadores económicos en cualquier administración de Europa utilizando registros de licitadores, sistemas de clasificación, los perfiles de CEN BII (qualification profile) y el VCD (virtual compay dossier de PEPPOL), así como los mapas de traducción de requisitos de e-certis.

–         La armonización de las autoridades de certificación en toda Europa que acreditan y verifican los certificados que se utilizan en las firmas electrónicas reconocidas

–         El uso equilibrado de las firmas electrónicas y en su caso la encriptación.

No obstante se ha avanzado mucho en la definición de los estándares CEN BII y PEPPOL está validando con experiencias (se hace camino al andar) que estos estándares son utilizables por sistemas de información y su uso es posible por los agentes que intervienen en los sistemas.

Por tanto en muchas áreas de la contratación pública electrónica ya empieza a haber interoperabilidad real y en mi opinión, poco a poco, se irán solucionando el resto de los problemas, siempre que haya interoperabilidad política que verifique la dirección, la evaluación y la monitorización en el uso de las tecnologías de la información en la contratación  pública electrónica

Si te interesan estos temas únete a la red formal de contratación pública electrónica

• blog de compras pública eficaces
• blog de contratación pública electrónica.
• Wiki de contratación pública
• Comunidad de prácticas de contratación pública
• Grupo en linkedin
• Grupo en Facebook
• Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)