¿Portal corporativo o software por separado? Criterios para decidir

La respuesta corta: ninguna de las dos es incorrecta. La diferencia aparece según cuánto se tocan los procesos entre sí. El enfoque de portal corporativo es el modelo que reúne tareas como ausencias y permisos, asignación de activos, visitantes y auditorías en una sola infraestructura de usuarios, permisos y notificaciones; el enfoque de software por separado consiste en usar un producto distinto para cada proceso.

Este artículo es más una guía de decisión que una presentación de producto; nuestro propósito es ayudarle a decidir con las preguntas correctas, cualquiera que sea el camino que elija. Damos los ejemplos con YazSis KurumsalPortal, pero los criterios valen sea cual sea la solución que considere.

Dónde son fuertes los softwares por separado

• Experiencia profunda: En áreas como la nómina, la contabilidad o la planificación de la producción existen productos específicos que han madurado durante años.
• Inversión existente: Desmontar un sistema que el equipo conoce bien y que funciona suele ser un riesgo innecesario.
• Necesidad de una sola unidad: Para un trabajo que solo concierne a un departamento y no se cruza con otros procesos, un producto aparte puede bastar.

Es decir, “reunirlo todo en un solo software” no es un objetivo en sí mismo. Tiene sentido conservar el producto que hace bien un trabajo; el problema es que, a medida que aumenta el número de productos, también aumentan las costuras entre ellos.

El costo oculto de los softwares por separado

El costo real se acumula no en los productos en sí, sino en los huecos entre ellos. Cuando un nuevo empleado empieza a trabajar, se abren cuentas por separado en el sistema de permisos, en el registro de visitantes, en la hoja de asignación de activos y en la herramienta de comunicados. Cuando el empleado se va, la misma baja debe hacerse en cinco lugares; si se olvida en uno, queda adentro un usuario antiguo.

• Cada producto tiene su propia lista de usuarios, su propia contraseña y su propia lógica de permisos; de quien es “administrador” en uno, nadie sabe cómo está autorizado en otro.
• Las notificaciones llegan desde cinco lugares distintos; el empleado no sabe a cuál mirar.
• Para el informe de dirección, los datos se juntan a mano.
• El contrato, la actualización y el soporte de cada producto se siguen por separado; las fechas de renovación se dispersan en meses diferentes.

El aporte principal del portal: los permisos comunes

El beneficio más concreto de un portal corporativo es que los permisos se gestionan desde un solo lugar. En el módulo Gestión de Menús y Permisos de KurumsalPortal, los permisos de visualización y de operación se definen por capas de rol, departamento y usuario. A un usuario se le puede dar solo permiso para ver un menú; el permiso de operar se define aparte. Así, quien debe ver la información no tiene por qué ser también quien puede modificarla.

El acceso temporal también se gestiona desde el mismo lugar: a quien sustituye a un directivo de permiso se le puede dar autorización por un tiempo determinado. Como cada permiso concedido y retirado queda registrado, después se puede auditar quién tuvo qué permiso y cuándo. Para los administradores del sistema y los equipos de tecnologías de la información, esto significa responder a las solicitudes de permisos desde un único registro y no “mirando muchas pantallas”. De este modo, el principio de mínimo privilegio también se puede aplicar en la práctica.

Si los permisos se gestionan en cinco productos distintos, es imposible saber quién puede ver qué; si se gestionan en un solo lugar, hasta la pregunta se vuelve fácil.

Seis criterios para decidir

1. ¿Qué tan conectados están los procesos? Las tareas que toca todo empleado, como permisos, tareas, comunicados y visitantes, se benefician de una infraestructura común; las de un solo departamento, menos.
2. ¿Cuántos productos distintos está dispuesto a gestionar? Cada producto significa un contrato, una actualización y un canal de soporte.
3. ¿Qué sensibilidad tienen los permisos y los datos personales? Definir en un solo lugar el alcance por roles reduce el margen de error en los datos sensibles.
4. ¿Cómo accederán los empleados? Un único acceso que se usa desde el navegador del teléfono, sin instalar aplicaciones, marca la diferencia para los equipos de campo y por turnos.
5. ¿Cómo será la relación con los sistemas existentes? Si no va a abandonar su ERP, su sistema de control de asistencia (PDKS) o su sistema de nómina, el flujo de datos debe conversarse desde el principio.
6. ¿Cómo será el crecimiento? ¿Se puede empezar pequeño y añadir módulos, o cada nueva necesidad es una nueva compra?

Una forma práctica de evaluarlo es esta: anote los tres procesos que han generado más tráfico de correos y llamadas en el último mes. ¿Cuántos de ellos tocan a los mismos empleados, a los mismos aprobadores y a los mismos canales de notificación? Si la respuesta es “la mayoría”, una infraestructura común le ahorrará tiempo; si es “ninguno”, un producto aparte también puede bastar.

El modelo mixto también es válido

La decisión casi nunca es “todo o nada”. KurumsalPortal consta de 33 módulos y no hace falta contratarlos todos juntos; se empieza con los módulos necesarios y, a medida que crece la necesidad, se agregan otros a la misma infraestructura de usuarios, permisos y notificaciones. El portal funciona de forma independiente: si se necesita un flujo de datos con el ERP, el PDKS o el sistema de nómina, qué datos se transfieren y cómo se determina conjuntamente en el análisis de necesidades. No hablamos de una integración lista para usar; el alcance se define según el proyecto. Esto también muestra que el modelo mixto es una opción realista: los sistemas que exigen experiencia especializada se quedan donde están y los trabajos dispersos intermedios se reúnen en el portal.

Para ver qué modelos se ajustan a su propio proceso, puede revisar la lista de módulos en la página de KurumsalPortal; y en el análisis de necesidades podemos evaluar juntos qué trabajos se beneficiarían de la infraestructura común.