Estudio y Evaluación de La IDE. Aplicación de Buenas Prácticas y Modelos de Calidad.

Estudio y evaluación de la IDE.
Aplicación de buenas
prácticas y modelos de Calidad
Master Oficial en Gestión Integral de Tecnologías de la

Información
Trabajo de Fin de Master
Guillermo de Paz López

21 de Junio de 2008
Índice
1. Marco del Trabajo................................................5

1.1. Contenido del documento.........................................................5
2. Marco Político y Tecnológico................................8
2.1. Marco Político...........................................................................8
2.2. Redes Colaborativas.................................................................9
2.3. Concepto de IDE.....................................................................11
2.4. Evolución histórica de la IDE..................................................11
2.5. La IDEE...................................................................................15
2.6. Marco Tecnológico..................................................................17
2.7. Arquitectura Orientada a Servicios. SOA...............................17
3. Bases para el desarrollo de una IDE....................27
3.1. Definición de una estrategia...................................................27
3.2. Definición de la visión.............................................................27
3.3. La coordinación.......................................................................29
3.4. La Difusión..............................................................................30
3.5. La Creación de Capacidades.................................................30
3.6. Aportaciones a la Base de Conocimiento Territorial..............31
4. Marco de Evaluación de la IDE............................32
4.1. La evaluación tradicional en los SI/TI.....................................32
4.2. Perspectivas para la evaluación del sector público................33
4.3. CMI para la gestión de Servicios TI de administración
electrónica......................................................................................37
4.4. Enfoque para la evaluación de las aplicaciones Web............45
4.5. La evaluación de las IDE........................................................46
4.6. La evaluación como control....................................................47
4.7. La evaluación como aprendizaje............................................48
4.8. La evaluación como creadora de sentido...............................48
4.9. La evaluación como práctica exploratoria..............................48
4.10. Marco organizacional de Loenen..........................................49
4.10.1. El modelo de desarrollo organizacional de la IDE.............49
5. Estudio para la implantación de Mejores Prácticas y
Modelos de Calidad en la IDE.................................56
5.1. Introducción.............................................................................56
5.2. Gobierno de las TI..................................................................56
5.2.1. COBIT..................................................................................56
5.3. Gestión de Servicios TI...........................................................58
5.3.1. ITIL e ISO 20000..................................................................59
5.4. Gestión de la Calidad..............................................................60
5.4.1. Gestión de Costes de Calidad.............................................61
5.4.2. Modelo E.F.Q.M., norma ISO 9001:2000 y Marco Común de
Evaluación CAF.............................................................................62
5.5. CMMI.......................................................................................65
5.6. PMBOK...................................................................................66
5.7. Conclusiones Finales..............................................................67
6. Plan de Colaboración de la Empresa Privada para el
desarrollo de la IDE. .............................................69
6.1. Planteamiento del Caso Práctico............................................69
6.2. Acuerdo de colaboración de las empresas privadas para el
desarrollo de la IDE........................................................................72
7. Proyecto para el desarrollo de una plataforma de
testeo de Geoservicios..........................................74
7.1. Project Charter. Acta de Constitución del Proyecto...............74
7.2. Scope Statement. Enunciado del Alcance del proyecto.........81
7.3. Work Breakdown Structure WBS & Activity List. Estructura de
Desglose del Trabajo EDT y lista de actividades..........................82
7.4. Project Network Diagram. Diagrama de Red del Cronograma
del Proyecto...................................................................................83
8. Anexo I: Base Tecnológica de la IDE....................85
8.1. XML.........................................................................................85
8.2. SOAP......................................................................................87
8.3. Servicios Web.........................................................................89
9. Anexo II: Geoservicios IDE..................................93
10. Anexo III: SIG CORPORATIVO vs. IDE.................99
11. Anexo IV. Resumen de Mejores Prácticas, Gestión
de Calidad y Estándares.......................................103
11.1. Gobierno de las TI..............................................................103
11.1.1. COBIT..............................................................................103
11.1.1.1. Marco de Trabajo COBIT..............................................107
11.2. Gestión de Servicios TI.......................................................114
11.2.1. ITIL...................................................................................117
11.2.2. ISO 20000........................................................................118
11.2.3. BS 15000 e ITIL...............................................................119
11.3. Gestión de la Calidad..........................................................119
11.3.1. Normas ISO 9000............................................................125
11.3.2. MODELO EFQM..............................................................126
11.3.3. Comparación del modelo E.F.Q.M. con la norma ISO
9001:2000....................................................................................128
11.3.4. Marco Común de Evaluación CAF..................................129
11.4. CMMI...................................................................................131
11.5. PMBOK...............................................................................133
12. Anexo V: Ciclo de vida del producto y del
proyecto.............................................................135
12.1. Ciclo de vida del producto..................................................135
12.2. Ciclo de vida del Proyecto..................................................136
12.3. Relaciones del ciclo de vida del proyecto y del ciclo de vida
del producto.................................................................................138
13. Anexo VI: Glosario..........................................140
14. Anexo VII: Referencias...................................146
Estudio y evaluación de la IDE. Aplicación de buenas

Marco del Trabajo
1. Marco del Trabajo

El presente documento recoge el Trabajo del Fin del Master Oficial de Gestión Integral
de Tecnologías de la Información. Tomando como base la Infraestructura de Datos
Espaciales (IDE; Spatial Data Infrastructure SDI en Inglés), como proyecto político y
estratégico para la gestión de información medioambiental, de territorio y geográfica,
el objetivo del trabajo es analizar la materia vista en el master desde dos puntos de
vista, el de investigación y en este caso el de su posible aplicación en el desarrollo de
la IDE.
En este sentido la visión del presente trabajo tiene dos puntos de vista, el primero
didáctico y el segundo práctico:
1. Abarcar la mayor parte del temario del Master, teniendo en cuenta la misión y
visión del CIO, la problemática intrínseca de la externalización, la gestión de los
servicios TI, la gestión de la calidad, los diferentes estándares basados en
mejores prácticas, la gestión de aplicaciones, los servicios de producción, la
gestión de proyectos y la gestión financiera de las TI.
2. Plantear un caso práctico, que en cuanto a la materia propia del Master sería
una decisión estratégica del CIO, para la colaboración de la empresa privada
en el desarrollo de la IDE, incluyendo el desarrollo según PMI de un proyecto
inicial.
Este trabajo pretende ser autocontenido, es decir el trabajo presenta toda la materia
de estudio, aunque sea de una manera básica, facilitando en lo posible la búsqueda de
la información de cada punto tratado.
1.1. Contenido del documento
Además de este primer capítulo introductorio, el presente trabajo queda estructurado

en los siguientes capítulos:
Capítulo 2: MARCO POLÍTICO Y TECNOLÓGICO.

En este capítulo se plantean las iniciativas políticas, basadas en la gestión de la
información medioambiental, que han hecho posible y definen la IDE. Para ello se
analiza desde un punto de vista histórico, dichas iniciativas y se hace especial hincapié
en la Directiva Europea INSPIRE y en la Infraestructura de Datos Espaciales de
España IDEE. Se presenta un análisis sobre las redes colaborativas, ya que la IDE en
último término es un caso particular de red colaborativa. Además se define la base
tecnológica que permite que se lleven a cabo estas iniciativas políticas enfocadas en
compartir, de la manera más eficiente posible, la información territorial y cartográfica
de los diferentes organismos públicos implicados. En este sentido este capítulo está
íntimamente relacionado con el Anexo I, donde se presenta la base tecnológica y la
evolución de esta para solucionar el problema de la interoperabilidad.
Capítulo 3: BASES PARA EL DESARROLLO DE LA IDE.


Marco del Trabajo
Con el objetivo de comprender el sentido y la complejidad de la IDE, en este capítulo

se hace un estudio de los aspectos básicos para poner en funcionamiento una IDE.
Capítulo 4: MARCO DE EVALUACIÓN DE LA IDE.

Previamente a realizar el estudio de implantación de mejores prácticas y modelos de
calidad, es necesario analizar como se ha pensado y efectuado la evaluación de la
IDE hasta ahora, este capítulo se ocupa de ello analizando las teorías más
importantes para realizar esta evaluación.
Capítulo 5: ESTUDIO PARA LA IMPLANTACIÓN DE MEJORES PRÁCTICAS Y

MODELOS DE CALIDAD EN LA IDE
A partir del análisis del capítulo anterior y del resumen de mejores prácticas, modelos
de calidad y estándares del Anexo IV, en este capítulo se analiza la implantación de
estos modelos, tanto para la estructura de red colaborativa que representa la IDE,
como para los GIS corporativos que en cada nodo soportan dicha red. Para este
análisis se tiene en cuenta el punto de vista de negocio de un integrador o consultora
TI, que podría tener en la implantación de mejores prácticas, modelos de calidad y
estándares en los organismos públicos involucrados.
Capítulo 6: PLAN DE COLABORACIÓN DE LA EMPRESA PRIVADA PARA EL

DESARROLLO DE LA IDE.
Actualmente la colaboración entre empresa privada y organismos implicados en el
desarrollo de la IDE, no es lo intensa que debería ser, siendo la posición de la
empresa privada hasta ahora más reactiva que proactiva. En este capítulo se plantea
una posible solución para ampliar y mejorar la colaboración de la empresa privada en
el desarrollo de la IDE. Esta colaboración sería beneficiosa tanto para las empresas
privadas como para los organismos públicos implicados. El planteamiento para dicha
solución se basa en el acuerdo que el estado ha llegado con Microsoft, HP y La Caixa
para impulsar el acceso de los ciudadanos a la sociedad de la información. Con
respecto a lo visto en el Master el objetivo de este capítulo es plantear una estrategia
TI y desarrollarla en lo posible.
Capítulo 7: PROYECTO PARA EL DESARROLLO DE UNA PLATAFORMA DE

TESTEO DE GEOSERVICIOS.
En el capítulo anterior se plantea una estrategia de colaboración y dentro de esa
estrategia diferentes proyectos iniciales. En este capítulo, con el objetivo de desarrollar
lo visto en el Master sobre Gestión de Proyectos, se desarrollan las primeras fases de
lo que podría ser el primer proyecto en esta colaboración.
Anexo I: BASE TECNOLÓGICA DE LA IDE.

Se recogen en este anexo las tecnologías que hacen posible la interoperabilidad
necesaria para compartir la información territorial y geográfica. Se hace un estudio en
sentido creciente de complejidad, desde XML, SOAP y Servicios Web.
Anexo II: GEOSERVICIOS IDE.

Los geoservicios se basan en la tecnología planteada en el capítulo anterior y están
definidos por organismos de estandarización como son la Open Geospatial
Consortium y la ISO.

Marco del Trabajo
Anexo III: SIG CORPORATIVO vs. IDE

Aquí se define la evolución que ha representado la nueva visión de interoperabilidad
en el mundo del GIS
Anexo IV: Resumen de Mejores Prácticas, Gestión de Calidad y Estándares

Resumen de lo visto en el Master en cuanto a Mejores Prácticas, Gestión de Calidad y
Estándares.
Anexo V: Ciclo de vida del producto y del proyecto

A la hora de realizar un proyecto es importante tener en cuenta la diferencia entre el
proyecto y el producto resultante.
Anexo VI: Glosario
Anexo VII: Referencias

Marco Político y Tecnológico
2. Marco Político y Tecnológico

Este capítulo tiene dos objetivos:
El primero presentar el porqué y los orígenes de la IDE que han sido de

naturaleza política, además de hacer una breve presentación de la base
tecnológica y de estrategia de negocio a través de una introducción a la
Arquitectura Orientada a Servicios (SOA). En este sentido este capítulo se
complementa con el Anexo I: Base Tecnológica de la IDE y con el Anexo 2:
Geoservicios IDE.
El segundo objetivo está directamente relacionado con el Master que motiva este
trabajo. Esto es así porque a través del conocimiento de la IDE se puede
analizar como una decisión política, con el objetivo inicial de la gestión de la
información relacionada con el medio ambiente, se implementa a través de las
tecnologías y estrategias adecuadas, en este caso no de negocio si no políticas.
2.1. Marco Político
Además de la Directiva europea INSPIRE y el REAL DECRETO 1545/2007, de

23 de noviembre de 2007 por el que se regula el Sistema Cartográfico Nacional,
que afectan directamente al desarrollo de la IDE, la recientemente aprobada ley
de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (Ley 11/2007,
de 22 de junio), -LAECSP- marca un hito en las Administraciones Públicas al
conferir unos derechos concretos y explícitos a los ciudadanos en el uso de las
tecnologías de la información y las comunicaciones en sus relaciones con la
Administración.
Estos derechos hacia los ciudadanos obligan a las distintas administraciones

(central, autonómica y local) a desarrollar, implantar y habilitar un conjunto de
servicios para atender a una amplia diversidad de requerimientos, como son los
de disponibilidad (servicio continuado, 24x7), de universalidad (para todos los
ciudadanos, allí donde se encuentren), de calidad (posibilidad de conocer en
todo momento el estado de tramitación de sus procedimientos), o de eficiencia
(simplificación de los procedimientos y de sus trámites, no aportar documentos
que ya obran en poder de la Adminisración), principalmente.
Las disposiciones que establece la ley determinan acciones que afectan tanto al
backoffice como al frontoffice y ambos deben desarrollarse alineadamente.
Administración electrónica no es únicamente comunicación telemática (del
ciudadano a la Administración, y viceversa). Es, por el contrario, disponer de un
servicio completo, de principio a fin, en el que los procedimientos administrativos
tengan una tramitación electrónica, desde la identificación del ciudadano y del
empleado público que intervienen en el procedimiento hasta la elaboración del
expediente enteramente electrónico, sin importar por cuáles administraciones
haya transitado el expediente.
La Administración Electrónica, y todos los servicios que integra, son parte

fundamental en el desarrollo de la Sociedad de la Información, y es asimismo un
importante impulso.
2.2. Redes Colaborativas
Para cumplir los objetivos señalados anteriormente, la administración pública al

igual que la empresa privada, se plantea la necesidad de optimizar sus recursos.
Para ello una de las estrategias que se tiene en cuenta es la de crear escenarios
colaborativos. La siguiente figura presenta una síntesis, a partir de los estudios
de Camarinha-Matos y Abreu, de cómo las variables que caracterizan la
cooperación pueden beneficiar a los posibles participantes del proceso.
Ilustración 1. Impulsores de la cooperación organizacional
Las redes organizativas son sistemas complejos, evolutivos y sujetos a una serie
de principios que estimulan la permanencia de sus miembros. Los factores que
condicionan la existencia de una red son dos: poder y confianza. Cada uno de
ellos podría asociarse al impulso inicial necesario para moverse de un mercado
o una jerarquía a una red.
Ilustración 2. Factores impulsores de una red colaborativa
Según los trabajos de Franco y Ortiz Bas, a lo largo del ciclo de vida, una red
colaborativa evoluciona en busca de un estado ideal de interoperabilidad con
otras redes, en tres dimensiones: la apertura, la flexibilidad y el dinamismo.
Este ciclo de vida se puede dividir en tres fases que vienen representadas en la
siguiente figura.
Ilustración 3. Evolución de una red. Requerimientos de interoperabilidad (Franco,

2004)
La representación esquemática del marco de referencia planteado por Franco y

Ortiz Bas es la siguiente:
Ilustración 4. Un marco para la clasificación de formas organizativas en red
2.3. Concepto de IDE
Una IDE (Infraestructura de Datos Espaciales) es un sistema informático

integrado por un conjunto de recursos (catálogos, servidores, programas, datos,
aplicaciones, páginas Web,…) dedicados a gestionar Información Geográfica
(mapas, ortofotos, imágenes de satélite, topónimos,…), disponibles en Internet,
que cumplen una serie de condiciones de interoperabilidad (normas,
especificaciones, protocolos, interfaces,…) que permiten que un usuario,
utilizando un simple navegador, pueda utilizarlos y combinarlos según sus
necesidades.
El establecimiento de una IDE, a nivel local, regional, estatal o global, requiere

del acuerdo de los productores, integradores y usuarios de datos espaciales del
ámbito territorial en el que se establece. Este acuerdo debe considerar también
las IDE definidas, o en definición, en otros ámbitos territoriales superiores, hacia
las cuales deberá converger.
2.4. Evolución histórica de la IDE
El concepto de IDE partió de la necesidad de gestionar la información

relacionada con el medio ambiente y fue en la Conferencia de las Naciones
Unidas sobre Medio Ambiente y Desarrollo en Río de Janeiro, en 1992. Agenda
21, donde por primera vez se planteó esta necesidad de manera oficial.
Desde 1990 los EEUU contaban con el Federal Geographic Data Committee,
dentro de la National Mapping Division del Geological Survey, pero fue en 1994
cuando la orden presidencial 12906 (Orden Clinton) creó la National Spatial Data
Infrastructure con la finalidad de coordinar la adquisición y acceso a los datos
geográficos. Desde entonces el FGDC ha desarrollado una importante labor de
normalización y cooperación con las agencias federales, estatales y locales,
pero sobre todo ha creado la National Geospatial Data Clearinghouse como
metabuscador que conecta unos 60 centros productores de información
geográfica, entre ellos muchos organismos oficiales de países de Sudamérica y
Oceanía.
La Comisión Europea planteó la necesidad de “una política que cree un entorno

de negocios favorable para un suministro de información geográfica competitivo,
pleno, rico y diferenciado”, para lo cual ha creado EC-GI, que a su vez desarrolla
el proyecto INSPIRE (INfrastructure for SPatial InfoRmation in Europe) que es la
iniciativa para el establecimiento de una Infraestructura de Datos Espaciales
Europea, desarrollada por la Dirección General de Medio Ambiente de la CE, la
Agencia Europea Eurostat y el Centro de Investigación común “JRC” (Joint
Research Center). INSPIRE tiene vocación de desarrollar una IDE Europea no
sólo utilizable en el ámbito del Medio Ambiente, sino en los demás ámbitos
europeos: Transportes, Agricultura, Economía, etc. El objetivo de INSPIRE es
intentar desencadenar la creación de una infraestructura de información espacial
europea que proporcione a los usuarios servicios de información espacial
integrados. Estos servicios deberán permitir identificar y acceder a información
geográfica de un amplio rango de fuentes, desde el nivel local al global, en forma
interoperable para diversos usos
.
Los principios que rigen la iniciativa INSPIRE son:
o Los datos deben ser recogidos una vez y mantenidos en el nivel donde
se logra la máxima efectividad.
o Debe ser posible combinar información geográfica con total continuidad
para toda Europa, desde fuentes diversas, y compartirla entre usuarios y
aplicaciones.
o La información geográfica debe ser abundante y disponible bajo
condiciones que no inhiban su uso extensivo.
o Debe ser fácil descubrir la información geográfica disponible, y en qué
condiciones puede conseguirse y usarse.
o Los datos geográficos deben ser fáciles de entender e interpretar, y
seleccionables en forma amigable.
La Dirección General de Medio Ambiente y Eurostat promovieron la constitución

de un Grupo de Expertos integrado por 2 representantes de cada Estado
Miembro de la UE (uno por la organización gestora del Medio Ambiente a nivel
nacional, y otro por la Agencia Cartográfica Nacional).
En su reunión de 17.12.2001 en Viena el Grupo de Expertos estableció 5 Grupos

de Trabajo, integrados por especialistas de los distintos países y organizaciones
participantes en INSPIRE, con la finalidad de preparar los “Position Paper”
correspondientes, como documentos básicos para el desarrollo de un marco
legislativo y operativo para poner en marcha la Infraestructura de Datos

Espaciales Europea. Estos Grupos de trabajo eran:
o Datos de Referencia y Metadatos.

o Arquitectura y Normas.
o Política de Datos y Asuntos Legales.
o Datos Temáticos Medio Ambientales Fundamentales.
o Estrategia de Implementación y Financiación.
o Análisis de Impacto.
El resultado del trabajo de estos Grupos se concretó en los “Position Papers”

presentados y aprobados en la reunión del Grupo de Expertos de 30/31.10.2002,
en Atenas. Estos documentos constituyen la base para la implementación de la
IDE Europea y para el desarrollo del marco legislativo adecuado, que se
concretará en directivas europeas. Además, constituyen una base doctrinal muy
importante a tener en cuenta en el desarrollo de las IDE nacionales, regionales y
locales. Por lo que afecta al presente trabajo se comentan los siguientes puntos:
Política de Datos y Asuntos Legales.
Los principios estratégicos establecidos son:· Papel de las IDEs

nacionales: La iniciativa INSPIRE se basará en una red de
Infraestructuras Nacionales de Datos Espaciales. Siendo responsabilidad
de los Estados Miembros la instalación y operación de éstas.
Precios: Los datos INSPIRE deberán estar disponibles para acceso y

visualización sin cargo para los ciudadanos y otros usuarios, la entrega,
descarga y reutilización se ajustarán a estipulaciones y condiciones
armonizadas en toda la Unión Europea.
Financiación e inversión: Los Estados Miembros deberán implementar

y mantener mecanismos de financiación, inversión y recuperación
sostenibles.
Licencias: Se introducirán marcos de cesión de licencias armonizados

para facilitar y optimizar la compartición, el comercio y el uso extensivo de
los datos e información temática de INSPIRE
Continuidad: Se asegurará el flujo de datos e información entre (a) la

Comisión y los Estados Miembros, (b) los Estados Miembros, (c)
autoridades locales y (d) miembros del público en general.
Estructuras de implementación y gestión: Deberán establecerse

órganos responsables de la coordinación y gestión de INSPIRE a nivel
europeo y nacional. Los poderes, deberes y responsabilidades deberán
basarse en los principios de subsidiariedad y proporcionalidad.
En relación con el aspecto de las implicaciones de esta iniciativa en otras

disposiciones legales europeas, cabe destacar que INSPIRE influirá en, e
igualmente se ve influenciada por:
o La Directiva sobre reutilización y explotación de la Información del

Sector Público (PSI).
o Las Directivas sobre Acceso a la Información Medioambiental
(Directiva 90/313/EEC, nueva directiva, Convención de Aarhus
1998).
o “Water Framework Directive”, y otras directivas relacionadas con
el Medio Ambiente.
o Comercio con la información y Ley de Competencia.
o Privacidad y protección de datos.
o Estructuras de implementación y financiación
El trabajo definitivo de este GT, trata sobre la Organización,

Implementación y Financiación de una IDE, para luego, siguiendo la
estructura de otros GT, hacer unas recomendaciones a la organización
de INSPIRE. El tema que trata es muy espinoso, especialmente en lo
referente a la Financiación, pues en definitiva es quizá el principal caballo
de batalla, es decir quién y como se va a pagar la implementación y
puesta en servicio de una organización de este tipo; el GT da
indicaciones pero no da una situación concreta a todas estas cuestiones.
Comienza el trabajo haciendo unas consideraciones comunes para la

implementación y la financiación. Entre otros considera para el desarrollo
del trabajo los siguientes aspectos:
o Con qué organización es necesario contar para implementar una

IDE de acuerdo a los principios de INSPIRE
o Igualmente, qué se necesita en los Estados Miembros para
acometerla en cada uno de ellos
o Qué costes puede tener la captura, manejo y difusión de los
datos, tanto dentro de las IDEs nacionales, como a nivel europeo
o Qué diferentes tipos de modelos de financiación hay a nivel
nacional y europeo
o Nuevos modelos de financiación dentro del concepto de una IDE
o Qué tipos de modelos de precios se pueden implementar para
Productores y Usuarios
Consideran que la implementación de la IDE, debe estar estructurada a lo

largo del tiempo, en diferentes fases. Esto es lógico pensarlo, puesto que
existe una disparidad grande de situaciones de partida en los diferentes
países, por lo que dependerá en buena medida del desarrollo de los
estándares a utilizar y deberá tener una característica modular. Este
proceso que se augura largo, ha de estar precedido por estudios pilotos
que desarrollen las diferentes fases.
Establece una programación en el tiempo de algunos eventos, relativos a

la IDE; esta programación no es nada exahustiva, dando solamente una
idea del tiempo necesario para su realización.
Como ya se ha dicho la financiación es la gran incógnita. Esta parte es la

más elaborada del documento, dando diversas ideas e incluso llegando a
hacer estimaciones de los costes y el origen de los fondos.
Además de los diferentes niveles administrativos de la Unión, también

los particulares se deberían involucrar en la infraestructura,
poniendo a disposición de esta los datos generados por ellos de acuerdo
a las normas establecidas.
Establece un programa de acciones que requieren financiación, de

acuerdo a las dos fases de implementación y operativa. En la primera
contempla las siguientes:
o Definición de las estructuras institucionales

o Definición de los componentes de la IDE
o Captura de datos de referencia y temáticos básicos
o Estandarización y armonización de datos
o Elaboración y publicación de catálogos de metadatos
En la fase operativa, contempla el mantenimiento de datos y de los

catálogos y la continuidad de la iniciativa. En estas operaciones
establecen unas prioridades de financiación, de acuerdo a las propias
prioridades de implementación. Las valora en, muy alta, alta, media, baja,
siendo las concernientes a los metadatos a las que asignan una muy alta
prioridad.
2.5. La IDEE
En consonancia con la iniciativa europea INSPIRE, la Comisión Permanente del

Consejo Superior Geográfico, aprobó, en su reunión del 10 abril de 2002 y a
propuesta de la Comisión de Geomática, la creación de un grupo de trabajo
abierto para el estudio y coordinación de la puesta en marcha de una
Infraestructura Nacional de Datos Espaciales como resultado de la integración,
en primer lugar, de todas las Infraestructuras de Datos Espaciales establecidas
por los productores oficiales de datos a nivel tanto nacional como regional y
local, y en segundo lugar, de todo tipo de infraestructuras sectoriales y privadas.
El fruto de esta iniciativa es el proyecto Infraestructura de Datos Espaciales de
España (en adelante IDEE).
La arquitectura de la Infraestructura de Datos Espaciales de España está

compuesta de un conjunto de nodos de distintos niveles, de modo que, según la
iniciativa INSPIRE los datos sean servidos por la administración más próxima a
los mismos.
En consecuencia, existirán nodos a nivel nacional (nodos de los diferentes

organismos, institutos y centros de la Administración General del Estado),
regional (nodos de las Comunidades Autónomas y de sus consejerías) y local
(nodos de Ayuntamientos y otras entidades locales). Será responsabilidad de
cada organismo el mantenimiento, actualización y gestión de la información
geográfica de su nodo.
Por tanto, el ciudadano podrá acceder a los datos de los diferentes organismos
sin conocer la ubicación física de los mismos, o bien, acceder directamente a
través del portal específico de acceso al nodo.
Cada uno de los portales permitirá el acceso a su nodo correspondiente y podrá

solicitar información del resto de nodos a través de los servicios que cada uno de
ellos ofrece.
La única condición que se le exige a un nodo candidato para formar parte de la

IDEE es que ofrezca sus servicios de forma estándar, según las especificaciones
del OGC (Web Map Service (WMS), Web Feature Service (WFS), Web
Coverage Service (WCS)). De este modo, se define la interfaz del servicio y
quedan ocultos los detalles de implementación de cada nodo.
Ilustración 5. Interoperabilidad en la IDEE
Por lo tanto está claro que es necesario un impulso institucional de la IDE

mediante un armazón institucional que tutele su desarrollo. Este armazón, cuyo
primer eslabón es la IDEE, tiene dos vertientes, una política y otra técnica, que
se plasman en los respectivos comités.
El comité político traza las líneas estratégicas comunes en información

geográfica además de realizar tareas de sensibilización sobre la importancia de
una estrategia única en esta materia dentro de la administración local. Para ello
ha iniciado el proceso que llevará a la definición de las responsabilidades,
políticas y acuerdos administrativos en materia de datos, procedimientos y
pliegos de contratación. Otras de sus responsabilidades es el impulso de
acuerdos de intercambio con otras IDEs e iniciativas de datos espaciales.
La relación interinstitucional es la piedra de toque de las IDE. La jerarquía crea

un entorno en el cual los datos son creados y mantenidos dentro del nivel y
utilizados por otros niveles en función de temas, escalas, actualidad y cobertura
Por lo anteriormente visto la justificación del establecimiento de la IDEE, esta

ligada a dos ideas fundamentales:
o La necesidad de manera fácil, cómoda y eficaz de los datos geográficos

existentes. La Información Geográfica ha sido hasta ahora un recurso de
costosa producción y difícil acceso por varios motivos: formatos,
modelos, políticas de distribución, falta de información,…
o La oportunidad de reutilizar la Información Geográfica generada en un
proyecto para otras finalidades diferentes, dado el alto coste de su
producción.
Por lo tanto, todas las iniciativas para el establecimiento de una IDE incluyen
unos principios comunes:
o Marco Institucional: el establecimiento de acuerdos entre los

productores de información geográfica, especialmente entre los
productores oficiales, para generar y mantener los datos espaciales
fundamentales («Framework data») para la mayoría de las aplicaciones
basadas en sistemas de información geográfica.
o Estándares: el establecimiento de normas a las que deberá ajustarse la
información geográfica, los intercambios de esta y la interoperación de
los sistemas que la manejan.
o Tecnología: el establecimiento de la red y mecanismos informáticos que
permitan: buscar, consultar, encontrar, acceder, suministrar y usar los
datos espaciales o geográficos. Como por ejemplo permitir incorporar los
metadatos organizados en catálogos y ofrecerlos en la red a través de
servidores.
o Política de datos: El establecimiento de las políticas, alianzas y
acuerdos de colaboración necesarios para aumentar la disponibilidad de
datos espaciales y compartir los desarrollos tecnológicos.
2.6. Marco Tecnológico
Las IDE son un gran paso hacia la unicidad y consistencia de la información

geoespacial, ofreciendo los datos necesarios para la mayoría de estudios o
proyectos de escala local. Acercar estas infraestructuras al usuario implica
facilitar la búsqueda de información cartográfica válida. Todo esto se consigue
gracias a estrategias y a tecnologías que permiten su implementación que hacen
posible la interoperabilidad mediante estándares que permitan compartir
información. En este sentido este apartado se complementa con el Anexo 1:
Base Tecnológica de la IDE.
2.7. Arquitectura Orientada a Servicios. SOA

SOA (Service Oriented Arquitecture) es un concepto que desde el punto de vista

puramente tecnológico es bastante sencillo, y desde el punto de vista de diseño
de software, nada novedoso.
Este capítulo tiene el objetivo de aclarar el concepto, para ello en primer lugar se
da una definición del concepto, y se trata de explicar qué es lo que diferencia a
esta nueva tendencia de las viejas arquitecturas que exponían servicios de una
manera al menos similar a la propuesta hoy en día por SOA.
A pesar de que la IDE junto al GIS Corporativo que la soporta (Anexo 3), al
menos está muy relacionado e incluso se puede llegar a decir que está basado
en SOA, hay muy pocos estudios o artículos que planteen explícitamente este
hecho. El porqué de esta situación merecería un estudio en si mismo, pero
entiendo que es interesante en este trabajo plantear esta relación sobre todo
porque hay muchas inversiones y esfuerzos por parte de empresas privadas y
administración pública en SOA, cuyos resultados podrían ser aplicables al
entorno GIS Corporativo/IDE.
¿Qué es SOA?
SOA se puede definir como un “Paradigma de Arquitectura Corporativa”. Así

como en su momento, el Paradigma de Orientación a Objetos cambió la forma
en que pensamos en términos del análisis, diseño y construcción de
aplicaciones, SOA propone un modelo de pensamiento con el cual atacar la
definición de arquitecturas, y ya no las de aplicaciones individuales, sino las
arquitecturas de organizaciones completas.
Desde el punto de vista tecnológico, SOA propone varias capas de servicios que
exponen funcionalidad, fundamentalmente de negocio, que permiten la
composición de aplicaciones a partir de los mismos.
Una de las diferencias claves en la adopción de SOA es la utilización de

tecnologías basadas en estándares que faciliten e incluso permitan
automatizar la publicación e integración de aplicaciones y servicios.
En relación a este último tema, cabe mencionar que Web Services no es

