Cómo construir una política de selección de software

Introducción

Construir una política de selección de software no consiste en crear un procedimiento burocrático para impedir que las personas incorporen herramientas nuevas. Consiste en establecer unas reglas mínimas para que las decisiones sobre aplicaciones sean coherentes, comparables, documentadas y proporcionales al riesgo que introducen.

En muchas organizaciones, el software entra por caminos muy distintos. Una persona contrata una aplicación porque necesita resolver un problema urgente, un responsable propone una plataforma para mejorar un proceso, un proveedor recomienda una herramienta, una suite incorpora un módulo nuevo o un equipo comienza a utilizar un servicio gratuito que termina almacenando información empresarial. Cada decisión puede parecer razonable por separado y, sin embargo, el conjunto puede acabar lleno de duplicidades, dependencias, cuentas sin responsable y costes difíciles de explicar.

Una política de selección ayuda a evitar ese crecimiento por acumulación. No decide qué producto concreto debe utilizarse en todos los casos. Define cómo debe tomarse la decisión: qué problema hay que describir, qué alternativas deben revisarse, qué requisitos son obligatorios, quién puede aprobar una incorporación, qué debe documentarse, cuándo conviene realizar un piloto y qué ocurre después de contratar.

La política también sirve para proteger la capacidad de cambiar. Una aplicación no solo debe funcionar hoy. Debe poder administrarse con los recursos disponibles, permitir recuperar información, integrarse razonablemente con el ecosistema y tener una salida comprensible si deja de encajar.

Este artículo desarrolla una política práctica para pequeñas y medianas organizaciones que necesitan disciplina tecnológica sin convertir cada compra en un proyecto corporativo. El objetivo es crear un método repetible que permita decidir rápido en casos sencillos y exigir más análisis cuando el coste, la criticidad, los datos o la dependencia sean mayores.

Índice

• Qué es una política de selección de software
• Por qué una empresa necesita reglas comunes
• Definir el alcance de la política
• Principios que deben orientar cualquier selección
• Definir quién propone, evalúa, aprueba y administra
• Crear niveles de decisión según riesgo y coste
• Qué información debe contener una solicitud de nueva aplicación
• Obligar a definir el problema antes de buscar productos
• Revisar alternativas existentes antes de comprar
• Separar requisitos obligatorios, importantes y preferencias
• Criterios comunes para evaluar cualquier aplicación
• Política sobre datos, propiedad y portabilidad
• Política sobre identidad, permisos y seguridad
• Política sobre integraciones y automatizaciones
• Política sobre coste total y presupuesto
• Política sobre dependencia y reversibilidad
• Cuándo comparar varias candidatas formalmente
• Cuándo exigir un piloto
• Cómo gestionar excepciones sin destruir la política
• Registrar la decisión de aprobación o rechazo
• Conectar selección e implantación
• Revisar aplicaciones después de incorporarlas
• Vincular la política a renovaciones y ciclo de vida
• Tratar aplicaciones no autorizadas y shadow IT
• Plantilla mínima de política de selección
• Ejemplo práctico de aplicación de la política
• Niveles de madurez de la política
• Errores frecuentes
• Preguntas frecuentes
• Conclusión

Qué es una política de selección de software

Una política de selección de software es un conjunto de reglas que define cómo se decide si una aplicación puede incorporarse al ecosistema tecnológico de una organización. Su función no es recomendar marcas concretas, sino establecer un proceso de decisión suficientemente consistente.

Una política útil debería responder a preguntas como:

• ¿Quién puede proponer una aplicación?
• ¿Qué información debe aportar?
• ¿Qué problemas justifican incorporar una herramienta nueva?
• ¿Qué alternativas existentes deben revisarse primero?
• ¿Qué requisitos son obligatorios?
• ¿Qué riesgos deben analizarse?
• ¿Quién aprueba la decisión?
• ¿Cuándo hace falta comparar varias opciones?
• ¿Cuándo conviene hacer un piloto?
• ¿Qué documentación debe conservarse?
• ¿Quién será responsable de la aplicación una vez implantada?
• ¿Cuándo debe revisarse de nuevo?
• ¿Cómo se retira si deja de ser necesaria?

La política transforma decisiones aisladas en un sistema de gobierno. Una persona puede seguir tomando decisiones rápidas, pero lo hace dentro de unas reglas conocidas.

Política no significa comité permanente

Una pequeña empresa no necesita convocar varias reuniones para autorizar una aplicación auxiliar de bajo riesgo. La política debe ser proporcional. Puede permitir decisiones simplificadas cuando coste, datos y criticidad son bajos.

Política no significa catálogo cerrado

El objetivo tampoco es prohibir cualquier herramienta que no aparezca en una lista. El catálogo describe lo que existe. La política explica cómo se incorpora algo nuevo.

Política significa consistencia

