Cómo diseñar un catálogo interno de aplicaciones

Introducción

Un catálogo interno de aplicaciones permite que una empresa deje de tratar su software como una suma de iconos, suscripciones y conocimientos personales y empiece a gestionarlo como una cartera comprensible. Su función es mostrar qué aplicaciones están reconocidas por la organización, para qué se utilizan, quién responde por ellas, qué importancia tienen y en qué momento de su ciclo de vida se encuentran.

Cuando una empresa utiliza pocas herramientas, esta información parece innecesaria. Todo el mundo sabe cuál es la aplicación de facturación, dónde se almacenan los documentos o qué servicio se utiliza para gestionar proyectos. El problema aparece cuando el entorno crece: se incorporan herramientas especializadas, aplicaciones SaaS, software instalado, servicios propios, pruebas temporales, integraciones y plataformas que amplían sus funciones. Entonces empieza a resultar difícil responder preguntas aparentemente sencillas.

¿Qué herramienta debe utilizarse para una tarea concreta? ¿Cuál está aprobada y cuál sigue en pruebas? ¿Quién es el responsable de una aplicación? ¿Qué sistemas son críticos? ¿Qué servicio se renueva el próximo trimestre? ¿Dónde se consulta su documentación? ¿Qué aplicaciones almacenan datos sensibles? ¿Cuál está pendiente de sustitución? ¿Qué herramientas parecen duplicadas? ¿Qué aplicación puede retirarse sin afectar a otros procesos?

Un catálogo interno bien diseñado responde a esas preguntas sin intentar convertirse en un manual de cada producto ni en un inventario puramente técnico. Actúa como una capa de gobierno entre la cartera de software y las personas que necesitan entenderla.

Este artículo explica cómo diseñar ese catálogo para una pequeña o mediana organización, qué campos merece la pena registrar, cómo diferenciarlo de inventario y documentación, qué estados y clasificaciones utilizar, cómo mantenerlo actualizado y, sobre todo, cómo convertirlo en una herramienta que ayude a tomar decisiones sobre selección, costes, seguridad, duplicidades, renovaciones y retirada de aplicaciones.

Índice

• Qué es realmente un catálogo interno de aplicaciones
• Catálogo, inventario y documentación: tres funciones distintas
• Qué problemas debe resolver el catálogo
• Definir qué debe aparecer en el catálogo
• Elegir correctamente la unidad de catalogación
• Campos mínimos de una ficha de aplicación
• Describir finalidad y uso autorizado
• Diseñar estados y ciclo de vida
• Clasificar criticidad e impacto
• Registrar responsables sin crear ambigüedad
• Representar usuarios, colectivos y accesos
• Catalogar datos y fuentes de verdad
• Representar integraciones y dependencias
• Registrar costes y renovaciones con utilidad práctica
• Añadir información de seguridad sin guardar secretos
• Incluir continuidad y recuperación de forma proporcional
• Relacionar el catálogo con la documentación
• Elegir dónde mantener el catálogo
• Diseñar vistas útiles para distintos usuarios
• Incorporar una aplicación al catálogo
• Actualizar el catálogo cuando cambia la realidad
• Representar sustitución, retirada y archivo
• Usar el catálogo para tomar decisiones
• Medir la calidad del catálogo
• Ejemplo práctico de catálogo para una pequeña empresa
• Método paso a paso para construirlo
• Errores frecuentes
• Preguntas frecuentes
• Conclusión

Qué es realmente un catálogo interno de aplicaciones

Un catálogo interno de aplicaciones es una relación estructurada de las herramientas que forman parte del entorno tecnológico de una organización, enriquecida con información funcional y de gobierno suficiente para comprender qué papel desempeña cada una.

No se limita a decir que existe una aplicación. Debe permitir responder al menos:

• qué función empresarial cumple;
• quién debe utilizarla;
• quién responde por ella;
• qué importancia tiene;
• qué datos relevantes maneja;
• qué otras aplicaciones dependen de ella;
• en qué estado se encuentra;
• dónde está la documentación asociada;
• cuándo debe revisarse;
• qué decisión de ciclo de vida existe sobre ella.

El catálogo representa aplicaciones, no simplemente tecnología

Una aplicación puede ser un servicio SaaS, un programa instalado, una solución autoalojada, una herramienta móvil, un sistema interno o una plataforma compuesta por varios componentes. El catálogo debe representar la unidad funcional que tiene sentido para la organización.

El catálogo es una fuente de orientación

También puede responder una pregunta dirigida al usuario: «¿qué herramienta está reconocida para realizar esta tarea?». Esta dimensión diferencia el catálogo de una lista exclusivamente administrativa.

El catálogo forma parte del gobierno

Cuando se actualiza correctamente, permite observar cómo evoluciona el ecosistema. Una aplicación puede pasar de evaluación a aprobada, de aprobada a restringida, de activa a sustitución y finalmente a retirada.

En ese sentido, el catálogo se relaciona con la arquitectura general explicada en cómo construir un ecosistema de aplicaciones que realmente funcione: no describe toda la arquitectura, pero ofrece una vista estructurada de las piezas que la componen.