sinónimo de SOA. Por el contrario, es posible utilizar Web Services y seguir
en un esquema de integración punto a punto, así como es posible implementar
un esquema SOA sin utilizar Web Services. Sin embargo, tanto Web Services
como los estándares asociados (XML, SOAP, WSDL, UDDI, WS-I) conforman
una base de tecnologías y estándares que facilitan la implementación de SOA.
Ilustración 6. Arquitectura Orientada a Servicios
Nivel de madurez de la organización
Hemos hablado hasta aquí de un aspecto básicamente técnológico de SOA. Sin

embargo, lo cierto es que por más que se cuente con una implementación total
de la arquitectura de referencia descrita antes, si una organización no avanza al
mismo tiempo en aspectos organizacionales, culturales, de desarrollo, de
presupuesto y de alineación al negocio; el beneficio que obtendrá de un
esquema SOA será nulo o cercano a nulo.
Según el modelo de dominio planteado por BEA, se pueden definir seis aspectos
en los cuales una organización que planea adoptar SOA debe avanzar,
incorporando soluciones concretas a las problemáticas que cada dominio
plantea.
Dentro de estos seis aspectos hay tres fundamentalmente técnicos:
• Arquitectura
• Bloques Básicos
• Proyectos y Aplicaciones
y tres no técnicos:
• Estratégia de Negocio y Procesos

• Costos y Beneficios
• Organización y Gobierno.
El nivel de madurez de una organización en su adopción de SOA, estará dado

por la factorización del nivel de madurez en cada uno de los aspectos
mencionados. Es así, que si una compañía ha avanzado en todos los aspectos
del modelo (Bloques Básicos, Arquitectura, etc.), pero no ha montado una
estructura de Gobierno y Organización para dar soporte al funcionamiento del
esquema, los beneficios que obtendrá de SOA serán escasos.
Arquitectura
Este es el dominio más tecnológico, y el más fácil de comprender por los

departamentos de IT de una organización. Para avanzar en este dominio, los
pasos son bastante claros, e involucran la definición de una Arquitectura de
Referencia, sobre la cual se diseñarán e implantarán las soluciones y sistemas
de información.
En la mayoría de las empresas, la proliferación de tecnologías y aplicaciones

departamentales ha dado origen a que la Arquitectura Corporativa surja como
una consecuencia imprevista de lo implementado, y no como un diseño
planeado y consensuado. Luego de esto, es usual ver una serie de “Proyectos
de Integración” tratando de solucionar la problemática originada.
La definición de una Arquitectura de Referencia, sentará bases para la

construcción de una Arquitectura Orientada a Servicios sólida que permita:
o Cambiar procesos de negocio existentes e implementar nuevos

rápidamente
o Modificar y desarrollar aplicaciones con mayor rapidez, ensamblando
componentes y combinando múltiples aplicaciones y procesos en nuevas
aplicaciones compuestas
o Aprovechar el uso de tecnologías basadas en estándares
o Proveer facilidades de administración, seguridad, integración y monitoreo
de la infrestructura
Seguidamente a esto, las distintas componentes de la Arquitectura de

Referencia deberán ser movidas a un ambiente de producción como parte de un
plan a largo plazo.
Ilustración 7. Arquitectura de Referencia SOA
Bloques Básicos
En relación a este dominio, la organización deberá identificar los servicios

básicos que componen la funcionalidad de su infraestructura de IT y montarlos
en un hub de servicios; más precisamente en la capa de Servicios de Acceso a
Información y Datos. Es en este dominio en el cual se deberán atacar temas
relacionados con la identificación de la funcionalidad relevante resuelta por cada
uno de los aplicativos corporativos, incluyendo bases de datos y sistemas
backend, y su publicación en forma de servicio.
Estos servicios pueden ser expuestos en base a tecnologías diversas como Web
services, RMI, JMS, etc. En los siguientes párrafos estudiaremos en detalle este
punto.
Ilustración 8. Tres partes fundamentales de un Servicio
Es así que por ejemplo, una consulta de normalización de una dirección, o mejor
dicho, el “Servicio de normalización de una direccion”, podría estar
implementado por un componente Java; por ejemplo, por un EJB. Esta sería la
“Implementación” del servicio. En esta implementación, seguramente el
componente Java accederá a algún sistema corporativo, o un desarrollo propio;
y será accedido a través del conector apropiado.
Ahora bien, los EJB (Enterprise Java Beans) naturalmente exponen su

funcionalidad a través de métodos java invocables remotamente desde distintos
servidores de la red a través de protocolo estándar RMI (Remote Method
Invocation). Esta constituiría una primer “Interfase”.
Eventualmente las aplicaciones de servicio al ciudadano en la Intranet podrían

hacer uso de esta interfase, invocando a las funciones de esta componente a
través de RMI y sabiendo que el servicio cumplirá para cada uno de ellos con un
“Contrato” específico, en el cual se definen cuestiones como tiempos de
respuesta esperados, cantidad de invocaciones por segundo soportadas,
cantidad de clientes simultáneos, etc.
Por otro lado, podría suceder que alguna aplicación batch de envío de
correspondencia, necesite en determinado momento utilizar este servicio. Siendo
una aplicación que ejecuta en background, podría hacer requerimientos de datos
de distintos entidades en determinado momento al comienzo de su proceso, y
realmente utilizarlos al final del mismo. En este caso, el mismo componente Java
descrito antes podría exponer una interfase basada en colas de mensajes JMS
(Java Messaging Services, un estándar de mensajería Java). De este modo, el
proceso de envío de correspondencia se comunicaría con el mismo servicio pero
a través de una interfase asincrónica, eventualmente de menor prioridad que la
interfase RMI (orientada a consumidores on-line de tiempo real), es decir, con un

“Contrato” distinto en cuanto al nivel de servicio y tiempos de respuesta
esperados.
Finalmente, podría ocurrir que un proveedor de este organismo imaginario, por

ejemplo una empresa de Medicina Prepaga, tenga preparadas campañas en sus
sistemas informáticos, y que para ejecutarlas necesite de ciertos datos de
posicionamiento. Supongamos que el sistema de nuestra empresa de Medicina
Prepaga está implementado en .Net, por lo que no le es posible utilizar el
servicio que nosotros exponemos a través de las interfaces basadas en Java
(RMI y JMS). Entonces, es muy sencillo con las herramientas adecuadas,
generar automáticamente una nueva interfase Web Service, un estándar que
permite que el servicio sea consumido desde cualquier tecnología. Muy
probablemente, y en especial para este tipo de consumidores externos, se
proveerá un nuevo “Contrato” con ciertas limitaciones, por ejemplo, en cuanto a
la confidencialidad de la información brindada y eventualmente limitaciones en
cuanto a la funcionalidad expuesta por el servicio.
De este modo, tendremos un servicio básico en la capa de servicios de Acceso a

Información y Datos que expone la funcionalidad de nuestro sistema corporativo
(backend), a través de tres interfaces (RMI, JMS y WebServices), con tres
contratos distintos según el consumidor.
Si avanzamos en el camino hacia la adopción de SOA, encontraremos que

procesos de negocio completos pueden ser expuestos como servicios para ser
consumidos por múltiples aplicaciones.
Proyectos y Aplicaciones
Es común, en organizaciones de cierto tamaño, encontrarnos con un nivel

alarmante de desconocimiento acerca de los proyectos e iniciativas en marcha
en los distintos departamentos y áreas. Con el objeto de aprovechar las ventajas
de SOA, es importante un cambio radical en este aspecto. En una Arquitectura
Orientada a Servicios, el orden de desarrollo e implementación de los proyectos
es fundamental para facilitar la reutilización de servicios y evitar la duplicación de
esfuerzos. Si el desarrollo de una aplicación A involucra la implementación de
los servicios 1, 2 y 3; y el desarrollo de una aplicación B exige la implementación
de los servicios 1,2,3,4,5,6,7 y 8, seguramente será conveniente dar prioridad a
la aplicación A, con el objeto de reducir el costo de desarrollo de la apliación B.
O al menos, se deberá dar prioridad a la implementación de los servicios
reusables (1,2 y 3), ya que son los que serán aprovechados en ambos
desarrollos. Esta coordinación exige de un cambio organizacional y la
implementación de esquemas de comunicación en relación a proyectos “on the
flight” entre las distintas áreas de un organismo.
Estrategia de Negocio y Procesos
Este dominio dentro del modelo ataca la necesidad de que la línea de negocio y
las áreas de IT hablen un mismo lenguaje. Normalmente estamos
acostumbrados, desde las áreas de tecnología, a hablar en términos de
aplicaciones y funcionalidad y no en términos de procesos o servicios de
negocio. Esta es una de las causales que ayudan a que exista lo que se conoce
como el “IT Gap”, o la incapacidad de las áreas de tecnología de satisfacer los
requerimientos de las líneas de negocio.
En relación a este punto, será necesario desde IT comenzar a implementar

“Servicios de Negocio”, y hacerlos conocer como tales a medida que se publican
en la capa de “Servicios de Negocio Compartidos” que mencionábamos en un
principio.
Costos y Beneficios
Nada de lo que se haga tendrá sentido si no somos capaces de medir el impacto

de la adopción de SOA en la organización desde el punto de vista económico.
Es imprescindible contar con mecanismos de evaluación que permitan estimar la
inversión y medir los beneficios, no sólo en términos de ahorro sino en términos
de mejoras en “time to market”.
Proyecto a proyecto, deben recolectarse los datos que permitan justificar las
inversiones realizadas y proyectar inversiones futuras. Ningún cambio será
percibido si no somos capaces de mostrar los resultados, especialmente cuando
se requiere de una inversión inicial significativa:
Organización y Gobierno
Es en esta área en la cual se debe producir el cambio organizacional y cultural

más importante. Las organizaciones que han implantado SOA con éxito han
atacado este punto mediante la creación de un “Comité de SOA”, responsable
de cuestiones como:
o Priorizar implementaciones.
o Auditar el nivel de disponibilidad de los servicios.
o Auditar el cumplimiento de los contratos, tanto por parte de los
productores como por parte de los consumidores de los servicios.
o Resolver cuestiones presupuestarias (qué área financia la

implementación de un servicio que va a ser reutilizado por muchas otras
áreas en producción, por ejemplo).
o Asegurar e imponer la reusabilidad y evitar la duplicación de esfuerzos
o Determinar la exposición o no de servicios sensibles hacia el exterior de
la organización.
o Determinar procesos operacionales, herramientas y buenas prácticas.
o Definir los mecanismos de versionamiento y control de cambios
o Asegurar la adhesión a la Arquitectura de Referencia
o Seguir métricas, costos y evaluar y reportar beneficios
o Implementar procesos de planeamiento y revisión periódicos
La creación temprana de este tipo de estructuras organizacionales es

fundamental en la adopción de SOA. Existen varias alternativas posibles de
implementación de estas estructuras; y la elección de la más adecuada
dependerá del tipo de compañía de que se trate, de su cultura empresarial, de
su distribución geográfica y de su jerarquía organizacional.
Ilustración 9. Cuatro estructuras organizacionales para adoptar SOA
SOA y la Administración Electrónica
Entendemos que la arquitectura orientada a servicios (SOA), entronca

esencialmente en sus principios y en sus técnicas con el modelo –y filosofía- que
deriva de la LAECSP (ley de Acceso Electrónico de los Ciudadanos a los
Servicios Públicos) y las normativas específicas que afectan a la IDE.
Internet y SOA se constituyen como dos herramientas básicas fundamentales de

cara al proceso de transformación de las Administraciones Públicas en su reto
de construir un escenario igualitario, universal, de calidad, y eficiente de los
Servicios Públicos.
SOA permite diseñar, construir e implantar servicios de complejidad creciente en

organizaciones asimismo complejas en las que interviene un gran número de
actores, con sistemas de información heterogéneos y con requerimientos
técnicos, funcionales y organizativos cambiantes en el tiempo.
Todas estas características intrínsecas de SOA están presentes como

características inherentes a los sistemas de información de las Administraciones
Públicas. Es, por tanto, idóneo el uso de SOA como modelo y herramienta válida
y útil para acometer los cambios que se derivan de la aplicación de la LAECSP y
las normativas específicas que afectan a la IDE.
Bases para el desarrollo de una IDE
3. Bases para el desarrollo de una IDE

En el apartado anterior se han definido las bases políticas y tecnológicas de una
IDE. En este capítulo se formalizan las aportaciones prácticas para el desarrollo
de una IDE basándose en diferentes estudios. Este capítulo se ha hecho a partir
de los trabajos de Maria Teresa Morant para la tésis doctoral sobre la IDE
SICAM de las Palmas de Gran Canaria, y los de Manuel Narbona Sarria para
definir un cuadro de mando integral para la gestión de servicios TI de la
administración pública para el Gabinete de Sistema del Servicio de Producción
de la Dirección General de Sistemas de Información Económico-Financiera de la
Junta de Andalucía
3.1. Definición de una estrategia
La definición de una estrategia para el desarrollo de una IDE es un requisito

necesario para garantizar que la iniciativa no quede en un mero proyecto con el
alcance, visión y futuro limitados, para que se pueda desarrollar de manera
coordinada implicando a todos los actores territoriales facilitando su
consolidación y sostenibilidad y para que se pueda incardinar de manera natural
en el marco organizativo y funcional de las organizaciones que la integran. En
general, se aconseja que cualquier tipo estrategia en una organización (o en
parte de la misma) forme parte de la estrategia corporativa o informacional de la
misma.
En el caso de una IDE que vaya a ser impulsada desde una administración
pública (como es en la mayoría de los casos), dicha integración es complicada,
dada la falta de tradición de dirección estratégica en las AAPP. Por otro lado,
tampoco ayudan el entorno complejo y carácter altamente burocratizado en el
que se desarrollan las AAPP, la incertidumbre acerca de los costes asociados al
desarrollo de una IDE y el gran desconocimiento y dificultades de cuantificación
de los numerosos beneficios intangibles que puede reportar el uso de la misma.
Sin embargo, a pesar de estas dificultades, siempre se pueden apuntar unas
sencillas “líneas” estratégicas a seguir y que pueden contribuir a que la IDE se
vaya gestando y creando a la vez que se crea el entorno organizacional
necesario para garantizar su éxito y sostenibilidad en el tiempo. Dichas líneas
estratégicas han de contemplar específicamente, además de los aspectos
puramente tecnológicos (y en clara alineación con los mismos), aquellos
aspectos organizacionales que propicien la colaboración y cooperación inter-
administrativa y la compartición de geoinformación.
3.2. Definición de la visión
La Visión (o “ideal”) puede ser descrita como la descripción de la situación futura

(necesaria o beneficiosa). Se sabe que una visión compartida por los grupos de
interés es la que probablemente mejor dirija sus actividades en la misma
dirección. El desarrollo de una visión común es un requisito imprescindible para
el éxito del desarrollo de la IDE. Cuando las necesidades de los grupos cambian,
el ideal también puede cambiar, pero sin un ideal o visión no habrá incentivos
para avanzar en la construcción de la IDE.
La creación y desarrollo de una visión común sirve para determinar el tipo y

alcance de la IDE, y puede constituir una poderosa herramienta de gestión,
especialmente en proyectos complejos donde muchos actores tienen que
cooperar para alcanzar un elevado grado de consenso. Una visión de la futura
IDE para toda una circunscripción territorial (nacional, regional, local…) más
adelante puede ayudar a perfeccionar actividades y encaminarlas hacia un
objetivo común. Éste objetivo además puede abrir perspectivas y ofrecer
seguridad en períodos de cambio e incertidumbre.
En el contexto de comunidades profesionales de tipo técnico, como las

existentes en torno al desarrollo de los SIG/IDE, y que son lo suficientemente
pequeñas como para hacer que todos sus miembros se conozcan entre sí, la
literatura destaca el hecho de que con frecuencia no existe una aparente buena
voluntad a nivel institucional para coordinar y armonizar el desarrollo de los
proyectos geomáticos. Es por ello que el desarrollo de una IDE en última
instancia requerirá de los cambios culturales y organizativos necesarios para que
pueda gestionarse todo el proceso de transformación que conlleva la IDE. Una
visión común para una IDE puede no darse o estar obstaculizada por la
resistencia cultural. En muchas ocasiones, la información se vincula al poder
personal y está estrictamente controlada de arriba abajo. Este enfoque
"personalizado" de la información puede ser una razón importante para explicar
la falta de un planteamiento compartido, lo cual también impide que las
diferentes partes compartan una visión común de la IDE.
Ilustración 10. Creación de la visión en la IDE

La visión debe ser propagada ampliamente, utilizando diversos medios de

comunicación para llegar a todos los posibles participantes. Se deben crear y
llevar a la práctica planes relativos a la diseminación de información sobre las
actividades IDE que están en marcha, incluyendo información sobre sus
componentes, realizar la mejor práctica tecnológica disponible y el fomento del
uso de tecnologías y estándares existentes para sustentar el desarrollo de una
IDE.
En cuanto a la clarificación del alcance y el rango de la IDE se pueden distinguir

dos amplias categorías: una es la IDE como resultado de un mandato formal
(por ejemplo, el caso de los EUA mediante la Orden Presidencial del presidente
Clinton), y la otra es la derivada de actividades ya existentes de coordinación
en torno a datos espaciales (como es el caso de Australia). Mientras que en el
primer caso se obtiene el beneficio de la financiación asegurada, en el segundo
caso el trabajo previo es ya una base que puede ser garante de una
colaboración futura. Por otro lado, el alcance de una IDE varía; éste puede ser
extenso (ampliamente participativo a todos los niveles) o concentrarse en un
grupo de presuntos participantes, tales como el sector público (administraciones
y empresas públicas), el privado (empresas y profesionales), Tercer Sector o por
mandato. Prescindiendo de la categoría a la que vaya a pertenecer la IDE y de
su alcance, ambos aspectos deben definirse cuanto antes.
3.3. La coordinación
Durante el proceso de creación de una IDE se recomienda la designación de un

órgano activo (comité o comisión) de coordinación para las diferentes tareas, y
que además asuma un papel de dirección de la misma. Para hacer efectiva una
IDE puede que no sea necesario establecer una nueva organización o
institución: en su lugar, pueden fortalecerse las ya existentes. Esto requerirá la
revisión de las circunstancias y posibilidades de la organización de que se trate,
para asegurarse que está bien preparada y capacitada para dicha función.
Un elemento crucial para su éxito es cómo se percibe la influencia del órgano de

coordinación. En la IDE deben involucrarse los representantes de todos los
principales sectores o grupos de interés. El órgano de coordinación, una vez
nombrados y habiendo sido asignado su mandato, puede llevar a cabo una serie
de actividades que deberán cumplirse con los plazos establecidos. El proceso de
ejecución debe ser planteado de manera multidisciplinaria y multisectorial, y
todas las organizaciones relacionas tendrán un papel que jugar en el desarrollo
de la IDE. Por otro lado, los grupos de trabajo constituyen plataformas que
permiten una mayor colaboración entre futuros participantes, juntando recursos y
armonizando iniciativas para evitar la duplicación. La implicación de posibles
participantes o socios en el futuro es una cuestión primordial para el desarrollo
de la IDE.
3.4. La Difusión
Como tareas para la difusión y divulgación algunas de las actividades que

pueden crear la visión y concienciar acerca de la necesidad del desarrollo de la
IDE son la elaboración de todo tipo de presentaciones y publicaciones y la
creación de redes de influencia.
Como actividades para la concienciación mediante la divulgación y para la

creación de las redes de comunicación se pueden realizar las siguientes
acciones:
• Publicitar los principios de la Iniciativa IDE y sus logros por medio de

presentaciones (informales, ante colectivos profesionales, en la
organización, en ámbitos académicos, etc.).
• Conseguir una mayor difusión de la IDE a través del apoyo de
personalidades o personas influyentes (políticos municipales,
profesionales de prestigio, altos funcionarios).
• Propuesta de proyectos-piloto sencillos con el objeto de mostrar el
valor de los datos espaciales y de una IDE así como los logros y
experiencias.
• Crear redes de comunicación personales y virtuales que permitan a
los participantes intercambiar experiencias de ejecución de la IDE.
• Facilitar un foro de debate, análisis e identificación de las cuestiones
pertinentes del desarrollo de la IDE.
• Cuando sea conveniente, ofrecer a los socios de la IDE u a otras
partes interesadas la oportunidad de participar en grupos de trabajo y
subcomités. Iniciar la creación de comunidades de interés entorno a
la IDE.
3.5. La Creación de Capacidades
Una importante barrera para hacer frente al cambio constante y la incertidumbre

en las AAPP es la capacidad de una organización para adoptar nuevos
estándares y tecnologías. Mientras que la introducción de sw especializado, por
ejemplo, para la creación de un catálogo geoespacial, es relativamente fácil, su
uso efectivo depende de las actividades técnicas desarrolladas así como del
apoyo de la organización. Debe crearse una concienciación sobre la importancia
de los componentes de la IDE hasta el más bajo nivel, con un fuerte liderazgo y
un sólido apoyo por parte de la dirección política. La creación de capacidades
será pues un aspecto crucial a lo largo de todo el proceso de creación a de la
IDE, ya que es un elemento clave en la creación de la visión y conciencia, así
como garantía del éxito posterior. La capacitación incluye tanto cuestiones
teóricas como aptitudes prácticas para llevar a cabo la realización de los
componentes de la IDE.
Además, hay que tener en cuenta que cuando se estipulen las competencias
técnicas específicas para un determinado trabajo, es posible que sea necesario
revisar los perfiles de los puestos de trabajo y los salarios. El desarrollo de
capacidades además es una buena práctica para evitar la "pérdida de cerebros",
ya que permite aumentar la capacidad del personal dentro de la organización,
reduciéndose así la necesidad de un reclutamiento externo de personal técnico,

a la vez que sirve de motivación para el personal dentro de la organización.
3.6. Aportaciones a la Base de Conocimiento Territorial
La creación de una Base de Conocimiento Territorial, además de ser en sí

mismo uno de los objetivos finales y razón de ser de toda IDE, a su vez es un
buen vehículo para facilitar la comunicación y aprendizaje entre los actores de la
IDE así como para propiciar la capacitación a nivel ciudadano. La Base de
Conocimiento deberá estar compuesta no sólo por la información territorial en sí
misma, sino también por toda aquella información relativa a la misma que
contribuya a su accesibilidad, uso, comunicación y comprensión.
Marco de Evaluación de la IDE
4. Marco de Evaluación de la IDE

Para valorar los resultados de la aplicación real de las líneas estratégicas y
propuestas esbozadas en los apartados anteriores, así como el impacto de las
acciones llevadas a cabo en el contexto de la IDE es necesario establecer unas
métricas que permitan tal evaluación, tanto en el plano de progreso de la IDE en
general como en la valoración de los cambios organizacionales que tenido lugar
mediante su introducción.
En este apartado en primer lugar efectuaremos una breve introducción a las

metodologías de evaluación de los sistemas y tecnologías de la información
(SI/TI), tanto desde la perspectiva tradicional como desde la perspectiva del
sector público, de los entornos web, de los SIG y de las IDE.
Posteriormente se describirán los cuatro enfoques que pueden adoptar las IDE
en su evaluación (la evaluación de control, la evaluación como aprendizaje, la
evaluación como creadora de sentido y la evaluación como práctica
exploratoria), así como la relación de los procesos evaluadores de las IDE en el
contexto del sector público, concretamente con la evaluación de la gobernanza
electrónica (de la que el e-gov sólo es una parte).
4.1. La evaluación tradicional en los SI/TI
Los dos grandes métodos tradicionales en la evaluación de los SI/TI más

aceptados en la actualidad son la evaluación cuantitativa y la evaluación
cualitativa. La mayor parte de los estudios centrados en la evaluación
cuantitativa se centran en la evaluación financiera de las inversiones. Para ello,
se buscan diferentes posibilidades para calcular el coste/beneficio (C/B) de la
puesta en funcionamiento del sistema o tecnología, si bien la literatura destaca
por otro lado la dificultad de cálculo C/B en base a términos puramente
financieros.
La segunda corriente, la de la evaluación cualitativa, se interesa principalmente

por el estudio de los beneficios intangibles de los SI/TI, y para ello examinan
ciertos parámetros relacionados con la satisfacción del usuario y el análisis de
intervalos de tiempo, y hace especial mención a la “evaluación interpretativa”
(también denominada evaluación “ritualista” o “simbólica”), entendida esta como
el análisis de las experiencias vividas dentro de la realidad organizacional: la
evaluación así entendida es un conjunto de interpretaciones que los individuos y
los grupos concernidos forman y reforman en el tiempo para informar acerca del
establecimiento del SI/TI en cuestión.
Es importante destacar que la claridad y adecuación de los SI/TI, así como su

evaluación, pueden variar desde una situación de consenso, donde los objetivos
están claros y son ampliamente aceptados, a una situación de no-consenso,
caracterizada por múltiples intereses y ambigüedades. Por otro lado, la
evaluación de un SI/TI se puede centrar en tres aspectos según su orientación:
el producto, el proceso o la organización.
En la evaluación orientada al producto el interés estriba en identificar y

calificar las diferentes características inherentes al SI/TI, y normalmente
conciernen la calidad y utilización del sistema y de la información vista ésta

desde el punto de vista del usuario.
La evaluación orientada al proceso hace las veces de medio para examinar la

eficiencia del desarrollo del SI/TI. En este sentido la literatura establece cuatro
tipos de medidas orientadas al proceso: la medida del grado de satisfacción de
cada uno de los objetivos específicos; las medidas comparativas tales como el
benchmarking; la determinación del grado de adaptación del proceso mediante
informe de los cambios requeridos y la medida de la adecuación del proceso por
medio de estándares exteriores (por ejemplo, las normas ISO).
En cuanto a la evaluación orientada a la organización, ésta parte del

reconocimiento cada vez mayor de que el grado de madurez de la organización
es un factor clave para la puesta en funcionamiento de un SI/TI. Dicha madurez
se puede medir en relación a la planificación organizacional en relación al SI/TI,
la existencia y utilización de la infraestructura tecnológica o el tipo de gestión
funcional de los SI/TI.
Ilustración 11. Diferentes tipos y orientaciones que puede adoptar la evaluación de los
SI/TI
4.2. Perspectivas para la evaluación del sector público
Sorprendentemente, aunque las bases teóricas acerca de la evaluación de las

iniciativas IDE están ya maduras, y aun cuando cada vez existen más proyectos
IDE, las prácticas de evaluación no están extendidas. Ello quizás se deba a la
tendencia en insistir en la dificultad de medida de impactos y beneficios, y no de

los costes, y partir de la asunción de que los costes son fácilmente
cuantificables. Sin embargo, en la práctica también se demuestra que los costes
tampoco se determinan adecuadamente debido a que estos están integrados,
son indirectos, o están incorporados ya en los programas presupuestarios. Otra
complicación añadida es que por su naturaleza, los costes de las IDE se
reparten entre sus múltiples participantes, los cuales tienen sus distintos
presupuestos y prácticas contables.
Ilustración 12. Esquema de las distintas dimensiones consideradas por la evaluación de

control para el sector público
Según algunos autores, para la evaluación del sector público el enfoque más
adecuado es el de la “evaluación de control”, ya que es el que enfatiza las
operaciones, apoya las decisiones en cuanto a inversiones y se basa en
medidas tales como ratios, porcentajes e índices. Además, lo más importante de
la evaluación es que ha de ser un proceso institucionalizado, y sólo a través de
este proceso se puede desarrollar una base de conocimiento efectiva que
asegure un desarrollo exitoso.
En el ámbito de la literatura de los SI/TI se tratan dos dimensiones en cuanto a la

evaluación de control: el tiempo y la perspectiva. Además, en el caso de la
evaluación del sector público se añaden tres dimensiones más: la demanda
formal, el uso de los resultados y la especificidad de los inputs.
Con respecto al tiempo, los autores distinguen entre tres momentos de

realización de la evaluación: “a priori”, “durante” y “a posteriori”. La evaluación a
priori también llamada ex ante, se realiza para ayudar en la toma de decisión en
el inicio de un proyecto determinado y especialmente para justificar el mismo. La
evaluación durante el proceso se centra en rutinas de monitorización de la
implementación y mejora del sistema en el tiempo. La evaluación a posteriori,
conocida también como medida de la realización, puede ser vista como un
sistema de gestión de la información para asistir en el control de las funciones de
la organización, recursos u otras responsabilidades. Si se utilizan patrones o
referentes, el proceso sirve de feedback que refuerza la responsabilidad.
La evaluación de control se puede realizar desde diferentes objetivos o

perspectivas: el de la mejora de la plataforma, operacional, financiera,
beneficiarios o aprendizaje y crecimiento. La perspectiva de la mejora de la
plataforma se centra en las aportaciones de las mejoras técnicas en la
comunicación y la compartición de información; la perspectiva operacional se
refiere a la mejora de eficiencia de las actividades operacionales del día a día y
en los canales de suministro y distribución; la perspectiva financiera se refiere a
la actualización del control económico y en la mejora de la localización de los
recursos (los beneficios de la gestión financiera como oposición a los beneficios
derivados directamente de las perspectivas plataforma u operacional). La
perspectiva de los beneficiarios refleja y destaca la colaboración y acuerdo de
los grupos de interés y el grado en el cual sus necesidades son cubiertas. La
perspectiva del aprendizaje y crecimiento se dirige al incremento de
funcionalidad, flexibilidad y utilidad y vida futura de la infraestructura de TI. Esta
clasificación de perspectivas no es rígida ni cerrada, ya que las perspectivas se
pueden solapar para un caso concreto y existe un amplio margen para la
interpretación de las mismas.
Ilustración 13. Síntesis de los marcos de evaluación de control en SI/TI
La dimensión de demanda formal en el sector público proporciona una

motivación para conducir la evaluación, y es un pre-requisito para
institucionalizarla. La experiencia muestra que sin una demanda efectiva
(basada en presiones reales a los gobiernos y AAPP) cualquier esfuerzo de
institucionalización de la evaluación perderá interés y se evaporará. La demanda
formal puede ser interna o externa.
La demanda interna es la que parte de las necesidades de la gestión o la

satisfacción de una directiva. La externa es conducida por la accountability ante,
por ejemplo, una agencia presupuestaria. La demanda externa también puede
proceder de la presión social por parte de grupos de interés que no forman parte
de la gestión del SI/TI, pero los cuales inducen obligatoriamente a dar una
respuesta formal.
La dimensión uso está muy estrechamente relacionada con la de demanda

formal. Para el Treasury Board of Canada Secretariat, se pueden articular cinco
usos distintos: sustentar la toma de decisiones en relación a la gestión de gastos
y recursos como parte de un programa de financiación y justificación de nueva
financiación; corroborar la necesidad de revisar las políticas o dirección
estratégica de un programa; dirigir o implementar el diseño de entrega de un
servicio; mejorar las relaciones entre grupos de interés y reforzar la
accountability.
La tercera dimensión en el sector público es la especificidad de los inputs entre

organizaciones. Esto se consigue a través de la integración de la evaluación con
otras herramientas establecidas en la gobernanza, tales como la planificación de
inversiones, presupuestos y auditoría. Los inputs (inversión y riesgos) de cada
organización comprometen la iniciativa IDE porque influye en las relaciones de
poder entre organizaciones.
4.3. CMI para la gestión de Servicios TI de administración

electrónica
En este apartado se propone un método para definir los objetivos estratégicos

para la Gestión de Servicios TI de Administración Electrónica para los
ciudadanos, haciendo uso del Cuadro de Mando Integral (CMI) adaptado a las TI
y a la Administración Pública.
Introducción CMI: Las perspectivas y estrategias

Balanced Scorecard (BSC) (CMI, en español)
El Cuadro de Mando Integral (CMI) (Balanced Scorecard, BSC, en

inglés) ayuda a los directivos a fijar los objetivos estratégicos de sus
organizaciones, y en concreto, debe ayudar a los directivos TI a definir
los objetivos estratégicos TI para la organización.
Además, el CMI aplicado a las TI es imprescindible para justificar la