Si dos necesidades similares aparecen en momentos distintos, deberían evaluarse con criterios comparables. Esa consistencia evita que una aplicación se apruebe solo porque quien la propuso insistió más o porque una demostración resultó convincente.

Por qué una empresa necesita reglas comunes

Sin política, cada nueva herramienta puede resolver un problema local y empeorar el sistema global. El coste no aparece necesariamente en el momento de contratar. Aparece después, cuando hay que administrar cuentas, revisar permisos, integrar datos, renovar licencias o sustituir la herramienta.

Evitar software impulsivo

Una política obliga a explicar qué problema se quiere resolver antes de comprar. Esa simple pregunta filtra muchas incorporaciones basadas en curiosidad, moda o demostraciones comerciales.

Reducir duplicidad

Antes de contratar, debe comprobarse qué herramientas existentes ya cubren parte de la necesidad. Esto reduce el riesgo descrito en cómo evitar tener veinte programas que hacen lo mismo.

Controlar datos

Cada aplicación nueva crea otro lugar donde puede quedar información empresarial. La política obliga a decidir qué datos almacenará, quién podrá acceder y cómo podrán recuperarse.

Controlar costes indirectos

La cuota mensual es solo una parte. También existen implantación, formación, soporte, administración, integraciones y salida.

Evitar dependencias invisibles

Una herramienta puede convertirse en crítica sin que nadie haya decidido conscientemente asumir esa dependencia. La política introduce una comprobación antes de que eso ocurra.

Facilitar futuras revisiones

Cuando se documenta por qué se eligió una aplicación, años después es posible comprobar si aquella razón sigue vigente.

El propósito no es ralentizar la tecnología, sino reducir decisiones que parecen rápidas al principio y generan años de complejidad después.

Definir el alcance de la política

Una política necesita dejar claro qué tipos de software cubre. Si el alcance es ambiguo, las personas encontrarán excepciones involuntarias y parte de la cartera crecerá fuera del proceso.

Puede incluir:

• aplicaciones SaaS;
• software instalado en ordenadores;
• aplicaciones móviles utilizadas con información empresarial;
• servicios autoalojados;
• plugins y extensiones con acceso a datos corporativos;
• plataformas de automatización;
• servicios de almacenamiento;
• aplicaciones contratadas por departamento;
• herramientas gratuitas utilizadas de forma recurrente;
• servicios que se integran con aplicaciones existentes.

Definir exclusiones razonables

No toda utilidad instalada requiere el mismo proceso. Un visor local sin acceso a datos sensibles puede tratarse con una regla simplificada. Una plataforma que almacenará clientes o administrará identidades necesita más análisis.

Usar el riesgo como criterio

La política puede establecer que ciertas características eleven automáticamente el nivel de revisión:

• almacenar datos personales;
• tener acceso administrativo;
• integrarse con sistemas críticos;
• ejecutar acciones automáticas;
• procesar pagos o información económica;
• convertirse en fuente principal de datos;
• utilizarse por muchas personas;
• tener un coste recurrente significativo.

Así se evita aplicar el mismo procedimiento a una pequeña herramienta auxiliar y a una plataforma que sostendrá un proceso crítico.

Principios que deben orientar cualquier selección

Una política duradera necesita principios más estables que los productos del momento. Estos principios sirven como filtros cuando aparecen tecnologías nuevas.

El problema precede a la herramienta

No se aprueba una aplicación porque sea interesante. Se aprueba porque existe una necesidad identificada que la herramienta resuelve suficientemente bien.

El proceso precede a las funciones

La selección debe comprobar cómo encaja el software en el trabajo real, no limitarse a comparar listas de características.

La mínima complejidad suficiente

Entre dos opciones válidas, conviene preferir la que resuelva el problema con menor carga razonable de administración, integración y aprendizaje.

Los datos deben seguir bajo control

Debe conocerse qué información entra, cómo puede recuperarse y qué ocurre al cancelar.

La seguridad debe ser proporcional al riesgo

No todas las herramientas necesitan controles corporativos avanzados, pero las que manejan información sensible o crítica sí deben cumplir requisitos mínimos.

La salida debe analizarse antes de la entrada

Una herramienta difícil de abandonar necesita mayor justificación.

La decisión debe poder explicarse

Meses después debería ser posible entender por qué se eligió esa aplicación y qué problema debía resolver.

La herramienta debe encajar en el ecosistema

Una excelente aplicación aislada puede ser una mala incorporación si duplica datos, crea dependencias o exige procesos paralelos.

Estos principios complementan el método individual de cómo elegir correctamente las aplicaciones que utilizará una empresa, pero aquí se convierten en reglas que deben repetirse en todas las selecciones.

Definir quién propone, evalúa, aprueba y administra

Una política falla si no asigna responsabilidades. No todas las decisiones requieren varias personas, pero sí debe saberse quién cumple cada papel.

