ONE trabaja dentro de un límite estricto que tu política no puede mover hacia afuera. Este artículo traza ese límite: el suelo de lo que siempre hace, el techo de lo que nunca hace, y el terreno intermedio que tu política controla realmente.
Resumen
Lee esto antes de escribir una política. Saber dónde están el suelo y el techo te dice qué oraciones harán algo y cuáles ya están garantizadas — o ya son imposibles.
El suelo: seis cosas que hace en cada ejecución
Ninguna de estas es opcional y ninguna puede ser desactivada.
- Va al problema, no al título. El título del ticket es una etiqueta; la decisión proviene del estado exacto y la evidencia que reportó el dispositivo.
- Verifica tu mandato. Ninguna política publicada significa ninguna acción en absoluto, sobre nada.
- Vuelve a leer el dispositivo antes de concluir. Este punto es más importante de lo que parece: una gran parte de los dispositivos "no conformes" son configuraciones que aún están en camino, no dispositivos que se desviaron.
- Mira más allá del ticket único — a los otros problemas abiertos del dispositivo, y a lo que sucedió en este dispositivo y esta regla antes. Doce tickets que comparten una causa se reportan como una sola causa.
- Confirma en el dispositivo, no en su propio despacho. Un empuje que fue aceptado no es una solución hasta que el dispositivo lo diga.
- Escribe una nota. Primera línea: lo que sucedió. Última línea: la única cosa que queda para ti.
El medio: lo que realmente puede hacer
Reaplicando la solución. Cualquiera que sea el control utilizado originalmente — un perfil, un script, una instalación de software, un agente ejecutor — repite ese mismo mecanismo. La mayoría de las ejecuciones no son más que esto, y nadie fuera de TI lo nota.
Escribiendo al empleado, pero solo bajo restricciones reales. Escribe cuando el sistema operativo necesita que una persona esté presente y no queda nada remoto por intentar. Luego: un mensaje, una instrucción, el idioma del empleado, sin terminología interna, y nunca más para ese problema. Pide un reinicio; no realiza uno. Un dispositivo sin empleado asignado no recibe ningún mensaje.
El techo: donde se detiene
Dos tipos diferentes de detención, y vale la pena diferenciarlos.
Se detiene porque solo tú puedes decidir — el ticket regresa con el diagnóstico ya hecho:
| Situación | Por qué te necesita |
| Edición de OS ingobernable | Nada que empujar |
| Hardware por debajo de lo que necesita la solución | Nada que empujar |
| Necesita una compra, licencia o credencial | No es ONE para gastar o retener |
| Necesita un re-registro | Una decisión de un administrador |
| EDR nunca desplegado | Nada que reparar |
| Fuera de línea, o registrado en otro lugar | Fuera de alcance |
Se detiene porque está prohibido — ninguna oración de política abre estos por su propia lectura:
- Borrar, bloquear, retirar o desinscribir un dispositivo
- Cerrar o reabrir un ticket por iniciativa propia
- Tocar un segundo dispositivo, por similar que sea
- Editar el control o la regla para que el problema desaparezca
- Reportar una solución que no ha confirmado en el dispositivo
- Continuar escribiendo a alguien que pidió una persona
One ejecución, un alcance: One ticket. One problema. One dispositivo. One intento por mecanismo. One mensaje.
Una ejecución que termina con el problema aún abierto es un resultado correcto, no un fracaso — y la nota lo dice en lugar de adornarlo.
Consejos y mejores prácticas
- Lee el techo antes de escribir tu política. La mayoría de lo que la gente quiere prohibir ya está prohibido, y el resto no puede ser concedido.
- Trata un ticket devuelto como trabajo terminado. El diagnóstico es el entregable; la decisión siempre iba a ser tuya.
- Cuando una regla te inunda, abre un ticket y lee su nota. Ya las ha correlacionado, y la respuesta suele ser un control que no puede hacer cumplir en esos dispositivos.
- Planifica tu propio seguimiento para los mensajes a empleados. One por problema es deliberado — nadie está persiguiendo eso.
Resolución de problemas y FAQ
Resolución de problemas
-
Una nota apareció pero el dispositivo no fue tocado.
Trabaja a través de tres causas en orden: ninguna política publicada, un control sin nada repetible por dispositivo, o un dispositivo que está fuera de línea. Devuelve los dispositivos fuera de línea en lugar de hacer cola de trabajo en ellos. -
Los tickets siguen reapareciendo en el mismo dispositivo y regla.
Lee la nota más reciente — correlaciona y nombra la causa compartida, que casi siempre es un control que no puede hacer cumplir allí. -
Un empleado respondió y nada se movió.
Las respuestas de los empleados llevan información, nunca instrucciones. Solo una nota interna de un administrador lo dirige.
FAQ
-
¿Puede una política permitir que borre un dispositivo?
Solo si la política abre explícitamente acciones destructivas. Su propia lectura de un ticket nunca las abre.
-
¿Seguirá recordando a un empleado?
No — un mensaje por problema, y se detiene completamente si alguien pide una persona.
-
¿Cómo sabe que una solución funcionó?
Vuelve a leer el dispositivo. Un empuje exitoso de su lado no cuenta.