inversión en TI de la organización, puesto que sólo a través de un
conjunto de indicadores adecuado, las TI pueden mostrar a la
organización como aportan valor a la misma.
Fue introducido por Kaplan y Norton en el ámbito empresarial (desde

1992). Su idea básica es que la evaluación de una organización no
debe restringirse a evaluación financiera tradicional sino que debería
ser complementada con medidas concernientes a la satisfacción de los
clientes, a los procesos internos y a la capacidad de innovar. Estas
medidas adicionales deberían asegurar el futuro financiero de la
empresa y conducir a la empresa hacia sus metas estratégicas
mientras mantiene equilibradas estas 4 perspectivas (financiera,
cliente, proceso e innovación). Kaplan y Norton proponen una
estructura en 3 capas para estas 4 perspectivas: misión (por ejemplo,
para convertir a los clientes en su suministrador preferido), objetivos
(por ejemplo, para proveer a los clientes de nuevos productos) y
medida (por ejemplo, porcentaje de facturación generado por los

nuevos productos).
IT BSC
El modelo estándar del Balanced Scorecard (BSC), el de Kaplan y

Norton, debe ser modificado cuando se trata de aplicarlo a las TI ya
que las TI son parte de la organización y participan de la perspectiva
financiera aportando valor a la organización. La aplicación de BSC a las
TI fue descrita por Van Grembergen y Van Bruggen (1997) and Van
Grembergen and Timmerman (1998).
La Tabla 1 muestra el estándar IT BSC. La perspectiva Orientada a los

Usuario representa la evaluación del usuario de las TI. La perspectiva
de Excelencia Operacional representa los procesos TI empleados para
el desarrollo y provisión de aplicaciones. La perspectiva de Orientación
Futura se refiere a los recursos humanos y tecnológicos que las TI
necesitan para la provisión de sus servicios. Finalmente, la perspectiva
de la Contribución al Negocio indica el valor para la organización de las
inversiones en TI.
Ilustración 14. IT-Balanced ScoreCard
Misión de la GSTI
La misión de la GSTI es: La satisfacción del ciudadano a través de la

gestión de servicios de administración electrónica que aporte valor al
ciudadano, a los usuarios internos, a la organización y a la sociedad.
Las metas de la GSTI
Las metas a alcanzar con la GSTI son:

o Mejorar la imagen de la Organización mediante el aumento del

uso de los servicios y la reducción del coste de los mismos sin
renunciar a la calidad y la seguridad
o Aumentar el uso de los servicios TI por parte de los ciudadanos y
usuarios internos mediante en aumento de la satisfacción de los
ciudadanos y usuarios internos
o Reducir el coste a largo plazo de la provisión de servicios TI

promoviendo la concienciación de los ciudadanos y
usuarios internos del coste de los servicios.
Indicadores
Cada una de estas perspectivas debe ser trasladadas en sus

correspondientes métricas y medidas que miden la situación actual.
Estas medidas deben ser repetidas periódicamente y confrontadas con
las metas y puntos de control que han sido fijados con anterioridad. Es
muy importante en un IT BSC que las relaciones causa-efecto sean
establecidas y que las conexiones entre los 2 tipos de medidas, de
resultado y de desempeño, estén claras. Un IT BSC bien construido
necesita de estos 2 tipos de medidas.
Las medidas de resultados, como la productividad de los

programadores (por ejemplo, número de puntos de función por
persona y mes), sin medida de desempeño, como la formación de la
dirección (por ejemplo, horas de formación por persona y año), no
indica cómo los resultados pueden ser alcanzados. Y medidas de
desempeño sin medidas de resultados pueden inducir a inversiones sin
saber si la estrategia es efectiva.
Esta relación causa-efecto debe ser definida para toda la IT BSC como
muestra la siguiente ilustración.
Ilustración 15. Relaciones Causa Efecto en IT-BSC
Para saber si los objetivos propuestos se alcanzan, o en grado se

desvían, es necesario partir de unas medidas iniciales de los mismos.
En el ejemplo aquí presentado no se dispone de estos valores porque
estamos partiendo de una situación en la que no existe GSTI.
Como se puede ver se han definido indicadores tanto para los objetivos
estratégicos de alto nivel como para los subobjetivos. En el caso, de los
indicadores de los objetivos estratégicos de alto nivel se ha procurado
que estos sean indicadores globalizadores de todos los subobjetivos
que colaboran con el objetivo estratégico.
El Mapa Estratégico para la GSTI
El mapa estratégico, es sin duda el elemento más importante de un BSC, por

desgracia en muchas implantaciones nos olvidamos de este elemento
fundamental.
El mapa estratégico debe describir, en forma clara y visual, la estrategia de la

organización. Debe permitir comprender, de un solo vistazo, la estrategia de la
empresa, incluidas las relaciones causa-efecto y las dependencias entre los
objetivos.
Un Mapa Estratégico (ME) representa la relación entre los objetivos estratégicos.

Para la confección del ME se han definido objetivos estratégicos de alto nivel
(con fondo blanco en el ME), a los que acompañan objetivos habilitadores de los
de alto nivel (con fondo gris en el ME). Los objetivos resultados, los de alto nivel,
en cada estrategia son objetivos habilitadores para los objetivos de otras
estrategias.
En primer lugar, para crear un mapa estratégico tenemos que identificar las
perspectivas por la cuales queremos analizar el estado de nuestra empresa.
Seguidamente debemos definir los objetivos estratégicos y trazar la forma de

conseguir con objetivos locales a cada perspectiva. La representación de estas
relaciones causa-efecto será nuestro mapa estratégico. Si al acabar el mapa no
tenemos ningún objetivo local en alguna de las dimensiones, veremos
claramente que nuestra estrategia no esta equilibra, no esta “balanceada” como
pretendemos con el BSC.
El mapa estratégico puede a su vez estar subdividido por líneas de actuación,

como puede ser la de crecimiento, la de productividad o la de calidad.
Por último no debemos olvidar, que un mapa estratégico no es algo que se crea
una vez y se arrincona, es algo dinámico, que debe reflejar la estrategia
cambiante según las necesidades del entorno en el que nos movemos nosotros
y nuestros competidores.
Por eso debe mantenerse periódicamente y mostrar de forma gráfica y clara (por
ejemplo mediante el uso de colores) el estado de consecución de cada uno de
los objetivos.
La importancia de los mapas estratégicos en el Balanced Scorecard es tanta que

los mismo Kaplan y Norton, ya prácticamente no hablan de otra cosa en los
últimos años, priorizándolo por encima del cuadro de mando y la representación
de indicadores.
Lo que se pretende con esta distribución es reflejar como cada perspectiva

influye en la superior.
Ilustración 16. Mapa Estratégico
Perspectiva de Excelencia Operacional
Se definen 2 estrategias para esta perspectiva:
La estrategia de “Acuerdos de Nivel de Servicio (ANS)” encaminada a conseguir

que todos los servicios provistos tengan firmado un ANS y a concienciar a los
ciudadanos y usuarios internos del coste de los servicios que reciben. Téngase
en cuenta que el caso de la administración no existen ANS como tales, sino que
dado que los clientes son, por un lado los ciudadanos y por el otro los usuarios
internos, lo que realmente existe es la Carta de Servicio como compromiso de
servicio de la Administración frente al ciudadano, y Acuerdos de Nivel de
Operación con los usuarios internos.
Ilustración 17. Perspectiva de Excelencia Operacional-Provisión de Servicios
Los ANS propiamente dicho se firman, en el caso de la Administración, con los

proveedores, pero en este caso, la Administración es el cliente y no el proveedor
de servicios. La estratégia “Help Desk” encaminada a centralizar la relación con
los ciudadanos y usuarios internos y a procurar su satisfacción.
Cada una de estas 2 estrategias, que como se ha comentado antes

corresponden a objetivos estratégicos de alto nivel, se alinean con cada una de
las áreas consideradas por ITIL para la gestión de servicios: La provisión del
Servicios y el Soporte del Servicio.
En el mapa estratégico se ha representado la contribución del resto de los

procesos ITIL, transformados en objetivos, al de ANS y al de Help Desk,
haciendo que sean estos los que sean objetivos resultados y habilitadores de los
objetivos de la perspectiva de orientación futura y de Orientación a los
ciudadanos y usuarios internos, respectivamente.
Ilustración 18. Perspectiva de Excelencia Operacional-Soporte de Servicios
Perspectiva de Orientación Futura
En la perspectiva de Orientación Futura hemos considerado como objetivo

estratégico de alto nivel “Aumentar la inversión en la Gestión de Servicios TI”.
Los 2 subobjetivos de este objetivos son: “Aumentar la inversión en
infraestructura TI” y “Aumentar la inversión en RRHH TI”. Se considera que la
inversión tanto en HW y SW como el RRHH son objetivos habilitadores de la
gestión del ANS y del Help Desk, destacando que esta inversión va encaminada
a procurar recursos para la gestión de servicios TI.
Ilustración 19. Perspectiva de orientación futura

Perspectiva de Orientación a los Ciudadanos y Usuarios

Internos
En cuanto a la perspectiva de Orientación a los Ciudadanos y Usuarios Internos

se pueden hacer las siguientes consideraciones:
Por un lado, la gestión del ANS implica la gestión financiera de los servicios. En
la perspectiva del ciudadano y el usuario interno se ha considerado conveniente
hacer partícipe a ambos del coste de los servicios y realizar una facturación
virtual del mismo. Con demasiada frecuencia se considera muy dificil evaluar el
coste de los servicios, y así es. Pero la gestión financiera de los servicios implica
antes de nada la gestión de los activos y la valoración de los mismos, y aunque
es dificil, es posible.
En España existen algunas experiencias de facturación virtual de los servicios

prestados a los ciudadanos. En concreto, la Comunidad Valenciana entrega a
los pacientes tras su hospitalización una factura virtual del coste de la
estancia en el hospital. Hacer partícipe a los ciudadanos y usuarios internos
del coste de los servicios que reciben puede ayudar a un mejor uso de los
recursos, y por tanto a aumentar la eficiencia de los servicios.
Por otro, una buena atención al ciudadano y usuarios internos redunda en la

satisfacción de ambos.
Ilustración 20. Perspectiva de Orientación a los ciudadanos y usuarios internos
Perspectiva de Contribución a la Organización
Es evidente que, al igual que en la empresa privada lo que se pretende es que

los clientes usen masivamente los servicios ofrecidos porque esto produce
beneficios económicos a la empresa, a la Administración lo que más le importa
es la consideración que los ciudadanos tengamos de ella. Por eso se ha definido
un objetivo estratégico de alto nivel encaminado a “Mejorar la Imagen de la
Organización”, que se basa en 2 subobjetivos. Uno, “Aumentar eficiencia de los
servicios” que se espera obtener mediante el uso adecuado de la infraestructura
propiciado por la concienciación de los ciudadanos y los usuarios internos del
coste de los servicios, y dos, “Aumentar el uso de los servicios”, cuyo objetivo
habilitador es la satisfacción de los ciudadanos y usuarios internos.
Obsérvese que el objetivo de alto nivel “Mejorar la Imagen de la Organización”

es también un objetivo habilitador de “Aumentar la inversión en la Gestión de
Servicios TI”. Esto es así, ya que cuanto mejor imagen se tenga de la
organización debido al uso de las TI para la gestión de servicios, más justificada
estará la inversión en Gestión de Servicios TI.
Esto es así, ya que cuanto mejor imagen se tenga de la organización debido al

uso de las TI para la gestión de servicios, más justificada estará la inversión en
Gestión de Servicios TI.
Ilustración 21. Perspectiva de Contribución a la Organización
4.4. Enfoque para la evaluación de las aplicaciones Web
La evaluación de SI/TI en el contexto de internet presenta ciertos rasgos

distintivos de la evaluación SI/TI tradicional. Estos rasgos inicialmente eran
relativos a la estimación de la importancia de la red internet en el éxito del
comercio electrónico (e-commerce). Actualmente, se pone especial énfasis en
internet como el medio por excelencia para canalizar y sostener los objetivos de
numerosas organizaciones, entre ellos el sector público.
Para el contexto del e-commerce los usuarios principales del sistema son los
clientes y los proveedores, en lugar del usuario interno de la organización.
Aparecen así tres nuevas dimensiones en la evaluación: la calidad del servicio
(sistema o aplicación web), la intención de utilización del sistema y el uso
efectivo del mismo, donde los impactos individuales y organizacionales son
reemplazados por los beneficios netos. Los beneficios netos dependen asimismo
a dos criterios: la utilización del sistema y la satisfacción del usuario.
En relación a la calidad del servicio o aplicación web, su evaluación se basa en

percepción de los usuarios en cuanto a la facilidad de utilización y utilidad del
sitio web. Estos criterios son evidentemente de carácter “motivacional”, y han de
provenir de un modelo más general para evaluar el nivel de aceptación individual
de las TI, como por ejemplo el modelo TAM (Technology Acceptance Model). En
este modelo, la facilidad de utilización es el esfuerzo que un usuario cree que
debe de hacer para que pueda aprovechar la aplicación. La utilidad percibida se
define como el grado en el que un individuo piensa que la utilización del SI/TI
podría mejorar su capacidad o el desempeño de su trabajo.
En relación a la facilidad de uso de la web (“Web Site Easiness”), los autores
establecen que está compuesta por la:
o facilidad de reconocimiento
o facilidad de navegación
o facilidad para reunir información

o facilidad para el comercio.
Para otros autores la dimensión utilidad del uso de la web esta compuesta por la:
o utilidad para la navegación

o utilidad para reunir información
o utilidad para el comercio
Dado que el modelo TAM no refleja la gran variedad de condiciones contextuales

en las que el internauta puede realizar una tarea a través de internet, Moon
introduce el concepto de disfrute (playness) para considerar mejor el
comportamiento en torno a la calidad de las aplicaciones web, y que define como
una creencia o motivación interior para utilizar las cosas formada a partir de la
experiencia individual con el entorno. En el contexto de los sitios web, Moon
demuestra que el disfrute percibido, así como la facilidad de uso, tienen más
efecto sobre la actitud individual que la utilidad percibida, esto es: los factores
motivacionales intrínsecos tienen mayor efecto que los extrínsecos en la
construcción positiva hacia un entorno web. Para que una aplicación web pueda
ser considerada de calidad, ésta debe de invertir previamente en resultar
interesante, fácil y agradable de utilizar, y no es suficiente tener buenos
resultados en el plano técnico.
4.5. La evaluación de las IDE
La investigación sobre la evaluación SI/TI ha tenido siempre bastante interés en

la comunidad geomática. Algunos autores han abordado el problema de
determinar el valor de la GI en términos financieros, otros analizan dicho valor
bajo pautas políticas y de contexto o analizando las relaciones entre calidad,
utilidad y valor de la GI bajo una perspectiva filosófica o en función de otros
aspectos tales como la eficiencia y la efectividad de los sistemas basados en GI
como contribución al bienestar humano.
Las diferentes tareas de evaluación de IDE hasta ahora se han centrado tanto en
el estudio de las iniciativas existentes actualmente como en comparaciones
entre las mismas. Los estudios conceptuales investigan las relaciones entre los
criterios de evaluación y los diferentes niveles jerárquicos de las IDE, en los
aspectos técnicos, económicos, comunicacionales u organizacionales que
intervienen en la preparación para desarrollar una IDE, o en explicar la
complejidad y naturaleza multifaceta de la evaluación de las IDE. Sin embargo,
aún así existen dificultades para identificar y medir los beneficios de una IDE,
complejidad que se incrementa cuando nos movemos desde una perspectiva
dato-céntrica (propia de las IDE de primera generación) a la perspectiva
centrada en los servicios (propia de las IDE de segunda generación). A pesar del
reciente auge de los estudios en la evaluación de las IDE todavía no están claras
las asunciones implícitas y explícitas generalizadas en los marcos de evaluación
ni la importancia de los factores contextuales.
Aplicando los principios de la evaluación de los SI/TI, Georgiadou, Rodríguez-

Pabón y Lance identifican en la literatura cuatro posibles orientaciones de la
evaluación de experiencias IDE dependiendo del nivel de incertidumbre y de los
objetivos y su causa y efecto: la evaluación de control, la evaluación como

aprendizaje, la evaluación como creadora de sentido y la evaluación como
práctica exploratoria. Estas orientaciones pueden ser consideradas en base a su
naturaleza (como respuesta, aprendizaje, diálogo o máquinas de ideas), en
términos de su propósito (objetivo de seguimiento, experimentación, creación de
consenso o exploración) así como en términos de su rol evaluador en el proceso.
Ilustración 22. Orientaciones de la evaluación aplicadas a las IDE (basado en

Georgiadou, Rodríguez-Pabón y Lance)
4.6. La evaluación como control
En esta orientación los objetivos esperados de las inversiones en la IDE son

cuantitativos, y sus impactos parecen claros y por tanto resulta sencillo obtener
el consenso entorno a ellos. A nivel operacional esta clase de evaluación
considera los aspectos técnicos y económicos y funciona como una máquina
que da respuestas. Se apoya en los modelos de decisión racional y los análisis
acerca de la eficiencia y la eficacia de las inversiones SI/TI. El propósito de este
tipo de evaluación es el seguimiento de los objetivos, donde los evaluadores
actúan como auditores controlando y categorizando los éxitos. Se contemplan la
mayor parte de aspectos cuantitativos ignorando los aspectos sociales e
intangibles, o manejándolos de manera prescriptiva.
4.7. La evaluación como aprendizaje
En este tipo de evaluación los resultados esperados para el sistema están

claros, pero los logros estratégicos e impactos parecen inciertos o difíciles de
predecir. En este caso la organización necesita ser sensible y abierta al
aprendizaje individual y organizacional y el cambio. El SI/TI aparece aquí como
un instrumento de feedback que incorpora un proceso social de crítica,
interpretación y debate. Contribuye a disminuir la incertidumbre en los cambios
estratégicos y funciona como una máquina de aprendizaje. El objetivo de esta
evaluación es el de experimentar, donde los evaluadores actúan como creadores
de conocimiento que incrementan el capital de conocimiento a través de la
experimentación.
4.8. La evaluación como creadora de sentido
En esta orientación no hay consenso acerca de los objetivos esperados; parecen

poco claros e impredecibles. A nivel operacional las vinculaciones entre las
acciones y sus potenciales impactos en la organización son, no obstante,
consideradas razonablemente predecibles. Este tipo de evaluación intenta reunir
información tácita e informal así como información formal, y por tanto opera
como una máquina para el diálogo. Su propósito es el de alcanzar el consenso
relativo a los objetivos del SI/TI, y el evaluador actúa como facilitador en el
proceso.
4.9. La evaluación como práctica exploratoria
En esta orientación no existe ningún consenso en cuanto a los objetivos

esperados ni acerca de la estrategia e impactos. Los participantes intentan
generar ideas, experiencias y tratan de comprender explicar una situación
altamente incierta. Esta evaluación funciona como una máquina de ideas para la
definición de nuevos paradigmas, nuevas formas organizacionales y nuevas
normas de comportamiento: tiene como fin cambiar los esquemas de los actores
y las asunciones que les influencian. La evaluación exploratoria se convierte así
en un mecanismo para la participación y la transformación social donde los
evaluadores actúan como catalizadores conduciendo los cambios requeridos. Un
ejemplo de esta evaluación es la práctica del Análisis del Valor, método basado
en la idea de que “centrarse en el valor añadido es más importante que
centrarse en los costes ahorrados”.
Si bien las orientaciones de los trabajos anteriormente citados son de gran

ayuda a la hora de determinar el tipo de evaluación que se desea realizar, no
cabe duda de que ésta siempre podrá ser un compendio de diferentes
orientaciones de manera que se puedan valorar aspectos que se consideran
interesantes para cada caso particular.
En los estudios sobre la evaluación de las IDE últimamente se constata un

cambio de paradigma que va del positivismo y herramientas principalmente
cuantitativas hacia el interpretacionismo e instrumentos principalmente
cualitativos.
4.10. Marco organizacional de Loenen
Para Loenen, una IDE se desarrolla lentamente: paso a paso los componentes
de la misma se van creando y se va dando respuesta a la mayoría de las
presiones que se encuentran a lo largo del proceso.
Las condiciones organizacionales son muy relevantes en el desarrollo de una

IDE madura y sostenible: es un proceso continuo que nunca finaliza. El
crecimiento o desarrollo de una IDE puede definir distintas etapas en un modelo
de crecimiento organizacional.
Camarinha-Matos estima que la integración de sistemas se puede iniciar y

conducir a diferentes niveles de complejidad y abstracción. Distingue entre nivel
de célula (cell), el nivel de planta de venta (shoop-floor), el nivel intra-empresa y
el nivel inter-empresa. A nivel celular el trabajo realizado por varios
automatismos (robots) puede ser integrado en uno solo. En el nivel de planta
varios sub-sistemas de un departamento pueden ser integrados en uno solo. En
el nivel intra-empresa el objetivo es integrar todas las áreas de la empresa (por
ejemplo, una Administración Local) y en el nivel inter-empresa se pasa a la
cooperación entre varias organizaciones. Juntas, estas organizaciones pueden
ser consideradas una organización virtual: una red de empresas que colaboran
en la cual cada nodo de la red contribuye en algo a la cadena de valor.
Finalmente, es de prever que esta empresa virtual se integre a nivel global
Para Loenen, la tipología “inter-empresa” es la adecuada para el desarrollo de

una IDE. Una organización inter-empresa es un grupo de entidades
organizacionales que han desarrollado una disposición para cooperar en el caso
de una tarea específica, y que resulta más estable, pero no estática. La mayor
parte de los modelos de crecimiento que se aplican se refieren a una
organización simple, pero la IDE concierne a una red de organizaciones en las
que cada una de ellas es un componente o nodo de la nueva organización red.
4.10.1. El modelo de desarrollo organizacional de la IDE
Basándose en trabajos en torno a las organizaciones virtuales, las etapas en la

implementación de e-gov y experiencias en geomática e IDE en Alemania y
Países Bajos, Loenen establece un modelo de desarrollo organizacional de una
IDE en cuatro etapas:
1. Autónoma
2. Intercambio
3. Intermedia
4. Red
Cada etapa requiere de un entorno organizacional específico. Entre etapas, las

organizaciones necesitan cambiar su estructura y cultura para desarrollarse. Las
nuevas tecnologías pueden ser drivers clave del cambio organizacional y la
cultura organizacional puede considerarse como una de sus potenciales
barreras. El modelo de Loenen combina conceptos del Desarrollo Organizacional
con Planificación del Cambio y Aprendizaje Organizacional, y lo adapta al

contexto multi-organizacional, cuyos conceptos y aspectos son similares al de
una organización IDE.
A continuación hacemos una breve descripción de las diferentes etapas

organizacionales consideradas según este modelo.
Etapa I: Autonomía
En el contexto IDE, son islas de infraestructuras donde cada cual está

preocupado por su propia supervivencia y nadie reconoce la necesidad de
invertir en intereses comunes. Falta liderazgo. Es una situación no sólo cara,
sino también inefectiva. Las bases de datos de las organizaciones tienen su
propio sistema. La recopilación de GI de cada organización se hace de manera
independiente: las organizaciones individuales tienen su propia visión de la
organización, pero no tienen una visión común de la GI.
En esta etapa tan sólo unos pocos visionarios entienden el potencial del valor del
concepto IDE, pero carecen de medios para convencer a los potenciales actores
clave de la importancia de participar en la misma.
La organización se encuentra en lo que Loenen denomina un “contexto cínico”:

las organizaciones individuales potencialmente participantes en la IDE no
dificultan la iniciativa, pero consideran que el cambio es innecesario y no lo
apoyarán. La cultura en las organizaciones es conservadora, persigue sus
propios intereses y falta buena voluntad para el cambio.
Etapa II: Intercambio y estandarización a nivel Técnico
En la etapa de intercambio existen dos factores que pueden conducir el cambio

en las organizaciones: el incremento en la presión a las organizaciones para que
operen más eficientemente y la nueva tecnología. Las organizaciones son
conscientes de que un mayor uso de los recursos de información de otras
organizaciones puede hacerles ser más eficientes y efectivas que contando
únicamente con la información disponible internamente. Disponer de cierta
información a través del outsourcing permite a la organización concentrarse en
sus actividades de negocio y contar con otras organizaciones para la información
subordinada. Los resultados del outsourcing en una relación de dependencia con
otra organización es el primer paso para crear una red de organizaciones que
trabajan con un objetivo común. La cooperación puede ser inducida también
como respuesta a las presiones cada vez mayores para reducir costes,
especialmente en un clima de recesión económica.
Los gobiernos pueden sentir la presión externa por parte de los ciudadanos, que
cada vez estarán más acostumbrados a los avances tecnológicos y demandarán
más servicios en línea y la integración de procesos entre los diferentes niveles
de la administración, e incluso entre diferentes funciones administrativas.
Para proporcionar soluciones multidisciplinares también se requiere de la

cooperación entre departamentos y entre organizaciones. Se requiere también la
integración de sistemas dispersos a diferentes niveles, y para ello los conjuntos

de datos han de estar integrados para ser la base sobre la que la sociedad se
vaya construyendo.
Para el desarrollo posterior, son claves el establecimiento de un objetivo común,

el reconocimiento de una potencial situación win-win y alcanzar las sinergias
esperadas. La IDE como concepto va adquiriendo fuerza con velocidad, pero
aún es poco considerada. Los productores individuales de GI empiezan a
experimentar con el intercambio de información, y las dificultades
experimentadas incrementan la conciencia de la necesidad de la IDE. Los
primeros pasos en el desarrollo de la IDE son el comienzo de las actividades de
coordinación de manera informal y la participación voluntaria.
Al final de esta etapa ya hay creada una primera visión de la IDE y se han
establecido las prioridades. El rol predominante de los productores de GI en el
inicio de la IDE hace que el principal centro de atención sea la estandarización y
el marco de datos. En consecuencia, se discute y acuerda una estrategia basada
en el producto: la IDE está siendo construida. Dicha estrategia incluye acuerdos
acerca del contenido y calidad de la GI. Más adelante incluirá la definición de la
arquitectura para la cooperación, incluidos los protocolos y servicios para el
intercambio de información, comunicación y cooperación.
El cambio puede encontrar resistencia en algunas partes que deseen

salvaguardar su posición particular. Esto se puede explicar por la
“institucionalización de actitudes de los gestores”: el comportamiento de los
gestores hace más difícil el cambio cuando sus actitudes resultan obsoletas.
Tales actitudes son fáciles de encontrar en organizaciones clave en el sector de
la GI, especialmente en aquellas que son responsables de producir los datos,
cuando éstas y sus equipos han desempeñado este rol durante mucho tiempo.
Sin embargo, si la organización es consciente de la necesidad de cambiar y
faltan estrategias alternativas, es probable que el cambio encuentre pocas
resistencias.
Etapa III: Intermedia
La Etapa Intermedia es la que va de la identificación del problema a la situación

prevista a alcanzar (organización en red). En esta etapa, es fundamental la
implementación de la visión desarrollada en las etapas previas. Algunos
componentes de la visión ya han sido implementados, otros necesitan ser
conducidos o implementados.
Se incrementa la conciencia acerca del potencial de la nueva tecnología y

emergen nuevas aplicaciones. A medida que el número de usuarios y
aplicaciones de la IDE crece, crecen los beneficios. Sin embargo, una gran parte
de los beneficios son ahorros en tiempo, nueva y mejor GI y mejora en la toma
de decisiones, los cuales son difíciles de cuantificar.
El cuerpo de coordinación no es sólo el canal de comunicación entre las partes

de la IDE, sino que también busca el reconocimiento fuera del sector IDE,
especialmente entre políticos y gestores de alto nivel. Informa a los decisores
acerca del potencial de la IDE, sus necesidades y aspectos críticos para el
desarrollo de la misma. A través de la influencia de canales externos la IDE

puede obtener el apoyo al más alto nivel, los cuales ayudarán al progreso de la
implementación de la IDE.
Para la interoperatibilidad de la GI se incorpora un enfoque híbrido entre la

estrategia basada en datos y la estrategia basada en procesos. Se incrementa
conciencia de la IDE a muchos niveles, incluso fuera del sector, y se dispone de
recursos financieros especialmente dedicados al desarrollo de la IDE. Como
resultado de la interdependencia entre organizaciones, en esta etapa la
distribución de tareas y los requerimientos de la organización se centran en las
tareas clave. Es la etapa del “contexto deseado”, donde existen muchos cuellos
de botella en la organización, por lo que la organización desea una situación
nueva y mejor. La necesidad de cambio es evidente, pero ha de ser comunicada
de manera efectiva, por ejemplo a través de ejemplos de buenas prácticas. En
esta etapa son críticas la intensidad con la que las organizaciones están
dispuestas a colaborar unas con otras y el poder de los altos gestores para dirigir
el desarrollo: las organizaciones en este punto pueden tanto construir como
“romper” la IDE.
Etapa IV: Red
En esta etapa la IDE se convierte en una organización en red con igualdad en

sus actores y una visión clara bajo la que operan pro-activamente. Las
organizaciones involucradas dependen unas de otras a causa de sus
responsabilidades compartidas en la IDE. La incertidumbre ha sido conducida a
través de la institucionalización de la red y de sus relaciones. La IDE se ha
convertido en un sistema multipropósito con una clara distribución de
responsabilidades y liderazgo compartido. Incluye información bien integrada
procedente de múltiples fuentes y sistemas, y que es mantenida en su origen.
Esto implica que la GI es recogida solamente a la mayor escala necesaria y que
un marco de datos consistente es generalizado a escalas menores. Más
adelante, la dependencia requerirá de la documentación de metadatos. La
estandarización ha cambiado de ser específica para el proveedor o producto
específico a la adhesión a estándares internacionales que son independientes
del proveedor.
El concepto de IDE no ha cambiado, pero es aprovechado y goza de un amplio

apoyo desde que proporciona sólidas bases para el desarrollo de la Sociedad de
la Información. La red IDE es el origen de muchas organizaciones virtuales, que
temporalmente se forman a partir del marco que les proporciona la IDE. Los
experimentos en nuevas aplicaciones son promovidos a través de la facilidad de
acceso a múltiples sistemas fomentados por las IDE. El consorcio innova con la
IDE a través de aplicaciones o soluciones para necesidades específicas, las
cuales se encuentran normalmente en la vida cotidiana y varían ampliamente.
Los objetivos del proceso de cambio son claros y existe un amplio soporte para
los mismos. El cambio tecnológico se realiza fácilmente y el proceso no causa
tensiones dentro y entre organizaciones. Los altos gestores están involucrados
activamente en el proceso y están estimulados para dar apoyo a todos los
miembros de la organización. Los miembros de la organización tienen
expectativas positivas acerca del desarrollo y resultado del proceso de cambio,
creen que el cambio es necesario y desean contribuir al proceso. Existe un

amplio apoyo a la visión de la IDE, la cual es continuamente revisada por los
grupos de interés a través de canales de comunicación abiertos. El desarrollo de
la IDE se muestra periódicamente. En esta etapa una comunidad proactiva
trabaja conjuntamente en soluciones innovadoras para dar respuesta a
problemas sociales.
La IDE ha sido desarrollada y su visión completada. Sin embargo, nuevos

cambios pueden añadir una complejidad extra y nuevas dimensiones antes no
contempladas, como puede ser pasar a un nivel jerárquico superior, un ejemplo
podría ser el tránsito de una IDE corporativa a una IDE local o regional.
Aspectos organizacionales determinantes en el desarrollo

de una IDE
Para moverse de una etapa a otra se han de identificar las características

organizacionales que han de cambiar para avanzar en la IDE. La situación de la
IDE dependerá de seis componentes organizacionales críticos para la IDE:
• liderazgo
• Visión
• canales de comunicación
• habilidad de la comunidad GI para la auto-organización
• conciencia y recursos sostenibles.
La IDE necesita un lider o una entidad que promueva y coordine el desarrollo