Solicitante

Describe el problema, los usuarios afectados y el resultado esperado. Puede proponer una aplicación, pero no debería limitar la necesidad a un producto concreto si todavía no se han revisado alternativas.

Responsable funcional

Confirma que la necesidad existe y que la herramienta encaja con el proceso. Será una referencia para evaluar si la aplicación aporta valor después de implantarse.

Responsable técnico o tecnológico

Revisa integración, cuentas, datos, seguridad, administración, continuidad y compatibilidad con el ecosistema.

Aprobador económico

Cuando corresponda, valida presupuesto, modelo de licencias y costes recurrentes.

Administrador

Debe estar identificado antes de la implantación. Una herramienta sin administrador conocido empieza su vida como una futura aplicación abandonada.

Propietario de la decisión

En organizaciones pequeñas varios papeles pueden recaer en una misma persona. Lo importante es que las responsabilidades existan, aunque no se conviertan en cargos formales.

Crear niveles de decisión según riesgo y coste

La mejor forma de evitar burocracia es utilizar niveles. Cuanto mayor sea el impacto potencial, mayor será la evidencia exigida.

Nivel 1: herramienta auxiliar de bajo riesgo

Características posibles:

• coste bajo;
• uno o pocos usuarios;
• sin datos sensibles;
• sin integraciones críticas;
• fácil de cancelar;
• sin impacto relevante sobre otros procesos.

Puede aprobarse mediante una revisión breve.

Nivel 2: aplicación operativa

Almacena información empresarial, la utilizan varias personas o participa en un proceso regular. Requiere requisitos claros, revisión de datos, permisos, coste y alternativas.

Nivel 3: aplicación crítica o estructural

Puede convertirse en fuente principal, afectar a muchas personas, integrarse con varios sistemas o ser difícil de sustituir. Debe exigir comparación más rigurosa, piloto cuando proceda, análisis de salida y documentación completa.

Nivel 4: excepción estratégica

Una solución puede superar umbrales de coste o dependencia y seguir siendo razonable por su valor. La política debe permitir esa excepción, pero exigir que la justificación quede explícita.

Los niveles evitan dos extremos: aprobar todo sin control o someter cada utilidad a un procedimiento desproporcionado.

Qué información debe contener una solicitud de nueva aplicación

Una solicitud útil puede ser breve. Lo importante es que obligue a describir la necesidad antes de discutir productos.

Los campos mínimos pueden ser:

• problema que se quiere resolver;
• personas o procesos afectados;
• frecuencia del problema;
• resultado esperado;
• herramientas actuales relacionadas;
• alternativas ya consideradas;
• aplicación propuesta, si existe;
• datos que utilizará;
• usuarios previstos;
• integraciones necesarias;
• coste estimado;
• responsable funcional;
• administrador previsto;
• fecha deseada de implantación.

La solicitud no debe ser una defensa comercial

No necesita copiar las ventajas del proveedor. Debe explicar el contexto empresarial.

Debe permitir responder «no» o «todavía no»

Una buena política no obliga a elegir una aplicación cada vez que se presenta una necesidad. Puede concluir que el problema debe resolverse con una herramienta existente, un cambio de proceso o una prueba limitada.

Puede adaptarse al nivel de decisión

Las herramientas pequeñas utilizan una versión reducida; las críticas necesitan más detalle.

Obligar a definir el problema antes de buscar productos

Una de las reglas más valiosas consiste en impedir que la selección empiece con una lista de marcas. Primero se describe qué está ocurriendo.

Expresiones como «necesitamos un CRM mejor», «queremos una herramienta de IA» o «hace falta un gestor de proyectos» todavía no definen el problema.

Una descripción útil sería:

• las oportunidades llegan por varios canales y no existe un responsable común;
• los proyectos no muestran una próxima acción clara;
• los documentos se duplican entre varias carpetas;
• la misma información se introduce en tres sistemas;
• un proceso requiere seguimiento manual diario;
• los permisos no pueden diferenciarse con la herramienta actual.

Distinguir causa y síntoma

Si el problema es que nadie ha definido quién aprueba un paso, comprar software no resolverá la ambigüedad.

Definir un resultado observable

La política debería pedir una frase que describa cómo se reconocerá la mejora. Por ejemplo: «toda oportunidad debe tener responsable, estado y siguiente acción».

Relacionar con el proceso

Cuando la necesidad atraviesa varias aplicaciones, conviene revisar dónde encaja dentro del flujo. El mapa descrito en cómo organizar aplicaciones por procesos de negocio ayuda a evitar decisiones aisladas.

Revisar alternativas existentes antes de comprar

La política debe exigir una comprobación mínima de alternativas. No para bloquear nuevas herramientas, sino para evitar software innecesario.

Usar mejor una aplicación existente

Puede que la función ya exista pero no esté configurada, activada o conocida.

