Everything in context.

ITMDesk-Base es la capa Linux sobre la que se apoya todo lo demás: los servidores, sus actualizaciones, sus certificados, sus bases de datos y sus registros, administrados desde un solo lugar en vez de seis sesiones de terminal y una hoja de cálculo con fechas de vencimiento.

Pide lo mínimo posible a la máquina. Los servicios comparten lo que pueden en lugar de que cada uno lleve su propia copia de todo, porque el coste real de una plataforma no es la licencia: es la máquina que exige, la memoria que desperdicia y la tarde que alguien pierde averiguando cuál de sus partes se rompió.

Sentinel observa de forma continua, y lo que ve no se queda dentro de Base: un servicio que empieza a fallar se convierte en un ticket con su propio historial adjunto, y la corrección se convierte en un procedimiento que la siguiente persona puede seguir. Esa es la diferencia entre monitorizar algo y saber de ello.

ITMDesk-FunLab no es software. Es el trabajo de convertir un proceso que hoy vive en hojas de cálculo, hilos de correo y la memoria de alguien en una aplicación funcionando en producción, en semanas.

Semanas y no meses porque no se empieza de cero. Autenticación, permisos, el registro de quién hizo qué, almacenamiento, tratamiento de documentos y la infraestructura de abajo ya existen, ya funcionan y ya son los mismos que usa el resto de la plataforma. Lo que se construye es solo la parte realmente específica del problema.

ITMDesk-SM pasó de conversación a producción en tres semanas, desarrollo e infraestructura y despliegue incluidos. La cifra solo es interesante por lo que dice del noventa por ciento restante: ya estaba hecho.

ITMDesk-Blue es donde están las máquinas. Estaciones y servidores, Windows, macOS y Linux, con móviles y tabletas al lado: inventario, telemetría, software instalado, acceso remoto, comandos programados y el registro de quién hizo qué en cuál de ellas.

Los agentes son la parte que parece simple desde fuera. Un agente de macOS no es un agente de Windows con otro icono: el modelo de permisos es distinto, el mecanismo de actualización es distinto, y lo que cada sistema operativo acepta contar sobre sí mismo es distinto. Cada uno es un problema propio, y cada uno tiene que reportar igualmente al mismo retrato.

Ese retrato es lo que hace funcionar al resto. Un ticket sabe de qué máquina vino, quién es su dueño, qué contrato la cubre y si su disco lleva una semana llenándose. Nadie tiene que ir a mirarlo.

ITMDesk-TicketDesk es la mesa de servicio: las solicitudes llegan, se derivan, se responden y se cierran, con el SLA seguido y la conversación guardada.

Lo que lo separa de una mesa de servicio escrita en un fin de semana es lo que llega adjunto a la solicitud. La máquina de la que vino, su dueño, su historial y las últimas veces que algo parecido se resolvió, y cómo. La sugerencia extraída de esos casos viene de los tickets resueltos de la propia organización, no de internet.

Cada ticket cerrado deja el siguiente más corto. Eso no es una funcionalidad. Es lo que ocurre cuando las respuestas se guardan en el mismo sitio al que llegan las preguntas.

ITMDesk-ProjectManager es donde una demanda se vuelve trabajo con forma y fecha. Planes, tareas, responsables y dependencias: estructura suficiente para llevar un proyecto, y no tanta como para que operar la herramienta se convierta en el proyecto.

Se alimenta de lo que ya está pasando en otro sitio. Un ticket que vuelve una y otra vez es señal de que hay algo debajo por arreglar. Un parque envejeciendo es un proyecto esperando que lo nombren. El origen viaja con el trabajo, así que seis meses después todavía se puede decir por qué empezó.

La IA ayuda a fijar prioridades y señala el riesgo pronto. Propone; quien responde por el resultado sigue decidiendo.

ITMDesk-LearningDesk guarda lo que un equipo necesita saber: el onboarding, capacitaciones, la biblioteca de contenidos, la documentación, los documentos que las personas han firmado y las contraseñas compartidas que pueden usar.

Existe porque el conocimiento guardado en la cabeza de una persona es una caída esperando sus vacaciones. Un procedimiento escrito la noche en que hizo falta vale más que un manual escrito por adelantado, y aquí es donde queda para sobrevivir a quien lo escribió.

Las credenciales están aquí y no en una hoja de cálculo por la misma razón. Hay que quitar el acceso en el momento en que alguien cambia de función, y eso solo funciona cuando un único lugar sabe quién tiene qué.