ONE trabaja dentro de un límite estricto que su 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 su política controla realmente.
Resumen
Lea esto antes de escribir una política. Saber dónde se sitúan el suelo y el techo le dice cuáles de sus 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.
- Vaya al problema, no al título. El título del ticket es una etiqueta; la decisión proviene del estado exacto y de la evidencia que reportó el dispositivo.
- Verifique su mandato. Ninguna política publicada significa ninguna acción en absoluto, sobre nada.
- Vuelva a leer el dispositivo antes de concluir. Este punto importa más de lo que parece: una gran parte de los dispositivos "no conformes" son configuraciones que aún están en proceso, no dispositivos que se han desviado.
- Mire más allá del ticket único — a los otros problemas abiertos del dispositivo, y a lo que ocurrió en este dispositivo y esta regla antes. Doce tickets que comparten una causa se reportan como una sola causa.
- Confirme en el dispositivo, no en su propia gestión. Un empuje que fue aceptado no es una solución hasta que el dispositivo lo diga.
- Escriba una nota. Primera línea: lo que ocurrió. Última línea: la única cosa que queda para usted.
El medio: lo que realmente puede hacer
Reaplicando la solución. Lo que sea que el control utilizó 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/la empleado, pero solo bajo restricciones reales. Escriba cuando el sistema operativo necesita que una persona esté presente y no quede nada remoto por intentar. Entonces: un mensaje, una instrucción, el idioma del/la empleado/a, sin terminología interna, y nunca más para ese problema. Pide un reinicio; no realiza uno. Un dispositivo sin empleado/a asignado/a no recibe ningún mensaje en absoluto.
El techo: donde se detiene
Dos tipos diferentes de detención, y vale la pena diferenciarlos.
Se detiene porque solo usted puede decidir — el ticket regresa con el diagnóstico ya hecho:
| Situación | Por qué te necesita |
| Edición de SO 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 nuevo 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
- Lea el techo antes de escribir su política. La mayoría de lo que la gente quiere prohibir ya está prohibido, y el resto no puede ser concedido.
- Trate un ticket devuelto como trabajo terminado. El diagnóstico es el entregable; la decisión siempre iba a ser suya.
- Cuando una regla le inunda, abra un ticket y lea su nota. Ya ha correlacionado, y la respuesta suele ser un control que no puede hacer cumplir en esos dispositivos.
- Planifique su propio seguimiento para mensajes a empleados/as. 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.
Trabaje 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. Devuelva 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.
Lea la nota más reciente — correlaciona y nombra la causa compartida, que casi siempre es un control que no puede hacer cumplir allí. -
Un/a empleado/a respondió y nada se movió.
Las respuestas de los/as empleados/as llevan información, nunca instrucciones. Solo una nota interna de un/a administrador/a 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/a empleado/a?
No — un mensaje por problema, y se detiene completamente si alguien pide una persona.
-
¿Cómo sabe que una solución funcionó?
Vuelva a leer el dispositivo. Un empuje exitoso de su parte no cuenta.