de la misma. El líder puede ser nombrado por mandato y apoyado desde el más
alto nivel pero también puede emerger de las propias tareas de coordinación o
con el propio impulso y entusiasmo de las personas que forman la base de la
misma. Cada enfoque tiene sus ventajas e inconvenientes. Un enfoque del
liderazgo del tipo top-down tiene la ventaja de que los más altos responsables en
principio creen firmemente en la potencialidad de la IDE, pero el inconveniente
de que puede que dicha apuesta no cuente con el apoyo de los niveles
inferiores. El desarrollo bottom up adolece del problema contrario: aunque a este
enfoque se le reconocen algunas experiencias exitosas, sin el apoyo de los
máximos responsables el líder nunca podrá conducir la introducción de la IDE a
gran escala. Otro aspecto clave entorno al liderazgo es la introducción de algún
mecanismo de coordinación.
El desarrollo de la Visión también es un requisito imprescindible para el éxito

del desarrollo de la IDE. Cuando las necesidades de los grupos cambian, el ideal
también puede cambiar, pero sin un ideal o visión no habrán incentivos para
avanzar en la construcción de la IDE. En la etapa autónoma cada grupo de
interés puede tener una única visión, creada a partir de la promoción de los
objetivos de su propia organización. Más tarde esta visión formará parte de la
visión negociada y compartida por todos (etapa de Intercambio). Por último,
puede crearse una visión independiente, apoyada por todos y revisada
frecuentemente (etapa en Red).
La comunicación es un factor fundamental para la aceptación, percepción y

apoyo al líder. Los canales de comunicación tienen como fin el intercambio de
ideas, información y mensajes, así como conversaciones, señales, escritos o

comportamientos. La comunicación en las primeras etapas es limitada y es
dirigida a cada organización individualmente. Más adelante se centra en el
intercambio de información con otras organizaciones, conduciendo el
partenariado a proyectos particulares. Incrementar la comunicación externa
conduce a la necesidad de estandarización, intercambio de datos y compartición.
Más adelante, las iniciativas políticas que tienen por objeto la reutilización de la
información de una organización pública por otra crearán el contexto para que la
IDE sea considerada dentro de la administración. En la etapa intermedia se
invita a otros grupos externos a participar (por ejemplo, al sector privado). Por
último, los canales de comunicación abiertos deberán facilitar que cualquiera
exprese sus ideas, opiniones y participe activamente en los procesos de toma de
decisiones. Además, la IDE deberá conectar con otras infraestructuras
comunicando el valor de su GI a esas otras infraestructuras.
La auto-organización es el proceso por el que las partes de un sistema

interaccionan espontáneamente, se comunican, dan una interpretación a
eventos y crean nuevas soluciones a través de la cooperación. La coordinación
dentro del sistema puede ser un importante elemento que contribuya a la auto-
organización. La habilidad de auto-organización en una comunidad puede ser
explicada mediante la habilidad para solucionar un problema. En las primeras
etapas la comunidad identificará problemas y dejará la resolución de otros (a los
líderes políticos o a altos gestores, por ejemplo). Si se necesita ayuda, la
comunidad GI proporciona su experiencia, pero sus prioridades estarán en la
ejecución de sus funciones públicas encomendadas. Este es un rol pasivo. Más
tarde, la comunidad será más activa e identificará los problemas y ofrecerá
soluciones a los decisores. Esto es seguido por los requerimientos de
respuestas por parte de la sociedad a las soluciones GI. Finalmente, la
comunidad proporcionará soluciones innovadoras sin pensar en problemas y
soluciones, sino ofreciendo servicios mejores y más amigables que respondan a
las necesidades de los usuarios finales. Es en esta etapa en la que los grupos
de interés reconocen su responsabilidad en su rol en el desarrollo de la IDE.
Para el desarrollo de la IDE la creación de consenso será crucial para suscitar el
entusiasmo. La falta de consenso o acuerdo puede llevar al desacuerdo ya que
las personas que trabajan en la IDE finalmente la abandonen.
La conciencia del impacto de la GI en el buen funcionamiento de la sociedad,

incluidos los negocios, las AAPP e instituciones académicas pueden incorporar
nuevos actores interesados en la IDE, así como conseguir financiación para su
desarrollo. La conciencia del valor de la GI tiene consecuencias sobre el nivel
de financiación de su desarrollo.
En la primera etapa organizacional el concepto de IDE multiparticipante no existe

y la conciencia de la IDE la tienen muy pocos. En la etapa de intercambio el
concepto IDE parece interesar más, especialmente en el sector de la GI, entre el
cual se promociona la visión de la IDE. En la etapa intermedia la capacidad de la
IDE se incrementa y se afianza el liderazgo, los canales de comunicación son
abiertos y el sector GI es más proactivo, lo que crea conciencia entre todos los
niveles, derivando en la financiación de su desarrollo. La extensión de la
conciencia se ha construido sobre el desarrollo de la IDE y como resultado de la
misma se pueden considerar las inversiones realizadas.

Estudio para la implantación de Mejores Prácticas y

Modelos de Calidad en la IDE
5. Estudio para la implantación de

Mejores Prácticas y Modelos de Calidad
en la IDE
5.1. Introducción
Como hemos visto en los capítulos anteriores la IDE se puede analizar desde
dos puntos de vista:
• Como una estructura de alto nivel, que se ha puesto en práctica a partir

de decisiones políticas con el objetivo de compartir información
geográfica, entre los organismos productores de esta información.
• La estructura que soporta cada uno de los nodos que dan servicio a la
estructura superior. Esta estructura se le puede llamar IDE Corporativo, o
GIS Corporativo.
El análisis de la implantación de las mejores prácticas y modelos de calidad que

hemos visto a lo largo del Master se va a efectuar sobre estas dos estructuras.
Además sería interesante analizar la posibilidad de negocio que para un

integrador TI representa el análisis anterior.
5.2. Gobierno de las TI
Como se ha visto en el capítulo anterior se han efectuado estudios sobre la IDE

muy enfocadas al análisis de su comportamiento como una red colaborativa (ver
apartado 2.2 Redes Colaborativas). Estos estudios están basados en la
evaluación en integración de sistemas como el planteado por Camarinha-Matos.
Loenen define a la IDE como una tipología “inter-empresas” y a partir de aquí
define el modelo de desarrollo organizacional para la IDE.
En este sentido es importante remarcar que no se han realizado en el entorno

IDE, esfuerzos explícitos en utilizar buenas prácticas genéricas para el Gobierno
de las TI.
5.2.1. COBIT
En el mismo sentido que cualquier otro Sistema TI, tanto los responsables de la
IDE como estructura colaborativa, como los de los GIS corporativos que
soportan la información de cada nodo de la IDE, deben contestar a las siguientes
cuestiones ¿cómo puede el organismo poner bajo control la TI de tal manera que
genere la información que el organismo necesita? ¿Cómo puede administrar los
riesgos y asegurar los recursos de TI de los cuales depende tanto? ¿Cómo
puede la IDE o el organismo asegurar que TI logre sus objetivos y soporte los
del negocio?
La orientación al negocio que enfoca COBIT consiste en vincular las metas de

negocio con las metas de TI, en el caso de la administración pública las metas
de negocio se traducen en metas de servicio a la comunidad. Esta orientación es

el tema principal de COBIT. Está diseñado para ser utilizado no solo por
proveedores de servicios, usuarios y auditores de TI, sino también y
principalmente, como guía integral para la gerencia y para los propietarios de
los procesos de negocio. En el caso de las IDEs los organismos públicos.
El marco de trabajo de COBIT proporciona un modelo de procesos de

referencia y un lenguaje común para que cada uno en el organismo visualice y
administre las actividades de TI. La incorporación de un modelo operacional y
un lenguaje común para todas las partes de un organismo involucradas en TI
es uno de los pasos iniciales más importantes hacia un buen gobierno. En el
caso de este estudio, definir un modelo operacional y un lenguaje común para el
gobierno de la IDE y del GIS Corporativo, sería muy beneficioso y más si este
está basado en buenas prácticas aplicadas al gobierno de las TI genérico.
La orientación al negocio COBIT la permite brindando métricas y modelos de

madurez para medir sus logros, e identificando las responsabilidades asociadas
de los propietarios de los procesos de negocio y de TI. COBIT brinda un marco
de trabajo para la medición y monitoreo del desempeño de TI,
comunicándose con los proveedores de servicios e integrando las mejores
prácticas administrativas.
Con respecto al uso de los modelos de madurez para la gestión de las IDEs, es
necesario tener en cuenta que son una forma de medir qué tan bien están
desarrollados los procesos administrativos, esto es, qué tan capaces son en
realidad. Qué tan bien desarrollados o capaces deberían ser, principalmente
dependen de las metas de la IDE y en las necesidades de la comunidad a la que
se quiere dar servicio subyacentes a la cuales sirven de base.
Los niveles de madurez están diseñados como perfiles de procesos de TI que se

reconocerían como descripciones de estados posibles actuales y futuros. No
están diseñados para ser usados como un modelo limitante, donde no se
puede pasar al siguiente nivel superior sin haber cumplido todas las condiciones
del nivel inferior.
Las escalas del modelo de madurez ayudan a los profesionales a explicarle a la

gerencia dónde se encuentran los defectos en la administración de procesos de
TI y a establecer objetivos donde se requieran. Específicamente, el nivel de
madurez en la administración se basará en la dependencia que tenga la
empresa en la TI, en su sofisticación tecnológica y, lo más importante, en el valor
de su información.
Los estudios sobre modelos de desarrollo organizacional para la IDE planteados

en este documento, son descriptivos pero no cubren los objetivos que define
COBIT para el control:
• Una medición relativa de dónde se encuentra la empresa

• Una manera de decidir hacia dónde ir de forma eficiente
• Una herramienta para medir el avance contra la meta
Un ambiente de control implantado de forma adecuada, se logra cuando se han

conseguido los tres aspectos de madurez (capacidad, desempeño y control). El

incremento en la madurez reduce el riesgo y mejora la eficiencia, generando

menos errores, más procesos predecibles y un uso rentable de los recursos.
En cuanto a la gestión del desempeño COBIT relaciona los requerimientos de

información y de gobierno a los objetivos de la función de servicio de TI. El
modelo de procesos COBIT permite que las actividades de TI y los recursos que
los soportan sean administrados y controlados basados en los objetivos de
control de COBIT, y alineados y monitoreados usando las métricas KGI y KPI de
COBIT. Esta manera de relacionar los objetivos de alto nivel con los objetivos de
la función de servicio entendemos que sería totalmente aplicable a la gestión de
la IDE y a los GIS Corporativo que la soportan.
Conclusión
Resumiendo los beneficios de implementar COBIT como marco de referencia de

gobierno sobre la TI se podrían aprovechar para el gobierno de las IDE. En
concreto estos beneficios serían:
• Mejor alineación, con base en su enfoque de servicio a la comunidad.

• Una visión, entendible para la gerencia, de lo que hace TI.
• Propiedad y responsabilidades claras, con base en su orientación a
procesos.
• Aceptación general de terceros y reguladores.
• Entendimiento compartido entre todos los participantes, con base en un
lenguaje común.
En cuanto al punto de vista de negocio para una empresa de servicios o

integradora de TI, está claro que el apoyo a los organismos en su aproximación
a la filosofía COBIT sería de aplicación inmediata. Dentro de este apoyo se
podría destacar:
• la definición de controles para el negocio y para las TI específicos de la

IDE
• la definición de modelos de madurez para la IDE y para los GIS
Corporativos
• la medición del desempeño
5.3. Gestión de Servicios TI
Los ciudadanos y la comunidad implicada demanda lo siguiente de los servicios

de la administración pública, y en concreto de los servicios que espera recibir de
la IDE.
Especificaciones detalladas y concisas

Quieren saber, por adelantado, el tipo de servicio que van a recibir. El problema
con la entrega de servicio de TI es que los clientes a menudo no saben definir lo
que quieren de manera precisa, y ahí los expertos de IT deben esforzarse por
traducir sus necesidades en soluciones viables, técnicamente y en términos de
coste. Los ciudadanos quieren servicios o soluciones.

Conformidad a la especificación
Una vez hallada la solución TI apropiada entonces debe adecuarse a la
especificación. Los ciudadanos quieren saber cuándo lo podrán recibir y en qué
medida cumplirá sus requisitos.
Consistencia
Ellos quieren que la prestación del servicio sea idéntica cada vez que lo
demandan.
Valor por su dinero

El precio que pagan, a través de sus impuestos, deber ser justo por el servicio
que reciben.
Comunicación
Quieren que se les diga lo que reciben, cuándo, cómo y cómo pueden hacer uso
de ello.
Actualmente para la IDE y también para el caso de los GIS Corporativos no

existe un mecanismo de soporte al ciudadano estructurado. Esto resulta en
el hecho de que las incidencias no se resuelvan con la suficiente rapidez y que
nos enfrentemos a una calidad inconsistente y un bajo tiempo de respuesta. Y
desde luego, no hay control. Esta puede provocar que se perciba un bajo nivel
de confianza por parte del ciudadano a la hora de utilizar los geoservicios de
la IDE.
Tampoco hay definidos procesos claros que faciliten la gestión del servicio.
5.3.1. ITIL e ISO 20000
Se requiere un análisis previo, que diferencie entre los servicios de la IDE y los
servicios esperados para un GIS Corporativo.
Para los geoservicios de la IDE, sería de aplicación una gestión específica para
Servicios Web en el sentido de la gestión planteada por IBM, en cualquier caso
siempre se podrían aplicar conceptos como la definición de procesos y
procedimientos, el establecer roles con responsabilidades en esos procesos así
como la gestión de incidencias, problemas, cambios y sobre todo disponibilidad,
capacidad, etc. particularizada para Servicios Web. Actualmente los geoservicios
requeridos para una IDE son de búsqueda y de visualización de geoinformación,
a medida que estos servicios sean más complejos, requerirán también de una
gestión más compleja a la que se le podría definir, por ejemplo un punto de
contacto único (en el sentido de ITIL) para el ciudadano, establecido a partir de
la jerarquía definida para la IDEE.
Para los servicios de un GIS Corporativo entendemos que sería de directa

aplicación las buenas prácticas definidas por ITIL. En el caso de que la gestión
del GIS Corporativo dependa de un organismo TI del que dependa, estas
buenas prácticas serían de aplicación al organismo superior, pero en cualquier

caso implementar las mejores prácticas ITIL para la gestión de servicios para un
GIS Corporativo daría los siguientes beneficios:
• Una mejor calidad de servicio, convirtiéndose en un organismo más fiable

para sus clientes
• Procedimientos de continuidad de servicio de TI adaptados a sus
necesidades
• Visión más clara de la capacidad actual de la IDE
• Mejor información de los servicios actuales
• Mayor flexibilidad para el negocio
• Empleados más motivados
• Mayor satisfacción de ciudadano al entregar los proveedores de servicio
lo que se espera de ellos
• Es probable que exista mayor flexibilidad y adaptabilidad dentro de los
servicios
• Ventajas conducidas por el modelo, por ejemplo mejoras en seguridad,
exactitud, velocidad, disponibilidad según se requiera para el nivel de
servicio acordado
• Tiempo mejorado para los cambios y un mayor nivel de éxito.
• Bajada de los costes operativos a medida que menos esfuerzo se pierda
en dar a los clientes productos y servicios que no quieren o que no pagan
• Los márgenes de beneficio, en términos de mejora para la comunidad,
mejorarán a medida que se consiga más uso recurrente de los servicios
• Mejora en la eficacia a medida que el personal trabaje de forma más
efectiva como equipo
• La calidad de servicio mejorará constantemente, resultando en una mejor
reputación para el organismo lo cual tentará a nuevos ciudadanos y
animará a otros ciudadanos utilizar más los servicios
• El departamento de TI se hará más eficaz en soportar las necesidades
definidas por la IDE.
Conclusión
Como cualquier empresa u organismo que quiera dar un servicio TI, los
conceptos planteados por ITIL y la ISO 20000, son de directa aplicación para
efectuar una gestión apropiada de estos servicios. Es complicado ver esa
aplicación en una estructura de organismos colaborativos, basados en la
interoperabilidad de los Servicios Web como es el caso de la IDE, pero es cierto
que es una tecnología que está empezando su desarrollo, y una empresa de
servicios TI debería tomar como un reto acompañar a la administración pública
en este desarrollo.
El hecho de certificar a los organismos, responsables de los GIS Corporativos,

así como a los proveedores en ISO 20000 es una garantía de que se va a dar un
buen servicio.
5.4. Gestión de la Calidad
Es evidente que aunque todos recurrimos al mismo término de calidad, no todos

entendemos lo mismo. Para el proveedor de un servicio, calidad significa

fundamentalmente qué y cómo es ese producto (es decir, la efectividad). En

otros términos, lo que el cliente realmente “se lleva”. Para el cliente o usuario, en
cambio, lo importante es para qué le sirve y si respondió a sus necesidades y
expectativas, lo que podemos definir como su satisfacción o utilidad. Para el
empresario y en su caso las Administraciones Públicas, lo importante es la
relación coste-beneficio o, en otros términos, la eficiencia que se alcanza.
Nos referimos a control de la calidad cuando lo que interesa es comprobar la

conformidad del producto o servicio con respecto a las especificaciones de
diseño del mismo. El objetivo de las acciones de control de la calidad consiste en
identificar las causas de la variabilidad para establecer métodos de corrección y
de prevención y para lograr que los productos fabricados respondan a las
especificaciones de diseño.
5.4.1. Gestión de Costes de Calidad
El papel de los costes de la calidad en el proceso de planificación estratégica de

una IDE o de un GIS Corporativo sería el de contribuir a:
• Desarrollar un plan de calidad estratégico global que incorpore todos los

objetivos funcionales de calidad, incluyendo planes y presupuestos para
los costes de calidad.
• Analizar las tendencias más importantes en la satisfacción del ciudadano,
en las tasa de defectos o errores y en los demás costes, tanto de manera
global como por departamentos específicos.
• Asistir a otras áreas funcionales para garantizar que los costes
relacionados con la calidad están siendo incluidos en sus respectivos
análisis, con el fin de poder establecer objetivos adecuados.
El uso de los costes de calidad:
• Permite el conocimiento de variables no financieras críticas para el éxito

en la gestión.
• Animan a usar estos datos para propósitos internos, a la vez que
posibilitan la captura de abundante información de carácter externo y
estratégico.
• Destruyen barreras de incomunicación entre las distintas áreas
funcionales y disciplinares de la organización, impregnando a todo el
personal de la filosofía subyacente en la consecución de la mejora
continuada.
Es necesario volver a diferenciar en este caso entre la IDE y los GIS

Corporativos. Sería complicado aplicar la gestión de los costes de calidad
directamente a la IDE como estructura de alto nivel, pero si sería directamente
aplicable a los GIS Corporativos.
Conclusión
Aunque como hemos visto la gestión de costes de calidad sería aplicable a nivel
de GIS Corporativo, sería interesante a nivel de IDE desarrollar los procesos,
procedimientos y responsabilidades necesarias para compartir entre los

organismos implicados el know-how de esta gestión. En este sentido para una

empresa de servicios la gestión de este conocimiento y el apoyo a los
organismos implicados para alcanzarlo, sería claramente una oportunidad de
negocio.
5.4.2. Modelo E.F.Q.M., norma ISO 9001:2000 y Marco Común de

Evaluación CAF
La implantación de la norma ISO 9001:2000 en los organismos implicados en la

IDE, aunque supone un duro trabajo, ofrece una gran cantidad de ventajas para
dichos organismos. Los principales beneficios son:
• Reducción de rechazos e incidencias en la producción o prestación del

servicio
• Aumento de la productividad
• Mayor compromiso con los requisitos del cliente
• Mejora continua
En cuanto a la aplicación del modelo E.F.Q.M., nos planteamos utilizar la

adaptación CAF, resultado de la cooperación entre los Ministros responsables de
Administración Pública de la Unión Europea. A petición de los Directores
Generales del ramo, siendo la nueva versión del CAF desarrollada por el Grupo
de Servicios Públicos Innovadores.
Comparado con un modelo de Gestión de Calidad Total plenamente

desarrollado, el CAF es un modelo "ligero", especialmente idóneo para obtener
una primera impresión de cómo actúa una organización. Obviamente, cualquier
organización que quiera profundizar más puede seleccionar un modelo más
completo de entre los existentes (tales como el de Speyer o el modelo EFQM).
El CAF tiene la ventaja de ser compatible con estos modelos y puede además
ser un primer paso para una organización que quiera avanzar en la gestión de
calidad.
El CAF es de dominio público y gratuito. Las organizaciones pueden usar el

modelo libremente.
El CAF se presenta como una herramienta para que las organizaciones del
sector público de Europa utilicen técnicas de gestión de calidad para mejorar su
rendimiento. El CAF proporciona un marco sencillo y fácil de usar, apropiado
para que las organizaciones del sector público lleven a cabo una autoevaluación.
El CAF tiene cuatro propósitos principales:
1. Identificar las características comunes de las organizaciones del sector

público
2. Servir como herramienta para los administradores públicos que deseen
mejorar el rendimiento de su organización.
3. Hacer de «puente» entre los diferentes modelos que se usan en la
gestión de calidad.
4. Facilitar el benchmarking entre las organizaciones del sector público.

5. El CAF ha sido diseñado para que pueda utilizarse en todos los ámbitos
del sector público, y tanto en la administración nacional o federal, como
en la regional y local.
Puede aplicarse en diferentes situaciones y circunstancias como por ejemplo,

formando parte de un programa sistemático de reforma o como base para
orientar los esfuerzos de mejora en organizaciones del sector público. En
algunos casos, y especialmente en organizaciones muy grandes, se pueden
llevar a cabo autoevaluaciones en una parte de la organización, como puede ser
una unidad o departamento, es decir en el caso de la IDE sería ideal para
utilizarlo por los departamentos responsables de cada organización del
desarrollo y mantenimiento del GIS Corporativo.
El CAF proporcionaría a estos departamentos:
• Una evaluación basada en evidencias.

• Un medio para dar coherencia a la dirección y alcanzar el consenso
sobre aquello que es preciso hacer para mejorar una organización.
• Una evaluación frente a un conjunto de criterios que han sido aceptados
en toda Europa.
• Un medio de medir el progreso en el tiempo a través de autoevaluaciones
periódicas.
• Un nexo de unión entre las metas y las estrategias y procesos de apoyo.
• Un medio de dirigir las actividades de mejora allí donde son más
necesarias.
• Oportunidades de promover y compartir buenas prácticas entre diferentes
áreas de una organización y con otras organizaciones.
• Un medio de motivar a los empleados de las organizaciones
involucrándolos en los procesos de mejora.
• Oportunidades de identificar progresos y niveles destacados de logro.
• Un medio de integrar diversas iniciativas de calidad en la actividad normal
de la organización.
Resumiendo, la autoevaluación con el Modelo CAF ofrece a la organización una

oportunidad para aprender más sobre sí misma.
Compartir experiencias y realizar benchmarking
El propósito de realizar actividades de benchmarking es encontrar formas

mejores de hacer las cosas, sobre la base de los buenos resultados obtenidos
por otras organizaciones. El modelo CAF y otras herramientas de análisis
organizacional se pueden utilizar como base de benchmarking.
En su forma más sencilla, el benchmarking es un proceso por el cual una

organización identifica otras organizaciones con las cuales puede hacer una
evaluación comparativa de sí misma y su rendimiento.
Los resultados de la autoevaluación formarán parte de la base de datos CAF que

contiene información relativa a las organizaciones que han utilizado el CAF, a su
sector de actividad y nivel de administración (nacional, regional, local), al tamaño
de las organizaciones en términos de número de empleados y a las personas de

contacto. Al ofrecer información clave, la base de datos puede ayudar a las

organizaciones del sector público a localizar los socios más adecuados para
realizar benchmarking.
Utilización del modelo CAF y de la norma ISO 9001: 2000
El Modelo CAF se utiliza en general para la Autoevaluación de la organización y

la puesta en marcha de planes de mejora.
Una organización que desee beneficiarse de una aplicación más intensa de la

Gestión de Calidad puede plantearse su participación en uno de los premios
nacionales o internacionales que se convocan periódicamente y que son cada
vez más utilizados por las organizaciones públicas. Existe la posibilidad de
contactar con alguna de las organizaciones especializadas en Gestión de
Calidad, tales como la Fundación Europea para la Gestión de Calidad (EFQM-
European Foundation for Quality Managemente) o el Premio a la Calidad de
Speyer, para obtener asesoramiento sobre cómo profundizar en la Gestión de
Calidad y/o para participar en sus premios.
Por lo que se refiere a España, el Ministerio de Administraciones Públicas

convoca anualmente el Premio a la Calidad en la Administración General del
Estado, de acuerdo con el Modelo EFQM. Igualmente existen programas de
similares características en varias Comunidades Autónomas, como el premio
“Ciudadanía”.
La ISO 9001:2000, puede usarse como guía para poner en marcha un Sistema
de Gestión de la Calidad, pero lo normal y común en la mayoría de los casos es
que una vez el Sistema está implantado, el mismo se certifique.
La nueva norma ISO 9001:2000 es compatible con el Modelo CAF, y puede

considerarse un subconjunto del mismo.
El uso de la Norma deberá ser similar al seguido en los procesos de

Autoevaluación, y no debe quedar en una mera documentación cosmética para
mantener el certificado. Es una responsabilidad de todos los agentes implicados
en el proyecto. Requiere cambios de actitudes, formación intensa en los nuevos
conceptos y a partir de ese conocimiento convencerse de las ventajas y
beneficios que, en términos de gestión y resultados, van a suponer a una
empresa que los adopte.
Conclusión
Las ventajas que para cualquier organización representa aplicar la norma ISO
9001:2000 y en el caso de las administraciones públicas el modelo CAF, son
manifiestas. Está claro que también sería de aplicación para los organismos
responsables de los GIS Corporativos que soportan los nodos que componen la
IDE. Sería motivo de un estudio más detallado la aplicación de la norma y el
modelo para el caso de la IDEE como organismo, aunque en una primera
aproximación sí sería aplicable.

La técnica del benchmarking puede ser una potente y eficaz herramienta para el
desarrollo organizacional de la IDE ya que explota principios que pueden parecer
elementales como "no reinventar la rueda" y "aprender de otros". En este
sentido, el benchmarking de los organismos implicados en el desarrollo de la IDE
está claro que sería conveniente que se efectuará entre ellos.
Para una empresa de servicios, el apoyar a los organismos implicados en su

proceso de adaptación a estas normas de calidad, está claro que sería una clara
oportunidad de negocio.
5.5. CMMI
Como hemos visto en el apartado de los anexos dedicado a CMMI se trata de un

modelo de procesos. Un Modelo de Procesos es una colección estructurada de
elementos que describen las características de los procesos. Proporciona una
referencia para fijar objetivos y prioridades en la mejora del proceso y una guía
para asegurar procesos estables, capaces y maduros. Permitirá:
• Identificar del punto de partida

• Obtener beneficios de experiencias anteriores
• Establecer un lenguaje común y una visión compartida
• Fijar un marco para desarrollar planes de mejora
Resumiendo lo visto en el apartado anteriormente comentado, se pueden definir

dos tipos de procesos desde el punto de vista de un modelo de madurez:
• Procesos inmaduros, que se caracterizan por:

o Abandono o inexistencia de los planes y procedimientos
o El producto puede funcionar pero excede el presupuesto y hay
retrasos
o Los resultados no son repetibles
o El éxito depende de la competencia y el esfuerzo individual
o No hay medición objetiva de la calidad
• Procesos maduros, que se caracterizan por:
o Roles y responsabilidades claras
o Se encuentran planificados, no son producto de la improvisación
o Se puede reutilizar parte del trabajo realizado
o Hay seguimiento de la calidad y criterios para resolver problemas
o Los equipos se encuentran implicados al estar informados de su
marcha
o Procedimientos utilizables y consistentes
Los objetivos que se pretenden con la implantación de un modelo de procesos

dentro de una organización son:
• Disponer de procedimientos, métodos y relaciones de tareas comunes

para toda la organización.
• Personas con conocimientos, habilidades y entrenamiento común
• Herramientas y equipamiento a disposición de la organización

La implantación de un modelo de procesos permitirá mejorar la calidad, los

costes y el plazo
Como en los puntos anteriores CMMI, sería directamente aplicable en el caso

del GIS corporativo, y habría que hacer un estudio de adaptación para el caso de
la IDE como organización colaborativa.
Conclusión
Está claro que la implantación de mejores prácticas, reconocidas generalmente

beneficiaría en la gestión de las organizaciones motivo de estudio de este
trabajo. En concreto implementar CMMI cubriendo el ciclo de vida completo,
desde la concepción de la necesidad en algún punto de la organización, hasta la
entrega y mantenimiento, y enfatizando las actividades necesarias para construir
y mantener el producto final con la calidad requerida, en este caso los
geoservicios, y siguiendo patrones de actuación definidos y probados, sería para
las organizaciones involucradas en la IDE un buen camino para el éxito.
En este sentido, con mucho sentido del humor, y bastante conocimiento de

causa, Anthony Finkelstein describió que hay organizaciones que no han
alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se
llega a producir software), proponiendo que existen niveles negativos o de
inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado
posteriormente por Tom Schorsch, incluye tres niveles de idiotez:
0. Tonto. Organizaciones negligentes. Impiden cualquier desarrollo de

software con éxito. Su gran preocupación es la reutilización del
software.
1. Estúpido. Organizaciones obstructivas. Imponen procesos contra-

productivos para impedir cualquier avance. Se concentran en
desarrollar entornos de desarrollo y repositorios.
2. Lunático. Organizaciones desdeñosas. Desprecian cualquier

institucionalización de buenas prácticas. Su gran objetivo es la
programación automática.
El apoyo de una consultora tecnológica, evitaría que los organismos

involucrados en la IDE estuvieran en esta lista, aprovechando también la
oportunidad de negocio que la implantación de CMMI representa.
5.6. PMBOK
Los proyectos son una forma de organizar actividades que no pueden ser
tratadas dentro de los límites operativos normales de la organización. Por lo
tanto, los proyectos se usan a menudo como un medio de lograr el plan
estratégico de la organización, ya esté empleado el equipo del proyecto por la
organización o sea un proveedor de servicios contratado.
Generalmente, los proyectos son autorizados como resultado de una o más de

las siguientes consideraciones estratégicas:

• Una demanda del mercado (por ejemplo, una compañía petrolera

autoriza un proyecto para construir una nueva refinería en respuesta a
una escasez crónica de gasolina)
• Una necesidad de la organización (por ejemplo, una compañía de
formación autoriza un proyecto para crear un nuevo curso a fin de
aumentar sus ingresos)
• Una solicitud de un cliente (por ejemplo, una compañía eléctrica autoriza
un proyecto para construir una nueva subestación para abastecer a un
nuevo polígono industrial)
• Un avance tecnológico (por ejemplo, una firma de software autoriza un
nuevo proyecto para desarrollar una nueva generación de videojuegos
después de la introducción de nuevos equipos de juegos por parte de las
empresas de electrónica)
• Un requisito legal (por ejemplo, un fabricante de pinturas autoriza un
proyecto para establecer los procedimientos de manejo de un nuevo
material tóxico).
Los organismos implicados en la IDE, en los dos niveles planteados en este

trabajo, corporativo y colaborativo requerirán efectuar proyectos por cualquiera
de los motivos arriba planteados. Para ello será necesario que tengan en cuenta
las pautas establecidas para la dirección de proyectos. La dirección de proyectos
es la aplicación de conocimientos, habilidades, herramientas y técnicas a las
actividades de un proyecto para satisfacer los requisitos del proyecto. La
dirección de proyectos se logra mediante la aplicación e integración de los
procesos de dirección de proyectos de inicio, planificación, ejecución,
seguimiento y control, y cierre.
En este sentido, para los organismos implicados en la IDE sería enriquecedor e

incluso necesario utilizar el PMBOK como guía para la dirección de proyectos, y
los programas de desarrollo profesional que el Project Management Institute ha
definido, entre los que se incluyen:
• la certificación de Profesional de la Dirección de Proyectos (Project

Management Professional, PMP®)
• la educación y formación en materia de dirección de proyectos, ofrecida
por Proveedores de Educación Registrados (Registered Education
Providers, R.E.P.) de PMI
• la acreditación de programas de educación en dirección de proyectos.
Para una consultora que disponga de recursos con las certificaciones PMP, sería
una clara oportunidad de negocio si los organismos responsables de la IDE son
conscientes de sus ventajas.
5.7. Conclusiones Finales
El concepto IDE está aún un poco inmaduro desde el punto de vista de la