Simplificar el proceso

Una necesidad puede desaparecer eliminando pasos o aclarando responsabilidades.

Resolver temporalmente de forma manual

Cuando el volumen es muy bajo, una aplicación nueva puede añadir más administración que valor.

Ampliar una plataforma actual

Un módulo adicional puede ser razonable si cubre suficientemente la necesidad y reduce integraciones.

Incorporar una aplicación especializada

Debe justificarse cuando aporta una ventaja clara frente a las opciones existentes.

No hacer nada todavía

Si el problema es pequeño, poco frecuente o inestable, esperar puede ser la mejor decisión.

Esta comprobación obliga a que una nueva aplicación compita no solo contra otras candidatas, sino también contra el sistema actual.

Separar requisitos obligatorios, importantes y preferencias

La política debe exigir prioridades. Una lista donde todo es imprescindible termina haciendo imposible una selección racional.

Obligatorios

Si una aplicación no cumple uno, queda descartada. Pueden incluir:

• exportación de datos;
• determinados permisos;
• multiusuario;
• autenticación reforzada;
• compatibilidad con un sistema existente;
• acceso desde dispositivos concretos;
• historial de cambios;
• requisitos legales o contractuales.

Importantes

Influyen mucho en la decisión, pero puede existir una solución alternativa aceptable.

Preferencias

Interfaz, comodidad o funciones deseables que no deben desplazar requisitos críticos.

No requeridas

También conviene identificar capacidades que no justifican pagar un plan superior.

La política puede exigir que los requisitos se definan antes de comparar productos. Así se evita ajustar las reglas después de enamorarse de una opción.

Criterios comunes para evaluar cualquier aplicación

Los criterios concretos varían según el caso, pero una política debería mantener una estructura común.

Adecuación funcional

¿Resuelve el proceso real y sus excepciones principales?

Usabilidad

¿Las personas pueden realizar las tareas habituales con una fricción razonable?

Datos

¿Qué almacena, cómo se importa, cómo se exporta y qué ocurre al cancelar?

Identidad y permisos

¿Permite cuentas individuales, roles adecuados y recuperación administrativa?

Integración

¿Puede conectarse de forma mantenible con los sistemas que realmente lo necesitan?

Administración

¿Cuánto trabajo recurrente exige para usuarios, configuración, soporte y revisiones?

Continuidad

¿Qué ocurre si el servicio deja de estar disponible?

Proveedor

¿Existe soporte suficiente, condiciones comprensibles y una evolución razonable?

Coste total

¿Qué coste introduce durante todo su ciclo de vida?

Reversibilidad

¿Puede sustituirse con un esfuerzo aceptable?

Estos criterios no pretenden repetir el análisis detallado de cada herramienta. La política los convierte en un marco obligatorio que debe considerarse antes de aprobar.

Política sobre datos, propiedad y portabilidad

La información suele durar más que la aplicación. Por eso cualquier política de selección debe incluir reglas sobre datos.

Identificar qué datos almacenará

No es lo mismo una aplicación auxiliar sin información relevante que un sistema que guarda clientes, contratos, proyectos o históricos.

Conocer la titularidad de la cuenta

Las aplicaciones empresariales importantes deberían estar contratadas mediante identidades controladas por la organización.

Exigir exportación proporcional a la criticidad

Cuanto más importante sea la información, más exigente debe ser la comprobación de exportación.

Revisar adjuntos y relaciones

Exportar una tabla puede ser insuficiente si el valor está en archivos, comentarios o relaciones entre registros.

Definir retención al cancelar

Debe conocerse cuánto tiempo conserva el proveedor la información y qué debe hacer la empresa antes de cerrar.

Evitar datos duplicados sin autoridad

Si la herramienta va a mantener información que ya existe en otro sistema, la política debe exigir una regla de fuente de verdad.

La portabilidad no elimina la dependencia, pero evita que una decisión tecnológica se convierta en una pérdida de control sobre la información.

Política sobre identidad, permisos y seguridad

La seguridad de una aplicación debe evaluarse según lo que podrá hacer y la información que manejará.

Cuentas individuales

Las herramientas compartidas deberían permitir identificar usuarios cuando la trazabilidad sea relevante.

Administradores conocidos

Debe existir al menos una identidad administrativa controlada por la organización.

Autenticación adecuada

Las aplicaciones críticas deberían ofrecer mecanismos de autenticación proporcionales al riesgo.

Roles y permisos

La política puede exigir que el acceso se limite a lo necesario y que la herramienta permita diferenciar funciones cuando el proceso lo requiera.

Recuperación

La cuenta administrativa debe poder recuperarse sin depender exclusivamente de una persona o dispositivo.

Registro de actividad

Cuando la aplicación modifica información crítica, puede ser necesario conservar historial suficiente para investigar cambios.