Catálogo, inventario y documentación: tres funciones distintas

Uno de los errores más comunes consiste en intentar que una sola hoja o wiki sea a la vez inventario técnico, catálogo, documentación, gestor de contraseñas, monitorización y repositorio de procedimientos. El resultado suele ser demasiado grande para mantenerse y demasiado incompleto para cualquiera de esas funciones.

El inventario identifica

El inventario responde principalmente «¿qué existe?». Puede registrar servidores, aplicaciones, servicios, licencias, dispositivos o componentes técnicos. En un entorno amplio, una referencia útil es cómo inventariar servidores, aplicaciones y servicios.

El inventario tiende a ser exhaustivo y administrativo.

La documentación explica

La documentación responde «¿cómo utiliza y administra la organización esta aplicación?». Incluye decisiones, configuración diferencial, procedimientos, integraciones, recuperación, reglas de negocio y conocimiento necesario para operar.

Ese nivel de detalle corresponde a cómo documentar todas las aplicaciones utilizadas por una empresa.

El catálogo orienta y gobierna

El catálogo responde «¿qué aplicaciones forman parte de la cartera reconocida, para qué deben utilizarse, quién responde por ellas y en qué estado están?».

Puede apoyarse en el inventario y enlazar a la documentación, pero no debe duplicarlos.

Una misma aplicación puede aparecer en los tres

Por ejemplo, una herramienta de proyectos:

• el inventario registra proveedor, licencia y existencia;
• el catálogo indica que está aprobada para gestionar proyectos operativos, quién es responsable, su criticidad y su estado;
• la documentación explica qué tipos de proyecto se crean, qué estados se utilizan, cómo se administran usuarios y qué integraciones existen.

Separar estas funciones hace que cada pieza sea más pequeña, más clara y más fácil de mantener.

Qué problemas debe resolver el catálogo

Antes de diseñar columnas conviene definir qué decisiones debe soportar. Si no existe un propósito claro, el catálogo se convierte en otra tabla que nadie consulta.

Orientar a los usuarios

Debe ser posible saber qué aplicación corresponde a cada necesidad reconocida. Esto reduce el uso de herramientas paralelas por simple desconocimiento.

Detectar aplicaciones sin responsable

Una ficha sin propietario funcional o administrador es una señal de riesgo. La aplicación puede seguir utilizándose mientras nadie asume cambios, renovaciones o incidencias.

Mostrar aplicaciones en evaluación

Los pilotos y pruebas deben ser visibles para evitar que una herramienta temporal se convierta silenciosamente en una pieza permanente.

Facilitar renovaciones

El catálogo puede mostrar qué servicios se acercan a renovación, quién debe revisar su valor y si existe una decisión pendiente.

Detectar duplicidad

Agrupar por finalidad o capacidad permite localizar varias herramientas que compiten por la misma función.

Apoyar seguridad

Puede identificar aplicaciones críticas, con datos sensibles, expuestas a Internet o con requisitos especiales de acceso.

Apoyar continuidad

Permite distinguir qué herramientas necesitan recuperación prioritaria y cuáles pueden permanecer inactivas durante más tiempo.

Facilitar delegación

Una persona que asume responsabilidades tecnológicas puede empezar por el catálogo para entender el paisaje antes de profundizar en documentación técnica.

El catálogo alcanza valor cuando se utiliza para estas decisiones reales, no cuando se limita a contar aplicaciones.

Definir qué debe aparecer en el catálogo

El alcance debe ser suficientemente amplio para representar la cartera relevante, pero no tan amplio que incluya cada utilidad trivial instalada en un equipo.

Aplicaciones empresariales compartidas

Deben aparecer las herramientas utilizadas por varias personas o que sostienen procesos comunes.

Aplicaciones críticas aunque tengan pocos usuarios

Una aplicación puede ser utilizada únicamente por administración o por una persona técnica y seguir siendo esencial.

Servicios SaaS

Si almacenan datos, participan en procesos o generan coste recurrente, deben catalogarse.

Aplicaciones autoalojadas

También deben aparecer. La tecnología de despliegue puede registrarse como atributo, pero el catálogo general no debe depender de que la herramienta use Docker, una máquina virtual o instalación directa.

Existe un tratamiento específico para ese entorno en cómo crear un catálogo interno de aplicaciones Docker. El catálogo empresarial general debe situarse un nivel por encima.

Aplicaciones en evaluación

Si una prueba utiliza datos reales, requiere cuentas o puede terminar en producción, debe ser visible con estado de evaluación.

Herramientas personales con función empresarial

Si una aplicación personal almacena información corporativa o participa en un proceso, su existencia debe al menos ser detectada y evaluada.

Qué puede quedar fuera

Utilidades locales triviales, herramientas del sistema operativo o software sin impacto empresarial pueden mantenerse fuera si su inclusión no aporta decisiones útiles.

La regla puede ser: catalogar aquello cuya existencia, indisponibilidad, coste, acceso o retirada tenga relevancia organizativa.