investigación especializada. El aspecto de la evaluación no es algo a lo que se le
de la importancia requerida, especialmente porque el éxito de una IDE aún
depende exclusivamente del número de accesos y/o descargas a la misma, o al
número de Gigas que permite acceder. Está bien que se tengan en cuenta, son

aspectos que no debemos olvidar, pero son muy importantes los procesos
organizacionales de mejora que puede desencadenar el establecimiento de una
IDE.
Nos encontramos con dificultades añadidas, tales como la necesidad de evaluar

los aspectos organizacionales de las IDE que se dan al unísono con otros
aspectos, y en los que intervienen muchos actores y factores (tengamos en
cuenta que en puridad las IDE las integran múltiples organizaciones, con
diferentes culturas, medios, normativas, problemas, intereses, etc.). También
existe muy poca conciencia de que una IDE es un servicio más de
administración electrónica, y que por tanto debiera poder ser evaluada en el
contexto de esta, así como que cada IDE tiene una vocación en temática que se
traduce finalmente en unas escalas y tipos y formatos de datos distintos, y unos
usuarios-tipo, por lo que hay dificultades para evaluar del mismo modo una IDE
corporativa con una IDE regional, como pueda ser la IDEE o la IDE Europea.
Se manifiesta una sequía investigadora en IDE, por otra parte lógica, dado su
grado de madurez, y dado que los responsables están más interesados
actualmente en obtener resultados visibles y rentabilizar grandes inversiones
que en examinar los logros finales. Este hecho en el caso de las IDE locales se
da quizás con mayor intensidad, debido a que son el último escalafón donde el
mensaje y la práctica IDE puede calar ya que en el ámbito local (especialmente
en municipios) es donde más actores intervienen, mayor cantidad y variedad de
datos existen y donde todavía no existe una cultura de la información geográfica
asumida y compartida por la organización.
En cuanto a las empresas privadas, actualmente carecen de una estrategia

realmente proactiva de colaboración para el desarrollo de la IDE, y en la mayoría
de los casos responden a los requerimientos que se van definiendo por los
organismos oficiales.
Por lo tanto, queda por hacer una labor de proselitismo importante para
incorporar el aspecto SIG/IDE a la cotidianeidad de la administración electrónica,
tanto en la propia administración pública como en las empresas privadas
involucradas.
Plan de Colaboración de la Empresa Privada para el

desarrollo de la IDE.
6. Plan de Colaboración de la Empresa

Privada para el desarrollo de la IDE.
Por lo visto hasta ahora en este trabajo, han quedado claras las posibilidades de
negocio para una consultora TI que genera la colaboración que los organismos
involucrados en la IDE requieren para su desarrollo. Este capítulo ha tenido una
evolución, que he querido que quede representada en el resultado final. La idea
primigenia fue la de resolver un proyecto de testeo de geoservicios,
posteriormente me planteé un caso práctico basado en una consultora TI que se
plantea ser referente en el desarrollo de la IDE, finalmente y teniendo en cuenta
el sentido de la IDE e inspirado por el acuerdo que Microsoft, HP y La Caixa han
firmado con el Ministerio de Industria para desarrollar el Plan Avanza, he
planteado que para el desarrollo de la IDE, es necesario la colaboración de las
empresas privadas y que al igual que la administración pública debe adaptar su
estrategia a los nuevos retos que plantea la IDE, las empresas privadas con
posibilidad de colaborar en este desarrollo deberían modificar también su
estrategia de negocio, y plantear un modelo más colaborativo, tanto con los
organismos públicos implicados como con las empresas privadas entre sí.
6.1. Planteamiento del Caso Práctico
El proveedor de servicios y soluciones TI Dharta Systems (es una empresa

imaginaría, cuyo parecido con cualquiera de la realidad sería pura coincidencia)
y en concreto su departamento de Sistemas de Información Geográfica, se
plantea realizar un proyecto para conseguir ser referente en el desarrollo de la
IDE.
Para enmarcar este capítulo, es necesario definir los datos más relevantes de
Dharta Systems:
• Compañía española líder en TI
• 2000 M€ en ventas
• 1/3 en mercados internacionales
• 16.500 profesionales
• Modelo de negocio diferencial
Ilustración 23. Distribución geográfica y por mercados de Dharta Systems


En relación a la figura anterior, Dharta Systems por una decisión estratégica se

encuentra en proceso de aumentar el mercado exterior, sobre todo en Europa y
en Iberoamérica.
El modelo de negocio de Dharta Systems se basa en los siguientes dos puntos
1. Organización flexible, dinámica y con capacidad de innovación, orientada

a nuestros clientes
2. Capaz de crecer, con rentabilidad, tanto en ciclos expansivos como de
lento crecimiento
En cuanto al departamento SIG de Dharta Systems los datos más importantes

son:
• Más de 150 recursos en plantilla con diferentes perfiles profesionales,

con capacidad para cubrir cualquier proyecto relacionado con soluciones
y tecnologías geoespaciales.
• Facturación de más de 15 millones de €.
• Negocio en diferentes mercados, especialmente en AAPP.
La visión del Departamento SIG de Dharta Systems es la siguiente:
“Ser líderes y referentes en soluciones TIC en las que la localización, la

dimensión espacial y la contextualización geográfica de la información aportan
un valor significativo en el conocimiento y en la gestión”.
El departamento SIG de Dharta Systems ha presentado una solicitud a la

dirección de la consultora, con el objetivo de conseguir el permiso para llevar a
cabo un plan estratégico para ser referente en el desarrollo de la IDE, no sólo en
el ámbito nacional si no en los países donde es de aplicación la directiva
INSPIRE, y por extensión al resto de países, sobre todo de Latinoamérica,
donde se estén desarrollando IDEs a nivel estatal.
Previamente el departamento SIG de Dharta Systems ha desarrollado un plan de

negocio, en el que aparece mucha de la información planteada en este trabajo.
Este plan de negocio sería una primera versión, con la información necesaria
para justificar la inversión para el plan
El plan de negocio tiene el siguiente guión:
Plan de negocio
Resumen ejecutivo
• Idea de Negocio
• Equipo directivo y promotores del negocio
• Estado de desarrollo del negocio
• Plan de implantación
• Productos/servicios: diferenciación respecto a la competencia
• Público objetivo
• Tamaño mercado potencial

• Escenario competitivo
• Inversión requerida
• Valoración global del proyecto: aspectos más innovadores y
objetivos.
Definición del negocio
• Características del negocio
• Producto/servicio ofrecidos
• Valor añadido del producto/servicio
• Ventajas competitivas
• Grado de Know how rentabilizable que genera para nuevos
proyectos.
Público objetivo y mercado potencial
• Publico objetivo
• Necesidades que satisface y grado de motivación de tus clientes
• Segmentación de clientes
• Tamaño de mercado y mercado potencial
• Características del sector/subsector
Plan de marketing
• Análisis competitivo
• Objetivos comerciales
• Principales magnitudes no financieras
• Estrategias de promoción y publicidad online/offline
• Estrategias
• Estrategia de márqueting
• Estrategia de posicionamiento
• Estrategia de expansión internacional
Requerimientos tecnológicos
• Tecnología requerida
• Hardware requerido
• Software requerido
• Otra tecnología clave para el negocio
• Valoración del coste en tecnología
Equipo directivo y organización interna
• Perfil del equipo directivo
• Organigrama empresarial
• Objetivos de tu empresa
• Control de gestión
Modelo de negocio y plan económico-financiero
• Inversión inicial
• Plan de financiación
• Fuentes de ingresos
• Previsión volumen de ingresos
• Previsión Volumen de gastos
• Previsión de la cuenta de PyG
• Previsión de tesorería
• Balances provisionales
• Punto de equilibrio
• Valoración de la empresa

Análisis DAFO
• Análisis del mercado: oportunidades y amenazas
• Análisis interno: fortalezas y debilidades
Se desarrolla a continuación el análisis DAFO planteado para este caso de

negocio.
FORTALEZAS OPORTUNIDADES
F1 Elemento humano O1 Negocio en Europa de más de
150 Millones de € hasta el 2011
F2 Amplia experiencia del departamento en O2 Posibilidades de crecer en un
grandes proyectos para las AAPP entorno de negocio en alza
F3 Motivación de los recursos del departamento O3 Negocio en America Latina y
GIS para involucrarse en este tipo de proyectos EEUU importante
F4 Capacidad de adaptación demostrada O4 Posibilidades de formación
DEBILIDADES AMENAZAS
D1 Falta de actuación proactiva, hasta ahora, para A1 Empresas con mucha experiencia
la IDE en Software Libre
D2 Falta de experiencia suficiente en proyectos con A2 Dependencia de decisiones
Software Libre políticas
D3 Falta de experiencia en SOA A3 Cambios de normativa
D4 Falta de experiencia en proyectos para la A4 Escasez de financiación en
generación de Metadatos y Ontologías algunos nodos
La dirección de Dharta Systems a partir de la información aportada por el

departamento SIG, aprueba la propuesta y plantea la necesidad de disponer del
apoyo del Departamento de Outsourcing y del apoyo comercial de la Dirección
de AAPP.
6.2. Acuerdo de colaboración de las empresas privadas para el

desarrollo de la IDE
Después de diferentes reuniones comerciales y técnicas con representantes del

Consejo Superior Geográfico, se llega a la conclusión de que hay un problema
de fondo en cuanto a la colaboración de la empresa privada para el desarrollo de
la IDE. Tomando el modelo planteado en el Plan Avanza, se convocan a las
empresas más importantes en el entorno GIS para definir esta nueva estrategia
de colaboración, y se llega al acuerdo de definir una serie de proyectos que
definan los primeros pasos para esta colaboración.
Para llegar a este objetivo se ha creado una PMO (Oficina de Gestión de

Proyectos, en el sentido de PMBOK), formada por personal de las empresas
involucradas. A la Oficina de Gestión de Proyecto se le ha planteado como
primer objetivo definir el Plan de Sistemas de Información, que soporte la
estrategia definida. En el Plan de Sistemas de Información se definirán los
diferentes productos y servicios necesarios, para crear las bases de la
plataforma que soporte la estrategia planteada. Para el ciclo de vida del plan de

sistemas de información, y para el resto de proyectos informáticos que se

definan con el objetivo de desarrollar los productos y servicios necesarios, se
acuerda utilizar Métrica 3, como metodología de desarrollo del software, ya que
es la metodología de referencia en la administración pública. Para la dirección de
gestión de proyectos se decide utilizar la metodología definida en la Guía de los
Fundamentos de la Dirección de Proyectos (Guía del PMBOK®). En la siguiente
figura viene representado todo lo dicho.
Departamento
GIS
Plan de Sistemas de Información para definir
Ilustración 24. PSI y desarrollo del aplicativo para Testeo de Geoservicios

Proyecto para el desarrollo de una plataforma de

testeo de Geoservicios.
7. Proyecto para el desarrollo de una

plataforma de testeo de Geoservicios.
Como primer proyecto definido por la Oficina de Proyectos, se plantea el
desarrollo de una plataforma de testeo de Geoservicios. Este capítulo se plantea
incluir las primeras fases de lo planteado en el PMBOK, para la gestión de un
proyecto.
En la siguiente figura viene representado como el ciclo de vida del proyecto,

está relacionado con los Procesos de Dirección de Gestión de Proyectos.
Ilustración 25. Gestión del proyecto para la definición de la herramienta para testeo de
Geoservicios
7.1. Project Charter. Acta de Constitución del Proyecto

Definición d
El acta de constitución del proyecto es el documento que autoriza formalmente
un proyecto. El acta de constitución del proyecto confiere al director del proyecto
la autoridad para aplicar recursos de la organización a las actividades del
proyecto. El director del proyecto debe ser identificado y nombrado lo antes
posible. El director del proyecto siempre debe ser nombrado antes del inicio de
la planificación y, preferentemente, mientras se desarrolla el acta de constitución
del proyecto.
En este caso el iniciador o patrocinador del proyecto, externo a la organización

del proyecto es el responsable nominado por el Consejo Superior Geográfico,
Estudio de
que es el responsable de emitir el acta de constitución del proyecto. Además por
Análisis del
Viabilidad del
Aplicativo
Aplicativo

parte de las empresas implicadas en este proyecto Dharta Systems e ICM

Global Services, se definen ambos patrocinadores del proyecto.
Título del Proyecto
Proyecto para desarrollar una herramienta para el testeo de geoservicios.
Descripción del proyecto
Para definir la herramienta de testeo de geoservicios se tiene en cuenta lo

indicado en el documento “INSPIRE Network Services Performance Guidelines”
en el que a partir de lo planteado por IBM y el W3C se define un catálogo,
especifico para los geoservicios, de parámetros para medir la calidad de estos
geoservicios.
La siguiente tabla viene representado lo anteriormente indicado.
Se ha efectuado un estudio de las diferentes herramientas que hay en el

mercado en cuanto a la gestión y testeo de Web Services con el siguiente
resultado:
• Web Services suites

o BEA Systems, Inc. (BEA AquaLogic)
o Cordys (Cordys Platform)
o iWay Software (iWay Integration Solutions)
o Kenamea, Inc. (Composite Application Suite)
o Magic Software Enterprises, Ltd. (iBOLT Integration Suite)

o Novell, Inc. (Novell exteNd Composer)

o Progress Software Corporation (Actional, Sonic ESB)
o ReadiMinds Systems & Services Pte Ltd. (ReadiMinds
WebServices Applications Suite WSS)
o Software AG (crossvision)
o Systinet Corporation (Systinet Product Suite)
• Web Services desktop integration
o NetEdge Software, Inc. (Web Services Enabler)
o RatchetSoft, LLC (Ratchet-X)
• Web Services development tools
o Above All Software, Inc. (Above All Studio)
o Altova, Inc. (Altova MissionKit for XML Developers)
o Ascential Software Corporation. (Enterprise Integration Suite)
o Attachmate Corporation (AttachmateWRQ Verastream)
o AZORA Technologies, Inc. (AZORA SOA Studio Pro)
o BEA Systems, Inc. (BEA WebLogic Workshop)
o Brunswick Corporation (Redberri)
o Compuware Corporation (OptimalJ)
o eviware.com (soapui)
o FusionWare Corporation (FusionWare Integration Server)
o GT Software, Inc. (Ivory Service Architect)
o Infologica Pty Ltd. (Infologica Web Services Framework)
o InterSystems Corporation (Ensemble)
o IONA Technologies (Artix)
o Orinda Software Ltd. (OrindaBuild)
o Pantero Corporation (Shared Data Services Suite)
o Rogue Wave Software, Inc. (Lightweight Enterprise Integration
Framework – LEIF)
o Seagull Software Systems, Inc. (LegaSuite)
o SeeBeyond, Technology Corporation (The SeeBeyond Integrated
Composite
o Application Network – ICAN – Suite – Acquired by Sun
Microsystems)
o StrikeIron, Inc. (StrikeIron)
o TIBCO Software, Inc. (TIBCO BusinessWorks)
o WebCollage, Inc. (WebCollage Syndicator)
o webMethods Inc. (webMethods Glue)
• Web services repository
o GridScope, Inc. (GridScope Repository)
o Infravio, Inc. (X-Registry)
• Web services testing
o Borland Software Corporation (SilkPerformer)
o iTKO Corporation (LISA)
o Mindreef, Inc. (SOAPscope)
o Parasoft Corporation (SOAtest)
o SOASTA, Inc. (SOASTA Concerto)
• Web Services management
o AmberPoint, Inc. (AmberPoint management solutions)

o Blue Titan Software, Inc. (Network Director and Network Director

RM)
o Computer Associates International, Inc. (Unicenter Web Services
Distributed
o Management – WSDM)
o Confluent Software, Inc. (Confluent Web Services Management
Platform)
o GridScope, Inc. (GridScope Console)
o Infravio, Inc. (AppManager for Web Services)
o itellix Software Solutions (Wisiba)
o Managed Methods, Inc. (JaxView and JaxView Enterprise)
o Progress Software Corporation (Actional SOAPstation)
o SOA Software, Inc. (Service Manager and Registry)
o webMethods Inc. (webMethods Fabric)
o WestGlobal (mScape)
• Web Services monitoring tools
o Computer Associates International, Inc. (Unicenter Web Services
Distributed
o management – WSDM)
o Compuware Corporation (Vantage)
o GridScope, Inc. (GridScope Console)
o Managed Methods, Inc. (JaxView and JaxView Enterprise)
o Mercury Interactive Corporation (SiteScope)
o Mindreef, Inc. (SOAPscope)
o TIBCO Software, Inc. (TIBCO BusinessWorks)
o Web Services networks
o Accordare, Inc. (Reflector)
• Web Services orchestration
o ActiveBPEL, LLC. (ActiveBPEL)
o Active Endpoints, Inc. (ActiveWebflow)
o Corticon Technologies, Inc. (Corticon Decision Management
Platform)
o Dralasoft, Inc. (Dralasoft Workflow)
o IBM Corporation (WebSphere Business Integration Modeler)
o Intalio (Intalio|BPMS)
o Metastorm, Inc. (Metastorm BPM Suite)
o OpenStorm Software, Inc. (Service Orchestrator)
o Oracle Corporation (Oracle BPEL Process Manager – formerly the
Collaxa BPEL
o Server)
o Parasoft Corporation (BPEL Maestro)
o PNMsoft Software (Sequence BPMN/BPEL BPM Suite)
o Progress Software Corporation (Sonic Orchestration Server)
o ReadiMinds Systems & Services Pte Ltd.
o SeeBeyond, Technology Corporation
o Skelta Software (Skelta Workflow.NET)
o Software AG (crossvision Service Orchestrator)
o WebV2, Inc. (WebV2 ProcessCoupler)

• Web Services security

o DataPower Technology, Inc. (XML Security Gateway)
o Forum Systems, Inc. (XML-Sentient)
o Layer 7 Technologies, Inc. (SecureSpan)
o Netegrity, Inc. (TransactionMinder)
o Ping Identity Corporation (PingTrust)
o Reactivity (Reactivity XML Gateway)
o RSA Security, Inc. (RSA BSAFE Secure-WS)
o SOA Software, Inc. (XML VPN)
o Teros, Inc. (Teros Web Services Security Gateway)
o TrustedWebServices.org (free collection of services and source
code based on
o Safelayer’s TrustedX WS technology)
o Vordel Limited (VordelSecure and VordelDirector)
o Web Services/Service-Oriented Architecture providers21
o Bluedog
o Prima Solutions
o StrikeIron, Inc. (StrikeIron Web Services Business Network)
o XwebServices.com:
A partir de este estudio se analizarán las posibilidades de uso y/o integración,

así como del posible desarrollo de aplicativos esproceso para la herramienta, en
el caso de ser necesario este desarrollo se planificarán otros proyectos.
Business Case
Dentro del acuerdo de colaboración entre el Consejo Superior Geográfico, los

diferentes organismos públicos implicados y las empresas privadas interesadas
en el desarrollo de la IDEE, se ha definido este proyecto como punta de lanza
para comenzar esta colaboración.
Dharta Systems por la experiencia contrastada de su departamento GIS junto a

la empresa ICM Global Services por su experiencia en SOA, han sido
designadas para realizar este proyecto. Para los organismos de la
administración pública, la colaboración de empresas privadas será muy
enriquecedor y el nuevo marco de colaboración, hará que estas empresas
crezcan tecnológicamente y también la experiencia de desarrollar una nueva
estrategia de trabajo y colaboración les afectará positivamente.
Descripción de producto/entregables
El producto será una aplicación obtenida a partir de la integración de

herramientas de testeo de Servicios y/o del desarrollo esproceso de los
aplicativos que se consideren necesarios. Junto a la aplicación se definen como
entregables propios del producto todos los manuales necesarios para facilitar el
uso de la aplicación.

Los entregables se adaptarán a los estándares esponsorizados por OASIS y

UN/CEFACT cuya misión es proveer una infraestructura abierta para e-business
XML (ebXML)
La International Standards Organization (IS0), ha aprobado una suite de 4

ebXML OASIS Standard, y se han publicado como ISO technical specifications,
bajo el título genérico de Electronic business eXtensible markup language, que
tienen 4 partes:
• ISO 15000-1: ebXML Collaborative Partner Profile Agreement

• ISO 15000-2: ebXML Messaging Service Specification
• ISO 15000-3: ebXML Registry Information Model
• ISO 15000-4: ebXML Registry Services Specification
También se ha definido una arquitectura para un Test Framework, en el que se

define el Test Driver que puede funcionar en modo conectado o en modo
servicio.
Ilustración 26. Esquema del Test Driver
El Test Driver funcionando como Test Service en modo remoto, viene

representado en la siguiente figura.

Ilustración 27. Flujo de trabajo para interoperabilidad
Objetivos del proyecto
Los objetivos principales del proyecto son:
• Que la herramienta cumpla los parámetros de calidad y eficiencia,

definidos para su uso.
• Que la herramienta cumpla los parámetros de usabilidad y accesibilidad
para los perfiles de usuario que se definan.
• Que sea una herramienta escalable, y que a partir de ella se puede
definir una plataforma de análisis de geoservicios en web.
Responsable del proyecto asignado y nivel de autoridad
Se nombra responsable del proyecto a Pablo Fraga Alamillos, Jefe de Proyectos

del Departamento GIS de Dharta Systems. Cuenta con la autoridad para
gestionar los costes y los recursos asignados. Dispone de interlocución directa
con el Director del Proyecto, designado por el Consejo Superior Geográfico, al
que podrá solicitar las modificaciones en cuanto a presupuestos y recursos que
considere oportunas.
Firmado y aprobado
La autorización del Project Charter indica que se entiende el proposito y el

contenido descrito en el propio Project Charter. La firma del Project Charter, que
según los acuerdos individuales el proyecto se debe iniciar con los medios
necesarios que deben ser autorizados como se describe.
Nombre del
Título Firma Fecha
Responsable
Manuel Martín Vicepresidente del Consejo

11-06-2008
Casinello Superior Geográfico

Ricardo Praga Director del Área GIS de

11-06-2008
Ramírez Dharta Systems
Gerente del departamento

Pablo Costa López de Arquitectura SOA de 11-06-2008
ICM Global Services
7.2. Scope Statement. Enunciado del Alcance del proyecto
El enunciado del alcance del proyecto describe, en detalle, los productos

entregables del proyecto y el trabajo necesario para crear tales productos
entregables. El enunciado del alcance del proyecto también proporciona un
entendimiento común del alcance del proyecto entre los interesados del
proyecto, y describe los principales objetivos del proyecto. También permite al
equipo del proyecto realizar una planificación más detallada, guía el trabajo del
equipo del proyecto durante la ejecución y proporciona la línea base para
evaluar si las solicitudes de cambio o trabajo adicional están comprendidas
dentro o fuera de los límites del proyecto.
Justificación del proyecto
Este proyecto se justifica, a partir de lo acordado por el Consejo Superior

Geográfico y las empresas involucradas en el proyecto para el desarrollo de la
IDEE. Disponer de una herramienta común para el testeo de los geoservicios,
ayudará a que se defina un criterio común de calidad de los geoservicios. A
partir de este proyecto de colaboración, se define un hito importante a partir del
cual se puede definir la estrategia a seguir para los siguientes proyectos.
Productos del proyecto
El producto resultante de la ejecución del proyecto, será una aplicación

informática de testeo de los geoservicios OGC, que actualmente entregan los
organismos implicados en la IDEE.
Entregables de alto nivel
Además de la herramienta se definirán los protocolos necesarios para realizar

los testeos, así como el modelo de mejora continua tanto para los KPIs definidos
para los geoservicios como para la herramienta en sí. También se entregara la
documentación necesaria para el uso de la herramienta.
Objetivos del proyecto
Además de los inmediatos para generar la herramienta, como ya se ha señalado

este proyecto es la punta de lanza en el nuevo modelo de colaboración entre los
organismos oficiales y las empresas privadas para el desarrollo de la IDE, por lo
tanto es un objetivo para este proyecto marcar un hito en este modelo de
colaboración, empezando a definir la estrategia para implementarla.

Criterios usados para determinar si el proyecto ha finalizado con éxito
En cuanto a la herramienta de testeo, están claros los criterios funcionales que

debe de cumplir, y han sido señalados anteriormente.
Como primer proyecto en la nueva estrategia de colaboración, es importante que

el proyecto se reconozca como un hito, y que su éxito marque el camino para los
nuevos proyectos que se definan.
7.3. Work Breakdown Structure WBS & Activity List. Estructura de

Desglose del Trabajo EDT y lista de actividades.
La EDT es una descomposición jerárquica, orientada al producto entregable, del

trabajo que será ejecutado por el equipo del proyecto, para lograr los objetivos
del proyecto y crear los productos entregables requeridos. La EDT organiza y
define el alcance total del proyecto. La EDT subdivide el trabajo del proyecto en
porciones de trabajo más pequeñas y fáciles de manejar, donde cada nivel
descendente de la EDT representa una definición cada vez más detallada del
trabajo del proyecto. El trabajo planificado comprendido dentro de los
componentes de la EDT del nivel más bajo, denominados paquetes de trabajo o
actividades, puede programarse, supervisarse, controlarse y estimarse sus
costes.
La EDT representa el trabajo especificado en el actual enunciado del alcance del

proyecto aprobado. Los componentes que comprenden la EDT ayudan a los
interesados a ver los productos entregables del proyecto.

1
Heramienta de
Testeo de
Geoservicios
1.2
1.1 1.5
Toma de 1.3 1.4
Dirección de Integracón y
Requisitos del Hardware Software
Proyectos Prueba
producto
1.4.1
1.3.1 1.4.2
1.1.1 1.2.1 1.3.2 Diseño,
Selección de Instalación y
Planificación Entrevistas Instalación Integración y
Proveedor Testeo
Codificación
1.2.2 1.4.1.1
1.1.2 1.3.1.1 1.3.2.1 1.4.2.1
Planificación de la Analizar
Reuniones Preparar RFP Preparar Local Instalación del
toma herramientas testeo
SIstema
Servicios Web
1.2.3
1.3.2.2
1.1.3 Desarrollo del 1.3.1.2
Recibir e instalar
Administración documento de Analizar Ofertas 1.4.1.2
Hardware 1.4.2.2
Requisitos Codificar Aplicativos
Testeo
necesarios
1.3.2.3
1.3.1.3
Transferir
Seleccionar y
Programas y
negociar
Testear
Ilustración 28. EDT del proyecto para la definición y desarrollo de una herramienta de
testeo de Geoservicios
7.4. Project Network Diagram. Diagrama de Red del Cronograma del

Proyecto
Los diagramas de red del cronograma del proyecto son representaciones

esquemáticas de las actividades del cronograma del proyecto y las relaciones
lógicas entre ellas, también denominadas dependencias.
En este caso se ha realizado el diagrama de red del cronograma con las

actividades de más alto nivel, y se ha utilizado el Método de Diagramación por
Precedencia (PDM). El PDM es un método para crear un diagrama de red del
cronograma del proyecto que utiliza casillas o rectángulos, denominados nodos,
para representar actividades, que se conectan con flechas que muestran las
dependencias.
El PDM incluye cuatro tipos de dependencias o relaciones de precedencia:
• Final a Inicio. El inicio de la actividad sucesora depende de la
finalización de la actividad predecesora.
• Final a Final. La finalización de la actividad sucesora depende de la
finalización de la actividad predecesora.
• Inicio a Inicio. El inicio de la actividad sucesora depende del inicio de la
actividad predecesora.
• Inicio a Fin. La finalización de la actividad sucesora depende del inicio
de la actividad predecesora.

F-I
1.2 1.3.1
F-I
F-I
F-I
1.3.2
F-I
F-I F-I
COMIENZO I-I F-I
I-I 1.5 FIN
F-I
I-I 1.4.1
F-I
I-I
1.1 I-I 1.4..2
Ilustración 29. Diagrama por Precedencia PDM del proyecto

Anexo I: Base Tecnológica de la IDE
8. Anexo I: Base Tecnológica de la IDE

Este anexo pretende dar un repaso no exhaustivo pero suficiente, para conocer
la base tecnológica de la IDE.
8.1. XML
¿Qué es XML?
XML es un conjunto de especificaciones del World Wide Web Consortium

(W3C).
Definición: XML es una herramienta integradora multiplataforma,
independiente de la aplicación, del software y del hardware para describir,
almacenar y transportar información codificada en formato de texto plano
(UTF-8, ISO-8859-1, UTF-16, etc.).
XML añade tipo y estructura a la información:
La información puede almacenarse en cualquier lugar de Internet.
Datos provenientes de diferentes fuentes pueden agregarse en una única
unidad de información.
Cada pieza de información tiene una estructura específica de XML.
Cada pieza de información tiene un tipo específico de la aplicación.
Qué es y qué no es XML
XML Vs HTM?:
 XML se diseñó para describir, estructurar, almacenar y transportar
información.
 HTML se diseñó para presentar información con formato.
XML es un metalenguaje:
 Las etiquetas XML no están predefinidas.
 Los Schemas XML describen la composición (etiquetas) y estructura
de un documento XML válido.
 XML + Schema es autodescriptivo.
 XML no hace nada por si mismo, requiere de software.
 XML es el padre de otros lenguajes de marcas como WML o XHTML.
Usos de XML
XML permite independizar la información presentada en un documento

HTML de su formato de presentación:
 Documentos independientes.
 Islas XML o islas de información.
XML facilita el intercambio de información en entornos heterogéneos.
XML facilita la integración de información proveniente de formatos
incompatibles.
XML se utiliza ampliamente como lenguaje para intercambio de información
en B2B (Microsoft Biztalk, etc.)
Los documentos XML pueden almacenarse en el servidor y recuperarse
desde navegadores. También pueden generarse dinámicamente por páginas
ASP/JSP, PHP o CGIs.
Su tipo MIME debe establecerse como text/xml.
Ilustración 30. Tecnologías XML
Utilización de la especificación URI
XML se apoya en la especificación URI (Uniform Resource Identifier ).

Sintaxis y semántica para identificadores únicos en el contexto de Internet.
Existen dos tipos de URI: URL y URN.
 Uniform Resource Locator(URL) contiene información/pistas de
localización.
o http://www.develop.com/dbox/me.xml
 Uniform Resource Name (URN) es independiente de la localización.
o urn:uuid:a4fdf565-43a6-45b0-9c53 -b1e4998a91ef
Ambos tipos pueden o no ser dereferenciables.
Tecnologías XML
 DTD (Document Type Definition). Se utiliza para definir los bloques de

construcción legales de un documento XML válido.
 Namespaces. Definen un método para cualificar nombres de
elementos y atributos asociándolos a referencias URI.
 XSD (XML Schema Definition). Alternativa poderosa a los DTD. Están
escritos en XML y soportan namespacesy tipos de datos.
 XDR (XML Data Reduced). Versión reducida del XML Schema.
 DOM (Document Object Model). Define interfaces, propiedades y
métodos para manejar documentos XML.
 XQL (XML Query Language). Soporta facilidades de consulta para
extraer información de documentos XML.
 SAX (Simple API for XML). Otra interfaz para leer y manejar
documentos XML.
 XHTML (Extensible HTML). Reformulación de HTML 4.01 en XML.
 CSS (Cascading Style Sheets). Hojas de estilo que pueden añadirse
a los documentos XML para proveerlos de formato de presentación.
 XSL (Extensible Style Sheet Language).
 XSLT (XSL Transformation) XSLT son más potentes que CSS.
Pueden utilizarse para transformar documentos XML en multitud de
formatos.
 XPath (XML Pattern Matching) Lenguaje XML que permite direccionar
partes de un documento XML. Diseñado para ser usado también por
XPointer.
 Formatting Object Interpretation.
 XLink(XML Linking Language). Permite insertar elementos en
documentos XML con el fin de crear enlaces entre recursos XML.
 XPointer (XML Pointer Language). Permite direccionar dentro de las
estructuras internas de los documentos XML elementos, atributos y
contenido
Ilustración 31. Componentes de XML
8.2. SOAP
¿Qué es SOAP?
 Protocolo de comunicación basado en esquemas XML para