Revisión periódica

La seguridad no termina al contratar. Usuarios, permisos y administradores deben revisarse durante el ciclo de vida.

Una política común evita que cada aplicación resuelva identidad y recuperación con criterios completamente diferentes.

Política sobre integraciones y automatizaciones

Las integraciones pueden convertir una aplicación aparentemente pequeña en una pieza estructural. Por eso deben formar parte de la selección desde el principio.

Integrar solo con propósito

Cada conexión debería eliminar trabajo, reducir errores o permitir un flujo necesario.

Preferir mecanismos soportados

APIs, webhooks, importaciones estructuradas o conectores documentados suelen ser más mantenibles que automatizaciones basadas en interfaces cambiantes.

Documentar origen y destino

Debe conocerse qué dato se mueve, por qué, con qué frecuencia y quién responde cuando falla.

Evitar cuentas personales

Una integración crítica no debería depender de la cuenta de quien la configuró.

Valorar coste de integración

Un producto económico puede exigir conectores adicionales o desarrollo continuo.

Valorar la salida

Si varias aplicaciones dependen de la nueva herramienta, una futura sustitución será más difícil.

Cuando las conexiones son una parte central de la decisión, conviene aplicar criterios de integración sin dependencias innecesarias.

Política sobre coste total y presupuesto

La política debe impedir que la decisión se reduzca a la cuota mensual.

El coste puede incluir:

• licencias;
• usuarios adicionales;
• módulos;
• almacenamiento;
• implantación;
• migración de datos;
• formación;
• integraciones;
• administración;
• soporte;
• coste de salida.

Definir umbrales

La empresa puede establecer que por debajo de cierto coste una decisión siga un proceso simplificado, siempre que no existan riesgos elevados de datos o seguridad.

Separar coste y valor

Una herramienta barata puede ser innecesaria. Una más cara puede estar justificada si sustituye procesos costosos o reduce riesgo.

Calcular coste en horizonte razonable

Para aplicaciones importantes conviene mirar al menos varios años o el periodo en el que se espera depender de ellas.

Revisar cómo escala el precio

El modelo por usuario, contactos, almacenamiento o automatizaciones puede cambiar mucho el coste futuro.

Para decisiones significativas, la política puede apoyarse en el enfoque de cómo medir el coste total del software empresarial.

Política sobre dependencia y reversibilidad

Una aplicación que será difícil de sustituir debe superar un umbral de decisión más alto.

Dependencia de datos

¿Puede recuperarse la información de forma útil?

Dependencia de configuración

¿Campos, automatizaciones y plantillas quedarán atrapados dentro de la plataforma?

Dependencia de usuarios

¿Cuántas personas tendrán que reaprender su trabajo si cambia?

Dependencia de integraciones

¿Cuántos procesos externos dependerán de ella?

Dependencia económica

¿Un cambio de precio afectaría a una función crítica?

Dependencia de una persona

¿Solo alguien concreto sabrá administrarla?

Reversibilidad

La política puede clasificar decisiones como fácilmente reversibles, moderadas o difíciles de revertir.

Cuanto menor sea la reversibilidad, mayor debería ser la exigencia de pruebas, documentación y análisis previo. El objetivo no es evitar toda dependencia, sino asumirla de manera consciente.

Cuándo comparar varias candidatas formalmente

No toda necesidad exige estudiar cinco productos. La política debe indicar cuándo una comparación formal aporta valor.

Comparación simplificada

Puede bastar cuando:

• el riesgo es bajo;
• el coste es reducido;
• la decisión es fácilmente reversible;
• la necesidad es auxiliar;
• una alternativa existente encaja claramente.

Comparación formal

Conviene cuando:

• la aplicación será crítica;
• almacenará información importante;
• tendrá muchos usuarios;
• requerirá migración;
• se integrará con varios sistemas;
• el coste recurrente es significativo;
• la salida futura será difícil.

Mismas reglas para todas las candidatas

Las alternativas deben evaluarse con requisitos y escenarios equivalentes. De otro modo, la comparación se convierte en una colección de impresiones.

El método detallado pertenece al artículo cómo comparar aplicaciones antes de implantarlas. La política simplemente define cuándo ese nivel de comparación es obligatorio.

Cuándo exigir un piloto

Un piloto reduce incertidumbre cuando la decisión es importante y no puede resolverse leyendo documentación o viendo una demostración.

Situaciones que justifican piloto

• el proceso tiene muchas excepciones;
• la adopción de usuarios es incierta;
• la integración es crítica;
• el coste de migración será alto;
• la aplicación sustituirá una herramienta consolidada;
• la dependencia futura será elevada;
• la función prometida es difícil de validar de otra forma.

El piloto debe tener criterios de éxito

Antes de empezar conviene definir qué se medirá:

• tiempo;
• errores;
• calidad del resultado;
• facilidad de uso;
• integración;
• administración;
• funciones que faltan;
• incidencias observadas.

El piloto debe ser reversible

No conviene migrar toda la información ni cancelar la herramienta actual para comprobar después si la alternativa funciona.

La política transforma el piloto en una herramienta de decisión, no en una prueba indefinida que termina convirtiéndose por inercia en producción.

Cómo gestionar excepciones sin destruir la política

Toda política necesita excepciones. Lo importante es que sean explícitas y trazables.

Urgencia operativa

Puede ser necesario incorporar una herramienta rápidamente para resolver una incidencia o necesidad temporal. La política puede permitir autorización provisional con revisión posterior.

Requisito de cliente o proveedor

Una relación externa puede obligar a utilizar una plataforma concreta. La excepción debe documentar alcance, datos y tiempo previsto.

Herramienta especializada sin alternativa

Puede aprobarse aunque tenga mayor coste o dependencia si la función es necesaria y no existe sustituto razonable.

Prueba temporal

Una aplicación puede utilizarse durante un periodo limitado sin convertirse automáticamente en estándar corporativo.

La excepción debe caducar

Una buena práctica es asignar fecha de revisión. Si no existe caducidad, lo provisional tiende a convertirse en permanente.

Registrar el motivo

La política se debilita cuando las excepciones son informales. Se fortalece cuando puede explicar por qué una decisión concreta se apartó de la regla general.

Registrar la decisión de aprobación o rechazo

La documentación de una selección no necesita ser extensa. Una ficha breve puede conservar el razonamiento esencial.

Conviene registrar:

• problema;
• resultado esperado;
• aplicación elegida;
• alternativas consideradas;
• requisitos decisivos;
• riesgos principales;
• coste previsto;
• responsable funcional;
• administrador;
• fecha de aprobación;
• fecha de revisión;
• motivo del rechazo, si procede.

Documentar también los «no»

Una aplicación descartada puede volver a proponerse meses después. Conservar una nota evita repetir todo el análisis si las condiciones no han cambiado.

Registrar supuestos

Si la decisión depende de que existan diez usuarios, un precio concreto o determinada integración, conviene anotarlo. Cuando esos supuestos cambien, puede ser necesario revisar la elección.

Evitar informes gigantes

La documentación debe ser proporcional. El objetivo es conservar conocimiento de decisión, no crear un expediente burocrático innecesario.

Conectar selección e implantación

Una aplicación aprobada todavía no forma parte correctamente del ecosistema. La política debe definir el paso de decisión a producción.

Crear cuentas bajo control empresarial

La titularidad debe quedar clara desde el principio.

Configurar usuarios y permisos

No conviene empezar con acceso total «para simplificar» y esperar corregirlo después.

Migrar datos con criterio

Solo debe incorporarse la información necesaria, verificando estructura e integridad.

Configurar integraciones

Las conexiones aprobadas deben documentarse y utilizar cuentas técnicas cuando corresponda.

Preparar soporte y administración

Debe saberse quién gestiona incidencias, altas, bajas y cambios de configuración.

Formar a los usuarios

La adopción forma parte del valor esperado. Una aplicación no crea beneficio si las personas continúan trabajando fuera de ella.

Actualizar el inventario

La nueva herramienta debe aparecer en la documentación del ecosistema.

La ejecución detallada se desarrolla en cómo implantar una nueva aplicación sin generar caos. La política debe garantizar que ninguna aprobación termina simplemente en «ya está contratada».

Revisar aplicaciones después de incorporarlas

Una política de selección no termina con la contratación. Las hipótesis iniciales deben comprobarse.

Revisión temprana

Después de un periodo razonable conviene revisar:

• si los usuarios la utilizan;
• si el problema original ha mejorado;
• si aparecieron funciones faltantes;
• si se crearon procesos paralelos;
• si el coste real coincide con lo previsto;
• si la administración resulta sostenible;
• si las integraciones funcionan;
• si existen permisos excesivos.

Revisión periódica

Una aplicación que fue adecuada puede dejar de serlo. Cambian procesos, precios, usuarios y alternativas.

Conservar la pregunta original

La revisión debe volver al problema que justificó la herramienta. Si ya no existe o la aplicación no lo resuelve, su permanencia merece cuestionarse.

Esta disciplina ayuda a detectar a tiempo herramientas que empiezan a quedar infrautilizadas, aspecto tratado específicamente en cómo detectar aplicaciones infrautilizadas.

Vincular la política a renovaciones y ciclo de vida

Las renovaciones son un momento natural para revisar decisiones sin crear reuniones adicionales.

Antes de renovar

Conviene comprobar:

• usuarios activos;
• licencias necesarias;
• uso de funciones;
• coste actualizado;
• alternativas existentes;
• integraciones vigentes;
• problemas de soporte;
• capacidad de exportación;
• si la razón original sigue siendo válida.