Elegir correctamente la unidad de catalogación

La unidad de catalogación debe ser comprensible para quien consulta el catálogo. Una mala elección puede multiplicar fichas o esconder dependencias importantes.

Una ficha por aplicación funcional

Normalmente es la opción correcta. Si una plataforma de proyectos está formada internamente por base de datos, frontend y servicio de correo, el catálogo puede representar una sola aplicación y enlazar a la arquitectura técnica.

No crear una ficha por componente técnico

Eso corresponde al inventario de infraestructura. El catálogo debe evitar que el lector tenga que reconstruir mentalmente qué componentes forman un servicio.

Separar módulos cuando tienen vida propia

Una suite puede contener capacidades que se administran, licencian o gobiernan de manera independiente. Si un módulo tiene responsables, usuarios o decisiones de ciclo de vida propios, puede merecer una ficha separada.

Representar servicios compartidos

Identidad, almacenamiento, automatización o firma pueden utilizarse desde varias aplicaciones. Cuando tienen importancia funcional propia, deben aparecer como servicios del catálogo.

Evitar granularidad cambiante

Si unas fichas representan proveedores completos y otras representan funciones diminutas, los filtros pierden significado. Conviene definir una regla y aplicarla con consistencia.

La pregunta práctica es: «¿esta ficha representa algo sobre lo que la organización puede tomar una decisión independiente?». Si la respuesta es sí, probablemente sea una unidad válida.

Campos mínimos de una ficha de aplicación

Un catálogo útil no necesita empezar con cuarenta columnas. Es mejor disponer de diez campos actualizados que de cincuenta abandonados.

Una ficha mínima puede contener:

• nombre de la aplicación;
• finalidad;
• estado;
• criticidad;
• responsable funcional;
• administrador;
• colectivo de usuarios;
• modelo de provisión o ubicación;
• datos principales;
• proveedor;
• coste o referencia económica;
• fecha de renovación, cuando aplique;
• dependencias principales;
• enlace a documentación;
• fecha de última revisión.

Campos opcionales según necesidad

También pueden añadirse:

• URL de acceso;
• plan contratado;
• número de licencias;
• fuente de verdad asociada;
• clasificación de datos;
• tipo de autenticación;
• estado del backup;
• objetivo de recuperación;
• alternativa temporal;
• aplicación sustituta prevista;
• fecha de retirada;
• referencia contractual;
• área de negocio;
• procesos asociados.

Cada campo debe justificar su mantenimiento

Antes de añadir una columna conviene preguntar qué decisión permitirá tomar. Si nadie utilizará la información, será difícil mantenerla actualizada.

El catálogo no debe convertirse en un vertedero de metadatos. Debe contener información estable y accionable.

Describir finalidad y uso autorizado

La finalidad es uno de los campos más importantes porque explica por qué la aplicación existe.

Evitar descripciones comerciales

«Plataforma líder de productividad» no ayuda a decidir nada. La descripción debe utilizar lenguaje interno y concreto.

Ejemplos útiles:

• gestionar oportunidades comerciales hasta aceptación;
• planificar proyectos y asignar tareas operativas;
• almacenar documentación final de clientes;
• emitir facturas y conservar su registro;
• recibir solicitudes mediante formularios;
• mantener documentación técnica interna.

Definir límites de uso

Cuando una herramienta tiene muchas funciones, puede ser útil indicar qué no debe utilizarse como sistema principal.

Ejemplo: una aplicación de proyectos puede tener almacenamiento de archivos, pero la documentación definitiva debe conservarse en el repositorio documental.

Relacionar con procesos

Una aplicación puede intervenir en varias fases. El catálogo puede incluir procesos asociados o enlazar a un mapa como el descrito en cómo organizar aplicaciones por procesos de negocio.

La finalidad permite detectar deriva

Si años después la herramienta se utiliza para actividades muy diferentes a las que justificaron su incorporación, puede ser necesario revisar arquitectura, permisos o dependencia.

Diseñar estados y ciclo de vida

Un catálogo necesita más información que «activa» o «inactiva». Los estados permiten distinguir pruebas, producción, transición y retirada.

Un esquema sencillo puede ser:

Propuesta

La necesidad ha sido identificada, pero la aplicación todavía no está aprobada.

Evaluación

Se está probando o comparando. Su uso debe mantenerse limitado y reversible.

Aprobada

La herramienta ha superado el proceso de selección y puede utilizarse para la finalidad indicada.

Activa

Está implantada y forma parte de la operativa ordinaria.

Restringida

Sigue activa, pero no debe ampliar usuarios, funciones o datos porque existe una revisión o sustitución prevista.

En sustitución

Existe una herramienta o arquitectura nueva y se está realizando la transición.

En retirada

Ya no debe recibir nueva información; se están cerrando datos, integraciones, cuentas y contratos.

Retirada

Ha dejado de utilizarse. Puede mantenerse una ficha histórica mínima si existe valor de auditoría o referencia.

Estos estados impiden que las pruebas se conviertan accidentalmente en producción y hacen visible que una aplicación puede estar activa mientras su futuro ya está decidido.