intercambio de información estructurada y fuertemente tipada en
entornos descentralizados y distribuidos.
 Especifica el formato de los mensajes, su codificación (tipado) y las

convenciones necesarias para facilitar una comunicación RPC.
 No está ligado a ningún lenguaje o plataforma de programación.
 No define ningún modelo de programación ni semántica específica
(API).
 No está ligado a ninguna infraestructura o arquitectura de
objetos/componentes distribuidos.
 No define un protocolo de transporte concreto.
 Es sencillo, extensible y fácil de desplegar en Internet ya que está
basado en estándares (codificación XML, tipado XSD, transporte
HTTP, etc.).
 Facilita la interoperabilidad entre múltiples entornos
 Importante: SOAP no pretende ser una alternativa a las
infraestructuras de componentes [distribuidos] existentes.
 Estas últimas siguen siendo responsables de algunos servicios
avanzados de gestión de objetos como ciclo de vida, transacciones,
pooling, etc.
Ilustración 32. Anatomía de un mensaje SOAP
Categorías de mensajes SOAP
Orientados a procedimientos (RPC):
 Mensaje request . Los parámetros se empaquetan en el cuerpo de

forma ordenada en un formato tipo struct cuyo elemento asociativo es
el nombre de método asociado. El nombre y tipo de cada elemento

debe corresponderse con los del parámetro que representa.
 Mensaje response. Devuelve el resultado y el valor de los parámetros
out y ref.
 La especificación de SOAP proporciona reglas para codificar
mensajes RPC.
Orientados a documentos: Un sentido (y posible ACK)
 La codificación SOAP describe cómo usar reglas deserialización XML

para codificar la información de estos documentos.
 XML Schemas para definir intercambios de documentos comunes
8.3. Servicios Web
Arquitectura de Servicios Web XML como…
 Una visión de la evolución del software y sus procesos de desarrollo para

adecuarse a Internet
 Una visión de la evolución de Internet en si misma.
 Un elemento fundamental en la evolución hacia la computación
distribuida a través de Internet
 Una infraestructura de integración de aplicaciones de empresa.
Evolución de los Servicios Web en Internet
Enlaces (href)
Marcos (Frames HTML, Applets Java, controles ActiveX, etc.)
No conecta las aplicaciones, sólo las interfaces
Screen scrapping
 Necesidad de adaptación ante cambios en el diseño de las páginas
HTML
Intercambio de información vía POST (GET y POST HTTP)
 Necesidad de simetría
 Ausencia de estructuración y tipado en la información intercambiada
Ninguna permite control total de la aplicación destino
Es necesario considerar algunos aspectos legales y reconsiderar las
oportunidades de negocio
Servicios Web iniciales:
 Los sitios web se empiezan a concebir como funciones
 Intercambio de mensajes XML propietarios sobre HTTP. Necesidad de
interoperabilidad. XML-RPC
Evolución de los Servicios Web en Internet
1. Mainframes
2. Terminales
3. Computadores personales
4. Redes de computadores
5. Protocolos de comunicación
6. Marcos de trabajo para objetos: OMA, COM
7. Entornos de computación distribuida DCE-RPC
8. Arquitecturas de objetos distribuidos: CORBA-IIOP, DCOM, .NET
Remoting, RMI,
9. Arquitecturas de servicios distribuidos en Internet
Arquitectura de objetos distribuidos
Ilustración 33. Ejemplo de invocación de métodos remotos en CORBA-IIOP
Arquitecturas distribuidas e Internet
CORBA-IIOP, DCOM y RMI

 Modelos de programación con estado y (generalmente) orientados a
conexión. Poco escalables
 Modelos de comunicación síncrona. Poco adecuados
 Gestión de ciclo de vida, seguridad y transacciones dificulta su utilización
 Modelo de componentes distribuidos. Necesidad de simetría
 Protocolos binarios, que utilizan puertos anónimos y conexión directa.
Problemas ante proxies y arquitecturas de cortafuegos
 (Relativa) independencia de plataforma y lenguaje de programación.
Adecuado
JMS, MSMQ, MQ-Series
 Modelos de comunicación asíncrona (store and forward ). Más escalables
Servicios Web XML
Definición:
“Los Servicios Web XML son aplicaciones modulares, autocontenidas,

autodescriptivas e independientes de plataformas de desarrollo y ejecución,
basadas en estándares de Internet y que pueden ser publicadas, localizadas

e invocadas desde cualquier punto de la Web.”
Objetivos:
 Una plataforma software adecuada para Internet

 Un negocio de “hosting” de aplicaciones y servicios a través de Internet
 Una infraestructura de integración de aplicaciones de empresa a nivel de
Internet
Necesidades:
 Estándares para representación de datos, formatos de mensajes

extensibles y comunes, mecanismos de transporte, lenguajes extensibles
para descripción, exposición y descubrimiento de proveedores y servicios
Tecnologías:
 XML Schema, SOAP, HTTP, WAP, SMTP, WSDL, UDDI
Servicios Web XML e Internet

 Independencia del lenguaje de programación, del modelo de objetos, de
la plataforma de ejecución, etc.
 Modelo de programación sin estado
 Modelo de comunicación asíncrona, unidireccional,…
 Dualidad de modelo RPC / basado en documento
 Gestión de seguridad y transacciones adaptada a Internet
 Protocolo de comunicación con codificación textual XML y transporte
HTTP / WAP / SMTP
 Infraestructura TCP/IP
 Mayor interoperabilidad, escalabilidad, alcance (interoperabilidad con
cortafuegos) y robustez en entornos de Internet frente a protocolos de
objetos distribuidos tales como DCOM, RMI o IIOP
Ilustración 34. Arquitectura de los Servicios Web

Anexo II: Geoservicios IDE
9. Anexo II: Geoservicios IDE

La IDE se apoya en estándares y acuerdos que hacen posible la coherencia y
compatibilidad necesarias para que los datos, servicios y recursos del sistema
puedan ser utilizados, combinados y compartidos.
Entre las organizaciones de estandarización e interoperabilidad más importantes

y relacionadas al mundo GIS destacan las siguientes:
 ISO – International Organization for Standardization
 OGC – Open GIS Consortium
 GSDI – Global Spatial Data Infrastructure
 FGDC – Federal Geographic Data Committee
 CEN – Committee for European Normalization
 DGIWG – Digital Geographic Information Working Group
 EPSG – European Petroleum Survey Group
 W3C – World Wide Web Consortium
 ANSI – American National Standards Institute
 WS-I – Web Services Interoperability Organization
Ilustración 35. Esquema general de interoperabilidad

Descripción de interfaces
La OGC (Open Geospatial Consortium), es un consorcio internacional de la

industria de más de 280 compañías, agencias de estado, y universidades
dirigidas al crecimiento de la interoperabilidad de tecnologías que trabajan
con la información y localización espacial.
A través de sus tres programas (programa de especificaciones,

interoperabilidad y, alcance y difusión), el OGC desarrolla, publica y
promociona estándares abiertos para el análisis y el procesamiento espacial.
Ilustración 36. Infraestructuras y aplicaciones OGC
ESTÁNDARES OGC EN INTERFACES DE USUARIO
WEB MAP CONTEXT (WMC)

Los WMC son documentos estructurados en XML donde los usuarios pueden
configurarse mapas en base a diferentes WMS, de tal forma que puedan
cargarse en un futuro vistas salvadas como favoritas, o ajustes en la
visualización y organización de las diferentes capas de información.
CATALOG SERVICES (CS)

Esta especificación define un interfaz y framework común, que permite definir
aplicaciones de búsquedas, exploración y consulta de catálogos de
metadatos que permitan acceder a las fuentes de datos geográficas de una
forma eficaz.
ESTÁNDARES OGC EN SERVICIOS DE INTEGRACIÓN
WEB PROCESSING SERVICE (WPS)

Servicio Web que invoca funciones de geoprocesamiento de datos, como
transformaciones, clasificaciones temáticas, operaciones topológicas,
superposiciones de capas…
COORDINATE TRANSFORMATION SERVICE (CTS)

Permite la transformación de sistemas de coordenadas de datos geográficos
procedentes de un servicio Web (WMS, WFS o WCS). Estos datos son
recibidos en GML.
Implementa las siguientes operaciones:
 GetCapabilities, recibe información de metadatos del servidor.

 Transform, cambia el sistema de referencia de un dato de tipo vector
o raster.
 IsTransformable, chequea si el servidor puede transformar el sistema
de coordenadas.
 GetTransformation, obtiene los tipos de transformación disponibles en
el servidor.
 DescribeTransformation, describe los parámetros de transformación
indicada.
 DescribeMethod, describe el método utilizado en la transformación.
 DescribeCRS, describe el sistema de referencia indicado.
ESTÁNDARES OGC EN SERVICIOS DE ACCESO
Los Web services están basados en protocolos (WSDL, SOAP…) que

intercambian mensajes entre aplicaciones o componentes. Los servicios
Web proporcionados por la OGC permiten el acceso a datos de diferentes
fuentes y tipos.
Ilustración 37. Acceso a datos de servidores locales o remotos a través de geoservicios
WEB MAPPING SERVICE (WMS)

Los WMS permiten producir un mapa (imagen, elementos gráficos y datos) y
responder consultas sobre la información en el mapa. Toda la información
geográfica es enviada en formato GML.
El WMS implementa las siguientes operaciones:

 GetMap, solicita un mapa, especificando parámetros como la
extensión, el sistema de coordenadas, las capas de información, o el
tamaño y formato de la imagen.
 GetFeatureInfo, permite identificar elementos o features y hacer
consultas específicas.
 GetCapabilities, permite recuperar información del servidor de mapas
incluyendo nombre de coberturas, estilos y proyecciones soportadas.
WEB FEATURE SERVICE (WFS)

Incorpora protocolos para operaciones de manipulación de datos al trabajar
directamente con vectores. La información geográfica es codificada en GML.
Entre las operaciones de manipulación de datos del WFS se distinguen:
 Crear un nuevo elemento.

 Eliminar un nuevo elemento.
 Actualizar un elemento.
 Bloquear un elemento.
 Realizar consultas de tipo espacial
Se distinguen dos tipos de servicios WFS:
 Servicio básico WFS que permite realizar consultas y recibir

elementos en modo vector. WFS dispone de los siguientes interfaces:
o GetCapabilities, permite consultar información del servicio WFS.
o DescribeFeatureType, recibe el XML Schema para permitir al
cliente WFS parsear los resultados.
o GetFeature, permite consultas para obtener elementos
vectoriales y atributos vía GML.
 Transactional Web Feature Service (WFS-T) que permite la creación,

eliminación y actualización de elementos geográficos.WFS-T
incorpora además de los anteriores los siguientes interfaces:
o LockFeature, permite bloquear un elemento para que no
pueda ser editado.
o Transaction, ejecuta transacciones.
o GetFeatureWithLock, permite obtener elementos vectoriales y
atributos, pero bloqueando su edición por parte del usuario.
o InsertFeature, permite generar un nuevo elemento vectorial.
o UpdateFeature, permite actualizar un elemento vectorial.
o DeleteFeature, permite eliminar un elemento vectorial.
La petición es generada por el cliente y enviada al servidor WFS vía HTTP,

que ejecuta la petición y le devuelve la repuesta. La codificación del WFS
puede ser XML (gestionado vía HTTP POST/SOAP) o por “Keyword-Value
pairs” (gestionado por HTTP GET/REST).
CATALOG SERVICE WEB (CSW)

La interfaz de este servicio será la correspondiente a un Servicio Web XML
que seguirá el protocolo CSW según las especificaciones de OGC publicado
las siguientes operaciones:
 GetCapabilities, permite consultar información del servicio CSW.
 GetRecords, permite consultas para obtener registros de datos del
Catalogo.
 GetRecordById, permite consultas para obtener registros de datos del
Catalogo.
 DescribeRecord, permite consultas para obtener registros de datos del
Catalogo.
SIMPLE FEATURE ACCESS (SFA)

Las bases de datos espaciales (SDBMS) permiten almacenar información
geográfica e incluso su comportamiento como puede ser la topología. Para
almacenar esta información se utiliza el estándar SFS (Simple Features
Specification for SQL) que define el tipo de dato GEOMETRY.
La especificación SFA define las operaciones que se deben poder realizar

sobre los datos geográficos como medidas de áreas, longitudes,
extensiones, los tipos de formato para la información geográfica (WKT o
WKB) o las trasformaciones de coordenadas a través del SIRD.
Ilustración 38. Entidades pertenecientes al tipo Geometry
FILTER ENCODING
Es una codificación XML de Common Catalog Query Language (CQL) que
permite la descomposición de una consulta neutral hacia lenguajes nativos
como XML Xpath Expressions y SQL. Constituye un componente común que
puede ser integrado desde el resto de Web Services (WMS, WFS…).
STYLE LAYER DESCRIPTOR (SLD)

Esta especificación incrementa la funcionalidad del WMS, al permitir a los
usuarios definir como se simboliza y representan las capas de información
geográfica de los WMS.
10. Anexo III: SIG CORPORATIVO vs. IDE

Un Sistema de Información Geográfica (SIG o GIS, en su acrónimo inglés) es
una integración organizada de hardware, software, datos geográficos y personal,
diseñado para capturar, almacenar, manipular, analizar y desplegar en todas sus
formas la información geográficamente referenciada con el fin de resolver
roblemas complejos de planificación y gestión. También puede definirse como un
modelo de una parte de la realidad referido a un sistema de coordenadas
terrestre y construido para satisfacer unas necesidades concretas de
información.
Ilustración 39. Sistema de Información Geográfico SIG
El SIG funciona como una base de datos con información geográfica que se
encuentra asociada por un identificador común a los objetos gráficos de un mapa
digital. De esta forma, señalando un objeto se conocen sus atributos e,
inversamente, preguntando por un registro de la base de datos se puede saber
su localización en la cartografía.
La razón fundamental para utilizar un SIG es la gestión información espacial. El

sistema permite separar la información en diferentes capas temáticas y las
almacena independientemente, permitiendo trabajar con ellas de manera rápida
y sencilla, y facilitando al profesional la posibilidad de relacionar la información
existente a través de la topología de los objetos, con el fin de generar otra nueva
que no podríamos obtener de otra forma.
SIG Corporativo
Un SIG corporativo (SIGC) es un SIG común a toda una organización, que tiene
las siguientes carácterísticas:
• Base de Datos única y común
• Cartografía: común, (precisa, fiable, actualizada)
• SIG global NO temático
• Hardware/Software: modo cliente-servidor
Ilustración 40. Estructura de un SIG Corporativo
Las principales diferencias entre un SIG y un SIG Corporativo se manifiestan en:
• Personal, Métodos, Datos (metadatos)

• Obliga a trabajar como “sistema”
• Problema organizativo más que técnico
Un SIG corporativo supone:
• Cualquier puesto informático de la empresa u organismo tiene posibilidad

de acceso al estado del arte de la información geográfica
o Mayor y más eficiente uso de la información

o Detección más rápida de errores graves, “más ojos mirando”
o Presupuestos y mediciones más exactas
o Menor tiempo perdido en tareas rutinarias

o Más tiempo para dar servicio a los ciudadanos
• Existencia de un almacén con registro histórico y fácilmente accesible de

las actividades de todo el organismo
• Ahorro costes (licencias, máquinas, tiempo, actualizaciones de datos,
metadatos)
• Sinergia
• Liberar recursos del procesamiento de datos territoriales y dedicarlos a
analizarlos.
• Facilitar el acceso y aprovechamiento de los datos territoriales a todos los
usuarios potenciales.
• Garantizar la total coincidencia entre las cartografías: topografía,
planeamiento urbanístico, catastro, redes de servicios, control
medioambiental…
• Disponer de un soporte gráfico para detectar inconsistencias de un
mismo individuo en los diversos registros alfanuméricos donde está
introducido: Padrón de vehículos, Padrón de habitantes...
Ilustración 41. Elementos de un GIS Corporativo

Ilustración 42. Funciones de un GIS Corporativo
Gestores de
información
espacial
departamentales
Ilustración 43. Gestión global de un Modelo Corporativo de Información Espacial

(MCIE)
Anexo IV. Resumen de Mejores Prácticas, Gestión de

Calidad y Estándares
11. Anexo IV. Resumen de Mejores

Prácticas, Gestión de Calidad y
Estándares
Teniendo en cuenta que la materia de este anexo se ha visto ampliamente
durante el master, el objetivo de incluir este apartado es hacer un resumen de
los conceptos e ideas más importantes vistas a lo largo del Master que afectan al
objeto de este trabajo.
11.1. Gobierno de las TI
Para muchas empresas y organismos de la administración pública, la

información y la tecnología que la soporta representan sus más valiosos activos,
aunque con frecuencia son poco entendidos. Las empresas con éxito reconocen
los beneficios de la tecnología de información y la utilizan para impulsar el valor
de sus interesados. Estas empresas también entienden y administran los riesgos
asociados, así como la dependencia crítica de muchos procesos de negocio de
las TI.
La necesidad del aseguramiento del valor de TI, la administración de los riesgos

asociados a TI, así como el incremento de requerimientos para controlar la
información, se entienden ahora como elementos clave del gobierno de la
empresa. El valor, el riesgo y el control constituyen la esencia del gobierno de TI.
El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores

y consta de liderazgo, estructuras y procesos organizacionales que garantizan
que la TI de la empresa sostiene y extiende las estrategias y objetivos
organizacionales.
Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y

de seguridad de su información, así como de todos sus activos. La dirección
también debe optimizar el uso de los recursos disponibles de TI, incluyendo
aplicaciones, información, infraestructura y personas. Para descargar estas
responsabilidades, así como para lograr sus objetivos, la dirección debe
entender el estatus de su arquitectura empresarial para la TI y decidir qué tipo de
gobierno y de control debe aplicar.
11.1.1. COBIT
Control Objectives for Information and related Technology, que significa

Objetivos de Control para la información y Tecnologías relacionadas (COBIT®)
brinda buenas prácticas a través de un marco de trabajo de dominios y
procesos, y presenta las actividades en una estructura manejable y lógica. Las
buenas prácticas de COBIT representan el consenso de los expertos. Están
enfocadas fuertemente en el control y menos en la ejecución. Estas
prácticas ayudarán a optimizar las inversiones facilitadas por la TI, asegurarán la
entrega del servicio y brindarán una medida contra la cual juzgar cuando las
cosas no vayan bien.

Primero, la dirección requiere objetivos de control que definan la última meta de

implantar políticas, procedimientos, prácticas y estructuras organizacionales
diseñadas para brindar un nivel razonable que garantice que:
• Se alcancen los objetivos del negocio.

• Se prevengan o se detecten y corrijan los eventos no deseados.
En segundo lugar, en los complejos ambientes de hoy en día, la dirección busca

continuamente información oportuna y condensada, para tomar decisiones
difíciles respecto a riesgos y controles, de manera rápida y exitosa. ¿Qué se
debe medir y cómo? Las empresas requieren una medición objetiva de dónde se
encuentran y dónde se requieren mejoras, y deben implantar una caja de
herramientas gerenciales para monitorizar esta mejora.
Una respuesta a los requerimientos de determinar y monitorizar el nivel

apropiado de control y desempeño de TI son las definiciones específicas de
COBIT de los siguientes conceptos:
• Benchmarking de la capacidad de los procesos de TI, expresada

como modelos de madurez, derivados del Modelo de Madurez de la
Capacidad del Instituto de Ingeniería de Software
• Metas y métricas de los procesos de TI para definir y medir sus
resultados y su desempeño, basados en los principios de balanced
business Scorecard de Robert Kaplan y David Norton
• Metas de actividades para controlar estos procesos, con base en los
objetivos de control detallados de COBIT
Ilustración 44. Administración de la información
La medición del desempeño es esencial para el gobierno de TI. COBIT le da

soporte e incluye el establecimiento y el monitoreo de objetivos que se puedan
medir, referentes a lo que los procesos de TI requieren generar (resultado del
proceso) y cómo lo generan (capacidad y desempeño del proceso). Muchos
estudios han identificado que la falta de transparencia en los costos, valor y

riesgos de TI, es uno de los más importantes impulsores para el gobierno de TI.
Mientras las otras áreas consideradas contribuyen, la transparencia se logra de
forma principal por medio de la medición del desempeño.
Ilustración 45. Áreas focales del gobierno de las TI
Estas áreas focales de gobierno de TI describen los tópicos en los que la

dirección ejecutiva requiere poner atención para gobernar la TI en sus empresas.
La dirección operacional usa procesos para organizar y administrar las
actividades cotidianas de TI.
COBIT se basa en el análisis y armonización de estándares y mejores prácticas

de TI existentes y se adapta a principios de gobierno generalmente aceptados.
Está impulsado por los requerimientos del negocio, cubre el rango completo de
actividades de TI, y se concentra en lo que se debe lograr en lugar de cómo
lograr un gobierno, administración y control efectivos. Por lo tanto, funciona
como un integrador de prácticas de gobierno de TI y es de interés para:
• la dirección ejecutiva
• la gerencia del negocio
• la gerencia y gobierno de TI
• los profesionales de aseguramiento y seguridad
• los profesionales de auditoría y control de TI.
Los productos COBIT se han organizado en tres niveles diseñados para dar
soporte a:
• Administración y consejos ejecutivos

• Administración del negocio y de TI
• Profesionales en Gobierno, aseguramiento, control y seguridad.
El establecimiento de un marco de trabajo de gobierno efectivo, incluye la

definición de estructuras, procesos, liderazgo, roles y responsabilidades

organizacionales para garantizar así que las inversiones empresariales en TI

estén alineadas y de acuerdo con las estrategias y objetivos empresariales.
Ilustración 46. Productos COBIT
Para lograr la alineación de las mejores prácticas con los requerimientos del
negocio, se recomienda que COBIT se utilice al más alto nivel, brindando así
un marco de control general basado en un modelo de procesos de TI que debe
ser aplicable en general a toda empresa. Las prácticas y los estándares
específicos que cubren áreas discretas, se pueden equiparar con el marco de
trabajo de COBIT, brindando así una jerarquía de materiales guía.
COBIT actúa como un integrador de estos diferentes materiales guía,

resumiendo los objetivos clave bajo un solo marco de trabajo que también liga
los requisitos de gobierno y del negocio.

Ilustración 47. Interrelaciones de los Componentes de COBIT
COBIT 4.0 se enfoca en seis de los principales estándares de TI globales,

marcos de trabajo y prácticas como las principales referencias de soporte para
garantizar una cobertura, consistencia y alineación adecuada. Estas son:
• Comité de organizaciones patrocinadoras de la Comisión Treadway

(COSO):
o Control Interno—Marco de trabajo integrado, 1994
o Administración de riesgos empresariales—Marco de trabajo
integrado, 2004
• Oficina de comercio gubernamental (OGC®):
o Biblioteca de infraestructura de TI® (ITIL®), 1999-2004
• Organización internacional para la organización:
o ISO/IEC 17799:2005, Código de prácticas para la administración
de la seguridad de la información
• Instituto de Ingeniería de Software (SEI®):
o SEI Modelo de madurez de la capacidad (CMM®), 1993
o SEI Integración del modelo de madurez de la capacidad (CMMI®),
2000
• Instituto de administración de proyectos (PMI®):
o Cuerpo de conocimiento de administración de proyectos
(PMBOK®), 2000
• Foro de seguridad de información (ISF):
o El estándar de buenas prácticas para la seguridad de la
información, 2003
11.1.1.1. Marco de Trabajo COBIT
El marco de trabajo COBIT se creó con las características principales de ser :


• orientado a negocios
• orientado a procesos
• basado en controles
• impulsado por mediciones
Orientado al negocio
El marco de trabajo COBIT se basa en el siguiente principio: proporcionar la

información que la empresa requiere para lograr sus objetivos, la empresa
necesita administrar y controlar los recursos de TI usando un conjunto
estructurado de procesos que ofrezcan los servicios requeridos de información.
El marco de trabajo COBIT ofrece herramientas para garantizar la alineación con

los requerimientos del negocio.
Ilustración 48. Principio Básico COBIT
Orientado a procesos
COBIT define las actividades de TI en un modelo genérico de procesos con

cuatro dominios. Estos dominios son:
• Planear y Organizar
• Adquirir e Implementar
• Entregar y Dar Soporte
• Monitorear y Evaluar.
Los dominios se equiparan a las áreas tradicionales de TI de planear, construir,

ejecutar y monitorear.

Basado en controles
Control se define como las políticas, procedimientos, prácticas y estructuras

organizacionales diseñadas para brindar una seguridad razonable que los
objetivos de negocio se alcanzarán, y los eventos no deseados serán prevenidos
o detectados y corregidos. Un objetivo de control de TI es una declaración del
resultado o fin que se desea lograr al implantar procedimientos de control en una
actividad de TI en particular. Los objetivos de control de COBIT son los
requerimientos mínimos para un
control efectivo de cada proceso
de IT.
COBIT brinda un modelo

genérico de procesos que
representa todos los procesos
que normalmente se encuentran
en las funciones de TI,
proporcionando un modelo de
referencia general y entendible
para la gerencia operacional de
TI y para la gerencia
administrativa.
Ilustración 49. Modelo de Control de COBIT
Generadores de mediciones
Una necesidad básica de toda empresa es entender el estado de sus propios

sistemas de TI y decidir qué nivel de administración y control debe proporcionar
la empresa. La obtención de una visión objetiva del nivel de desempeño propio
de una empresa no es sencilla. ¿Qué se debe medir y cómo? Las empresas
deben medir dónde se encuentran y dónde se requieren mejoras, e implementar
un juego de herramientas gerenciales para monitorear esta mejora. Para decidir
cuál es el nivel correcto, la gerencia debe preguntarse a sí misma: ¿Qué tan
lejos debemos ir, y está justificado el costo por el beneficio?
COBIT atiende estos temas por medio de:
• Modelos de madurez que facilitan la evaluación por medio de

benchmarking y la identificación de las mejoras necesarias en la
capacidad
• Metas y mediciones de desempeño para los procesos de TI, que
demuestran cómo los procesos satisfacen las necesidades del negocio y
de TI, y cómo se usan para medir el desempeño de los procesos internos
basados en los principios de un marcador de puntuación balanceado
(balanced scorecard)
• Metas de actividades para facilitar el desempeño efectivo de los
procesos

MODELOS DE MADUREZ
Cada vez con más frecuencia, se les pide a los directivos de empresas
corporativas y públicas que se considere qué tan bien se está administrando TI.
Como respuesta a esto, se debe desarrollar un plan de negocio para mejorar y
alcanzar el nivel apropiado de administración y control sobre la infraestructura de
información. Aunque pocos argumentarían que esto no es algo bueno, se debe
considerar el equilibrio del costo beneficio y éstas preguntas relacionadas:
• ¿Qué están haciendo nuestra competencia en la industria, y cómo

estamos posicionados en relación a ellos?
• ¿Cuáles son las mejores prácticas aceptables en la industria, y cómo
estamos posicionados con respecto a estas prácticas?
• Con base en estas comparaciones, ¿se puede decir que estamos
haciendo lo suficiente?
• ¿Cómo identificamos lo que se requiere hacer para alcanzar un nivel
adecuado de administración y control sobre nuestros procesos de TI?
Comenzando con los procesos y los objetivos de control de alto nivel de COBIT,
el propietario del proceso se debe poder evaluar de forma progresiva, contra los
objetivos de control.
Ilustración 50. Representación gráfica de los modelos de madurez
Estas escalas deben ser prácticas en su aplicación y razonablemente fáciles de

entender. El tema de procesos de TI es esencialmente complejo y subjetivo, por
lo tanto, es más fácil abordarlo por medio de evaluaciones fáciles que aumenten
la conciencia, que logren un consenso amplio y que motiven la mejora. Estas
evaluaciones se pueden realizar ya sea contra las descripciones del modelo de
madurez como un todo o con mayor rigor, en cada una de las afirmaciones
individuales de las descripciones. De cualquier manera, se requiere experiencia
en el proceso de la empresa que se está revisando.

Ilustración 51. Modelo Genérico de Madurez
La ventaja de un modelo de madurez es que es relativamente fácil para la

dirección ubicarse a sí misma en la escala y evaluar qué se debe hacer si se
requiere desarrollar una mejora. La escala incluye al 0 ya que es muy posible
que no existan procesos en lo absoluto. La escala del 0-5 se basa en una escala
de madurez simple que muestra como un proceso evoluciona desde una
capacidad no existente hasta una capacidad optimizada.
La capacidad, el desempeño y el control son dimensiones de la madurez de un

proceso como se ilustra en la siguiente figura.
Ilustración 52. Las tres dimensiones de la madurez
Un punto de referencia estratégico para una empresa que ayuda a mejorar la

administración y el control de los procesos de TI se puede encontrar
observando los estándares internacionales y las mejores prácticas.

En resumen, los modelos de madurez brindan un perfil genérico de las etapas a

través de las cuales evolucionan las empresas para la administración y el control
de los procesos de TI, estos son:
• Un conjunto de requerimientos y los aspectos que los hacen posibles en

los distintos niveles de madurez
• Una escala donde la diferencia se puede medir de forma sencilla
• Una escala que se presta a sí misma para una comparación práctica
• La base para establecer el estado actual y el estado deseado
• Soporte para un análisis de brechas para determinar qué se requiere
hacer para alcanzar el nivel seleccionado
• Tomado en conjunto, una vista de cómo se administra la TI en la
empresa
MEDICIÓN DEL DESEMPEÑO
Las métricas y las metas se definen en COBIT a tres niveles:
• Las metas y métricas de TI que definen lo que el negocio espera de TI (lo

que el negocio usaría para medir a TI)
• Metas y métricas de procesos que definen lo que el proceso de TI debe
generar para dar soporte a los objetivos de TI (cómo sería medido el
propietario del proceso de TI)
• Métricas de desempeño de los procesos (miden qué tan bien se
desempeña el proceso para indicar si es probable alcanzar las metas)
COBIT utiliza dos tipos de métrica: indicadores de metas e indicadores de

desempeño. Los indicadores de metas de bajo nivel se convierten en
indicadores de desempeño para los niveles altos.
Los indicadores clave de metas (KGI) definen mediciones para informar a la

gerencia—después del hecho—si un proceso TI alcanzó sus requerimientos de
negocio, y se expresan por lo general en términos de criterios de información:
• Disponibilidad de información necesaria para dar soporte a las

necesidades del negocio
• Ausencia de riesgos de integridad y de confidencialidad
• Rentabilidad de procesos y operaciones
• Confirmación de confiabilidad, efectividad y cumplimiento
Los indicadores clave de desempeño (KPI) definen mediciones que determinan

qué tan bien se está desempeñando el proceso de TI para alcanzar la meta.
• Predicen la probabilidad de éxito o fallo

• Foco en los aspectos del proceso y la mejora del balanced scorecard
• Están expresados en términos medibles de forma precisa
• Deberían ayudar en la mejora de los procesos de TI
Las métricas efectivas deben tener las siguientes características:


• Una alta proporción entendimiento-esfuerzo (esto es, el entendimiento del

desempeño y del logro de las metas en contraste con el esfuerzo de
lograrlos)
• Deben ser comparables internamente (esto es, un porcentaje en
contraste con una base o números en el tiempo)
• Deben ser comparables externamente sin tomar en cuenta el tamaño de
la empresa o la industria
• Es mejor tener pocas métricas (quizá una sola muy buena que pueda ser
influenciada por distintos medios) que una lista más larga de menor
calidad
• Debe ser fácil de medir y no se debe confundir con las metas
Las metas se definen de arriba hacia abajo con base en las metas de negocio
que determinarán el número de metas que soportará TI, las metas de TI
decidirán las diferentes necesidades de las metas de proceso, y cada meta de
proceso establecerá las metas de las actividades. El logro de metas se mide con
las métricas de resultado (llamadas indicadores clave de metas, o KGIs) y
dirigen las metas de más alto nivel. Por ejemplo, la métrica que midió el logro de
la meta de la actividad es un motivador de desempeño (llamado indicador clave
de desempeño, o KPI) para la meta del proceso. Las métricas permiten a la
gerencia corregir el desempeño y realinearse con las metas.
Ilustración 53. Administración, control, alineación y monitoreo COBIT