Renovación automática no debe significar revisión automática

La tarjeta puede renovar el servicio sin intervención, pero la organización debe conservar un punto de control.

Reducir licencias antes de eliminar la aplicación

A veces el problema no es la herramienta, sino un exceso de usuarios contratados.

Retirar cuando deja de aportar valor

La política debe contemplar el final del ciclo de vida. El cierre ordenado se desarrolla en cómo retirar aplicaciones antiguas sin perder información.

Incorporación, revisión y retirada forman parte del mismo gobierno. Una buena política no solo decide qué entra; también ayuda a decidir qué debe salir.

Tratar aplicaciones no autorizadas y shadow IT

Las herramientas utilizadas fuera del proceso formal no siempre aparecen por irresponsabilidad. Muchas nacen porque una necesidad real no estaba bien resuelta.

No empezar por prohibir

Primero conviene entender por qué se utiliza la aplicación, qué problema resuelve y qué información contiene.

Clasificar el riesgo

Una utilidad personal sin datos críticos no tiene el mismo impacto que un servicio que almacena clientes o credenciales.

Regularizar cuando aporta valor

Si la herramienta resuelve bien una necesidad, puede pasar por el proceso normal y convertirse en aplicación aprobada.

Sustituir cuando existe una alternativa adecuada

Si duplica una función ya cubierta, conviene migrar el uso al sistema oficial.

Retirar cuando el riesgo es desproporcionado

Una herramienta puede no ser aceptable si no permite controlar acceso, recuperar información o cumplir requisitos básicos.

Aprender del caso

Si aparecen muchas herramientas no autorizadas para la misma necesidad, probablemente la política o el ecosistema oficial tienen un hueco.

Una política eficaz reduce shadow IT ofreciendo un camino razonable para proponer soluciones, no simplemente cerrando la puerta a cualquier cambio.

Plantilla mínima de política de selección

Una pequeña empresa puede comenzar con una política de una o dos páginas. Un esquema práctico podría ser:

1. Objetivo

Garantizar que las aplicaciones incorporadas resuelvan necesidades reales, encajen en el ecosistema y puedan administrarse y sustituirse con un riesgo razonable.

2. Alcance

Aplicable a aplicaciones SaaS, software instalado, extensiones, servicios autoalojados y herramientas que almacenen o procesen información empresarial.

3. Principios

• problema antes que producto;
• revisar alternativas existentes;
• mínima complejidad suficiente;
• control de datos;
• seguridad proporcional;
• coste total;
• reversibilidad;
• responsable identificado.

4. Niveles de decisión

Proceso simplificado para bajo riesgo, revisión estándar para aplicaciones operativas y revisión reforzada para aplicaciones críticas.

5. Información mínima

Problema, usuarios, datos, coste, alternativa, responsable, integraciones y resultado esperado.

6. Criterios de evaluación

Funcionalidad, usabilidad, datos, seguridad, integración, administración, continuidad, coste y salida.

7. Aprobación

Responsable definido según nivel de decisión.

8. Implantación

Cuentas corporativas, permisos, documentación, inventario e integraciones controladas.

9. Revisión

Revisión inicial tras la implantación y después en renovaciones o cambios importantes.

10. Retirada

Exportación, desconexión, cierre de accesos, cancelación y actualización documental.

11. Excepciones

Permitidas con motivo, responsable y fecha de revisión.

Esta plantilla no pretende ser un reglamento universal. Debe adaptarse al tamaño, riesgo y velocidad de cambio de la organización.

Ejemplo práctico de aplicación de la política

Imaginemos una empresa de ocho personas que recibe solicitudes por correo y formulario. Un responsable propone contratar una nueva herramienta para centralizar seguimiento y recordatorios.

1. Solicitud

El problema se describe así: algunas solicitudes no tienen responsable ni próxima acción visible y el seguimiento depende de bandejas personales.

2. Nivel de decisión

La futura aplicación almacenará datos de clientes y será utilizada por cinco personas. Se clasifica como aplicación operativa y necesita revisión estándar.

3. Alternativas internas

La empresa comprueba si alguna herramienta actual puede resolver el problema. Una aplicación existente permite registrar contactos, pero no gestionar adecuadamente estados y próximas acciones.

4. Requisitos

Se definen como obligatorios:

• cuentas individuales;
• responsable por registro;
• estado configurable;
• próxima acción;
• exportación de datos;
• historial básico;
• permisos suficientes;
• uso desde navegador.

5. Comparación

Se estudian tres alternativas con los mismos escenarios. Una queda descartada porque no exporta correctamente el histórico. Otra exige un plan demasiado alto para los permisos necesarios.

6. Piloto

La tercera se prueba con un subconjunto de oportunidades durante unas semanas. Se observa reducción de solicitudes sin seguimiento y buena adopción.

