---
title: Primeros pasos
description: Ruta orientativa para poner en contexto la empresa, asignar responsabilidades y conectar el catálogo de gobierno.
audiencia: Administrador | Data Owner | Data Steward | Ingeniero de datos
roles: Administrador coordina; Data Owner y Data Steward definen negocio; Ingeniero de datos aporta contexto técnico
modulo: Visión transversal de gobierno de datos
revision: "2026-10-19"
section: "empezar"
order: 20
sources:
  - CONTEXT.md
  - Módulosydependencias.md
  - Roles,capacidadesyalcance.md
  - Modelodeobjetosyrelaciones.md
  - Cómoleerelmapaderelaciones.md
---

# Primeros pasos

El inicio de GovFrame consiste en formar un contexto de gobierno mínimo pero conectado: una taxonomía comprensible, responsables con alcance y, cuando la empresa lo necesite, trazabilidad hacia sus fuentes técnicas. Esta es una **ruta funcional orientativa**; adapta la secuencia a los módulos habilitados y a las decisiones de la empresa. No presupone formularios, estados de workflow ni automatizaciones no confirmadas.

## Antes de empezar

| Aspecto | Qué comprobar | Responsable habitual |
|---|---|---|
| Empresa | La empresa debe estar `active` para operar normalmente. | Administrador o gestión de plataforma autorizada |
| Roles y alcance | Cada participante necesita membresía activa, capacidad adecuada y alcance de Dominio/Subdominio o de Repositorio, según su trabajo. | Administrador |
| Módulos | Confirma que los módulos necesarios estén activos. Un módulo desactivado no es operable aunque exista un enlace directo. | Administrador o gestión de plataforma autorizada |
| Modelo taxonómico | Acordad si se usará Dominio → Entidad → Atributo o el modelo con Subdominio. | Administrador con Data Owner |
| Fuentes técnicas | Antes de usar un Diccionario técnico útil, debe existir un Repositorio registrado. | Ingeniero de datos |

No se debe intentar resolver permisos modificando parámetros del navegador ni usar un rol como sustituto del alcance. Owner y Steward trabajan dentro de sus Dominios o Subdominios autorizados; el Ingeniero de datos administra únicamente los Repositorios con scope técnico asignado.

## Recorrido recomendado

1. **Delimita el primer ámbito.** Elige un Dominio cuyo lenguaje, responsable y necesidad de trazabilidad sean reconocibles. Si la organización necesita una división estable, incorpora Subdominios. Evita crear una estructura exhaustiva antes de poder usarla.

2. **Nombra responsables y asigna alcance.** Registra la responsabilidad de negocio y asigna a las personas los scopes que les permiten actuar. Distingue el rol de sesión de un rol de gobierno: el primero controla la capacidad operativa; el segundo documenta la responsabilidad en el catálogo.

3. **Construye el vocabulario y los objetos de negocio.** Documenta Entidades y Atributos relevantes y, si el módulo está activo, añade Términos de negocio para expresar definiciones compartidas. Mantén nombres legibles para las personas; los códigos técnicos no sustituyen esos nombres en la guía funcional.

4. **Añade el contexto técnico cuando esté disponible.** El Ingeniero de datos registra el Repositorio dentro de su alcance y puede sincronizar metadata según la configuración de la empresa. Después, el Diccionario técnico conecta campos físicos con Atributos del catálogo. No asumas que toda tabla o todo campo de una fuente ya tiene asociación de negocio.

5. **Expresa controles y entregas con los objetos existentes.** Una Regla de calidad se asocia a un Atributo y puede relacionarse con campos físicos. Para generar SQL necesita tanto esas asociaciones válidas como un dialecto configurado; no es una promesa de ejecución automática. Los Activos, Productos y Contratos permiten documentar qué se entrega y con qué atributos, términos, reglas, campos o sistemas relacionados cuando sus módulos y dependencias estén disponibles.

6. **Conecta el trabajo pendiente.** Utiliza los Workflows, solicitudes, tareas, comentarios, clasificaciones o certificaciones que estén habilitados para dejar trazabilidad de decisiones y seguimiento. No conviertas Riesgos o Controles en inventarios separados: en el modelo actual se representan mediante combinaciones de reglas, políticas/procedimientos, workflows, tareas, aprobaciones y objetos de stewardship.

7. **Revisa relaciones antes de ampliar.** El Explorador de relaciones ayuda a comprobar el contexto de un objeto en Panorama, analizar dependencias registradas en Impacto y seguir el vínculo físico en Detalle técnico. Una línea ausente indica que no hay relación registrada; no debe deducirse una dependencia por compartir el mismo Dominio.

> **Ejemplo sintético:** para “Clientes”, una primera entrega puede incluir el Dominio Clientes, la Entidad Cliente, el Atributo “Fecha de alta”, un Owner y un Steward con alcance, y un campo técnico asociado si ya está documentado. A partir de esa base se añade una regla o un contrato solo cuando exista el módulo y la relación correspondiente.

## Resultado esperado

Al finalizar este recorrido, la empresa debería disponer de un ámbito inicial navegable con responsables y alcance documentados, objetos de negocio con significado claro y, cuando se haya incorporado, un vínculo técnico verificable hacia campos y Repositorios. El resultado no es un catálogo completo ni certifica automáticamente calidad, cumplimiento o ejecución de procesos. Es una base trazable para ampliar cobertura sin perder el contexto de cada relación.

Si se configura una agenda de metadata, puede ser manual, diaria, semanal o mensual y sus snapshots quedan versionados. Comprueba la configuración efectiva antes de depender de ella: esta ruta no asume agendas automatizadas ni trabajos productivos activos.

## Referencias para continuar

- [Modelo de objetos y relaciones](/es/explicaciones/modelo-de-objetos-y-relaciones/)
- [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/)
- [Roles, capacidades y alcance](/es/referencia/roles-capacidades-y-alcance/)
- [Módulos y dependencias](/es/referencia/modulos-y-dependencias/)