Clasificar criticidad e impacto

La criticidad debe reflejar el impacto de una interrupción o pérdida, no el tamaño de la aplicación ni su precio.

Un esquema de cuatro niveles puede ser suficiente.

Auxiliar

Su indisponibilidad apenas afecta al trabajo y puede esperarse sin medidas especiales.

Importante

Su ausencia dificulta determinadas tareas, pero existe alternativa temporal o el proceso puede esperar.

Crítica

Su caída bloquea o degrada un proceso relevante y necesita recuperación prioritaria.

Esencial

Su indisponibilidad afecta a múltiples procesos o impide acceder a otras herramientas.

Criterios para asignar criticidad

• número de personas afectadas;
• procesos afectados;
• impacto económico u operativo;
• riesgo de pérdida de datos;
• existencia de alternativa manual;
• dependencias de otras aplicaciones;
• tiempo razonable de indisponibilidad.

La clasificación debe tener consecuencias. Una aplicación crítica puede exigir revisión de backup, acceso administrativo, continuidad y documentación más profunda. Si la etiqueta no cambia ninguna decisión, probablemente no aporta valor.

Registrar responsables sin crear ambigüedad

El campo «responsable» puede ser engañoso porque existen varios tipos de responsabilidad.

Responsable funcional

Responde por el uso empresarial. Puede explicar por qué existe la aplicación, qué proceso sostiene y si sigue aportando valor.

Administrador

Gestiona configuración, usuarios, permisos y aspectos operativos de la herramienta.

Responsable económico

Puede ser necesario cuando presupuesto o renovación pertenecen a otra función.

Responsable de datos

En determinadas aplicaciones puede existir una persona distinta que decide cómo se gobierna información relevante.

Evitar el responsable genérico

Poner «IT» o «Administración» puede ser insuficiente en una organización donde varias personas participan. El catálogo debe permitir identificar a quién acudir.

Registrar sustitución

Si un responsable cambia, la ficha debe actualizarse como parte del traspaso. Una aplicación sin propietario suele terminar con usuarios antiguos, permisos excesivos y renovaciones por inercia.

El catálogo ayuda a que las aplicaciones tengan dueño organizativo sin depender de quién las instaló originalmente.

Representar usuarios, colectivos y accesos

El catálogo no necesita copiar una lista completa de usuarios si esa información ya existe en la aplicación o en el sistema de identidad. Sí debe permitir entender quién debería utilizarla.

Colectivo de usuarios

Puede registrarse mediante funciones: comercial, administración, dirección, técnicos, proveedores o usuarios externos.

Número aproximado de usuarios

Ayuda a estimar impacto, licencias y esfuerzo de cambio.

Tipo de acceso

Puede ser individual, compartido, técnico, externo o administrativo. Las cuentas compartidas deberían hacerse visibles cuando sean inevitables.

Administrador principal y de respaldo

Las aplicaciones importantes no deberían depender de una sola persona para recuperar el control.

Enlace al proceso de altas y bajas

La ficha puede indicar cómo se gestionan accesos sin reproducir todo el procedimiento.

Para profundizar en esta dimensión puede utilizarse cómo organizar correctamente las cuentas de usuario de todas las aplicaciones.

El catálogo debe describir el modelo de acceso; la lista exacta de identidades pertenece al sistema que la gestione.

Catalogar datos y fuentes de verdad

Una aplicación puede ser poco crítica como interfaz y muy importante por la información que contiene. El catálogo debe reflejar esa diferencia.

Tipos de datos

Puede bastar con categorías:

• clientes;
• proveedores;
• facturación;
• proyectos;
• documentos;
• soporte;
• usuarios;
• analítica;
• configuración;
• información técnica.

Fuente de verdad

Cuando una aplicación tiene autoridad sobre un dato, conviene registrarlo. Esto evita que dos herramientas compitan por ser el lugar donde se corrige información.

Copias auxiliares

También puede indicarse que la aplicación recibe una copia pero no es la fuente oficial.

Datos sensibles

No hace falta describir cada campo. Una clasificación simple permite identificar dónde deben revisarse permisos, retención o protección.

Exportación

Puede registrarse si existe una vía razonable para recuperar los datos y dónde se documenta.

No almacenar datos reales en el catálogo

El catálogo describe qué información existe, no debe copiar clientes, documentos o credenciales.

Esta visión ayuda también a detectar duplicidades y preparar futuras migraciones.

Representar integraciones y dependencias

Un catálogo no necesita convertirse en un diagrama técnico completo, pero sí debe hacer visibles las dependencias que cambian la importancia de una aplicación.

Aplicaciones de las que depende

Por ejemplo, identidad, almacenamiento, correo o base de datos externa.

Aplicaciones que dependen de ella

Una herramienta aparentemente secundaria puede alimentar informes o procesos automáticos y ser más crítica de lo que parece.

Tipo de integración

Puede bastar con categorías: API, webhook, archivo, conector, correo, sincronización o intervención manual.

Finalidad de la conexión