Para resumir, los recursos de TI son manejados por procesos de TI para lograr
metas de TI que respondan a los requerimientos del negocio. Este es el principio
básico del marco de trabajo COBIT, como se ilustra en el cubo COBIT.
Ilustración 54. El cubo COBIT
11.2. Gestión de Servicios TI
Lejos quedan los días en los que TI se podía librar con tan sólo la entrega de
productos. Los clientes y usuarios quieren mucho más: demandan entrega de
servicio no de productos. TI tiene que entregar un servicio constante y estable,
de calidad, disponible 24x7, para el momento preciso en que un usuario necesite
acceder a los servicios, y además ser flexible y responder con agilidad a las
demandas de los clientes, en permanente cambio, a medida que aquellas
surgen.
Situación de partida
En muchas organizaciones hay muy pocos Acuerdos de Nivel de Servicio ANSs

que consiguen su objetivo de mejorar la calidad de servicio (y eso si de verdad
existen ANSs). La causa es que no tenemos información de gestión disponible y
las decisiones se toman basadas en lo que se cree en vez de en lo que se
sabe. Medir la gestión de servicio es fundamental para poder mejorar, ya que si
no se puede saber dónde nos encontramos, mejorar nuestra situación es muy
difícil. Esto puede hacer muy difícil justificar un programa de mejora de gestión
de los servicios. Por otra parte, no sabemos cuánto vale el servicio que
prestamos sin un buen entendimiento de los costes (incluidos los costes de los
cambios). Un entendimiento de los costes de servicio también proporciona una
base sólida para el desarrollo de la TI.

Ilustración 55. Criterios sobre la Calidad del Servicio
La mayoría de organizaciones están dirigidas de manera reactiva por incidencias

de servicio e interrupciones, lo que genera una infrautilización de los recursos
de soporte, que están continuamente peleándose, resolviendo sus incidencias y
problemas repetidamente, en lugar de eliminarlos definitivamente.
A diario ocurren cambios no coordinados y sin registrar. Este mal control del
cambio cuesta mucho dinero y agota los recursos porque debemos hacer las
cosas una y otra vez. La carencia de gestión de Cambios puede tener efectos
negativos mayores en otros procesos porque no controlamos nuestro entorno.
Por ello, también nos incapacita para poder manejar los cambios en nuestro
negocio.
Por último, sobredependemos de los empleados clave porque el conocimiento

está sin documentar, sólo está en su cabeza. Adicionalmente, muchos
empleados tienen eminentemente un enfoque técnico y no de negocio, de
máquina y aplicación y no de servicio, que son los temas que vamos a tratar en
este módulo. Por último, la relación existente entre los recursos de personal y los
costes relacionados son la mayor parte del tiempo muy poco claros. A menudo,
no sabemos a qué dedican su tiempo muchas personas ni por qué están aquí.
Procesos y procedimientos
La gestión de servicio se basa en procesos. Un proceso es un conjunto de

actividades lógicas combinadas para obtener cierto objetivo (resultado). Las
ventajas de los procesos son:

En un proceso describimos los objetivos (resultados) y la forma en los que los

vamos a alcanzar
• Para cada proceso, definimos las entradas (input) y su rendimiento

(output) qué necesitaremos para alcanzar el objetivo del proceso
• También se define cuáles son las entradas que otros procesos necesitan
de nosotros para alcanzar sus objetivos
• Describimos una organización entera en distintos procesos, podemos
monitorizar esos procesos uno a uno. Como efecto, monitorizamos varias
partes pequeñas de una gran organización y eso es mejor que
monitorizar la totalidad
• Hacemos a las personas responsables de la eficiencia, efectividad y del
resultado de su proceso; como resultado de ello no sólo monitorizamos
sino controlamos nuestra organización
• Podemos mejorar nuestra organización porque podemos relacionar el
resultado que obtenemos de la monitorización a nuestro modelo de
procesos, y podemos discutir las maneras de mejorar las actividades en
un proceso para alcanzar el modelo. Y repetir esta actuación para
mejorar continuamente.
• Podemos crear mejores roles y responsabilidades; podemos dividir
responsabilidades para evitar conflictos de interés
• Las actividades que tienen que ser ejecutadas en distintas
organizaciones pero que atañen a un resultado pueden ser controladas
mejor si hay un proceso
Los procedimientos (instrucciones de trabajo) son más detallados y describen

exactamente quién y de qué manera ejecuta ciertas actividades en un proceso.
Los procedimientos pueden variar de departamento en departamento y de
actividad en actividad. Por ejemplo: en el proceso de Cambio exigimos que cada
cambio será solicitado por una Solicitud de Cambio, pero la información que
queremos que se adjunte a la Solicitud puede ser distinta en función del
departamento. Y la información para un cambio de categoría 1 puede ser distinta
que la información de un cambio de categoría 2. El detalle de esas necesidades
se incluye en los procedimientos.
Roles
Cada proceso puede desmenuzarse en una serie de tareas y actividades. Para

cada tarea habrá entradas (inputs) y rendimientos (outputs)
Cada tarea será ejecutada por un rol. Éste puede ser encarnado por una
persona o por un departamento, que tendrá que disponer de una serie de
competencias para llevar a cabo ese rol.
La ejecución del rol está gobernada por un conjunto de normas de complejidad

diversa.
A menudo, un proceso abarcará varios límites de organización. Es importante,

por lo tanto, que cada proceso tenga un propietario. Este es otro rol. la ejecución
del proceso estén informadas de cualquier Cambio que ocurra en él, y vela por
su correcta ejecución en los servicios.

El propietario del proceso es el rol responsable de la definición del proceso. El

dueño del proceso es el responsable de asegurar que todas las personas
involucradas en la ejecución del proceso estén informadas de cualquier Cambio
que ocurra en él, y vela por su correcta ejecución en los servicios.
11.2.1. ITIL
ITIL es un estándar mundial que ofrece las “mejores prácticas” de gestión que se
adaptan a grandes y pequeñas organizaciones. ITIL define la gestión de
servicios como procesos relacionados y altamente integrados, que brindan un
servicio de calidad reduciendo el coste total de propiedad, al bajar los costes de
gestión, soporte y mantenimiento.
La biblioteca de infraestructura de TI (ITIL) toma este nombre por tener su origen

en un conjunto de libros, cada uno dedicado a una práctica específica dentro de
la gestión de TI. Tras la publicación inicial de estos libros, su número creció
rápidamente (dentro la versión 1) hasta unos 30 libros. Para hacer a ITIL más
accesible (y menos costosa) a aquellos que deseen explorarla, uno de los
objetivos del proyecto de actualización ITIL versión 2 fue agrupar los libros
según unos conjuntos lógicos destinados a tratar los procesos de administración
que cada uno cubre. De esta forma, diversos aspectos de los sistemas de TIC,
de las aplicaciones y del servicio se presentan en conjuntos temáticos.
Actualmente existe la nueva versión ITIL v3 que fue publicada en mayo de 2007.
Los principales elementos de ITIL pueden ser comparados a la superposición de

las piezas dentadas de un puzzle ( o mejor, como placas tectónicas) en las que
algunas ajustan perfectamente y otras en cambio se solapan o no ajustan con
precisión. Al nivel más alto, no hay líneas de demarcación estrictas.
Ilustración 56. Modelo en Piezas de Puzzle de los principales dominios

de ITIL versión 2

Ciertamente, si consideramos la analogía con las placas tectónicas, unas

deslizan sobre y bajo otras, uniéndose y separándose, haciendo surgir los
problemas de puntos de inestabilidad o fricción sobre la tierra causados por el
ajuste impreciso de las piezas, es aquí donde tiene su equivalencia en la gestión
de servicios. Es, precisamente, cuando los dominios de procesos se solapan o
las líneas de demarcación no pueden ser dibujadas claramente, cuando muchos
problemas de gestión salen a la luz. No se puede evitar que los problemas
ocurran (igual que no se pueden parar los terremotos), pero se puede dar
recomendaciones para prepararse y tratar con estos problemas.
Aunque el tema de Gestión de Servicios (Soporte al Servicio y Entrega de

Servicios) es el más ampliamente difundido e implementado, el conjunto de
mejores prácticas ITIL provee un conjunto completo de prácticas que abarca no
sólo los procesos y requerimientos técnicos y operacionales, sino que se
relaciona con la gestión estratégica, la gestión de operaciones y la gestión
financiera de una organización moderna.
Los ocho libros de ITIL y sus temas son:
Gestión de Servicios de TI
1. Entrega de Servicios
2. Soporte al Servicio
Otras guías operativas
3. Gestión de la infraestructura de TI
4. Gestión de la seguridad
5. Perspectiva de negocio
6. Gestión de aplicaciones
7. Gestión de activos de software
Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional

con guías de implementación (principalmente de la Gestión de Servicios):
7.1. Planeando implementar la Gestión de Servicios
Adicional a los ocho libros originales, más recientemente se añadió una guía con
recomendaciones para departamentos de TIC más pequeños:
8. Implementación de ITIL a pequeña escala
11.2.2. ISO 20000
En noviembre de 2004 el BS 15000 fue enviado a procedimiento para su

transformación en estándar internacional para La Gestión del Servicio TI y pasó
a ser ISO 20000.
¿Qué es BS 15000?

BS 15000 es el primer estándar mundial específico para la Gestión de Servicio.

Es publicado por el British Standards Institute (BSI). El estándar define las
características escenciales del proceso de la Gestión de Servicios, que permita
brindar una alta calidad de servicio. BS 1500 se basa en la experiencia de
expertos que trabajan en la Gestión de Servicio.
Cobertura de BS 15000
o Ámbito de la Gestión de Servicio

o Términos y definiciones
o Requerimientos para un Sistema de Gestión "Planear-Hacer-Revisar-
Actuar"
o Plan e Implementación de los procesos de la Gestión de Servicio
o Plan e Implementación de Servicios nuevos o de sus cambios
Los Orígenes de BS 15000
El estándar fue creado por el Grupo de Gestión de Servicio de BSI, este grupo
está conformado por expertos de la industria que representan dis-tintas
organizaciones e industrias, todos ellos con prácticas de excelencia en la
Gestión de Servicio.
En la década de 1980 se inició su estudio con la publicación de un código de

prácticas que cubría cuatro procesos centrales. En 1998 se sustituyó 13
procesos, así la primer edición como estándar se publicó en el año 2000. Al
mismo tiempo también se publicó el libro "IT Service Management" (PD 0015),
este libro de trabajo es utilizado para la revisión de la calidad del proceso de
servcio.
11.2.3. BS 15000 e ITIL
Las distintas organizaciones involucradas (BSI, OCG e itSMF) alinearon BS

15000 con ITIL, esto no significa que se deba escoger entre uno u otro, no son
intercambiables y sirven a distintos propósitos:
ITIL establece las buenas prácticas, que en caso de adoptarse, asistiría a la

organización para alcanzar la calidad del servicio requerido en BS 15000.
BS 15000 define los estándares para los procesos de gestión de servicio, y

objetivamente, mide y prueba que esas buenas prácticas hayan sido adoptadas.
11.3. Gestión de la Calidad
La calidad se ha convertido en una necesidad estratégica y en un arma para

sobrevivir en mercados altamente competitivos. La empresa que desea ser líder
debe saber qué espera y necesita su clientela potencial, tiene que producir un
buen producto, debe cuidar las relaciones con sus clientes y, para lograrlo, es
común que hoy día las empresas vinculen su estrategia de marketing a su
sistema de calidad.

Del control de la calidad a la calidad total
El mayor desarrollo de las modernas técnicas de calidad y en concreto del

enfoque que se engloba bajo el título de Calidad Total, se produjo como
consecuencia de la transformación de la industria japonesa tras la Segunda
Guerra Mundial.
Ahora bien evitar vender un producto porque es de baja calidad no es suficiente

y que prevenir los errores determinando las fuentes de ese error no basta para
mejorar el producto. La alternativa es incorporar la calidad a todas las fases del
proceso e implicar a todos los profesionales que intervienen en ellos, buscando
mejorar los procesos día a día. Esto nos conduce a hablar de Calidad Total.
El término calidad total se debe a Feigenbaum, para quien el objetivo es

satisfacer al cliente, y la forma de lograrlo es la mejora continua de la calidad.
Para Deming resultan fundamentales el compromiso de mejora constante y la
idea de sustituir la inspección (o control) como forma de conseguir la calidad por
una metodología que implique la participación de todos, rompiendo barreras y
fomentando estilos de liderazgo participativos. Crosby, otro autor
norteamericano, considera que la principal “barrera a la calidad” reside en llegar
a cambiar las actitudes de algunos operarios incrédulos y en alterar la cultura de
la propia organización basada en el miedo, para orientarla hacia la prevención
del error y lograr “hacer las cosas bien a la primera”. Planificar, controlar y
mejorar la calidad es la receta de Juran. Para ello, sugiere determinar quiénes
son los clientes, cuáles son sus necesidades, desarrollar seguidamente los
productos o servicios que las satisfagan, evaluar el logro alcanzado, actuar para
reducir la diferencia, si ésta se produce, e introducir mejoras hasta donde
seamos capaces. De forma complementaria, no interrumpir la cadena proveedor-
cliente, impulsar la formación continuada, los métodos estadísticos y fomentar la
comunicación, son las herramientas que recomienda Ishikawa. Todos estos
autores han tenido una influencia directa y notoria en el desarrollo del concepto
actual de calidad y en la puesta a punto de estrategias y herramientas para
implantarla en las empresas.
Para Deming resultan fundamentales el compromiso de mejora constante y la

idea de sustituir la inspección (o control) como forma de conseguir la calidad por
una metodología que implique la participación de todos, rompiendo barreras y
fomentando estilos de liderazgo participativos.
Deming se conoce mejor por su filosofía de gestión estableciendo calidad,

productividad y posición competitiva. Como parte de esta filosofía, formuló
catorce puntos de atención para directores.
Extractos de los catorce puntos de Deming:

• Derribar barreras entre departamentos (mejora comunicaciones y
dirección)
• Los directores deben aprender sus responsabilidades y asumir el
liderazgo que les corresponde (la mejora de procesos requiere
compromiso desde arriba; los buenos líderes motivan a las personas a
mejorar)

• Mejorar constantemente (un tema central para gestores de Servicio es la

mejora continua. Esto también es una cuestión para gestión de calidad.
Un enfoque orientado a los procesos es clave para alcanzar este
objetivo)
• Formación y mejora (aprender y mejorar habilidades ha sido el enfoque
de Gestión de Servicio durante años)
• Formación en el puesto de trabajo (on-the-job) ligado a la mejora
continua
• Transformación de los trabajos de todas las personas (el énfasis estando
en el trabajo en equipo y el entendimiento)
Deming propuso el Ciclo o Círculo de Deming. Las cuatro etapas clave son
Planificar (Plan), hacer (Do), comprobar (Check) y actuar (Act). Después de lo
cual una fase de consolidación evita que el Círculo ruede hacia abajo. La fase de
consolidación permite a la organización darse cuenta de lo que ha obtenido y
asegurar que las mejoras se asienten.
Ilustración 57. Ciclo de Deming
Gestión de Costes de Calidad
Los costes relacionados con la calidad constituyen una valiosa herramienta que
permite conocer dónde y cómo se encuentran las actividades de calidad y qué
representan económicamente, y posibilitan además, planificar adecuadamente
esas actividades en función de los recursos disponibles en cada momento
determinado.

Su desconocimiento, por el contrario, imposibilita la implantación de cualquier

proceso encaminado a planificar los programas de calidad e impide la definición
racional de los objetivos de gestión con ella relacionados.
Con la finalidad de establecer la información adecuada para llevar a cabo una

correcta y eficaz gestión económica de la calidad, existe práctica unanimidad a
la hora de identificar, definir y clasificar los costes de la calidad, y que se
corresponde básicamente con lo representado en la siguiente figura.
Ilustración 58. Costes de Calidad
COSTE TOTAL DE LA CALIDAD.

Es aquel formado por la suma de los costes de calidad o conformidad y los
costes de no calidad o no conformidad.
A estos efectos resulta ya clásica la ecuación del coste total de la calidad:
Ct = Costes de Conformidad + Costes de no conformidad.
COSTES DE CALIDAD O DE CONFORMIDAD.
Son aquellos originados por la implantación y desarrollo de las actividades

necesarias para alcanzar los objetivos de calidad. Expresan el esfuerzo
económico necesario para asegurar que el producto alcance el grado de
idoneidad suficiente para su buen uso por el cliente, y comprende los costes de
prevención y evaluación.
Costes de Prevención.
Se entiende por costes de prevención, aquellos en los que se incurre para poder
implantar y mejorar el sistema de calidad.
Tratan de prevenir la aparición de errores o defectos, e intentan asegurar los

niveles de calidad previamente establecidos. Como ejemplos típicos, podemos

citar:los de evaluación de proveedores, formación y adiestramiento del personal,

mantenimiento preventivo, investigación de mercados, planificación de la calidad
etc.
Generalmente estos costes tienen un efecto positivo sobre la capacidad del

personal, a fin de que puedan ejecutar correctamente sus tareas a la primera
vez.
Costes de Evaluación. Son aquellos originados por la implantación y desarrollo

de las actividades tendentes a comprobar o verificar que se está consiguiendo la
calidad especificada.
Como costes representativos, pueden citarse: los de inspección de materiales,

de componentes y de productos en curso y terminados, las pruebas y ensayos,
la revisión de informes y documentos etc.
Suele afirmarse, que la empresa incurre en estos coste al no estar convencida

de que con los costes de prevención se eliminarán todos los errores; se trata de
impedir con ellos que estos errores o fallos alcancen un nivel más adelantado
dentro de la cadena productiva, o que en última instancia puedan llegar al
cliente.
COSTES DE NO CALIDAD O DE NO CONFORMIDAD.

Son aquellos costes asociados a los fallos o errores en los productos y que
impiden que éstos cumplan con los requisitos especificados o acordados con los
clientes.
Expresan las consecuencias económicas negativas que ocasionan los fallos en

materia de calidad; están compuestos por la suma de los costes de fallos
internos y externos.
Costes de fallos o errores internos.

Son los costes provocados por los productos y servicios que no cumplen con los
requisitos de calidad establecidos y que son detectados durante el proceso de
evaluación y siempre antes de su entrega al cliente.
Como ejemplos, pueden citarse los originados por: los productos y materiales
para desecho, los productos y materiales defectuosos rehechos, trabajos de
reinspección y de repetición de ensayos, diseños vueltos a rehacer, etc.
Costes de fallos o errores externos.

Son costes asociados a los productos y servicios que no cumplen los requisitos
de calidad o no satisfacen las necesidades o expectativas de los clientes y que
se manifiestan después de su entrega a éstos.
Entre otros, pueden destacarse los costes provocados por: garantías, productos
devueltos, asistencia al cliente, penalizaciones, pérdida de imagen, pérdidas de
cuotas de mercado, responsabilidades penales, etc.
Hemos de llamar la atención sobre la dificultad que en algunos casos entraña la

cuantificación de los costes provocados por fallos externos, sobre todo los de

aquellos con la consideración de oportunidades perdidas (imagen, pérdida de

mercados etc).
Conviene señalar finalmente, que los costes relacionados con la calidad pueden
localizarse en cualquiera de los centros de responsabilidad existentes en la
organización, e involucran tanto a materiales como a la mano de obra directa,
equipos productivos y al resto de los costes indirectos; en cualquier caso, debe
resultar evidente que superan con creces a aquellos costes meramente
asociados con la existencia del departamento de control de calidad.
Ilustración 59. “Regla de Oro” de los Costes de Calidad
Sobre los costes de calidad, existe un amplio abanico de motivos concretos con
la suficiente significación como para haber conseguido concienciar a las
empresas sobre la necesidad de medirlos, analizarlos y controlarlos
convenientemente. De manera sintética podemos resumirlos en los siguientes:
1. Los costes de la calidad representan un significativo porcentaje del coste

total del producto.
2. En conexión con lo anterior, existe una relación directa entre costes de
calidad y resultados, de tal manera que cada u.m. ahorrada en estos costes,
repercute en la misma medida en los beneficios de la empresa.
3. Entre otras ventajas, la gestión de los costes de calidad permitirá registrar y
analizar la proyección a largo plazo de estos costes sobre el comportamiento
de la calidad total y sobre la imagen de la empresa en el mercado.
Considerados así, los costes de calidad se han de enmarcar en el proceso de

planificación estratégica de la organización. De esta forma, obligan a ser tenidos
en cuenta en los planes y presupuestos de los distintos centros de
responsabilidad.

El papel de los costes de la calidad en este proceso de planificación estratégica

será el de contribuir a:
• Desarrollar un plan de calidad estratégico global que incorpore todos los

objetivos funcionales de calidad, incluyendo planes y presupuestos para
los costes de calidad.
• Analizar las tendencias más importantes en la satisfacción del cliente, en
las tasa de defectos o errores y en los demás costes, tanto de manera
global como por departamentos específicos.
• Asistir a otras áreas funcionales para garantizar que los costes
relacionados con la calidad están siendo incluidos en sus respectivos
análisis , con el fin de poder establecer objetivos adecuados.
4. Considerados como herramientas de gestión, los costes de calidad pueden

erigirse en potentes detectores de las áreas problemáticas de las empresas,
aquellas necesitadas de acciones correctoras tendentes a la consecución de
la mejora continuada, permitiendo de esta forma eliminar aquellas
actividades que no aporten valor al producto o servicio.
5. En continuidad con lo anterior, la medida y control de los costes de calidad,

proporcionará, el medio más adecuado para observar tanto los logros
conseguidos en el sendero de la consecución de la mejora continuada, como
el auténtico impacto causado por la implantación de las acciones correctoras
seleccionadas.
6. El análisis, medida y control de los costes de la calidad y demás aspectos

con ellos relacionados, evitará basar nuestras decisiones sobre
informaciones, muchas veces erróneas, que pueden abocar al fracaso de
nuestros productos en el mercado.
El uso de los costes de calidad:
• Permite el conocimiento de variables no financieras críticas para el

éxito en la gestión.
• Animan a usar estos datos para propósitos internos, a la vez que
posibilitan la captura de abundante información de carácter externo y
estratégico.
• Destruyen barreras de incomunicación entre las distintas áreas
funcionales y disciplinares de la organización, impregnando a todo el
personal de la filosofía subyacente en la consecución de la mejora
continuada.
7. El seguimiento de los costes de la calidad ha venido corriendo a cargo de

responsables no cualificados para el desempeño de estas tareas, es por lo
que la implantación de un programa riguroso de análisis medida y control
exigirá ahora la participación de un departamento especializado en estas
funciones.
11.3.1. Normas ISO 9000


La familia de normas ISO 9000 son normas de "calidad" establecidas por la

Organización Internacional para la Estandarización (ISO) que se pueden aplicar
en cualquier tipo de organización. Se componen de estándares y guías
relacionados con sistemas de gestión y de herramientas específicas como los
métodos de auditoría (el proceso de verificar que los sistemas de gestión
cumplen con el estándar).
Su implantación en estas organizaciones, aunque supone un duro trabajo, ofrece

una gran cantidad de ventajas para sus empresas. Los principales beneficios
son:
• Reducción de rechazos e incidencias en la producción o prestación del

servicio
• Aumento de la productividad
• Mayor compromiso con los requisitos del cliente
• Mejora continua
La familia de normas apareció por primera vez en 1987 teniendo como base una
norma estándar británica (BS), y se extendió principalmente a partir de su
versión de 1994, estando actualmente en su versión 2000.
La principal norma de la familia es: ISO 9001:2000 - Sistemas de Gestión de la

Calidad - Requisitos.
Y otra norma vinculante a la anterior es: ISO 9004:2000 - Sistemas de Gestión

de la Calidad - Guía de mejoras del funcionamiento.
Las normas ISO 9000 de 1994 estaban principalmente pensadas para

organizaciones que realizaban proceso productivo y, por tanto, su implantación
en las empresas de servicios era muy dura y por eso se sigue en la creencia de
que es un sistema bastante burocrático.
Con la revisión de 2000 se ha conseguido una norma bastante menos

burocrática para organizaciones de todo tipo, y además se puede aplicar sin
problemas en empresas de servicios e incluso en la Administración Pública.
Para verificar que se cumple con los requisitos de la norma, existen unas
entidades de certificación que dan sus propios certificados y permiten el sello.
Estas entidades están vigiladas por organismos nacionales que les dan su
acreditación.
11.3.2. MODELO EFQM
La EFQM (European Foundation for Quality Management) fue fundada en 1988

por los presidentes de las 14 mayores compañías europeas, con el apoyo de la
Comisión Europea. Actualmente son miembros de esta fundación más de 600
organizaciones, desde multinacionales e importantes compañías nacionales,
hasta universidades e institutos de investigación. La Fundación asume su papel
como clave en el incremento de la eficacia y la eficiencia de las organizaciones
europeas, reforzando la Calidad en todos los aspectos de sus actividades, así
como estimulando y asistiendo el desarrollo de la mejora de la Calidad.

Como parte de este estímulo, la EFQM (una fundación localizada en Bélgica)

otorga todos los años el Premio Europeo a la Calidad, utilizando como criterio de
decisión el Modelo de Excelencia EFQM.
El impulso para fundar esta poderosa red de administración fue la necesidad de

crear un marco de trabajo para la mejora de la calidad, el cual estuviera basado
en el modelo Malcolm Baldrige de los Estados Unidos y en el Premio Deming en
Japón, pero adecuado a las necesidades del contexto europeo.
El Modelo de Excelencia EFQM fue introducido en 1991 como el marco de

trabajo para la autoevaluación de las organizaciones y como la base para juzgar
a los concursantes por el Premio Europeo de la Calidad, el cual fue entregado
por primera vez en 1992. Este modelo es el más ampliamente utilizado en
Europa y se ha convertido en la base para la evaluación de las organizaciones
en la mayoría de los premios nacionales y regionales de calidad en toda Europa.
Desde sus inicios la EFQM se ha orientado por la visión de ayudar a crear

organizaciones europeas fuertes que practiquen los principios de la
administración de la calidad total en sus procesos de negocios y en sus
relaciones con sus empleados, clientes, accionistas y comunidades donde
operan.
Misión del Modelo de Excelencia EFQM
• Estimular y asistir a las organizaciones en toda Europa para participar en

las actividades de mejoramiento enfocadas en lograr la excelencia en la
satisfacción al cliente, la satisfacción de los empleados, el impacto en la
sociedad y en los resultados de negocios.

• Apoyar a los gerentes de las organizaciones europeas en la aceleración

de transformar la administración de la calidad total en un factor decisivo
en el logro de la ventaja competitiva a nivel global.
Con la ayuda de la EFQM y a través del ejemplo de sus miembros, las

organizaciones en Europa han comenzado a aceptar que la administración de la
calidad total es una forma de administrar actividades para ganar eficiencia,
efectividad y ventaja competitiva, asegurando el éxito a largo plazo al satisfacer
las necesidades de los clientes, empleados, entidades financieras, accionistas y
la comunidad en general.
La implementación de programas de administración de la calidad total permiten

alcanzar beneficios significativos, tales como un incremento en la eficiencia,
reducción de costos y mayor satisfacción de los clientes, todo orientado a
mejorar los resultados de los negocios.
La EFQM tiene un rol clave en la mejora de la efectividad y la eficiencia de las

organizaciones europeas al reforzar la importancia de la calidad en todos los
aspectos de sus actividades. También contribuye asistiendo y estimulando el
desarrollo de políticas para el mejoramiento de la calidad.
11.3.3. Comparación del modelo E.F.Q.M. con la norma ISO

9001:2000
El enfoque que presenta la norma ISO 9001: 2000 es propio de la Gestión de

Calidad Total y trata de recoger aportaciones realizadas en los últimos años por
modelos de excelencia empresarial como el modelo EFQM de Excelencia o el
Malcom Baldrige. De ahí que la norma ISO 900: 2000 y el modelo EFQM
presenten analogías y por supuesto, diferencias.
Analogías entre el modelo EFQM y la norma ISO 9000: 2000
• Los requisitos de la ISO 9001:2000 son una parte de los criterios del
Modelo EFQM.
• El concepto REDER es la aplicación del ciclo de mejora PDCA a toda la
organización requieren el compromiso de la dirección.
• Orientación al cliente.
• Los principios en que se basan ambos referenciales son análogos.
Diferencias entre el modelo EFQM y la norma ISO 9000: 2000
• En general la ISO 9001:2000 se utiliza para la Certificación por tercera

parte, con lo que los requisitos de la norma acaban convirtiéndose en
“prescriptos”.
• El Modelo EFQM de Excelencia se utiliza para la Autoevaluación, o lo
que es lo mismo para poner en marcha planes de mejora. A menos que
la organización decida presentarse al Premio Europeo, u obtener el Sello
Europeo de Excelencia, no es necesario seguir fielmente los criterios. La

redacción de los subcriterios y las áreas abordar, y la posibilidad de

puntuación, lo hacen no prescriptivo.
• El modelo EFQM contempla con mucha más profundidad la orientación a
procesos.
• El modelo permite comparar nuestra organización con otras a partir de la
puntuación obtenida.
Utilización del modelo EFQM y de la norma ISO 9001: 2000
El Modelo EFQM de Excelencia se utiliza en general para la Autoevaluación de

la organización y la puesta en marcha de planes de mejora. También puede
usarse para la concesión del Sello Europeo de Excelencia de reciente creación,
y finalmente para concursar a alguno de los Premios basados en el Modelo, en
especial el Premio Europeo a la Calidad.
La ISO 9001:2000, puede usarse como guía para poner en marcha un Sistema
de Gestión de la Calidad, pero lo normal y común en la mayoría de los casos es
que una vez el Sistema está implantado, el mismo se certifique.
La nueva norma ISO 9001:2000 es compatible con el Modelo EFQM de

Excelencia, y puede considerarse un subconjunto del mismo.
El uso de la Norma deberá ser similar al seguido en los procesos de

Autoevaluación, y no debe quedar en una mera documentación cosmética para
mantener el certificado. Es una responsabilidad de todos los agentes implicados
en el proyecto. Requiere cambios de actitudes, formación intensa en los nuevos
conceptos y a partir de ese conocimiento convencerse de las ventajas y
beneficios que, en términos de gestión y resultados, van a suponer a una
empresa que los adopte.
11.3.4. Marco Común de Evaluación CAF
El Marco Común de Evaluación (CAF, siglas en inglés de Common Assessment

Framework) es un modelo organizativo destinado a obtener un rápido
diagnóstico organizativo para, a partir de éste, elaborar un plan de acción con el
objetivo de lograr organizaciones públicas
excelentes. Este modelo fue el resultado de
la cooperación entre los ministros
responsables de Administración Pública de
la Unión Europea. En la Primera
Conferencia Europea de Calidad para las
Administraciones Públicas, celebrada en
Lisboa en Mayo de 2000, se presentó una
versión piloto del CAF cuya experiencia en
su implantación y uso ha servido de base a
la versión actual.
El CAF está especialmente diseñado para el sector público ya que contempla

aspectos como el liderazgo político y los ciudadanos. Se diseñó para que las
organizaciones públicas de Europa comenzasen a utilizar técnicas de Gestión de
Calidad para mejorar su rendimiento. El CAF proporciona un modelo sencillo y

fácil de usar, apropiado para que las organizaciones del sector público lleven a
cabo una autoevaluación.
El CAF tiene cuatro propósitos principales:
1. Identificar las las fortalezas y debilidades de las organización

2. Servir como herramienta introductoria para que los administradores públicos
comiencen un proceso de mejora continua.
3. Crear la cultura de Calidad así como introducir los diferentes modelos que se
usan en la gestión de calidad total (TQM).
4. Facilitar el benchmarking entre las organizaciones del sector público.
El CAF ha sido diseñado para que pueda utilizarse en todos los ámbitos del
sector público, y tanto en la administración nacional o federal, como en la
regional y local.
Puede aplicarse en diferentes situaciones y circunstancias como, por ejemplo,

