Cuándo crear un portal interno para tu empresa

Un portal interno no es simplemente una intranet

Puede existir una intranet principalmente informativa: noticias internas, documentos generales, algún enlace útil. Para muchas empresas eso es exactamente lo que necesitan, y no hace falta nada más.

Lo que analizamos en esta guía es distinto: un espacio más operativo, donde además de consultar información también se puede:

• consultar información específica de un proceso,
• registrar datos,
• gestionar solicitudes,
• actualizar estados,
• adjuntar documentación,
• aprobar acciones,
• y hacer seguimiento de un proceso de principio a fin.

No es mejor ni peor que una intranet informativa: responde a una necesidad distinta.

Señales de que el trabajo está demasiado repartido

Ninguna señal es determinante por sí sola, pero cuando varias coinciden a la vez, suele valer la pena analizarlo con más detalle:

• Varios Excel para un mismo proceso. Cada persona mantiene su propia versión, y no siempre coinciden entre sí.
• Información repartida entre email y carpetas. Hay que buscar en varios sitios distintos para reconstruir el estado real de algo.
• Diferentes personas mantienen copias de los mismos datos. Sin que quede claro cuál de esas copias es la versión válida.
• Cuesta saber el estado actual de una solicitud o expediente. Hay que preguntarle a alguien en lugar de poder consultarlo directamente.
• Los empleados tienen que preguntar dónde está cada documento. El conocimiento vive en las personas, no en ningún sistema.
• Clientes o proveedores envían información por canales distintos. Correo, WhatsApp, llamadas, sin un punto único de entrada.
• Cada perfil trabaja con una visión diferente del proceso. Falta una imagen común de qué está pasando y en qué punto se encuentra.

Cuándo sí puede tener sentido centralizarlo

Centralizar suele tener sentido cuando coinciden varias de estas condiciones:

• El proceso ya está suficientemente definido como para diseñar algo alrededor de él.
• Participan varios perfiles, no solo una persona trabajando en solitario.
• Existe información común que esos perfiles necesitan consultar.
• Hay estados o un seguimiento que tiene sentido visualizar en un solo lugar.
• Existen permisos distintos: no todos deberían ver o hacer lo mismo.
• Hay documentos relacionados que hoy viven dispersos.
• El proceso tiene continuidad en el tiempo, no es algo puntual.
• Integrar el portal con otros sistemas aportaría valor real, no solo complejidad.

No hace falta que se cumplan todas: cuantas más coincidan, más claro suele estar el caso.

¿Quién debería utilizar el portal?

Antes de construir nada, conviene identificar qué perfiles lo usarán y para qué:

Empleados

Gestionan el proceso día a día: registran información, actualizan estados y ejecutan las tareas que les corresponden.

Responsables

Revisan, aprueban o consultan el avance, sin necesitar acceso a todo el detalle operativo.

Clientes

Pueden aportar información, hacer seguimiento de una solicitud o consultar el estado de algo que les afecta directamente.

Proveedores

Entregan documentación, consultan estados o realizan determinadas acciones dentro de un proceso que comparten con tu empresa.

No todos los perfiles necesitan ver ni gestionar lo mismo: definir esos roles y permisos con claridad es parte del diseño del portal, no un detalle técnico posterior. Eso no significa prometer una seguridad absoluta, sino diseñar los accesos según lo que cada perfil realmente necesita hacer.

Ejemplo: una solicitud que hoy vive entre email y Excel

Un caso habitual: alguien envía una solicitud por email, otra persona la registra en un Excel, la documentación asociada se guarda en una carpeta compartida, y cualquier duda se resuelve con más correos. El estado se actualiza a mano, cuando alguien se acuerda de hacerlo.

Un espacio común podría, en principio:

• registrar la solicitud en un único lugar,
• asociar la documentación directamente a esa solicitud,
• mostrar en qué estado se encuentra,
• asignar un responsable,
• y permitir que cada perfil realice la acción que le corresponde, sin depender de un correo.

Esto no significa que centralizarlo sea automáticamente la mejor decisión: antes conviene analizar cuántas solicitudes de este tipo existen, cuánta gente interviene y si el proceso está lo bastante definido como para diseñar algo alrededor de él.

Cuándo NO merece la pena crear un portal propio

Hay situaciones donde un portal propio probablemente no es la mejor decisión, al menos todavía:

• Solo lo utiliza una persona: no hay nada que centralizar entre varios perfiles.
• El proceso ocurre con muy poca frecuencia.
• El proceso todavía cambia constantemente y no se ha estabilizado.
• Una herramienta estándar ya lo resuelve razonablemente bien.
• El problema real es que dos sistemas no se comunican entre sí, y lo que hace falta es una integración, no una interfaz nueva.
• El problema real es una tarea repetitiva que podría automatizarse sin necesidad de crear ninguna pantalla nueva.
• Centralizarlo no aportaría suficiente valor operativo para justificar el esfuerzo.

En estos casos no es que un portal nunca vaya a tener sentido: en este momento, no es la prioridad.

Portal propio o herramienta estándar

Para verlo de forma más directa:

Ninguna opción es mejor en abstracto. Depende de si el proceso es lo bastante específico y estable como para justificar una plataforma propia, o si una herramienta ya existente encaja suficientemente bien.

Centralizar no debería significar crear otra isla

Un portal puede acabar convirtiéndose en otra herramienta aislada si obliga a duplicar información que ya existe en otro sitio. Antes de construirlo, conviene analizar:

• qué sistemas ya existen y qué información gestionan,
• dónde vive cada dato hoy,
• qué información necesita realmente el portal,
• qué sistema debería seguir siendo la fuente principal de cada dato,
• y qué información debería intercambiarse entre el portal y esos sistemas.

Cuando esto último es relevante, suele formar parte de un proyecto de integración con los sistemas que ya utiliza tu empresa.

Qué analizar antes de construirlo

Antes de diseñar ninguna pantalla, conviene tener claras unas pocas cosas:

• ¿Qué proceso queremos centralizar?
• ¿Quién interviene?
• ¿Qué puede hacer cada perfil?
• ¿Qué información necesita?
• ¿Qué documentos maneja?
• ¿Qué estados existen?
• ¿Qué excepciones aparecen?
• ¿Qué sistemas ya contienen parte de esa información?
• ¿Qué debería poder evolucionar en el futuro?

Responder a esto antes de empezar suele ahorrar bastantes decisiones equivocadas más adelante.

El portal debe partir del proceso

No conviene empezar por las pantallas, la tecnología o el diseño de un dashboard. Primero hay que entender el proceso, quién interviene, qué información maneja, qué responsabilidades y permisos existen, y qué sistemas ya forman parte de la operativa.

Con esa base, decidir qué hace falta, un portal propio, configurar una herramienta ya existente, integrar sistemas, automatizar alguna parte del proceso, o simplemente mantenerlo como está, resulta mucho más sencillo.