«CRM → proyectos: crear proyecto cuando una oportunidad se acepta» aporta más valor que simplemente anotar «integrado con proyectos».

Responsable de la integración

Cuando la conexión es importante, alguien debe saber dónde se configura y cómo se diagnostica.

Enlazar, no duplicar

La documentación técnica detallada puede vivir fuera del catálogo. La ficha solo necesita suficiente información para reconocer el efecto de un cambio.

Cuando el diseño de las conexiones sea el problema principal, puede profundizarse en cómo integrar aplicaciones sin crear dependencias innecesarias.

Registrar costes y renovaciones con utilidad práctica

El catálogo puede ayudar a controlar gasto, pero no debe intentar sustituir contabilidad o gestión contractual.

Coste recurrente aproximado

Puede registrarse una cifra o categoría cuando sea útil para priorizar revisiones.

Modelo de licencia

Por usuario, uso, almacenamiento, transacciones, tarifa plana o combinación.

Número de licencias

Ayuda a detectar exceso de capacidad contratada.

Fecha de renovación

Es uno de los campos más accionables. Permite revisar la aplicación antes de que se renueve automáticamente.

Duración o compromiso

Una suscripción mensual y un contrato anual presentan distinta reversibilidad.

Responsable de revisar

La renovación debería tener dueño. De otro modo, la tarjeta decide por la organización.

Coste total fuera del catálogo

Cuando se necesita evaluar implantación, integración, administración y salida, el análisis completo puede enlazarse a cómo medir el coste total del software empresarial.

El catálogo debe ayudar a saber qué merece revisión económica, no convertirse en un sistema financiero paralelo.

Añadir información de seguridad sin guardar secretos

El catálogo puede ofrecer una vista valiosa de seguridad si utiliza campos simples.

Tipo de autenticación

Cuenta local, SSO, autenticación multifactor u otro mecanismo relevante.

Exposición

Interna, Internet, acceso remoto restringido o aplicación móvil.

Privilegios administrativos

Puede indicarse quién los mantiene y si existe una cuenta de recuperación.

Clasificación de datos

Permite filtrar aplicaciones que requieren mayor revisión.

Registro de actividad

Puede marcarse si existe auditoría cuando la trazabilidad es importante.

Ubicación de secretos

La ficha puede decir «credenciales en gestor corporativo» o enlazar al procedimiento, pero nunca debe guardar contraseñas, tokens, claves privadas o códigos de recuperación.

Fecha de revisión de accesos

Para aplicaciones críticas puede ser útil conocer cuándo se revisaron administradores y permisos.

La función del catálogo es señalar dónde hay que mirar, no concentrar información sensible que aumente el impacto de una filtración.

Incluir continuidad y recuperación de forma proporcional

El catálogo puede proporcionar una vista rápida de continuidad sin convertirse en un plan de recuperación completo.

Tolerancia a indisponibilidad

Puede utilizarse una clasificación simple:

• puede esperar varios días;
• debe recuperarse durante la jornada;
• debe recuperarse con prioridad;
• bloquea múltiples procesos.

Alternativa temporal

Si existe un procedimiento manual o una herramienta de contingencia, puede indicarse brevemente.

Protección de datos

Para aplicaciones con datos propios, puede registrarse si existe backup o exportación periódica y enlazar al procedimiento.

Recuperación administrativa

Una herramienta SaaS sin backup técnico propio puede seguir necesitando un método para recuperar control de la cuenta.

Dependencia externa

Proveedor, identidad, red o DNS pueden influir en la continuidad aunque no estén dentro de la aplicación.

La profundidad debe ser proporcional a criticidad. Una utilidad auxiliar no necesita el mismo detalle que un sistema esencial.

Relacionar el catálogo con la documentación

El catálogo debe actuar como índice hacia conocimiento más profundo.

Una ficha no debe contener manuales completos

Si una sección requiere varias páginas para explicar configuración, procedimientos o recuperación, pertenece a la documentación.

Enlaces útiles

Una ficha puede enlazar a:

• guía de administración;
• procedimiento de altas y bajas;
• diagrama de integraciones;
• plan de recuperación;
• contrato o referencia comercial;
• documentación oficial del proveedor;
• procedimiento de backup;
• instrucciones de actualización;
• decisión de selección original.

Evitar copiar contenido

La duplicación crea divergencias. Si una URL, procedimiento o responsable cambia, debería actualizarse una fuente principal.

El catálogo como puerta de entrada

Una persona debería poder abrir una ficha y saber dónde encontrar la información detallada sin buscar entre carpetas o correos.

Esta estructura permite que el catálogo sea compacto y la documentación profunda, cada una cumpliendo su función.

Elegir dónde mantener el catálogo

No hace falta comprar una plataforma específica para empezar. La herramienta debe adaptarse al tamaño y al modo de trabajo.

Hoja de cálculo

Es una excelente opción inicial. Permite columnas, filtros, validaciones y vistas rápidas. Puede ser suficiente durante años en una microempresa.

Base de datos ligera

Resulta útil cuando existen muchas relaciones, automatizaciones o necesidades de consulta estructurada.