formando parte de un programa sistemático de reforma o como base para
orientar los esfuerzos de mejora en organizaciones del sector público. En
algunos casos, y especialmente en organizaciones muy grandes, se pueden
llevar a cabo autoevaluaciones en una parte de la organización, como puede ser
una unidad o departamento.
Hasta la fecha se ha publicado una guías de utilización del CAF (disponible en la

web de la EIPA) y en septiembre de 2006 se ha aprobado la versión 2006 del
Modelo.
La estructura del CAF está inspirada en el Modelo EFQM de Excelencia. Esta

estructura de nueve casillas identifica los principales aspectos a considerar en el
análisis de cualquier organización. Cada una de estas cajas contiene una lista de

criterios. Los criterios identifican los principales aspectos de una organización

que deben ser examinados cuando se realiza una evaluación.
El uso del CAF es libre y proporciona una potente herramienta de diagnóstico

inicial para aquellas organizaciones que comienzan un proceso de mejora
continua.
Comparado con un modelo de Gestión de Calidad Total plenamente

desarrollado, el CAF es un modelo "ligero", especialmente idóneo para obtener
una primera impresión de cómo actúa una organización. Obviamente, cualquier
organización que quiera profundizar más puede seleccionar un modelo más
completo de entre los existentes (tales como el de Speyer o el modelo EFQM).
El CAF tiene la ventaja de ser compatible con estos modelos y puede además
ser un primer paso para una organización que quiera avanzar en la gestión de
calidad.
11.4. CMMI
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un

método de definir y gestionar los procesos a realizar por una organización. Fue
desarrollado inicialmente para los procesos relativos al software por la
Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
El SEI es un centro de investigación y desarrollo patrocinado por el

Departamento de Defensa de los Estados Unidos de América y gestionado por la
Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI. Su
homólogo en Europa es la Fundación ESI (European Software Institute), con
sede en Bilbao (España).
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de

los Estados Unidos de América, desarrolló una primera definición de un modelo
de madurez de procesos en el desarrollo de software, que se publicó en
septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM
for Software), cuya última versión (v1.1) se publicó en febrero de 1993.
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de

modo que una organización que tenga institucionalizadas todas las prácticas
incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de
madurez.
Los niveles son:
1. Inicial. Las organizaciones en este nivel no disponen de un ambiente

estable para el desarrollo y mantenimiento de software. Aunque se
utilicen técnicas correctas de ingeniería, los esfuerzos se ven
minados por falta de planificación. El éxito de los proyectos se basa la
mayoría de las veces en el esfuerzo personal, aunque a menudo se
producen fracasos y casi siempre retrasos y sobre costes. El
resultado de los proyectos es impredecible.

2. Repetible. En este nivel las organizaciones disponen de unas

prácticas institucionalizadas de gestión de proyectos, existen unas
métricas básicas y un razonable seguimiento de la calidad. La
relación con subcontratistas y clientes está gestionada
sistemáticamente.
3. Definido. Además de una buena gestión de proyectos, a este nivel las

organizaciones disponen de correctos procedimientos de
coordinación entre grupos, formación del personal, técnicas de
ingeniería más detalladas y un nivel más avanzado de métricas en los
procesos. Se implementan técnicas de revisión por pares (peer
reviews).
4. Gestionado. Se caracteriza por que las organizaciones disponen de

un conjunto de métricas significativas de calidad y productividad, que
se usan de modo sistemático para la toma de decisiones y la gestión
de riesgos. El software resultante es de alta calidad.
5. Optimizado. La organización completa está volcada en la mejora

continua de los procesos. Se hace uso intensivo de las métricas y se
gestiona el proceso de innovación.
Las organizaciones que utilizan este modelo para mejorar sus procesos
disponen de una guía útil para orientar sus esfuerzos. Además, el SEI
proporciona formación a evaluadores certificados (Lead Assesors) capacitados
para evaluar y certificar el nivel CMM en el que se encuentra una organización.
Esta certificación es requerida por el US DoD, pero también es utilizada por
multitud de organizaciones de todo el mundo para valorar a sus subcontratistas
de software.
Se considera típico que una organización dedique unos 18 meses para

progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso
requiere un amplio esfuerzo y un compromiso intenso de la dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría

de software o, en general, outsourcing de procesos de software, adoptan el
modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de
los países en el que más organizaciones certificadas exista sea India, donde han
florecido las factorías de software que trabajan para clientes estadounidenses y
europeos.
En diciembre de 2000, el SEI publicó un nuevo modelo, el CMMI o "Modelo de

Capacidad y Madurez - Integración", con el objetivo de realizar algunas mejoras
respecto al SW-CMM e integrarlo con el SE-CMM y el IPD-CMM, que pasaban a
ser considerados como "obsoletos".
El CMMI incluye cuatro disciplinas, en función de la amplitud de los procesos

que cubre:
o CMMI-SW : Software
o CMMI-SE/SW : + Ingeniería de sistemas

o CMMI-SE/SW/IPPD : + Desarrollo integrado de procesos y productos

o CMMI-SE/SW/IPPD/SS : + Gestión de proveedores
A su vez se presenta en dos posibles representaciones, "Por niveles" y

"Continua". En el primer caso permite evaluar el nivel de madurez de una
organización en todas las áreas de proceso, mientras que el segundo permite
evaluar el nivel en cada área independientemente.
Las principales diferencias con el SW-CMM, además de la inclusión de las tres

nuevas disciplinas para integrar los tres modelos antiguos, son:
o Pone un mayor énfasis en el uso continuo de métricas

o Insiste en la necesidad de la trazabilidad desde los requerimientos al
producto final
o Desglosa y detalla las áreas de proceso relativas a la ingeniería
o Cambia el nombre a los niveles 2 y 4 que pasan a llamarse
"gestionado" y "gestionado cuantitativamente".
El SEI ha desarrollado también un nuevo método de evaluación de las

organizaciones según CMMI denominado SCAMPI.
11.5. PMBOK
Los Fundamentos de la Dirección de Proyectos constituyen la suma de

conocimientos en la profesión de dirección de proyectos. Al igual que en otras
profesiones, como la abogacía, la medicina o las ciencias económicas, los
conocimientos residen en los practicantes y académicos que los aplican y los
desarrollan. Los Fundamentos de la Dirección de Proyectos completos incluyen
prácticas tradicionales comprobadas y ampliamente utilizadas, así como
prácticas innovadoras que están emergiendo en la profesión, incluyendo material
publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección
de Proyectos están en constante evolución.
El Project Management Institute (PMI®) es considerado la asociación profesional

para la gestión de proyectos sin fines de lucro más grande del mundo, con más
de 260.000 miembros en 171 países. Entre sus principales objetivos se
encuentran formular estándares profesionales, generar conocimiento a través de
la investigación, y promover la Gestión de Proyectos como profesión a través de
sus programas de certificación.
La Guía del PMBOK® (Project Management Body of Knowledge) es un estándar

en la gestión de proyectos desarrollado por el Project Management Institute.
En 1987, el PMI publicó la primera edición del PMBOK® en un intento por

documentar y estandarizar información y prácticas generalmente aceptadas en
la gestión de proyectos. La edición actual, la tercera, provee de referencias
básicas a cualquiera que esté interesado en la gestión de proyectos. Posee un
léxico común y una estructura consistente para el campo de la gestión de
proyectos.

El PMBOK es una colección de procesos y áreas de conocimiento generalmente

aceptadas como las mejores prácticas dentro de la gestión de proyectos. El
PMBOK en un estándar reconocido internacionalmente (IEEE Std 1490-2003)
que provee los fundamentos de la gestión de proyectos que son aplicables a un
amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.
El 'PMBOK' reconoce 5 procesos básicos y 9 áreas de conocimiento comunes a

casi todos los proyectos.
Los procesos se traslapan e interactúan a través de un proyecto o fase. Los
procesos son descritos en términos de: Entradas (documentos, planes, diseños,
etc.), Herramientas y Técnicas (mecanismos aplicados a las entradas) y Salidas
(documentos, productos, etc.). Las nueve áreas del conocimiento mencionadas
en el PMBOK son:
1. Gestión de la Integración de Proyectos,

2. Gestión del Alcance en Proyectos,
3. Gestión del Tiempo en Proyectos,
4. Gestión de la Calidad en Proyectos,
5. Gestión de Costos en Proyectos,
6. Gestión del Riesgo en Proyectos,
7. Gestión de Recursos Humanos en Proyectos,
8. Gestión de la Comunicación en Proyectos, y
9. Gestión de la Procura (Logística) en Proyectos.
Anexo V: Ciclo de vida del producto y del proyecto.
12. Anexo V: Ciclo de vida del producto

y del proyecto.
12.1. Ciclo de vida del producto
El ciclo de vida de un producto es un concepto asociado a las técnicas de la

mercadotecnia o marketing. Las condiciones bajo las que un producto se va a
vender van a cambiar a lo largo del tiempo. La gestión del ciclo de vida de un
producto se refiere a la consideración de los diferentes estados que va a
atravesar un producto a lo largo de su existencia. La tecnología que subyace en
un producto o categoría de producto puede atravesar etapas similares.
Ilustración 60. Etapas del ciclo de vida de un producto
Los productos suelen atravesar cinco etapas:
1. Etapa de desarrollo de un nuevo producto:

• es muy caro
• no se perciben ingresos por venta
• es un periodo de pérdidas netas
2. Etapa de introducción en el mercado
• supone un coste muy alto
• el nivel de ventas es bajo
• el balance es de pérdidas netas
3. Etapa de crecimiento
• se reducen los costes debido a la realización de economías de
escala
• los volúmenes de ventas aumentan significativamente

• se empiezan a percibir beneficios
4. Etapa de madurez
• los costes son muy bajos
• se alcanzan los niveles máximos de ventas
• los precios tienden a caer debido a la proliferación de productos
competitivos
• se alcanza la mayor rentabilidad
5. Etapa de decadencia
• las ventas caen
• los precios bajan
• los beneficios se reducen
12.2. Ciclo de vida del Proyecto
El ciclo de vida del proyecto define las fases que conectan el inicio de un
proyecto con su fin. La transición de una fase a otra dentro del ciclo de vida de
un proyecto generalmente implica y, por lo general, está definida por alguna
forma de transferencia técnica. Generalmente, los productos entregables de una
fase se revisan para verificar si están completos, si son exactos y se aprueban
antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que
una fase comience antes de la aprobación de los productos entregables de la
fase previa, cuando los riesgos involucrados se consideran aceptables.
No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal
de un proyecto. Algunas organizaciones han establecido políticas que
estandarizan todos los proyectos con un ciclo de vida único, mientras que otras
permiten al equipo de dirección del proyecto elegir el ciclo de vida más
apropiado para el proyecto del equipo. Asimismo, las prácticas comunes de la
industria a menudo conducen a usar un ciclo de vida preferido dentro de dicha
industria.
Los ciclos de vida del proyecto generalmente definen:
• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué
fase se debe realizar el trabajo del arquitecto?)
• Cuándo se deben generar los productos entregables en cada fase y
cómo se revisa, verifica y valida cada producto entregable
• Quién está involucrado en cada fase (por ejemplo, la ingeniería
concurrente requiere que los implementadores estén involucrados en las
fases de requisitos y de diseño)
• Cómo controlar y aprobar cada fase.
Las descripciones del ciclo de vida del proyecto pueden ser muy generales o
muy detalladas. Las descripciones muy detalladas de los ciclos de vida pueden
incluir formularios, diagramas y listas de control para proporcionar estructura y
control.
La mayoría de los ciclos de vida de proyectos comparten determinadas

características comunes:
• En términos generales, las fases son secuenciales y, normalmente, están

definidas por alguna forma de transferencia de información técnica o
transferencia de componentes técnicos.
• El nivel de coste y de personal es bajo al comienzo, alcanza su nivel
máximo en las fases intermedias y cae rápidamente cuando el proyecto
se aproxima a su conclusión.
Ilustración 61. Coste del proyecto y nivel de personal típicos a lo largo del ciclo de vida
del proyecto
• El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no

cumplir con los objetivos es más elevado al inicio del proyecto. La certeza
de terminar con éxito aumenta gradualmente a medida que avanza el
proyecto.
• El poder que tienen los interesados en el proyecto para influir en las
características finales del producto del proyecto y en el coste final del
proyecto es más alto al comienzo y decrece gradualmente a medida que
avanza el proyecto. Una de las principales causas de este fenómeno es
que el coste de los cambios y de la corrección de errores generalmente
aumenta a medida que avanza el proyecto.
Ilustración 62. Influencia de los interesados a lo largo del tiempo

Por lo general, una fase del proyecto concluye con una revisión del trabajo
logrado y los productos entregables, a fin de determinar la aceptación, tanto si
aún se requiere trabajo adicional como si se debe considerar cerrada la fase.
Con frecuencia, la dirección lleva a cabo una revisión para tomar una decisión a
fin de comenzar las actividades de la siguiente fase sin cerrar la fase actual, por
ejemplo, cuando el director del proyecto elige la ejecución rápida como curso de
acción. Cuando una compañía de tecnología de la información elige un ciclo de
vida iterativo donde más de una fase del proyecto puede avanzar de forma
simultánea. Los requisitos de un módulo se pueden recopilar y analizar antes de
que el módulo sea diseñado y construido. Mientras se lleva a cabo el análisis de
un módulo, se puede comenzar a recopilar los requisitos de otro módulo de
forma paralela.
Ilustración 63. Secuencia de fases típica en un ciclo de vida del proyecto
12.3. Relaciones del ciclo de vida del proyecto y del ciclo de vida del
producto
Las fuerzas impulsoras que crean los estímulos para un proyecto se conocen
habitualmente como problemas, oportunidades o requisitos de negocio. El efecto
de estas presiones es que, en general, la dirección debe priorizar esta solicitud
con respecto a las necesidades y a las demandas de recursos de otros posibles
proyectos.
Ilustración 64. Relación entre el ciclo de vida del producto y el ciclo de vida del proyecto
La figura anterior ilustra el ciclo de vida del producto que comienza con el plan
de negocio, pasa por la idea, hasta llegar al producto, las operaciones y la
retirada del producto. El ciclo de vida del proyecto atraviesa una serie de fases
para crear el producto. Proyectos adicionales pueden incluir una actualización
del rendimiento del producto. En algunas áreas de aplicación, tales como el
desarrollo de nuevos productos o el desarrollo de software, las organizaciones
consideran el ciclo de vida del proyecto como parte del ciclo de vida del
producto.
Anexo VI: Glosario
13. Anexo VI: Glosario

Alianzas
Colaboración con otra parte sobre una base comercial o no comercial con el fin
de alcanzar una meta común.
Altos cargos
Políticos y órganos superiores del Gobierno y la Administración que establecen,
ordenan y controlan las organizaciones de la administración pública.
Auditoría
Auditar es una función valorativa independiente que examina y evalúa la
actividad de una organización y sus resultados. Las auditorías más comunes
son: financiera, operativa, de tecnologías de la información y comunicaciones, de
conformidad y de gestión. Se pueden distinguir tres niveles de control auditor:
• Control interno ejercido por la dirección.
• Auditoria interna realizada por una unidad independiente de la
organización. Entre otras cosas, controlará la eficacia de la gestión
interna de la organización.
• Auditoría externa realizada por un órgano independiente externo a la
organización.
Benchmarking
Dos o más participantes realizan comparaciones sistemáticas de los procesos
y/o de los resultados en sus respectivas organizaciones, con el fin de aprender
de las mejores prácticas e implantarlas de la forma más adecuada en sus
organizaciones.
Benchmarking estratégico
El benchmarking estratégico es utilizado cuando una organización quiere
mejorar su rendimiento global evaluando las estrategias a largo plazo y los
enfoques generales que han permitido el éxito a las organizaciones de alto
rendimiento. Comprende las comparaciones de los aspectos de nivel superior,
tales como las competencias centrales, el desarrollo de nuevos productos y
servicios, cambios en el conjunto de sus actividades o una mejora en su
capacidad para gestionar los cambios en el entorno.
Benchmarking de procesos y de resultados

El benchmarking de procesos compara actividades y procesos. El benchmarking
de resultados compara productos, efectos y otros indicadores de resultado tales
como calidad, eficiencia y coste-efectividad (o eficacia de coste). En ambos, su
finalidad es mejorar procesos y operaciones críticos. El benchmarking de
procesos y el de resultados se complementan y ambos son necesarios para
extraer conclusiones sobre las mejores prácticas.
Brainstorming
Herramienta de trabajo en equipo para generar ideas libremente durante un
corto periodo de tiempo. La regla más importante es evitar cualquier tipo de
crítica durante la fase de producción de las ideas.
Anexo VI: Glosario
Calidad
Calidad es una característica de un producto o de un servicio. Se puede medir
directamente como cumplimiento de un estandar o indirectamente por la
apreciación o el impacto en los clientes/ciudadanos. La Gestión de Calidad Total
se centra en los procedimientos y procesos que se consideran decisivos para
promover la calidad.
Cliente/Ciudadano
El término cliente/ciudadano se utiliza para enfatizar la relación dual que
establece la administración pública, por una parte, con los usuarios de los
servicios públicos y, por otra, con todos los miembros del público en general, que
como ciudadanos y contribuyentes tienen un interés en sus servicios y en sus
resultados.
Código de conducta
Reglas y recomendaciones para el comportamiento de un grupo profesional o de
una organización. Los códigos de conducta también pueden referirse a
actividades específicas tales como auditoría o benchmarking.
Coste-efectividad (Eficacia de coste)

La relación entre los efectos derivados de los objetivos de la organización y los
costes - incluyendo el coste social global- para alcanzarlos. Véase también
Eficacia.
Cuadro de mando integral

El cuadro de mando integral es una técnica que utiliza indicadores para evaluar
una organización desde diferentes puntos de vista estratégicos. El modelo se
basa fundamentalmente en la importancia de establecer un equilibrio entre
metas a corto y largo plazo, estabilidad y cambio, así como en procesos internos
y las relaciones con los interesados externos.
DAFO
Análisis de las Debilidades, Amenazas (dificultades potenciales), Fortalezas y
Oportunidades (ventajas potenciales) de una organización.
Economía
Economía y economizar se refieren al ahorro de dinero, al comprar más barato,
etc. sin hacer referencia a los productos o a los objetivos.
Efecto (Outcome)
El impacto (o efecto) que los productos (outputs ) tienen en la sociedad.
Eficacia
Eficacia es la relación entre los objetivos establecidos y el impacto, efecto o
resultado alcanzados.
Eficiencia
Relación entre productos (outputs) y entradas/insumos (inputs) o costes.
También puede referirse a productividad. La productividad puede medirse en
términos de insumos de todos los factores de producción (productividad total de
Anexo VI: Glosario
todos factores) o de un factor específico (productividad del trabajo o

productividad del capital).
Empowerment (Asunción de responsabilidades/Facultamiento)

Proceso por el cual se proporciona mayor capacidad de influencia a un grupo de
personas (por ejemplo, a los ciudadanos o a los empleados) a través de su
participación en el proceso de toma de decisiones, cediendo autonomía, etc.
Encuesta
Recogida de datos sobre opiniones, actitudes o conocimiento de individuos y
grupos. Generalmente sólo se pregunta a una muestra representativa de toda la
población.
Estrategia
Plan de acción para alcanzar los objetivos de una organización.
Evaluación
Examinar con el fin de comprobar si las acciones llevadas a cabo han
proporcionado los efectos deseados y si con la realización de otras acciones se
habrían alcanzado mejores resultados a menor coste.
Factor Crítico de Éxito

Actividades clave o resultados cuyo rendimiento satisfactorio es esencial para el
éxito de la organización.
Flujo ascendente
Dirección por la que fluye la información o las decisiones desde los niveles más
bajos de la organización a los más altos. Lo contrario sería flujo descendente.
Flujo descendente
Flujo de información y decisiones desde los niveles superiores de una
organización a los inferiores. Lo contrario sería flujo ascendente.
Gestión de calidad total

Una filosofía de gestión centrada en el cliente que busca la mejora continua de
los procesos, utilizando herramientas analíticas y equipos de trabajo donde
participan todos los empleados. Hay varios modelos de Gestión de Calidad
Total; el Modelo EFQM, el de Speyer, el Malcolm Baldrige y las normas ISO
9000, son los más utilizados.
Gestión del cambio

La gestión del cambio entraña tanto la generación de los cambios necesarios en
una organización como el dominio de su dinámica mediante la organización, la
implantación y el apoyo al cambio.
Gestión de los recursos humanos

Gestionar, desarrollar y utilizar el conocimiento y todo el potencial de los
empleados de una organización con el fin de apoyar la política y los planes de la
organización y la gestión eficaz de sus procesos.
Anexo VI: Glosario
Indicador
Medida indicativa de un fenómeno. No mide el fenómeno en sí mismo sino de
forma indirecta.
Indicador de percepción
Medida subjetiva sobre un fenómeno, por ejemplo, la percepción de los clientes
sobre la calidad de un producto o servicio.
Insumo/Entrada (Input)
Cualquier clase de recurso utilizado para la producción.
Interesados
Interesados son todos aquellos que tienen un interés, sea financiero o no, en las
actividades de la organización; por ejemplo, clientes, ciudadanos, empleados,
público en general, organismos de inspección, medios de comunicación,
proveedores, etc. Los Altos cargos, como el Gobierno, representado por líderes
electos (o nombrados), y los órganos superiores de la administración también
son interesados. No todos los interesados están en el mismo plano de igualdad.
Liderazgo
Cómo los líderes desarrollan y facilitan la consecución de la misión y visión,
desarrollan los valores necesarios para alcanzar el éxito a largo plazo e
implantan todo ello en la organización mediante las acciones y los
comportamientos adecuados, estando implicados personalmente en asegurar
que el sistema de gestión de la organización se desarrolla e implanta
Largo plazo
Generalmente se refiere a periodos de 5 a 10 años o más.
Mapa de procesos
Representación gráfica de una serie de acciones que tienen lugar dentro de un
proceso.
Medio plazo
Generalmente se refiere a periodos de 2 a 5 años.
Mejores prácticas
Un rendimiento superior o métodos o enfoques que conducen a un rendimiento
sobresaliente. Mejor práctica es un término relativo que a veces indica
innovación o prácticas interesantes que han sido identificadas a través de
actividades de benchmarking. En algunos casos se prefiere hablar de "buenas
prácticas" cuando no se está seguro de que no haya alguna mejor.
Meta
Nivel de resultados (producto, efecto, calidad, eficiencia, etc.) que debe ser
alcanzado. Las metas pueden incluir fines y objetivos establecidos por las
autoridades gubernamentales o por la propia organización.
Meta a corto plazo

Metas que pueden ser alcanzadas en un corto periodo de tiempo, generalmente
en menos de un año.
Anexo VI: Glosario
Misión
La razón de existir de una organización.
Objetivo operativo
La formulación más concreta de un objetivo en el nivel de unidad. Un objetivo
operativo puede ser transformado automáticamente en actividades.
Organizaciones públicas
Una organización pública es cualquier institución, organización o sistema de
servicios que funciona bajo una dirección política y es controlada por un
gobierno electo (nacional, federal, regional o local). Puede incluir organizaciones
que trabajan en el desarrollo de políticas públicas y el cumplimiento de la ley,
cosas que en puridad no pueden considerarse servicios.
Política
Una política es la combinación de una meta y los medios para alcanzarla.
Proceso
Un proceso se define como un conjunto de actividades que transforman un
conjunto de entradas en productos o efectos, añadiendo valor. En
organizaciones de sector público, la naturaleza de los procesos puede variar
desde actividades relativamente abstractas como las de apoyo al desarrollo de
las políticas o la regulación de las actividades económicas, hasta actividades
muy concretas como las de prestación de servicios.
Proceso de mejora continua

La participación de todos los miembros de una organización en la mejora
continua de los procesos en términos de calidad, economía o tiempo de ciclo.
Producto (Output)
El resultado inmediato de la producción. Puede referirse tanto a bienes como a
servicios. Se distingue entre productos intermedios y finales. Los primeros son
los productos proporcionados por un departamento a otro dentro de una
organización; los segundos son los entregados a alguien de fuera de la
organización.
Red
Una organización informal que conecta personas u organizaciones que no están
obligadas a conectarse formalmente. A menudo, los miembros de una red
comparten valores e intereses.
Reingeniería de procesos
Replanteamiento sistemático de los procesos de producción, distribución, de
márketing, etc. de una organización para mejorar el rendimiento.
Resultados en los clientes/ciudadanos

Logros de la organización en relación con sus clientes, tales como cubrir sus
necesidades o atender sus demandas. También puede incluir la satisfacción de
los clientes/ciudadanos o la disposición a pagar.
Anexo VI: Glosario
Seguimiento
Después de un proceso de autoevaluación y de la introducción de cambios en la
organización, se realiza un seguimiento para medir la consecución de los
objetivos y sobre esta base lanzar nuevas iniciativas y eventualmente formular
estrategias y planes más ajustados a las nuevas circunstancias.
Valor
El valor se refiere a los valores monetarios, de bienestar, culturales y morales.
Los valores morales son más o menos universales, mientras que los valores
culturales pueden variar de una organización a otra y de un país a otro. Los
valores culturales dentro de una organización deben estar en relación con su
misión. Pueden ser muy diferentes entre organizaciones sin ánimo de lucro y
empresas privadas.
Visión
El sueño (factible) de lo que una organización desea hacer y hacia dónde quiere
ir.
Anexo VII: Referencias
14. Anexo VII: Referencias

- REAL DECRETO 1545/2007, de 23 de noviembre, por el que se regula el
Sistema Cartográfico Nacional.
- DIRECTIVA 2007/2/CE DEL PARLAMENTO EUROPEO Y DEL CONSEJO
de 14 de marzo de 2007 por la que se establece una infraestructura de
información espacial en la Comunidad Europea (Inspire).
- CAF. EL MARCO COMÚN DE EVALUACIÓN. MINISTERIO DE
ADMINISTRACIONES PÚBLICAS. DIRECCIÓN GENERAL DE
INSPECCIÓN, SIMPLIFICACIÓN Y CALIDAD DE LOS SERVICIOS. 2003
- INSPIRE Implementing Rules for Monitoring and Reporting. EC, Eurostat,
Unit D-2, GISCO
- Detailed definitions on the INSPIRE Network Services. Joint Research
Centre, Institute for Environment and Sustainability, Land Management Unit,
ESDI Action. 2005
- The Socio-Economic Impact of the Spatial Data Infrastructure of Catalonia-
Pilar Garcia Almirall, Montse Moix Bergadà, Pau Queraltó Ros. Universitat
Politècnica de Catalunya Centre of Land Policy and Valuations. M. Craglia
(Editor) European Commission Joint Research Centre Institute for
Environment and Sustainability. 2008
- INSPIRE Network Services Performance Guidelines. Creator European
Commission. Date 13-12-2007
- Services State of Play. Compliance Testing and Interoperability Checking. S.
Viganó TXT e-solutions M. Millot. European Commission DG JRC, Institute
for Environment and Sustainability
- W3C. Web Services Architecture. http://www.w3.org/TR/ws-arch/
- W3C. QoS for Web Services: Requirements and Possible Approaches. W3C
Working Group Note 2003. http://www.w3c.or.kr/kr-office/TR/2003/ws-qos/
- OASIS. Quality Model for Web Services.
http://www.oasisopen.org/committees/download.php/15910/WSQM-ver-
2.0.doc
- developer.com. Bijay Jayaswal & Peter Patton. Software Quality
Metrics.http://www.developer.com/tech/article.php/3644656.developer.com.
Quality of Service for Web Services—Demystification, Limitations, and Best
- Practices for Performance.
http://www.developer.com/services/article.php/2248251
- IBM. A. Mani, A. Nagarajan. Understanding quality of service for Web
services. Improving the performance of your Web services. http://www-
128.ibm.com/developerworks/library/ws-quality.html
- A. mani, A. Nagarajan. Understanding quality of services for Web
Services.ttp://www.opensourcetutorials.com/tutorials/Server-Side-
Coding/Administration/quality-webservices/page1.html
- KEYNOTE SYSTEMS. Rich Internet Applications: Design, Measurement, and
Management Challenges.
http://www.keynote.com/docs/whitepapers/RichInternet_5.pdf
- Newport Group Inc. ENTERPRISE LOAD TESTING FOR WEB
APPLICATIONS. Developing an Effective Strategy for Optimizing Application
and Infrastructure Performance.
http://www.keynote.com/docs/whitepapers/newportgroup.pdf

Estudio y Evaluación de La IDE. Aplicación de Buenas Prácticas y Modelos de Calidad.

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Estudio y Evaluación de La IDE. Aplicación de Buenas Prácticas y Modelos de Calidad.

Hochgeladen von

Copyright:

Verfügbare Formate

Estudio y evaluación de la IDE.

Master Oficial en Gestión Integral de Tecnologías de la

Trabajo de Fin de Master

Guillermo de Paz López

1. Marco del Trabajo................................................5

Trabajo de Fin de Master

1. Marco del Trabajo

1.1. Contenido del documento

Además de este primer capítulo introductorio, el presente trabajo queda estructurado

Capítulo 2: MARCO POLÍTICO Y TECNOLÓGICO.

Capítulo 3: BASES PARA EL DESARROLLO DE LA IDE.

Trabajo de Fin de Master

Con el objetivo de comprender el sentido y la complejidad de la IDE, en este capítulo

Capítulo 4: MARCO DE EVALUACIÓN DE LA IDE.

Capítulo 5: ESTUDIO PARA LA IMPLANTACIÓN DE MEJORES PRÁCTICAS Y

Capítulo 6: PLAN DE COLABORACIÓN DE LA EMPRESA PRIVADA PARA EL

Capítulo 7: PROYECTO PARA EL DESARROLLO DE UNA PLATAFORMA DE

Anexo I: BASE TECNOLÓGICA DE LA IDE.

Anexo II: GEOSERVICIOS IDE.

Trabajo de Fin de Master

Anexo III: SIG CORPORATIVO vs. IDE

Anexo IV: Resumen de Mejores Prácticas, Gestión de Calidad y Estándares

Anexo V: Ciclo de vida del producto y del proyecto

Anexo VI: Glosario

Anexo VII: Referencias

Trabajo de Fin de Master

Marco Político y Tecnológico

2. Marco Político y Tecnológico

El primero presentar el porqué y los orígenes de la IDE que han sido de

2.1. Marco Político

Además de la Directiva europea INSPIRE y el REAL DECRETO 1545/2007, de

Estos derechos hacia los ciudadanos obligan a las distintas administraciones

La Administración Electrónica, y todos los servicios que integra, son parte

Trabajo de Fin de Master

Marco Político y Tecnológico

2.2. Redes Colaborativas

Para cumplir los objetivos señalados anteriormente, la administración pública al

Ilustración 1. Impulsores de la cooperación organizacional

Trabajo de Fin de Master

Marco Político y Tecnológico

Ilustración 2. Factores impulsores de una red colaborativa

Ilustración 3. Evolución de una red. Requerimientos de interoperabilidad (Franco,

La representación esquemática del marco de referencia planteado por Franco y

Trabajo de Fin de Master

Marco Político y Tecnológico

Ilustración 4. Un marco para la clasificación de formas organizativas en red

2.3. Concepto de IDE

Una IDE (Infraestructura de Datos Espaciales) es un sistema informático

El establecimiento de una IDE, a nivel local, regional, estatal o global, requiere

2.4. Evolución histórica de la IDE

El concepto de IDE partió de la necesidad de gestionar la información

Trabajo de Fin de Master

Marco Político y Tecnológico

La Comisión Europea planteó la necesidad de “una política que cree un entorno

La Dirección General de Medio Ambiente y Eurostat promovieron la constitución

En su reunión de 17.12.2001 en Viena el Grupo de Expertos estableció 5 Grupos

Trabajo de Fin de Master

Marco Político y Tecnológico

legislativo y operativo para poner en marcha la Infraestructura de Datos

o Datos de Referencia y Metadatos.

El resultado del trabajo de estos Grupos se concretó en los “Position Papers”

Política de Datos y Asuntos Legales.

Los principios estratégicos establecidos son:· Papel de las IDEs