7. Aprobación

La decisión se documenta con coste, responsable, datos almacenados y fecha de revisión.

8. Implantación

Se crean cuentas corporativas, se importan solo datos activos, se configura el formulario y se actualiza el inventario.

9. Revisión posterior

Al cabo de un periodo de uso se comprueba si el problema inicial realmente ha mejorado y si el número de licencias sigue siendo adecuado.

El valor de la política no estuvo en hacer la decisión más lenta. Estuvo en impedir que empezara por «me gusta esta aplicación» y en dejar una trazabilidad suficiente para revisarla después.

Niveles de madurez de la política

Una organización puede implantar la política gradualmente.

Nivel 1: preguntas mínimas

Antes de contratar se exige problema, coste, responsable y datos utilizados.

Nivel 2: revisión de alternativas

Se comprueba sistemáticamente si una herramienta existente ya cubre la necesidad.

Nivel 3: criterios comunes

Funcionalidad, datos, seguridad, integración, coste y salida se revisan de forma consistente.

Nivel 4: niveles de decisión y pilotos

Las aplicaciones críticas reciben más análisis y se utilizan pruebas cuando existe incertidumbre importante.

Nivel 5: ciclo de vida completo

La política conecta incorporación, inventario, renovaciones, revisión de valor, consolidación y retirada.

Una microempresa no necesita empezar en el nivel más avanzado. Incluso un formulario sencillo con diez preguntas puede reducir mucho la incorporación impulsiva de software.

La madurez consiste en que las decisiones importantes dejen de depender exclusivamente de memoria, entusiasmo o costumbre.

Errores frecuentes

Convertir la política en burocracia

Si una aplicación pequeña necesita el mismo procedimiento que una plataforma crítica, las personas buscarán caminos alternativos.

Definir la política solo como lista de herramientas permitidas

Eso no explica cómo evaluar necesidades nuevas ni qué hacer cuando cambia el mercado.

Empezar por el producto

La política debe exigir una necesidad antes de una marca.

No revisar aplicaciones existentes

La selección de software nuevo debe comenzar mirando qué capacidades ya están contratadas.

No asignar responsable

Una herramienta sin propietario funcional o administrador termina acumulando riesgo.

Analizar seguridad sin mirar usabilidad

Una aplicación muy segura que nadie utiliza correctamente puede crear procesos paralelos menos controlados.

Analizar precio sin coste total

La cuota pequeña puede ocultar implantación, conectores o administración.

No pensar en la salida

La portabilidad se descubre demasiado tarde si no se revisa antes de contratar.

Exigir comparaciones innecesarias

No toda aplicación auxiliar requiere tres proveedores y una matriz de puntuación.

No permitir excepciones

Una política rígida puede bloquear necesidades legítimas y fomentar herramientas fuera de control.

Permitir excepciones sin fecha

Lo temporal se convierte fácilmente en permanente.

No revisar después de implantar

La selección se basa en expectativas. La revisión posterior comprueba si realmente se cumplieron.

No conectar la política con renovaciones

Las herramientas pueden seguir años por inercia aunque la razón original haya desaparecido.

Copiar una política de una gran empresa

Una pequeña organización necesita disciplina, no una estructura de aprobación diseñada para cientos de personas.

Preguntas frecuentes

Conclusión

Construir una política de selección de software significa convertir decisiones tecnológicas aisladas en un proceso repetible. La empresa deja de incorporar herramientas únicamente por urgencia, costumbre o entusiasmo y empieza a exigir una explicación mínima sobre el problema, el valor esperado, los datos, el coste, la administración y la dependencia que se creará.

La política debe ser proporcional. Las aplicaciones auxiliares y reversibles necesitan poca fricción. Las plataformas críticas, con muchos usuarios, datos importantes o integraciones complejas, merecen una evaluación más rigurosa y, cuando exista incertidumbre, un piloto.

También debe conectar selección con ciclo de vida. Una herramienta aprobada necesita responsable, implantación ordenada, revisión posterior y un momento en el que vuelva a cuestionarse su valor. Las renovaciones son una oportunidad natural para comprobar que la razón original sigue vigente.

Las excepciones no debilitan la política si están justificadas y tienen fecha de revisión. Lo que la debilita es que las decisiones ocurran fuera del sistema sin que nadie pueda explicar después por qué una aplicación entró, qué datos contiene o quién la administra.

Una buena política de selección no intenta evitar decisiones equivocadas mediante más burocracia, sino hacer que cada decisión importante sea consciente, comparable, documentada y reversible en una medida razonable.

Cuando esta disciplina se aplica de forma consistente, el ecosistema crece con más orden. Se reducen duplicidades, las aplicaciones tienen responsables claros, los datos quedan más controlados y la organización puede incorporar nuevas tecnologías sin convertir cada necesidad en otra suscripción difícil de gobernar.