Wiki o gestor documental

Puede funcionar bien si cada aplicación tiene una ficha más narrativa, aunque conviene mantener campos consistentes para facilitar filtros.

Herramienta de gestión interna

Una plataforma ya utilizada puede incorporar el catálogo si permite estructura, permisos y mantenimiento sencillo.

Evitar una herramienta demasiado sofisticada

Si el catálogo necesita un administrador especializado, puede terminar siendo otra aplicación difícil de mantener.

Una fuente principal

No conviene mantener simultáneamente una hoja, una wiki y un documento con listas distintas. Puede haber vistas y documentación complementaria, pero debe existir una fuente oficial para el estado de cada aplicación.

La calidad del catálogo depende más de su uso y actualización que del producto elegido para almacenarlo.

Diseñar vistas útiles para distintos usuarios

Un mismo catálogo puede servir a perfiles diferentes si permite filtrar la información sin mostrar todas las columnas todo el tiempo.

Vista para usuarios

Puede mostrar:

• aplicación;
• finalidad;
• quién debe utilizarla;
• URL;
• estado;
• enlace a guía de uso.

Vista para administración tecnológica

Puede añadir:

• responsables;
• criticidad;
• integraciones;
• autenticación;
• backup;
• fecha de revisión.

Vista económica

Puede filtrar:

• proveedor;
• coste;
• licencias;
• renovación;
• compromiso contractual.

Vista de ciclo de vida

Permite localizar aplicaciones en evaluación, restringidas, en sustitución o pendientes de retirada.

Vista de riesgos

Puede destacar aplicaciones críticas, sin responsable, sin exportación conocida o con revisión vencida.

Las vistas convierten el catálogo en una herramienta operativa. Una tabla enorme con todas las columnas visibles puede ser técnicamente completa y prácticamente inutilizable.

Incorporar una aplicación al catálogo

La entrada en el catálogo debería formar parte natural del proceso de selección e implantación.

Durante la evaluación

Puede crearse una ficha con estado «evaluación». Así se registra quién prueba la herramienta, para qué y hasta cuándo.

En la aprobación

Se completan finalidad, responsable, datos, coste, criticidad y decisión de uso.

Durante la implantación

Se añaden URL, administrador, documentación, integraciones y modelo de acceso.

Antes de producción

Conviene comprobar que la ficha tiene al menos:

• finalidad clara;
• responsable funcional;
• administrador;
• estado;
• criticidad;
• datos principales;
• información de acceso;
• referencia económica, si aplica;
• documentación básica;
• fecha de revisión.

Relacionar con la política de selección

Una organización que utilice una política de selección de software puede exigir que ninguna aplicación pase a estado activo sin su ficha mínima.

Así, el catálogo deja de ser un trabajo retrospectivo y empieza a crecer de forma controlada.

Actualizar el catálogo cuando cambia la realidad

El principal riesgo de un catálogo no es que empiece incompleto, sino que se vuelva falso.

Actualizar por eventos

La ficha debería revisarse cuando:

• cambia el responsable;
• cambia el plan contratado;
• se incorpora una integración;
• se modifica la finalidad;
• cambia la criticidad;
• se amplían datos almacenados;
• se modifica el modelo de acceso;
• se decide sustituir la aplicación;
• se retira.

Revisión periódica

Además de actualizar por evento, conviene una revisión periódica. La frecuencia depende del ritmo de cambios y criticidad.

Fecha de última revisión

Es un campo sencillo que permite diferenciar información reciente de una ficha abandonada.

Revisión basada en riesgo

Las aplicaciones críticas pueden revisarse con mayor frecuencia que herramientas auxiliares estables.

Responsable de mantener la ficha

Debe saberse quién actualiza. «El catálogo se mantiene entre todos» suele significar que no lo mantiene nadie.

La actualización debe formar parte de los cambios tecnológicos, no ser una tarea separada que se recuerda meses después.

Representar sustitución, retirada y archivo

Un catálogo maduro no solo incorpora aplicaciones. También muestra cuáles están saliendo.

Estado en sustitución

Debe indicar qué aplicación la reemplazará, si ya está decidido, y la fecha prevista de corte.

Estado en retirada

La herramienta ya no debería recibir nuevos usos. Se están cerrando integraciones, datos, cuentas o contratos.

Ficha retirada

Puede conservar una versión mínima:

• nombre;
• finalidad histórica;
• fecha de retirada;
• motivo;
• destino de los datos;
• aplicación sustituta;
• documentación histórica relevante.

No borrar demasiado pronto

Conservar una ficha mínima puede explicar años después por qué existen ciertos datos o referencias.

No conservar indefinidamente información inútil

La ficha histórica también puede archivarse o eliminarse cuando ya no exista necesidad.

El proceso operativo completo de cierre se desarrolla en cómo retirar aplicaciones antiguas sin perder información. El catálogo permite saber en qué etapa se encuentra esa retirada.

Usar el catálogo para tomar decisiones

El catálogo alcanza su verdadero valor cuando permite formular consultas que desembocan en acciones.

