Creación de un prototipo de software basado en el
componente de Autoevaluación institucional del Modelo
Estándar de Control Interno MECI
Jorge Enrique Castro Pescador
Especialización en ingeniería de Software Universidad Dsitrital Francisco José de Caldas
Creación de un prototipo de software basado en el
componente de Autoevaluación institucional del Modelo
Estándar de Control Interno MECI
Jorge Enrique Castro Pescador
Director
Alexandra Abuchar Porras
RevisorJosé Ignacio Palacios
Especialización en ingeniería de Software Universidad Dsitrital Francisco José de Caldas
Índice
Introducción 4
I Contextualización de la investigación 5
1. Descripción de la investigación 5
1.1. Titulo . . . 5
1.2. Definición . . . 5
2. Estudio del problema de investigación 6 2.1. Planteamiento del problema . . . 6
2.2. Formulación del problema . . . 6
2.3. Sistematización del problema . . . 6
3. Objetivos de la investigación 8 3.1. Objetivo general . . . 8
3.2. Objetivos específicos . . . 8
4. Justificación de la Investigación 9 4.1. Justificación practica . . . 9
II Desarrollo de la investigación 28
7. Análisis de la información 28
7.1. Entrevistas . . . 28
8. Diseño de la Arquitectura Empresarial 31 9. Punto de vista del negocio 31 9.1. Punto de vista de la organización . . . 31
10.Punto de vista de la aplicación 41 10.1. Punto de vista de comportamiento de aplicación . . . 41
13.Extensión de Implementación y Migración 62 13.1. Punto de vista de proyecto . . . 62
13.2. Punto de vista de migración . . . 63
13.3. Punto de vista de migración e implementación . . . 64
15.Desarrollo del plan de trabajo bajo Scrum 67
III Cierre de la investigación 90 18.Resultados y discusión 90 19.Conclusiones 90 19.1. Aportes Originales . . . 91
19.2. Trabajos o publicaciones derivadas . . . 91
20.Prospectiva del trabajo de grado 91 20.1. Trabajos de investigación futuros . . . 91
Bibliografia 93 21.Anexos 94 21.1. Anexo 1 - Formato de entrevistas realizadas . . . 94
Introducción
La presente investigación tiene como objetivo abordar el problema que surge a partir de encontrar un mecanismo confiable y cómodo para la realización del proceso de autoevaluación institucional en aquellas entidades que implementen un modelo estándar de control interno, como área encargada de la medición y el seguimiento de los planes de acción, metas y en general, el ente de regulación por defecto a nivel interno de una organización de carácter descentralizado.
Siguiendo y tomando como base la definición del área, de sus funciones y los lineamientos que debe seguir, vigilados y presentes a la luz de la normatividad colombiana, se establecen ciertos mecanismos de medición y evaluación como el Modelo Estándar de Control Interno. Sin embargo, no se encuentran definidos en su totalidad y dependen de implementaciones concretas de software que cada entidad decide realizar según sus características particulares. Es de interés de la investigación encontrar un solución que pueda ser generalizada y apli-cada a varios contextos posibles conformar en lo posible un prototipo de software que pueda utilizarse a partir de éste estándar.
Por esto, esta investigación pretende hacer uso de la disciplina de la ingeniería de software para el levantamiento de requerimientos, definición de arquitectura empresarial del proceso, el uso de metodologías de desarrollo de software conocidas y consulta sobre los marcos de trabajo y herramientas tecnológicas que permitan solucionar el problema.
El problema de investigación que se espera resolver es la automatización del proceso debido a que generalmente se realiza de forma manual o con el uso de múltiples herramientas no integradas para la realización, consolidación, y análisis de resultados de las evaluaciones que puede llevar en los retrasos de entrega de los resultados.
Esto se considera una propuesta favorable debido a que actualmente el concepto de invertir en una infraestructura tecnológica y de sistemas de información como apoyo en estos procesos suele ser de gran ayuda para la organización que desea que aquellas tareas que sean repetitivas o que presenten dificultades puedan ser solucionadas. La ingeniería de software como disciplina fundamental para este paso se realiza con rigurosidad y metodología.
Parte I
Contextualización de la investigación
1.
Descripción de la investigación
1.1. Titulo
Creación de un prototipo de software basado en el componente de Autoevaluación insti-tucional del Modelo Estándar de Control Interno MECI
1.2. Definición
El componente de autoevaluación institucional es de gran interés para las entidades que buscan mecanismos adicionales a los ya establecidos para la medición de la gestión pública [6]. A nivel interno este componente puede ser útil para la toma de decisiones y conocer el estado de los planes y políticas en la organización. En el nivel externo, como herramienta de apoyo para la presentación de informes de gestión a entes de control nacional que se establecen según el tipo de entidad.
El tema de investigación se encuentra orientado al componente de autoevaluación institu-cional, un componente que pertenece al modulo de Control de evaluación y seguimiento del MECI, dentro de toda la estructura del estándar que comprende otros módulos y componentes definidos.
Modelo Estándar de Control Interno MECI. • Módulo Control de Evaluación y Seguimiento.
◦ Componente Autoevaluación Institucional. Autoevaluación del Control y Gestión.
En Colombia, existe un fundamento legal que soporta este control y son conocidas como contralorías de orden en el Distrito capital y a nivel Nacional. Existen implementaciones en sistemas de software que soportan la presentación de los informes y herramientas creadas por el estado y su funcionamiento se emplea para el control general en el nivel externo, pero a nivel interno cada organización es responsable de decidir si desea soportar sus procesos en estas tecnologías.
Aquellas organizaciones que no desean soportar este proceso tienden a hacerlo de forma manual, y es necesario que se les otorgue una herramienta con las tendencias tecnológicas actuales para que sus tareas, generalmente operativas, puedan ser automatizadas y el enfoque de los involucrados cambie derealizar estas tareas abuscar mecanismos de mejora del propio procesoesto con el fin de reorientar las actividades de los analistas del área y a la vez promover una cultura hacia la autoevaluación donde implique que realizar la evaluación sea algo fácil, cómodo y motivador.
2.
Estudio del problema de investigación
2.1. Planteamiento del problema
La evaluación acerca del cumplimiento de los objetivos de una organización siempre se ha considerado como un punto fundamental en las organizaciones maduras que buscan medir sus procesos y el nivel de avance de sus proyectos, estos procesos de medición interna general-mente se realizan de forma conjunta e implican a todos los involucrados en la organización. Actualmente es visto como un proceso sistematizado secuencial y que genera resultados luego de que la evaluación se realice y todos los resultados parciales por área o por proceso sean organizados y tabulados.
Un problema que surge a partir de esto es cuando la organización no tiene alineado este proceso con las tecnologías de información, evidenciando que el proceso de consolidación de la información y la obtención de los resultados es realizada manualmente y no existe un mecanismo de comunicación conveniente entre los actores del proceso, causando en el futuro retrasos en los resultados para las áreas que lo requieren, como las que llevan a cabo un rol en el mejoramiento continuo de la entidad (planeación, control interno, dirección general), posibles inconsistencias en los resultados, búsqueda de personal adicional temporal para agilizar el proceso y un retraso en la presentación de los informes de gestión a entes de control cuando al entidad es de carácter descentralizado.
Las decisiones a tomar para controlar parte de este problema incluye la alineación del proceso con las tecnologías de la información, dado que éste puede verse de forma estructurada, la consolidación de evaluaciones, resultados, cronograma del proceso y comunicación entre los involucrados pueden ser modelados en un sistema de software que permitirá realizar los subprocesos operativos con precisión y rapidez. La ingeniería de software entonces, proveerá de las metodologías para solucionar este problema y los mecanismos para el levantamiento de la información, las técnicas para el modelado del sistema de software, los detalles para la puesta en producción, alineación con los procesos existentes de la empresa y las practicas para el uso de interfaces de interacción de los usuarios y la herramienta.
De esta forma se facilita a los participantesobviar los detalles de éstas tareas y mantener la prioridad en enfocarse en cómo mejorar el proceso y el propio mecanismo de evaluación.
2.2. Formulación del problema
¿De que forma los entes involucrados en una organización que usan el modelo estándar de control interno se verán afectados de la implementación de un prototipo que automatice los procesos operativos para la autoevaluación institucional?
2.3. Sistematización del problema
3.
Objetivos de la investigación
3.1. Objetivo general
Construir un prototipo de herramienta basado en el componente de Autoevaluación insti-tucional del Modelo Estándar de Control Interno MECI bajo el enfoque de encuesta adoptado por diversas entidades de carácter Descentralizado, mediante la definición de la arquitectura empresarial del proceso particular con el fin de proporcionar un mecanismo confiable acerca de los indicadores de gestión relevantes para éstas organizaciones.
3.2. Objetivos específicos
1. Describir el proceso de Autoevaluación institucional basado en el modelo estándar de control interno MECI, mediante la definición del marco teórico, conceptual y la recolec-ción de la informarecolec-ción de especialistas de control interno, que otorgue el insumo inicial para identificar el contexto del problema.
2. Diseñar la arquitectura empresarial orientada al proceso de negocio de la autoevaluación institucional gestionada por el área de control interno de la organización utilizando una metodología de desarrollo de arquitecturas ADM con el fin de expresar una definición de requerimientos acertada para la descripción del prototipo a construir.
4.
Justificación de la Investigación
4.1. Justificación practica
Establecer un mecanismo de autoevaluación en las entidades publicas surge a partir de realizar un seguimiento a la gestión pública y los recursos que se destinan, utilizando herra-mientas que permitan medir la gestión realizada y cuyos indicadores sean transparentes y apoyen a las entidades reguladoras, el cómo se ejecutan en proyectos y planes, y la búsqueda de resultados que apoyen la toma de decisiones debe siempre buscar la mejora de los proyectos realizados con los recursos disponibles que aporta la misma sociedad y cuyo fruto debe ser beneficioso para ella[1].
Dentro de este conjunto de herramientas esta la autoevaluación institucional como un mecanismo de medición interno en cada organización.
5.
Marco de referencia
5.1. Marco Teórico
5.1.1. Antecedentes y estado actual
Las primeras definiciones sobre la necesidad de una regulación a las entidades publicas se formalizan en la normatividad colombiana desde 1993 y una serie de reformas y actualizaciones en la cual la versión del MECI actual corresponde a la del año 2014. Desde entonces, la norma ha buscado expresar las políticas y lineamientos que cumplan tanto en una escala de toda la estructura administrativa[7], como de forma interna de cada organización orientándola a cumplir sus propósitos misionales, en un enfoque de control y seguimiento.
Debido a que es modelo definido y presentado en un marco legal, es de carácter obliga-torio que cada entidad publica o perteneciente al estado lo adopte, generalmente en un área organizacional de la empresa como las áreas u oficinas de Control Interno: “El Modelo Es-tándar de Control Interno debe ser aplicado por todos los organismos y organizaciones de las Ramas del Poder Público en sus diferentes órdenes y niveles, por la organización electoral, los organismos de control, los establecimientos públicos, las empresas industriales y comerciales del Estado, las sociedades de economía mixta en las cuales el Estado posea el 90 % o más de capital social, el Banco de la República y los fondos de origen presupuestal.”[7]
Este modelo se ha caracterizado por adoptar una estructura organizativa en módulos, cada uno de los módulos se enfoca en un componente de planeación y gestión, de evaluación y seguimiento, y de comunicación. Los elementos de cada modulo se vienen actualizando sobre cada implementación del MECI, conformando versiones del estándar con el identificador del año a partir del regimiento de la actualización. Durante la implementación concreta, se han presentado dos versiones formales, 2005 y 2014, en las cuales se busca mejorar los elementos, actualizarlos o realizar modificaciones de los mecanismos de seguimiento, todos los cambios vienen dados por el conjunto de organismos de definen el estándar que anualmente se encuentran realizando revisiones a partir de informes y evidencias de las entidades que lo ponen en práctica.
5.1.2. Modelo Estándar de Control Interno
En Colombia, el Modelo Estándar de Control Interno, surge como un esfuerzo por crear una herramienta de apoyo para el control a la gestión publica, mediante mecanismos de evaluación y seguimiento que permitan, de forma generalizada, ser aplicables para todas las entidades públicas, y que posibiliten un medio de regulación del estado a estas entidades.
Es por esto que el departamento Administrativo de la Función Publica, con la colaboración de la academia, el Comité Interinstitucional de Control Interno Nacional-CICINAL, organis-mos de control y el Instituto de Auditores Internos II, [5, 7] determinar mediante una serie de decretos, actualizaciones, normas y estándares las características que deben encontrarse presentes en el control interno de las entidades y los diferentes enfoques implementales que pueden usarse para lograr estos indicadores de medición.
Figura 5.1: Estructura MECI 2014 [7]
Con el objetivo de medir elcumplimiento de objetivos organizacionales,el MECI establece una estructura compuesta de dos módulos, seis componentes y trece elementos en un esquema gráfico (Fig 5.1)
ESTRUCTURA DEL MODELO ESTÁNDAR DE CONTROL INTERNO
1. Módulo de Control de Planeación y Gestión a) Componente Talento Humano
1) Acuerdos compromisos y protocolos éticos 2) Desarrollo de talento humano
b) Componente Direccionamiento Estratégico
1) Planes, programas y proyectos 2) Modelo de operación por procesos 3) Estructura organizacional
4) Indicadores de gestión 5) Políticas de operación
c) Componente Administración del Riesgo
1) Politicas de administración del riesgo 2) Identificación del riesgo
3) Análisis y valoración del riesgo 2. Módulo Control de Evaluación y Seguimiento.
a) Componente Autoevaluación Institucional
b) Componente de Auditoría Interna
1) Auditoría interna
c) Componente Planes de Mejoramiento
1) Plan de mejoramiento
3. Eje Transversal Información y Comunicación a) Información y comunicación interna y externa
b) Sistemas de información y comunicación
cuyo objetivo es proporcionar un modelo para definir la estructura, autoridad y responsabi-lidad del área de control interno, identificar y analizar riesgos, establecer las actividades de control, realizar una evaluación continua, comunicar y evaluar las deficiencias y servir de apo-yo a los sistemas de gestión de calidad de la entidad. Asimismo busca cumplir con elprincipio de autogestión, es decir establecer acciones de la entidad a garantizar su función, verificarse y evaluarse a si misma, mantener una organización en sus procesos y otorgarle un sistema de comunicación con los departamentos que la vigilan y la regulan.
5.1.3. Marco conceptual de arquitectura empresarial
En la actualidad, muchas organizaciones han dado de cuenta lo necesario de integrar su negocio con las Tecnologías de la Información y la comunicación como un factor clave en el éxito del negocio, esto es posible lograrlo con la construcción de un contexto estratégico para la evolución de los sistemas de información en respuesta a las necesidades cambiantes.
Por esto, una arquitectura empresarial permite alcanzar el balance correcto entre la efi-ciencia de las Tecnologías de la Información y la innovación del negocio. El rol del Arquitecto de Software, quien define una arquitectura empresarial, es identificar como los implicados (stakeholders) y cómo los requerimientos que tengan deben ser conducidos durante desarrollo del sistema[9].
Las arquitecturas empresariales proveen una descripción formal del sistema tanto en sus propiedades estructurales como comportamentales y su evolución, y proveen un plan sobre como los productos pueden ser desarrollados y como van a ser integrados en todo el siste-ma. El uso de Marcos de Trabajo como un conjunto de estructuras fundamentales permite la construcción de arquitecturas empresariales concretas, a partir de una metodología para diseñar el estado objetivo, estos marcos de trabajo contienen un conjunto de elementos, una semántica definida y pueden adoptar uno más estándares.
5.1.4. The Open Group Architecture Framework
y mantener un conjunto de arquitecturas empresariales, por esto se tienen las bondades de un marco de trabajo estándar que incentiva el reuso de modelos y diseños arquitectónicos.
5.2. Revisión sucinta sobre el lenguaje de arquitectura empresarial
5.2.1. Especificación de Archimate
Archimate define un marco de trabajo para el modelado de arquitecturas empresariales incorporando un paradigma orientado al servicio que propone un principio organizativo en términos del negocio, aplicación e infraestructura. Archimate provee una representación uni-forme en términos de diagramas que describe la arquitectura empresarial y permite organizar los diferentes dominios y sus relaciones y dependencias[10].
Figura 5.2: Metamodelos a diferentes niveles de especificidad
El “core” del lenguaje consiste en tres tipos primarios de elementos: elementos de estruc-tura activa, elementos de comportamiento y elementos de estrucestruc-tura pasiva; los elementos de estructura activa se definen como entidades que son capaces de desempeñar algún comporta-miento; los elementos de comportamiento son definidos como unidades de actividad desempe-ñadas por uno o mas elementos de estructura activa; los elementos de estructura pasiva son definidos como los objetos en los cuales el comportamiento es realizado.
Figura 5.3: Estructura del Marco de Trabajo
represen-tarse como objetos físicos. Estos son tres aspectos: una estructura activa (un sujeto), un comportamiento (verbo) y una estructura pasiva (un objeto).
Figura 5.4: Conceptos clave de Archimate
También se presenta una distinción entre una vista interna y una vista externa en los sistemas, en el aspecto comportamental se define la vista externa por medio de un servicio: una unidad de funcionalidad que un sistema expone a su entorno. Los servicios son accesibles mediante interfaces, como puntos de acceso donde uno o mas servicios son expuestos al entorno (todo lo que se encuentra externo al sistema).
El comportamiento puede ser realizado por un elemento estructural único (actor, rol, componente), o de varios elementos estructurales, esto se conoce como una colaboración; se define como una agrupación temporal de dos o más elementos estructurales, que trabajan juntos para desempeñar un comportamiento colectivo; una interacción esta definida como una unidad de comportamiento realizado desempeñado por una colaboración.
Archimate también contiene una especificación para las relaciones entre los elementos, adoptados desde la especificación UML 2.0.
La estructura general del lenguaje de Archimate define tres capas primarias basadas en los componentes: La capa de negocio, que ofrece productos y servicios a clientes externos, los cuales son realizados en la organización en procesos de negocio por medio de los actores. La capa de aplicación que soporta la capa de negocio con servicios de aplicación realizados por aplicaciones de software. y la capa de tecnología, que ofrece servicios de infraestructura, almacenamiento, comunicación requerida para la ejecución de las aplicaciones. La estructura general dentro de cada capa es similar, mismos tipos de conceptos y relaciones son usadas pero su granularidad y semántica cambian.
Capa de Negocio Los aspectos de estructura activa en la capa de negocio refiere a la estruc-tura estática de una organización, en términos de las entidades de conforman la organización y sus relaciones. Las entidades activas son sujetos (actores de negocio o roles de negocio) que realizan un comportamiento como procesos de negocio o funciones. El concepto de interfaces de negocio son utilizadas para especificar ubicaciones (físicas o lógicas) o canales donde los servicios que un rol ofrece al entorno pueden ser accedidos, ejemplo, el mismo servicio puede ser ofrecido a a un numero diferente de interfaces, (email, teléfono o a través de Internet).
Figura 5.6: Metamodelo Capa de negocio
Figura 5.7: Metamodelo Capa de Aplicación
Capa de Tecnología El concepto principal de estructura activa para la capa de tecnología es el nodo, este concepto es utilizado para modelar entidades estructurales en esta capa, su comportamiento es modelado a través de relaciones explicitas en conceptos comportamentales. La interfaz de infraestructura es la ubicación lógica donde los servicios de infraestructura son ofrecidos por un nodo y pueden ser accedidos por otros nodos o componentes de aplicación de la capa de aplicación. Los nodos pueden ser dispositivos o sistemas de software y se pueden relacionar a través de rutas de comunicación (realizadas físicamente mediante redes).
Figura 5.8: Metamodelo Capa de Tecnología
Figura 5.9: Metamodelo Extensión Motivacional
Extensión de Implementación y migración El concepto central comportamental es un paquete de trabajo, un paquete de trabajo es claramente definido con fechas iniciales y finales, una definición concreta de los objetivos y resultados. Para este modelo se tienen en cuenta los entregables, la Platea y la brecha.
Figura 5.10: Metamodelo de Extensión de Implementación y migración
La extensión motivacional abarca el elemento que provee el contexto o la razón detrás de la arquitectura de una empresa, reconoce los conceptos de stakeholders y manejadores, las metas de los stakeholders deben ser traducidos dentro de la arquitectura de la organización y esta debe reflejar como los requerimientos son realizados por servicios, procesos y aplicaciones de software en las operaciones diarias. Los elementos “core” de la arquitectura se encuentran relacionados con elementos motivacionales por medio de los requerimientos, una relación de ejemplo entre el meta modelo y la extensión motivacional es que un actor de negocio puede ser asignado a un stakeholder, que puede ser visto como un rol motivacional.
Figura 5.11: Clasificación de puntos de vista de la arquitectura empresarial
La Metodología de Desarrollo Arquitectónico (ADM) es complementada con el lenguaje Archimate, que provee un conjunto de conceptos independientes, y una representación gráfica para construir modelos integrados consistentes de la arquitectura en todas sus fases. Fig. 5.5
5.2.2. Metodología de desarrollo ágil Scrum
Un proyecto basado en este marco de trabajo involucra un trabajo colaborativo para crear un nuevo producto definido a través de una visión del proyecto y entregables que aportan valor rápidamente durante su duración. La fuerza clave esta en el uso de pequeños equipos motivados concentrados en realizar tareas cortas concentradas durante ciclos de trabajo denominados Sprints.[11]
Figura 5.12: Metodología del proyecto bajo Scrum
Durante el sprint, se desarrollan reuniones diarias que son conducidas por los miembros del equipo para discutir el progreso diario. Al final del sprint, se realiza una reunión durante la cual el dueño del producto y los interesados más relevantes evalúan una demostración del entregable. El dueño del producto acepta el entregable solo si cumple con los criterios de aceptación definidos en las historias de usuario. El ciclo del sprint termina con una reunión de retrospectiva donde el equipo discute las formas de mejorar el proceso y el desempeño de la propia metodología para el siguiente sprint.[11]
El lanzamiento del producto (release) concluye con la ejecución de varios sprints que en-tregan valor agregado al producto final. El lanzamiento del producto se encuentra sujeto a la visión del proyecto inicial y los requerimientos de todas las historias de usuario. Nuevos lanza-mientos sobre el mismo producto pueden darse a partir de nuevas visiones del producto actual y agregación o modificación de requerimientos del dueño del producto y los stakeholders.[11]
5.3. Marco Conceptual
5.3.1. Autoevaluación Institucional
Los mecanismos de evaluación institucional permiten medir el nivel de ejecución de los planes, proyectos y programas que las entidades tienen previsto en sus objetivos organizacio-nales, en este proceso se tienen en cuenta una serie de etapas que identifican la autoevaluación institucional[5]:
Sensibilización sobre el proceso de autoevaluación por medio de actividades y comuni-cación sobre su importancia.
El uso de herramientas metodológicas que permitan medir con exactitud el estado in-terno de la organización con base a indicadores específicos y el soporte de auditorías internas.
El análisis de los resultados de la autoevaluación y la toma de decisiones orientadas a la realización de planes de mejoramiento para los hallazgos encontrados.
También se definen una serie de involucrados en este proceso:
El Nivel Directivo. “Debe evaluar los avances y grado de cumplimiento del plan in-dicativo, toma las decisiones correspondientes y da las orientaciones y lineamientos a seguir por parte de las áreas de la organización para garantizar el logro de los resultados previstos”[7].
Todos los niveles y áreas de la organización: “Evalúan periódicamente los avances de sus planes de acción y deben reportarlos a la Oficina de Planeación, así como también participar en los mecanismos que la oficina de control interno disponga para la ejecución de la autoevaluación”.
La oficina de Control Interno o quien haga sus veces: “Debe evaluar el sistema de control interno de la entidad, con énfasis en la existencia, funcionamiento y coherencia de los componentes y elementos que lo conforman y presentar informes a la Dirección y al Comité de Coordinación de Control Interno de la entidad”.
5.3.2. Contexto de la autoevaluación institucional en el MECI
La estructura del Modelo de Estándar de Control Interno consta de tres módulos prima-rios, El modulo de Control de Planeación y Gestión, El modulo de Control de Evaluación y seguimiento y un Eje transversal de Información y comunicación[7].
El objetivo del modulo de Evaluación y seguimiento, es establecer un proceso de mejo-ramiento continuo en la entidad, por medio de valoraciones a nivel de planes, programas y proyectos, con el propósito de detectar debilidades o falencias dentro de los mismos, y pro-yectar acciones encaminadas a contribuir con el logro de la misión y visión de la entidad.
El componente de autoevaluación institucional se enfoca de forma general tomando en cuenta la participación de todos involucrados dentro de la entidad categorizado según los pro-cesos, programas o proyectos y es vista como un proceso que se debe realizar periódicamente con el fin de entregar resultados sobre la gestión. Esto conlleva un conjunto de beneficios para la entidad como estimular el trabajo en equipo, aumentar la confianza entre los funcionarios, generar un compromiso y cultura por la autoevaluación, y además proveer mecanismos confia-bles para determinar el estado del control y de los riesgos que a su vez provee de información a la alta dirección.
El siguiente esquema representa el contexto general que se aborda dentro del MECI para el componente de Autoevaluación institucional[7].
Modelo Estándar de Control Interno.
• Módulo Control de Evaluación y Seguimiento. ◦ Componente Autoevaluación Institucional.
Autoevaluación del Control y Gestión.
Enfoques de Autoevaluación - Encuestas y cuestionarios
Existen varias herramientas utilizadas en la autoevaluación institucional inicialmente defi-nidos por el Departamento Administrativo de la Función Pública que han sido implementados en la guía de Autovaloración del Control,[4] entre los cuales se destacan:
Matriz de riesgo y control. Encuestas y cuestionarios. Entrevistas estructuradas. Entrevistas de Autovaloración. Talleres de Autovaloración.
Elenfoque de Encuestas y cuestionarios es una herramienta empleada en entidades cuando el nivel de funcionarios es bastante numeroso para la realización de Entrevistas estructuradas y el alcance de la autoevaluación es amplio, igualmente si la alta dirección desea minimizar el tiempo para la obtención de la información. Bajo este enfoque no se requiere experiencia por parte de los evaluadores y se reduce el numero de reuniones y coordinación para obtener los resultados.
5.3.3. Metodología estándar para la realización Autoevaluación Institucional
2. Definir la organización de la autoevaluación, bien sea por procesos, por áreas o por proyectos, luego definir el cronograma de trabajo para la aplicación de la encuesta. 3. Aplicar el enfoque de encuesta teniendo en cuenta la organización y el numero de
per-sonas involucradas, el formato de la encuesta lleva el conjunto de preguntas especificas, una escala de valoración, observaciones, evidencias de cumplimiento y una oportunidad de mejora, (estos dos últimos campos son opcionales y dependen de la organización de la evaluación).[5]
Las preguntas se encuentran orientadas a la organización de la evaluación, bien sea por procesos o por áreas, un conjunto de preguntas pueden ser evaluadas para todos los procesos y para procesos específicos.
La escala definida por el estándar es de tipo cualitativo para el evaluador: No sabe, No se cumple, Se cumple insatisfactoriamente, Se cumple aceptablemente, Se cumple en alto grado, Se cumple plenamente. y de tipo cuantitativo para el analista de cero a cinco respectivamente.
4. Tabular la información obtenida de las encuestas, realizar la valoración de forma ge-neral y entregar los resultados al representante de la Dirección, junto con las acciones correctivas o de mejoramiento. (para este procedimiento se toma en cuenta el anexo 2 del MECI 2005, para tabulación de encuestas e interpretación de resultados).
5. Someter a consideración del comité de coordinación de control interno los resultados y las acciones correctivas o de mejoramiento.
6. Analizar los resultados de la Autoevaluación y adoptar las acciones correspondientes que garanticen mantener la orientación de la entidad publica hacia el cumplimiento de sus objetivos institucionales.
5.4. Marco legal
Existe un fundamento legal que soportan los mecanismos de Autocontrol, Autorregulación y Autogestión dentro de las áreas de Control Interno, Así como su reconocimiento y las funciones que éstas deben cumplir dentro de las entidades de carácter publico las cuales se rigen a nivel nacional.
Ley 87 de 1993: Se establecen normas para el ejercicio del control interno en las entidades y organismos del estado; entre los objetivos y aspectos del sistema de control interno se destacan[1]:
• Garantizar la correcta evaluación y seguimiento de la gestión organizacional. • Establecimiento de sistemas modernos de información que faciliten la gestión y el
control.
• Organización de métodos confiables para la evaluación de la gestión.
Decreto 2145 de 1999: define el concepto de evaluación a la luz de la norma colombiana:[3] • Evaluación. Este componente es el complemento fundamental de la planeación, consistente en la verificación y seguimiento a la gestión dándole dinamismo al proceso planificador y facilitando la retroalimentación de las actividades, la toma de decisiones y la reorientación de las acciones para garantizar el logro de los resultados previstos.
Decreto 1599 DE 2005 - Por el cual se adopta el Modelo Estándar de Control Interno para el Estado Colombiano. Define formalmente el componente de la autoevaluación institucional para el MECI:
• Autoevaluación a la gestión: Elemento de control, que basado en un conjunto de indicadores de gestión diseñados en los planes y programas y en los procesos de la entidad pública, permite una visión clara e integral de su comportamiento, la obten-ción de las metas y de los resultados previstos e identificar las desviaciones sobre las cuales se deben tomar los correctivos que garanticen mantener la orientación de la entidad pública hacia el cumplimiento de sus objetivos institucionales.
Manual de Implementación MECI 2005 y MECI 2014. El manual de Implementación MECI, es una metodología estándar que sirve como apoyo de las leyes y decretos anterior-mente descritos y establece los lineamientos de forma practica para la implementación en los sistemas de control interno.Es la hoja de ruta para la realización de este proyecto, este incluye:
• Proceso de planeación para implementar el MECI en una organización en etapas definidas.
• Proceso de actualización del modelo en caso de que la organización ya tenga una implementación de MECI.
• Descripción de los Subsistemas y elementos del control, Estructura, roles y respon-sabilidades.
6.
Aspectos metodológicos
6.1. Tipo de estudio
El presente trabajo de investigación busca realizar una recopilación de los diferentes ele-mentos que caracterizan el problema dentro del contexto de las organizaciones de carácter descentralizado, para esto se identifican los hechos o las causas del problema y sus consecuen-cias y las situaciones que suelen presentarse a fin de mitigar el problema. Otros hechos que inciden pero que no son visibles deben determinarse para abordar el problema en su totalidad, dejando un precedente que pueda ser el insumo clave para futuras investigaciones dentro del contexto planteado.
El tipo de investigación sobre la cual se determinará el nivel de profundidad y la forma en que se abordaŕa el problema es de tipodescriptivo, realizando una previa caracterización de todos los hechos y situaciones presentadas dentro de un entorno empresarial y a partir de la experiencia adquirida en la realización del proceso, es de resaltar que también se deben obser-var las situaciones y comportamientos de las personas involucradas cuando están realizando el proceso y que actitudes se evidencian frente a este. La observación juega un papel importante puesto que permitirá describir con claridad todo el flujo del proceso, los actores externos a este y la forma en que los involucrados, que son los principales gestores de comunicación y ejecutores puedan resultar beneficiados.
Previas investigaciones se abordan acerca de las técnicas para la medición de objetivos empresariales y además estándares conocidos para este proceso, por tanto los antecedentes presentados sirven como apoyo para esta investigación y permitirán ampliar las bases y los fundamentos teóricos de éste estudio.
La recolección de información se centrará en la norma Colombiana como uno de los ejes centrales para la creación de la herramienta, debido a que el Modelo Estándar de Control Interno tiene su fundamento en los trabajos realizados y la experiencia de la gestión de la administración pública a lo largo de las ultimas tres décadas en el estado Colombiano de todas las entidades de carácter descentralizado que hacen parte de este; y cuyas experiencias y prácticas son recopiladas en sus manuales respectivos y además exigidas por el fundamento legal que le precede. La metodología del componente a analizar se encuentra soportado y documentado en gran medida y el conocimiento acerca de este se amplia con nuevas versiones del estándar.
Se espera que las evidencias y las situaciones que se presenten luego de que se implemente en una organización de este tipo y con base en la hipótesis planteada puedan ser la base para el inicio de investigaciones futuras que generen un conocimiento explicativo.
6.2. Método de investigación
Los métodos de investigación para el desarrollo del proyecto serán a partir de la obser-vación y la inducción.
Estas características particulares podrán analizarse desde el marco teórico general y del marco legal definido empleando al deducción con el fin de establecer sus relaciones con la información adquirida y la generación de un prototipo concreto que se encuentre orientado a una realidad particular.
Posibles lineas de investigación de interés en la que tendría cabida este proyecto de inves-tigación:
Ingeniería de software.
Mecanismos de medición en gestión empresarial. Arquitectura de Software.
Ingeniería de Requerimientos.
6.3. Fuentes y técnicas para la recolección de la información
6.3.1. Fuentes primarias
Las fuentes primarias para la recolección de la información parten de una observación inicial dentro del proceso en una entidad particular y las actividades que se realizan a cabo, identificando información relevante para el estudio. Luego se contrasta la información obtenida con la experiencia personal para obtener un cuerpo conceptual inicial que será refinado con las técnicas posteriores:
Entrevistas con los especialistas del área de control interno de la entidad. Entrevistas con los especialistas del área de sistemas de la entidad.
Entrevistas con los involucrados en el proceso, evaluadores y entes internos. Encuestas iniciales que indiquen las actitudes sobre el proceso.
Información que se desea obtener
Identificar los stakeholders, participantes y entes externos que influyen en la realización del proceso.
Flujo del proceso y todas las tareas realizadas durante la realización de la autoevaluación. Herramientas actuales utilizadas: descripción de las herramientas, el uso y la forma en que se emplean.
Cronograma del proceso, vigencia y objetivo de los resultados, tipo de resultado que se desea obtener y su uso en los informes de control interno.
Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivel de conocimiento de los usuarios acerca de las tecnologías de la información.
A partir de la información obtenida se busca conocer aspectos no considerados inicialmente y otros hechos que puedan servir para identificar situaciones subyacentes del problema de investigación.
6.3.2. Fuentes secundarias
La recopilación de la información secundaria parte de tres fuentes secundarias clave en la realización del estudio, la primera corresponde a toda la información relacionada con el proceso y el moldeamiento de los requerimientos dentro del entorno planteado de forma que la información obtenida se encuentre relacionada con el contexto de la gestión publica. Esto incluye:
Normas vigentes y actualizaciones sobre el estándar que se rige actualmente.
Información en artículos, revistas y casos de estudio de medición de objetivos empresa-riales.
Otros estándares encontrados relacionados con el objeto de estudio.
La segunda fuente principal corresponde a la información que se debe obtener con el fin de realizar la definición de la arquitectura empresarial del proceso, es decir, documentación exis-tente y practicas acordes para este problema particular a partir de la consulta de estándares y artículos disponibles en bases de datos académicas de la Universidad Distrital Francisco José de Caldas. Para esto se busca:
Seleccionar la Metodología para levantamiento de requerimientos indicada. Definición de la arquitectura empresarial orientada al proceso.
La tercera fuente principal corresponde a la búsqueda de información sobre la metodología para el desarrollo de software especifico consistente al problema planteado:
Realizar consultas bibliográficas sobre casos de estudio acerca de las metodologías de desarrollo de software y el ciclo de vida a tener en cuenta.
Las tres fuentes de información secundaria se encontrarán orientados al problema de investi-gación y sus objetivos específicos. Además se busca que sirvan como apoyo en la forma en la que se va a realizar la solución del problema, y mostrar el aprendizaje obtenido en el desarrollo del proyecto en las practicas utilizadas.
6.4. Tratamiento de la información
Para el tratamiento de la información obtenida tanto de fuentes primarias como de se-cundarias, es necesario aplicar técnicas de tratamiento de información especificas para cada caso:
Con la información obtenida a partir de las fuentes secundarias relacionadas de consultas acerca de la metodología de desarrollo de software, se pretende establecer los lineamien-tos y directrices del desarrollo, con la definición de las tareas especificas a realizar y un cronograma orientado al desarrollo del prototipo.
Parte II
Desarrollo de la investigación
7.
Análisis de la información
7.1. Entrevistas
Para esta investigación, se optó por realizar entrevistas personalizadas debido a que repre-sentan la forma más acertada de conocer el problema y los lineamientos que la solución debe tener en cuenta. Al ser una solución orientada a una herramienta de enfoque de encuestas no se opta por recolectar información a través de encuestas.
Realización de entrevistas
Grupo objetivo
Representantes del proceso en la entidad Especialistas de control interno
Especialista del área de sistemas
representantes de los procesos misionales, estratégicos, de apoyo y de evaluación y seguimiento de la entidad.
Universo Instituto para la protección de la niñez y la juventud IDIPRON
Forma de contacto Entrevista cara a cara
Muestra 7 entrevistas
Tipo de pregunta Todas las preguntas Abiertas
Forma de análisis Identificar a criterio del entrevistador las respuestas relacionadas al planteamiento del problema.
Cuadro 1: Ficha técnica realización de entrevistas
A continuación se describen los resultados de las entrevistas con los involucrados del proceso:
Para ver la estructura de la entrevista remitirse al anexo 1
Observaciones de las entrevistas con los especialistas del área de control interno de la entidad:
Se requiere una herramienta que otorgue resultados al momento que se desee consultar bien sea parciales o consolidados al final del proceso.
Se requiere que pueda utilizarse a través de las vigencias.
Es necesario que se de apoyo al proceso de información y seguimiento informando a los usuarios el objetivo de la autoevaluación.
Observaciones del especialista del área de sistemas de la entidad:
La herramienta debe ser acorde visualmente a los demás sistemas de información exis-tentes.
Se debe tener en cuenta la plataforma tecnología existente la momento de la fase de implementación.
Es recomendable que se utilicen tecnologías libres apoyando Política de Promoción y Uso del Software libre. Acuerdo 279 de 2007
Observaciones de los involucrados en el proceso, evaluadores y entes internos:
Actitudes del proceso: Los involucrados desconocen los resultados al final del proceso y no son informados de por que se realiza este tipo de autoevaluación.
Se desconoce el modelo estándar de control interno y los elementos a evaluar.
Actualmente se consolidan encuestas en formato excel lo que hace que el proceso tome más tiempo y cause menor motivación para realizar la evaluación.
Información relevante obtenida para la identificación del problema
Identificar los stakeholders, participantes y entes externos que influyen en la realización del proceso:
• Toda la organización hace parte del proceso, juegan el papel de evaluadores de sus propios procesos y des los cuales se involucran.
• Los entes externos como entes de control son informados a través del área de control interno
Flujo del proceso y todas las tareas realizadas durante la realización de la autoevaluación. • Todos los procesos de la entidad se encuentran involucrados de forma que contri-buyen al cumplimento de la misión y los objetivos organizacionales: La evaluación es transversal a todos los procesos y tiene en cuenta aspectos relacionados de los cuales se dan una valoración por parte de los involucrados del proceso que gestiona y de los involucrados que colaboran.
Herramientas actuales utilizadas: descripción de las herramientas, el uso y la forma en que se emplean:
• Herramientas ofimáticas, uso de correo electrónico para el envío de la información. • Manuales y documentación digital de los procesos de la entidad para la formulación
de preguntas.
• Se realiza en vigencia anual, se requiere que los resultados contribuyan a la creación actividades que mejoren las falencias en los procesos para la vigencia siguiente de acuerdo a los planes de mejoramiento, los resultados deben presentarse a la dirección general.
Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivel de conocimiento de los usuarios acerca de las tecnologías de la información.
• Los usuarios conocen las tecnologías de información como navegadores web, he-rramientas ofimáticas. Desde la entidad de tiene acceso a internet y equipos de computo.
Actitudes sobre el proceso: nivel de aceptación del enfoque de encuesta, motivación para realizar la evaluación, causas de rechazo al proceso e incomodidades realizándola.
8.
Diseño de la Arquitectura Empresarial
El diseño de la arquitectura empresarial orientada al proceso de autoevaluación institu-cional comprende los puntos de vista del lenguaje de descripción arquitectónica Archimate, punto de vista del negocio, aplicación, tecnológico, extensión motivacional y extensión de im-plementación y migración. Cada punto de vista es una descripción detallada del proceso de la organización definiendo el producto Valueme, Herramienta de apoyo para la realización de la autoevaluación institucional basada en el MECI.
9.
Punto de vista del negocio
El punto de vista del negocio trata acerca de procesos de negocio, servicios, funciones y eventos en unidades de negocio. Esta capa “ofrece productos y servicios a clientes externos, quienes son realizados en la organización por procesos de negocio desempeñados por actores de negocio y sus roles”.
9.1. Punto de vista de la organización
El punto de vista de la organización se enfoca en la organización interna de una compañía, departamento o entidad organizacional, es útil para identificar competencias, autoridad y responsabilidades en una organización.[10]
Figura 9.1: metamodelo organización
Punto de vista de la organización
Figura 9.2: modelo organización
9.2. Punto de vista de cooperación de actor
El punto de vista de Actor cooperación se enfoca en las relaciones entre los actores y su entorno, es útil determinando dependencias externas y colaboraciones y muestra la cadena de valor o red donde el actor opera.
Figura 9.3: metamodelo cooperación de actor
Punto de vista de cooperación de actor
Figura 9.4: modelo cooperación de actor
9.3. Punto de vista de función de negocio
El punto de vista de función de negocio muestra las funciones principales de negocio de una organización y sus relaciones en términos del flujo de la información, valor o bienes entre ellos. Las funciones de negocio son usadas para representar los aspectos mas estables en términos de las actividades primarias que desempeña, independientemente de los cambios organizacionales o desarrollos tecnológicos. Por lo tanto, la arquitectura de funciones pueden ser similares en compañías con actividades del mismo mercado. Esto provee una visión de las operaciones generales de la compañía, y puede utilizarse para identificar competencias necesarias o la estructura de la organización de acuerdo a sus actividades principales.[10]
Punto de vista de función de negocio
Las funciones de negocio realizadas por el analista son realizar las actividades de sensibi-lización, que incluye crear el cronograma de actividades del proceso. consolidar los resultados de las encuestas y realizar el análisis de los resultados para presentar el informe a la alta dirección. Las funciones de negocio del evaluador corresponden a completar la evaluación.
Figura 9.6: modelo función de negocio
9.4. Punto de vista de proceso de negocio
El punto de vista de proceso de negocio es usado para mostrar una estructura de alto nivel y composición entre uno o mas procesos de negocio, incluye conceptos como[10]:
Los servicios que un proceso de negocio ofrece al mundo exterior mostrando como un proceso contribuye a la realización de los productos
La asignación de los procesos de negocio a los roles quienes dan la visión de las respon-sabilidades de los actores asociados.
Figura 9.7: metamodelo proceso de negocio
Punto de vista de proceso de negocio
El proceso de negocio macro es la autoevaluación institucional, este realiza un servicio de negocio para presentar los resultados en tiempo real. Los subprocesos son la realización de la encuesta, que parte de un evento como la solicitud de la evaluación por parte del director del proceso, la consolidación y tabulación de los resultados y su posterior análisis, el evento de finalización es la presentación del informe con los indicadores de gestión obtenidos.
9.5. Punto de vista de cooperación de proceso de negocio
El punto de vista de cooperación de proceso de negocio es utilizado para mostrar la relación entre uno o más procesos de negocio con cada uno y/o con su entorno. Provee las dependencias entre procesos de negocio. Sus características principales son[10]:
Presenta relaciones causales entre los procesos de negocio de la empresa. Muestra una correlación entre procesos de negocio hacia funciones de negocio. Muestra la realización de servicios por procesos de negocio.
Uso de datos compartidos.
Figura 9.9: metamodelo de cooperación de proceso de negocio
Punto de vista de cooperación de proceso de negocio
Figura 9.10: modelo de cooperación de proceso de negocio
9.6. Punto de vista de producto
Figura 9.11: metamodelo de producto
Punto de vista de producto
10.
Punto de vista de la aplicación
El punto de vista de la aplicación trata acerca de las aplicaciones de software que so-portan los componentes del negocio con servicios de aplicaciones, componentes de aplicación reusables, e interfaces de comunicación para estos componentes.
10.1. Punto de vista de comportamiento de aplicación
El punto de vista de comportamiento de aplicación describe el comportamiento interno de una aplicación, es útil para diseñar el comportamiento principal de aplicaciones o componentes e identificar la superposición funcional entre diferentes aplicaciones.[10]
Figura 10.1: Metamodelo de comportamiento de aplicación
Modelo de comportamiento de aplicación
Se presentan un conjunto de componentes candidatos:
El gestor de la evaluación que proveerá la configuración para los módulos, componentes y elementos a los que pertenece la evaluación, el banco de preguntas y los tipos de evaluaciones, así como también el almacenamiento de las evaluaciones y su consulta. El analizador de resultados debe tabular los resultados y proveer los indicadores resul-tado de todas las evaluaciones realizadas.
El componente de comunicación debe ser configurable para presentar la información a los evaluadores acerca del proceso y enviar los informes de resultados a todos los involucrados.
El componente de organizador de cronograma debe configurar los tiempos y el periodo de las actividades, como por ejemplo las fechas para presentar la evaluación y generar los resultados.
ValueMe representa el componente de acceso que permite configurar y comunicarse con los demás componentes.
Figura 10.2: Modelo de comportamiento de aplicación
10.2. Punto de vista de cooperación de aplicación
Figura 10.3: Metamodelo de cooperación de aplicación
Modelo de cooperación de aplicación
En el punto de vista de cooperación de aplicación se presenta un modelo Front Office para la interfaz de comunicación visible para el usuario final y Back Office que representará la arquitectura en la que los componentes de aplicación van a estar localizados en el producto.
Figura 10.4: Modelo de cooperación de aplicación
10.3. Punto de vista de estructura de aplicación
Figura 10.5: Metamodelo de estructura de aplicación
Modelo de estructura de aplicación
El punto de vista de estructura de aplicación muestra la comunicación entre cada uno de los componentes a través de sus interfaces:
Gestor de la evaluación:
• Provee la evaluación realizada por el evaluador al analizador de resultados. • Requiere de la configuración de la evaluación: Preguntas, categorías, parámetros
de evaluación de ValueMe para configurar las evaluaciones.
• Requiere del evaluador como información de registro de la evaluación del Autenti-cador de usuarios.
Analizador de resultados:
• Provee los indicadores de resultados al componente de comunicación.
• Requiere de la evaluación del gestor en las evaluaciones para generar los indicadores de resultados.
Autenticador de Usuarios:
• Provee los usuarios evaluadores, administradores y analistas al gestor de la evalua-ción para la gestión de la evaluaevalua-ción.
• Requiere de las políticas de control de acceso del cronograma para permitir o denegar accesos según los tiempos establecidos en el cronograma.
Comunicación:
• Provee notificaciones, información e indicadores de resultados acerca del proceso a ValueMe y este a todos los involucrados (usuarios registrados).
• requiere de los indicadores de resultados sobre la evaluación del analizador de resultados.
• Provee el control de acceso para los usuarios según los tiempos establecidos para la evaluación, así como también las actividades se realizan en el proceso.
Figura 10.6: Modelo de estructura de aplicación
10.4. Punto de vista de Uso de aplicación
Figura 10.7: Metamodelo de uso de aplicación
Modelo de uso de aplicación
El punto de vista de uso de aplicación muestra la realización de los servicios de aplicación propuestos: recepción de evaluaciones y presentación de informes, y como estos servicios de aplicación son usados los procesos de negocio definidos y se definen los componentes candidatos que realizan estos servicios de aplicación.
11.
Punto de vista Tecnológico
El punto de vista de infraestructura general, trata acerca del hardware y la infraestructura de comunicación que soporta la capa de aplicación. Esta capa ofrece servicios de infraestruc-tura requeridos para desplegar las aplicaciones realizadas en los ordenadores y los sistemas de hardware y software.
11.1. Punto de vista de Infraestructura
el punto de vista de infraestructura contiene los elementos de software y hardware que so-portan la capa de aplicación, como dispositivos físicos, redes o sistemas de software. (sistemas operativos, bases de datos o middleware).[10]
Figura 11.1: Metamodelo de infraestructura
Modelo de infraestructura
Figura 11.2: Modelo de infraestructura
Especificaciones técnicas de infraestructura
Se cuenta con un servidor de email para el componente de comunicación, un servidor de aplicaciones ejecutado bajo un Sistema Operativo anfitrión, un sistema gestor de bases de datos NoSql y el producto de software.
Software Versión Descripción
Ubuntu Server 14.04 - 16.04 Sistema Operativo Anfitrión GNU/Linux Apache Tomcat 7.0.55 Contenedor de Aplicaciones java basado en servlets
Zimbra Collaboration 8.6.0 Servidor de correo electrónico SMTP
MongoDB 3.2.4 DBMS NoSQL orientado a documentos.
ValueMe 1.0 Producto de software web a construir
Cuadro 2: Especificaciones técnicas de infraestructura
11.2. Punto de vista de uso de infraestructura
Figura 11.3: Metamodelo de uso de infraestructura
Modelo de uso de infraestructura
En este punto de vista se identifican los servicios de infraestructura principales que co-rresponden al servicio de notificaciones, generar reportes, establecer tiempos de acceso a la aplicación, y gestionar los usuarios. Cada uno de los servicios de infraestructura entrega con-figuración y la funcionalidad requerida hacia los componentes de aplicación.
11.3. Punto de vista de Implementación y despliegue
El punto de vista de implementación y despliegue muestra como uno o más aplicaciones son realizadas sobre la infraestructura. Esto implica el mapeo de aplicaciones (lógicas) y componentes en artefactos (físicos). Esta vista juega un papel importante en el análisis del rendimiento y la escalabilidad debido a la relación entre la infraestructura y el mundo lógico de las aplicaciones.[10]
Figura 11.5: Metamodelo de implementación y despliegue
Modelo de implementación y despliegue
Figura 11.6: modelo de implementación y despliegue
11.4. Punto de vista de Estructura de información
El punto de vista de estructura de información es comparable a los modelos tradicionales creados en el desarrollo de la mayoría de sistemas de información, muestra la estructura de información usada en la empresa o un proceso específico o aplicación en términos de los tipos de datos o las estructuras de clases (orientado a objetos).[10]
Figura 11.7: Metamodelo de estructura de información
Modelo de Estructura de información
Figura 11.8: Modelo de estructura de información
11.5. Punto de vista de realización de servicio
El punto de vista de realización de servicio es usado para mostrar como uno o mas servicios de negocio son realizados por los procesos subyacentes (y algunas veces por componentes de aplicaciones), forma un puente entre la vista de productos de negocio y la vista de procesos de negocio.[10]
Modelo de realización de servicio
El punto de vista de realización del servicio muestra los procesos de negocio de la arqui-tectura: realización de la evaluación, consolidación de la información y análisis de resultados asignados a componentes de aplicación que serán de soporte para dichos proceso. Los procesos de negocio son realizados de forma secuencial y la realización de todos proveen los servicios de negocio definidos.
Figura 11.10: Modelo de realización de servicio
11.6. Punto de vista de Capas
El punto de vista por capas muestra las diferentes capas y aspectos de la arquitectura empresarial en un modelo. Existen dos categorías de capas, capas dedicadas y capas de servicio. Las capas son resultado de la relación de “agrupación” para un particionado natural de todo el conjunto de objetos y relaciones que pertenecen al modelo. La infraestructura, la aplicación, los procesos y los actores/roles pertenecen a la primera categoría. El principio estructural es que cada capa dedicada expone por medio de una relación de “realización” una capa de servicios, las cuales serán “usadas por” la siguiente capa dedicadas. A partir de esto se puede separar la estructura interna y la organización de cada capa dedicada de su comportamiento externo observable expresado como el servicio que esa capa dedicada realiza.[10]
Modelo de Capas
12.
Extensión Motivacional
12.1. Punto de vista de stakeholder
El punto de vista del stakeholder permite al analista modelar los stakeholders, los ma-nejadores internos y externos de cambio, y las valoraciones, (en términos de sus fortalezas, debilidades, oportunidades y amenazas) de estos manejadores. También los enlaces de alto nivel para los objetivos que conducen estas valoraciones. Estos objetivos conforman la ba-se para el proceso de ingeniería de requerimientos, incluyendo el refinamiento de objetivos, contribución, análisis de conflictos y los requerimientos derivados de estos objetivos.
Figura 12.1: Metamodelo de stakeholder
Modelo de stakeholder
En este punto de vista se presentan dos modelos gráficos correspondientes a los dos sta-keholders principales del proceso:
El modelo de los evaluadores, cuyo stakeholder concreto son los responsables de área de la entidad, y cuya misión se es realizar una evaluación de la organización a nivel interno, presenta como debilidad el desconocimiento del proceso y para qué puede llegar a ser importante, en sus fortalezas se encuentran la experiencia sobre las tareas que llega a cabo, los objetivos que pretenden fortalecer esa experiencia es crear un sistema de realimentación de la evaluación, y disminuir el desconocimiento con información acerca del proceso y su importancia.
Figura 12.3: Modelo de stakeholder Equipo de control interno
Figura 12.2: Modelo de stakeholder Responsable de Área
12.2. Punto de vista de realización de objetivos
Figura 12.4: Metamodelo de realización de objetivos
Modelo de realización de objetivos
El modelo de realización de objetivos muestra un objetivo seleccionado refinado en dos objetivos relacionados a la automatización del proceso de autoevaluación, estos objetivos concretos permiten evidenciar los requerimientos correspondientes que finalmente apunten a un principio motivacional en el proceso.
12.3. Punto de vista de contribución de objetivos
El punto de vista de contribución de objetivos permite al diseñador o analista modelar las relaciones de influencia entre los objetivos y los requerimientos. Las vistas resultantes pueden ser utilizadas para analizar el impacto que los objetivos tienen entre sí y determinar conflictos entre los objetivos de los stakeholders.
Figura 12.6: Metamodelo de contribución de objetivos
Modelo de contribución de objetivos
En el modelo de contribución de objetivos, se evalúa la forma en que el requerimiento obtenido a partir de un objetivo puede afectar de forma positiva o negativa otros objetivos relacionados.
Figura 12.7: Modelo de contribución de objetivos
12.4. Punto de vista de principios
Figura 12.8: Metamodelo de principios
Modelo de Principios
En este punto de vista se destaca el objetivo organizacional principal: ”brindar comodidad y rapidez en el proceso de autoevaluación” y todos los principios que realizan ese objetivo. Comunicación como medio entre los involucrados, un principio de seguimiento a los objetivos organizacionales, la capacidad de valoración y organización.
Figura 12.9: Modelo de principios
12.5. Punto de vista de realización de requerimientos
Figura 12.10: Metamodelo de realización de requerimientos
Modelo de realización de requerimientos
En el punto de vista de realización de requerimientos se especifican los requerimientos que realizan uno o más objetivos, para este caso el objetivo se relaciona con la realización de reportes y estado del proceso, donde se presentan dos requerimientos que realizan este objetivo. Adicionalmente se presentan restricciones o requerimientos refinados derivados de los principales.
Figura 12.11: Modelo de realización de requerimientos
12.6. Punto de vista de motivación
Figura 12.12: Metamodelo de motivación
Modelo de motivación
En el modelo de motivación se relacionan ambos stakeholders, los responsables de área y el equipo de control interno y sus valoraciones, para cada una de ellas se asocia a un objetivo que finalmente debe ser realizado por uno o más requerimientos, un requerimiento puede realizar dos objetivos y fortalecer valores de varios stakeholders simultáneamente que se relacionan por la caracterización del proceso.
13.
Extensión de Implementación y Migración
13.1. Punto de vista de proyecto
El punto de vista del proyecto es usado principalmente para modelar la gestión del cambio en la arquitectura, la arquitectura del proceso de migración desde una situación anterior (estado actual de la arquitectura empresarial) a una situación deseada (estado objetivo de la arquitectura empresarial) tiene consecuencias significativas en el corto y largo plazo para el crecimiento de la estrategia y las decisiones subsecuentes del proceso de realización. Algunos aspectos que deben tomarse en cuenta por el diseñador en este punto de vista son:
Desarrollar una arquitectura empresarial completa para una organización es una tareas que puede requerir varios años.
Todos los sistemas y servicios deben mantenerse operando en caso que ocurran modifi-caciones y cambios en la arquitectura empresarial durante el proceso de cambio. El proceso de cambio puede tener que tratar con estándares inmaduros de tecnología (mensajería, seguridad, datos).
El cambio tiene consecuencias serias para el personal, la cultura, la manera de trabajar y la organización.
Figura 13.1: Metamodelo del proyecto
Modelo del proyecto
Figura 13.2: Modelo del proyecto
13.2. Punto de vista de migración
El punto de vista de migración se implica modelos y conceptos que pueden ser usados para especificar la transición de una arquitectura existente a una arquitectura deseada. La platea es un estado relativo de la arquitectura que existe en un tiempo limitado, una brecha es una unidad de análisis de transición entre dos plateas.
Figura 13.3: Metamodelo de migración
Modelo de Migración
En el punto de vista de migración se presentan tres plateas que conformarán la evolución del sistema en sus versiones finales.
1. La primera platea corresponde a una versión de herramienta tipo web que se encuen-tre alineada con la definición de la arquitectura empresarial propuesta. Debe contener todos los lineamientos para la gestión de la evaluación mediante enfoque de encuesta y generación de reportes básicos.
2. La segunda platea corresponde a un sistema mejorado de comunicación entre todos los participantes y realimentación y valoración de la evaluación.
Figura 13.4: Modelo de migración
13.3. Punto de vista de migración e implementación
El punto de vista de migración e implementación es utilizado para relacionar programas y proyectos a las partes de la arquitectura que ellas implementa. esta vista permite modelar el alcance de los programas, proyectos y actividades en términos de las plateas que son realizadas o los elementos de la arquitectura individual que son afectados. Adicionalmente, la forma en que los elementos son afectados pueden se indicados anotando las relaciones. Este punto de vista puede ser utilizado en combinación con los puntos de vista de programas y proyectos para soportar la administración del portafolio.
El punto de vista de implementación y migración se sitúa para relacionar objetivos de negocio (y requerimientos) por medio de los programas y proyectos de la arquitectura.
Figura 13.5: Metamodelo de migración e implementación
Modelo de migración e implementación
El prototipo iterable se conoce como laPlataforma de Autoevaluación institucional basada en el Modelo Estándar de Control Interno MECI, ValueMe - Valórame, una herramienta de apoyo para la consolidación, gestión y entrega de resultados del proceso de autoevaluación institucional.