¿Qué aplicaciones no tienen responsable?

Puede generar una lista de revisión inmediata.

¿Qué aplicaciones críticas no tienen documentación suficiente?

Permite priorizar trabajo donde una incidencia tendría mayor impacto.

¿Qué servicios se renuevan en los próximos meses?

Facilita revisar valor, licencias y alternativas antes de pagar otro periodo.

¿Qué herramientas cumplen la misma finalidad?

Ayuda a detectar candidatos para el análisis desarrollado en cómo reducir el número de aplicaciones sin perder funcionalidades.

¿Qué aplicaciones están infrautilizadas?

El catálogo puede combinar usuarios, coste y finalidad para seleccionar candidatos que después se analicen con criterios de detección de aplicaciones infrautilizadas.

¿Qué aplicaciones dependen de una plataforma concreta?

Permite evaluar el impacto de cambiar un proveedor o una integración.

¿Qué aplicaciones tienen datos sensibles?

Facilita revisiones de permisos y controles.

¿Qué pruebas llevan demasiado tiempo abiertas?

Una vista de estado «evaluación» con antigüedad permite forzar una decisión: aprobar, ampliar justificadamente o cerrar.

¿Qué aplicaciones podrían ser difíciles de sustituir?

La combinación de criticidad, datos, integraciones y portabilidad permite identificar dependencias antes de que se conviertan en problemas.

Cuando el catálogo responde preguntas reales, mantenerlo deja de sentirse como documentación administrativa y se convierte en una herramienta de gestión.

Medir la calidad del catálogo

No hace falta medir decenas de indicadores. Unas pocas comprobaciones permiten saber si el catálogo es fiable.

Cobertura

¿Las aplicaciones relevantes están registradas?

Responsabilidad

¿Qué porcentaje tiene responsable funcional y administrador identificados?

Actualidad

¿Cuántas fichas llevan demasiado tiempo sin revisión?

Coherencia

¿Los estados, criticidad y categorías se utilizan con criterios comunes?

Utilidad

¿El catálogo se consulta durante renovaciones, auditorías, cambios o incidencias?

Calidad de enlaces

¿La documentación asociada sigue disponible?

Ciclo de vida

¿Las aplicaciones retiradas desaparecen del entorno o el catálogo solo acumula entradas?

Capacidad de responder preguntas

Una prueba práctica consiste en pedir a una persona autorizada que responda con el catálogo:

• qué aplicación se utiliza para una necesidad concreta;
• quién administra una herramienta;
• cuáles son críticas;
• qué servicios se renuevan pronto;
• cuáles están en evaluación;
• qué aplicaciones están pendientes de retirada.

Si esas respuestas requieren preguntar a varias personas, el catálogo todavía no está cumpliendo su función.

Ejemplo práctico de catálogo para una pequeña empresa

Imaginemos una empresa de diez personas que utiliza correo y calendario, CRM, gestor de proyectos, almacenamiento documental, facturación, firma electrónica, formularios y una herramienta interna de documentación.

En lugar de crear fichas técnicas exhaustivas, construye un catálogo con estos campos:

Primera decisión

La vista de renovaciones muestra que la herramienta A se renueva pronto mientras B sigue en evaluación. Esto obliga a decidir antes de pagar otro periodo.

Segunda decisión

El CRM y el gestor de proyectos almacenan algunos datos de cliente. El catálogo marca el CRM como fuente de verdad para información comercial y evita que ambos se traten como equivalentes.

Tercera decisión

Correo aparece como esencial porque también sostiene identidad y recuperación de otros servicios. Su importancia no se deduce únicamente de que «se use mucho».

Cuarta decisión

Al revisar responsables se descubre que la herramienta interna de documentación no tiene administrador de respaldo. Se corrige antes de que exista una incidencia.

Resultado

El catálogo no ha sustituido documentación, facturación ni administración de usuarios. Ha creado una vista que conecta esas áreas y permite decidir con mayor rapidez.

Método paso a paso para construirlo

1. Definir para qué se utilizará.

   Elegir preguntas concretas: aplicaciones aprobadas, responsables, criticidad, renovaciones, duplicidades y ciclo de vida.

2. Definir el alcance.

   Establecer qué tipos de herramientas deben aparecer y cuáles pueden quedar fuera.

3. Elegir la unidad de catalogación.

   Normalmente una ficha por aplicación funcional, no por componente técnico.

4. Partir del inventario existente.

   Recuperar nombres, proveedores y herramientas conocidas sin intentar documentarlas todavía.

5. Crear un conjunto mínimo de campos.

   Nombre, finalidad, estado, criticidad, responsable, usuarios, datos, proveedor, documentación y fecha de revisión forman una buena base.

6. Definir valores controlados.

   Estados y criticidad deben utilizar categorías conocidas para evitar que cada persona escriba variantes diferentes.

7. Completar primero aplicaciones críticas.

   Priorizar las herramientas cuya ausencia, pérdida o dependencia tendría mayor impacto.

8. Añadir responsables.

   Identificar propietario funcional y administrador.

9. Relacionar datos e integraciones.

   Registrar fuentes de verdad y dependencias principales sin duplicar diagramas técnicos.

10. Incorporar coste y renovación cuando aporte valor.

    Especialmente en aplicaciones recurrentes o con muchas licencias.

11. Enlazar documentación.

    El catálogo debe conducir hacia procedimientos y decisiones más detalladas.

12. Crear vistas.

    Usuarios, administración, renovaciones, riesgos y ciclo de vida pueden necesitar filtros diferentes.

13. Revisar incoherencias.

    Buscar aplicaciones sin responsable, sin finalidad clara, con estados ambiguos o con datos contradictorios.

14. Integrar el alta de nuevas aplicaciones.

    La ficha se crea durante evaluación y se completa antes de pasar a uso ordinario.

15. Integrar la retirada.

    Los estados deben mostrar sustitución, retirada y archivo.

16. Asignar mantenimiento.

    Definir quién actualiza la ficha y cuándo.

17. Usarlo en decisiones reales.

    Renovaciones, auditorías, consolidación, seguridad y continuidad deben empezar a consultar el catálogo.

18. Eliminar campos inútiles.

    Después de varios meses, cualquier dato que nadie use merece revisión.

La construcción puede ser gradual. Un catálogo con veinte fichas fiables es más útil que una base enorme que intenta descubrir y clasificar automáticamente cualquier software sin contexto empresarial.

Errores frecuentes

Confundir catálogo con inventario

Una lista de nombres y versiones identifica software, pero no explica su finalidad, estado ni responsabilidad.

Confundir catálogo con documentación completa

Si cada ficha contiene manuales extensos, será difícil mantener el conjunto. Conviene enlazar a documentación.

Crear demasiados campos al principio

La ambición inicial puede convertir el mantenimiento en una carga. Es mejor empezar con información que apoye decisiones reales.

No definir estados

Pruebas, producción y herramientas pendientes de retirada terminan mezcladas.

No definir criticidad

Todas las aplicaciones parecen igual de importantes y las prioridades desaparecen.

Usar descripciones de marketing

La finalidad debe explicar cómo se utiliza internamente.

Guardar secretos

El catálogo no es un gestor de contraseñas.

No distinguir responsable funcional y administrador

Puede terminar sin saberse quién decide sobre el valor de la aplicación y quién puede configurarla.

Mantener varias fuentes oficiales

Dos catálogos con estados diferentes son peor que uno incompleto.

Catalogar solo SaaS

Las aplicaciones instaladas o autoalojadas también forman parte del ecosistema.

Catalogar solo producción

Las pruebas pueden utilizar datos y generar dependencias. Deben ser visibles cuando tienen relevancia.

No registrar la fecha de revisión

Una ficha puede parecer precisa y llevar años desactualizada.

No utilizar el catálogo para retirar

Si el catálogo solo crece, terminará reflejando una cartera que también solo crece.

Automatizar sin validar contexto

Puede descubrirse técnicamente qué aplicaciones están instaladas, pero finalidad, criticidad, responsable y necesidad real requieren conocimiento humano.

Convertirlo en un proyecto de herramienta

Elegir durante semanas la plataforma perfecta para catalogar puede retrasar el objetivo principal: empezar a gobernar las aplicaciones.

Preguntas frecuentes

Conclusión

Diseñar un catálogo interno de aplicaciones significa crear una vista común y mantenible de la cartera de software. Su valor no está en acumular columnas, sino en hacer visibles las decisiones que normalmente quedan dispersas entre memoria, contratos, configuraciones y documentación.

El catálogo debe explicar qué aplicaciones están reconocidas, para qué se utilizan, qué estado tienen, quién responde por ellas, qué criticidad presentan, qué datos manejan y dónde puede encontrarse la información necesaria para administrarlas. Esa vista permite orientar a usuarios, preparar renovaciones, detectar duplicidades, revisar riesgos y controlar el ciclo de vida.

La clave está en mantener fronteras claras. El inventario identifica qué existe. La documentación explica cómo funciona y cómo se opera. El catálogo presenta la cartera desde una perspectiva funcional y de gobierno. Relacionar estas tres capas evita convertir una única herramienta en un repositorio inmanejable.

También debe ser un sistema vivo. Las aplicaciones entran en evaluación, se aprueban, cambian de criticidad, modifican sus responsables, se integran con otros sistemas y finalmente pueden ser sustituidas o retiradas. El catálogo debe acompañar esos cambios.

Un buen catálogo interno convierte aplicaciones dispersas en una cartera que puede consultarse, explicarse, revisarse y gobernarse con criterios comunes. Cuando esa información existe y se utiliza, la empresa depende menos de memoria informal y puede tomar decisiones tecnológicas con mayor claridad.

Para una pequeña organización no hace falta empezar con una plataforma sofisticada. Una tabla bien diseñada, unos estados consistentes, responsables identificados y una disciplina de actualización pueden proporcionar gran parte del valor. La sofisticación solo merece crecer cuando aumentan el número de aplicaciones y las decisiones que el catálogo debe soportar.