Soporte técnico

Entre 20 y 100 personas suele aparecer una zona incómoda: la empresa ya depende de Microsoft 365, redes, backups y aplicaciones, pero quizá todavía no justifica un equipo IT interno completo.

Externalizar no significa perder control. Un modelo bien diseñado mantiene decisiones y prioridades en la empresa, mientras delega operación especializada con responsabilidades y evidencia.

Señales de que el modelo actual quedó chico

• Gerentes o administrativos dedican tiempo recurrente a problemas técnicos.
• Altas, bajas y permisos se resuelven por mensajes sin trazabilidad.
• Nadie puede confirmar si los backups fueron probados.
• La infraestructura depende de conocimiento no documentado de una persona.
• Los mismos incidentes reaparecen y las mejoras siempre se postergan.

Qué puede aportar un departamento IT externo

• Mesa de ayuda y escalamiento con responsables definidos.
• Administración de identidades, dispositivos, red, servidores y servicios cloud.
• Monitoreo, mantenimiento, documentación y continuidad.
• Especialistas distintos para seguridad, Microsoft 365, redes e infraestructura.
• Plan periódico de riesgos, capacidad y proyectos.

Cuándo conviene mantener una función IT interna

Externalizar la operación no elimina la necesidad de gobierno. En empresas con procesos complejos puede ser conveniente conservar un referente interno.

• Prioriza necesidades y representa a las áreas usuarias.
• Conoce procesos, aplicaciones y restricciones del negocio.
• Aprueba accesos, cambios y presupuestos.
• Evalúa al proveedor mediante SLA, riesgos y resultados.

Modelo interno, externo o híbrido

• Interno: apropiado cuando existe carga estable, conocimiento muy específico y escala suficiente.
• Externo: útil cuando se necesita cobertura multidisciplinaria sin construir un equipo completo.
• Híbrido: un responsable interno gobierna y el proveedor ejecuta, monitorea y escala.
• Por demanda: aceptable en entornos simples y de baja criticidad.

Preguntas para evaluar antes de decidir

1. ¿Qué procesos se detienen si falla la tecnología?
2. ¿Qué tareas requieren presencia o conocimiento interno?
3. ¿Qué cobertura y especialidades hacen falta durante el año?
4. ¿Qué documentación y activos deberían permanecer bajo control de la empresa?
5. ¿Cómo se medirá que la externalización mejora la situación?

Empezar con un relevamiento, no con un contrato genérico

El primer paso es identificar servicios críticos, usuarios, sedes, activos, proveedores, riesgos y tareas hoy sin responsable. Esa evidencia permite decidir qué conservar internamente y qué delegar.

Un buen modelo externo debe dejar a la empresa con más control, mejor documentación y menos dependencia de personas aisladas.

Una propuesta de soporte IT debería permitir saber qué se recibe, quién responde y qué riesgos quedan fuera. Las frases como soporte integral o atención ilimitada no reemplazan un alcance verificable.

Este checklist ayuda a comparar proveedores con una base común y a detectar dependencias que podrían aparecer después de la contratación.

1. Alcance e inventario cubierto

• Usuarios, dispositivos, sedes y horarios considerados.
• Servidores, red, Wi-Fi, Microsoft 365, backups y aplicaciones incluidas.
• Tareas remotas, presenciales, preventivas y administrativas.
• Servicios de terceros que el proveedor coordina pero no opera.
• Exclusiones y supuestos utilizados para cotizar.

2. Mesa de ayuda y niveles de servicio

• Canales autorizados para abrir tickets.
• Criterios de impacto, urgencia y prioridad.
• Tiempos de respuesta y, cuando sea posible, objetivos de restauración.
• Escalamiento técnico y comunicación durante incidentes críticos.
• Indicadores y frecuencia de reportes.

3. Prevención, seguridad y continuidad

• Monitoreo y mantenimiento incluidos.
• Gestión de parches, antivirus o EDR y cuentas administrativas.
• Responsabilidad sobre backups y pruebas de recuperación.
• Revisión de altas, bajas, MFA y permisos.
• Tratamiento de vulnerabilidades, incidentes y excepciones.

4. Documentación y propiedad de la información

• Inventario, diagramas, configuraciones y procedimientos que se mantendrán.
• Uso de gestores seguros para credenciales y accesos privilegiados.
• Propiedad empresarial de dominios, licencias, cuentas y documentación.
• Acceso de la empresa a la evidencia y exportación al finalizar el servicio.
• Proceso de alta, cambio y revocación de técnicos del proveedor.

5. Condiciones comerciales

• Precio, moneda, impuestos, vigencia y ajuste.
• Límites de horas, visitas, guardias y desplazamientos.
• Tarifa y aprobación para tareas fuera de alcance.
• Tratamiento de proyectos y compras de hardware o licencias.
• Plazo, renovación, rescisión y asistencia de transición.

6. Evidencia que conviene pedir

• Ejemplo anonimizado de informe mensual.
• Modelo de inventario o documentación.
• Flujo de ticket crítico y escalamiento.
• Plan de incorporación inicial y primeros 90 días.
• Referencias o experiencia comprobable en entornos similares.

Cómo usar el checklist

Pedí que cada proveedor marque incluido, opcional o fuera de alcance y que explique cualquier supuesto. Después compará el costo total probable y los riesgos residuales, no sólo el valor mensual.

La propuesta ganadora debería ser la que mejor convierta necesidades reales en responsabilidades verificables y una relación que pueda medirse.

El soporte por hora paga intervenciones puntuales. El abono mensual contrata capacidad, continuidad y un alcance de gestión. Ningún modelo es universalmente mejor: la decisión depende de cuánto depende el negocio de la tecnología y de si se necesita solamente reparar o también prevenir.

La comparación correcta incluye el costo de las interrupciones, el tiempo interno dedicado a coordinar proveedores y el trabajo que nunca se realiza cuando nadie es responsable de prevenir fallas.

Cuándo funciona bien el soporte por hora

• La empresa tiene pocos usuarios y tecnología sencilla.
• Los incidentes son infrecuentes y no detienen procesos críticos.
• Existe una persona interna capaz de mantener inventario, accesos y proveedores.
• Se acepta que el diagnóstico comience cuando aparece el problema.

Cuándo conviene un abono administrado

• El correo, la red, el sistema de gestión o los servidores son esenciales para operar.
• Hay varias sedes, proveedores o tecnologías que necesitan coordinación.
• Se requieren tiempos de respuesta acordados y seguimiento de tickets.
• La empresa necesita mantenimiento, monitoreo, backups y documentación continuos.
• La dirección quiere un costo previsible y un plan de mejora.

Diferencias que deberían figurar en el contrato

• Horario, canales y SLA de respuesta.
• Cantidad de usuarios, activos y servicios cubiertos.
• Trabajo remoto, visitas, guardias y proyectos.
• Responsabilidades sobre backups, seguridad y terceros.
• Indicadores, documentación y reuniones incluidas.

El error de comparar sólo la tarifa horaria

Una tarifa menor puede terminar siendo más cara si cada incidente requiere redescubrir la infraestructura, esperar disponibilidad o coordinar nuevamente permisos y proveedores. Un abono tampoco genera valor por sí solo si se limita a descontar horas y no produce prevención.

• Medí horas de interrupción y recurrencia de incidentes.
• Revisá cuánto trabajo preventivo se ejecuta realmente.
• Calculá el tiempo de empleados dedicado a resolver o escalar problemas.
• Compará resultados y riesgos, no sólo unidades de facturación.

Modelo híbrido: una alternativa frecuente

Algunas pymes combinan un abono base para operación y prevención con proyectos cotizados por separado. Funciona cuando el límite entre tareas recurrentes y transformaciones está claramente documentado.

• El abono cubre soporte, monitoreo y administración ordinaria.
• Migraciones, renovaciones o nuevas sedes se presupuestan como proyectos.
• Las urgencias fuera de horario tienen reglas conocidas.
• La reunión periódica decide qué mejoras pasan a proyecto.

Una regla práctica para decidir

Si una falla tecnológica puede detener ventas, administración o producción, conviene evaluar un servicio con responsabilidad continua. Si la tecnología es simple y las interrupciones tienen impacto menor, la atención por hora puede ser suficiente.

Antes de decidir, analizá tres meses de incidentes y estimá el costo real de las interrupciones y tareas postergadas.

No existe un precio mensual correcto para todas las pymes. El valor depende de cuántas personas y sedes deben atenderse, qué infraestructura sostiene la operación, qué tiempos de respuesta se esperan y cuánto trabajo preventivo incluye el servicio.

En Argentina también importa cómo se expresa y actualiza el precio. Una propuesta profesional debería indicar moneda, impuestos, vigencia, mecanismo de ajuste y qué actividades se cotizan por separado. Comparar sólo el total mensual puede ocultar diferencias importantes de alcance.

La respuesta corta: el precio se construye con alcance y riesgo

Un abono administrado suele combinar una base de gestión con componentes variables. El objetivo no es comprar horas baratas, sino sostener un nivel de servicio previsible.

• Cantidad de usuarios, dispositivos, sedes y horarios de atención.
• Servidores, redes, Microsoft 365, backups y aplicaciones que deben administrarse.
• SLA de respuesta, canales de soporte y necesidad de guardias fuera de horario.
• Trabajo preventivo: monitoreo, parches, documentación, inventario y revisión de capacidad.
• Nivel de seguridad, cumplimiento y evidencia que necesita la empresa.

Qué debería incluir el abono mensual

Para comparar propuestas, conviene transformar la descripción comercial en entregables verificables.

• Mesa de ayuda con registro, prioridad, responsable y trazabilidad de cada solicitud.
• Administración de usuarios, permisos, equipos y servicios incluidos.
• Mantenimiento preventivo y monitoreo con acciones definidas ante alertas.
• Documentación mínima de infraestructura, accesos administrativos e inventario.
• Reunión periódica, indicadores y plan de mejoras priorizado.
• Procedimiento para incidentes críticos, escalamiento y comunicación.

Ejemplo de dimensionamiento para una empresa de 25 usuarios

Una empresa con 25 usuarios no se cotiza únicamente multiplicando personas por una tarifa. Dos organizaciones del mismo tamaño pueden tener complejidades muy distintas.

• Una sede, Microsoft 365 y equipos estandarizados reducen variabilidad operativa.
• Un servidor local, software de gestión, VPN y varias impresoras agregan dependencias.
• Dos sedes, Wi-Fi crítico o producción fuera de horario elevan cobertura y coordinación.
• Infraestructura sin inventario ni credenciales ordenadas requiere una etapa inicial de normalización.

Cómo comparar dos presupuestos sin equivocarse

1. Normalizar usuarios, activos, sedes, horarios y servicios incluidos.
2. Comparar SLA, límites, exclusiones y tratamiento de proyectos.
3. Pedir ejemplos de reportes, documentación y mantenimiento preventivo.
4. Verificar cómo se gestionan seguridad, backups y accesos privilegiados.
5. Calcular el costo total esperado, incluyendo bolsas de horas y extras probables.

Señales de una propuesta artificialmente barata

• No define activos, responsabilidades ni horario de cobertura.
• Promete atención ilimitada pero no establece prioridad o capacidad.
• Resuelve incidentes sin incluir prevención, documentación o monitoreo.
• No explica qué sucede ante una falla grave o fuera de alcance.
• Depende de una única persona sin mecanismo de continuidad.

Cómo obtener una estimación útil

Prepará una lista simple de usuarios, sedes, equipos, servidores, servicios cloud, horarios y problemas recurrentes. Con esa base, un proveedor puede proponer alcance y nivel de servicio en lugar de adivinar una cantidad de horas.

NeWeL puede realizar un relevamiento inicial y convertirlo en una propuesta comparable, con responsabilidades, exclusiones y prioridades explícitas.

Un panel verde confirma que una tarea terminó, pero no demuestra que el negocio pueda recuperar el contenido correcto. La prueba debe comenzar con una necesidad concreta y terminar con evidencia verificable por el propietario de la información.

Las restauraciones deberían ensayarse sin sobrescribir datos productivos y con cuentas de prueba o destinos alternativos siempre que la herramienta lo permita.

Definir escenarios y criterios antes de restaurar

• Mensaje individual y carpeta de correo eliminada.
• Archivo de OneDrive en una versión anterior.
• Carpeta o biblioteca de SharePoint con metadatos y permisos.
• Buzón o sitio asociado a una persona que ya no existe.
• Recuperación masiva posterior a borrado o cifrado.
• Tiempo máximo, punto de recuperación y responsable de aprobar cada prueba.

Preparar la prueba de forma segura

1. Elegir contenido de prueba sin datos sensibles.
2. Registrar fecha, ubicación, propietario y estado esperado.
3. Confirmar permisos administrativos y alertas.
4. Seleccionar un destino alternativo o ventana controlada.
5. Definir cómo revertir cualquier cambio no previsto.

Qué validar en Exchange Online

• El mensaje correcto aparece con adjuntos y propiedades necesarias.
• La restauración puede dirigirse al buzón original o alternativo según procedimiento.
• La búsqueda permite localizar por fecha, remitente o asunto.
• El tiempo medido coincide con el objetivo definido.
• La acción queda registrada y puede auditarse.

Qué validar en OneDrive y SharePoint

• Contenido, versión y estructura se recuperan correctamente.
• Metadatos y nombres mantienen integridad.
• Permisos no se amplían de forma accidental.
• Enlaces, aplicaciones o sincronización se comportan como se esperaba.
• El propietario funcional confirma que la información es utilizable.

Evidencia mínima de una prueba

• Identificador, fecha, alcance y responsable.
• Punto de recuperación seleccionado.
• Hora de inicio, finalización y RTO observado.
• Capturas o registros de origen, tarea y destino.
• Errores, limitaciones y acciones correctivas.
• Aprobación del propietario o área usuaria.

Frecuencia y rotación de pruebas

La frecuencia depende del riesgo y del cambio. Conviene rotar cargas de trabajo y escenarios, incluir una recuperación masiva periódica y repetir después de cambios importantes de herramienta, licencia o arquitectura.

• Pruebas pequeñas frecuentes para detectar fallas operativas.
• Ejercicios integrales menos frecuentes para medir capacidad y coordinación.
• Revisión de cuentas administrativas y alertas en cada ciclo.
• Seguimiento hasta cerrar los hallazgos.

El objetivo es recuperar el servicio, no completar una tarea

Una prueba se considera exitosa cuando el dato es correcto, utilizable, seguro y se recuperó dentro del objetivo. Si alguno de esos puntos falla, el backup necesita una acción correctiva aunque el software informe éxito.

SharePoint y un servidor de archivos pueden almacenar documentos, pero responden a modelos diferentes. SharePoint prioriza colaboración, versiones, búsqueda y acceso controlado desde Microsoft 365. Un file server ofrece compatibilidad directa con rutas, permisos NTFS y aplicaciones tradicionales.

La decisión no debería ser cloud contra local. Conviene analizar procesos, tipos de archivo, conectividad, permisos, integraciones y capacidad de administración.

Cuándo SharePoint suele ser una buena opción

• Las personas colaboran sobre documentos de Office desde distintas ubicaciones.
• Se necesitan versiones, coautoría, búsqueda y enlaces compartidos.
• La empresa ya usa Microsoft 365 y puede gobernar identidades y dispositivos.
• El contenido puede organizarse por sitios, equipos y procesos.
• Se quiere reducir dependencia de VPN para documentación cotidiana.

Cuándo un servidor de archivos sigue siendo necesario

• Aplicaciones heredadas trabajan con rutas SMB o bloqueos de archivo específicos.
• Hay archivos grandes, numerosos o sensibles a latencia.
• La operación debe continuar con conectividad externa limitada.
• Existen permisos o flujos que todavía no pueden rediseñarse.
• Equipos industriales o técnicos requieren acceso local especializado.

Diferencias que más afectan a una pyme

• Colaboración y versiones frente a compatibilidad con carpetas tradicionales.
• Permisos mediante sitios y grupos frente a ACL de archivos y carpetas.
• Costo de licencias y gobierno frente a hardware, backup y mantenimiento local.
• Acceso remoto basado en identidad frente a VPN y red corporativa.
• Límites de sincronización, nombres y tipos de archivo.

El modelo híbrido puede ser el correcto

No todo debe migrarse junto. Muchas empresas dejan datos técnicos o aplicaciones en el servidor y trasladan documentación colaborativa a SharePoint.

• Clasificar información por proceso y patrón de uso.
• Definir una ubicación autorizada para cada tipo de contenido.
• Evitar copias paralelas sin propietario.
• Aplicar backup, retención y permisos según cada plataforma.

Preguntas para decidir

1. ¿Qué aplicaciones dependen de rutas de red?
2. ¿Qué archivos necesitan coautoría o acceso externo?
3. ¿Cómo se administran hoy permisos y bajas?
4. ¿Qué ocurre si se corta Internet o falla el servidor?
5. ¿Quién mantendrá estructura, propietarios y ciclo de vida?

Errores frecuentes en una migración

• Copiar la estructura completa de carpetas sin rediseñar información.
• Sincronizar bibliotecas enormes en todos los equipos.
• Replicar permisos únicos archivo por archivo.
• Migrar sin limpiar duplicados, nombres inválidos o contenido obsoleto.
• Confundir disponibilidad de Microsoft 365 con una estrategia de backup.

Elegir por cargas de trabajo, no por moda

Relevá una carpeta o proceso representativo, medí tipos de archivo, permisos y uso, y ejecutá un piloto. La evidencia del piloto debería decidir qué migra, qué permanece y qué necesita rediseño.

Migrar no consiste en copiar carpetas. Los permisos NTFS, grupos históricos y excepciones por archivo rara vez deberían trasladarse de forma literal a SharePoint.

El objetivo es conservar el acceso legítimo y mejorar el gobierno, sin ampliar permisos ni interrumpir aplicaciones que todavía dependen del servidor.

1. Inventariar antes de mover

• Volumen, cantidad, tamaño, antigüedad y tipos de archivo.
• Propietarios y áreas que realmente utilizan cada carpeta.
• Grupos, permisos explícitos, herencia rota y cuentas sin vigencia.
• Aplicaciones, macros, enlaces y procesos que usan rutas de red.
• Datos sensibles, duplicados y contenido sujeto a retención.

2. Diseñar sitios y límites de seguridad

SharePoint funciona mejor cuando cada sitio o biblioteca tiene propósito y audiencia claros.

• Separar procesos o áreas con necesidades de acceso diferentes.
• Asignar propietarios responsables de revisar miembros.
• Usar grupos en lugar de permisos individuales.
• Mantener herencia dentro de cada límite siempre que sea posible.
• Definir reglas para invitados y enlaces compartidos.

3. Preparar contenido y dependencias

• Corregir nombres, rutas, caracteres y archivos incompatibles.
• Archivar o eliminar sólo con autorización y evidencia.
• Resolver aplicaciones que requieren SMB antes del corte.
• Definir estrategia para accesos directos, enlaces y sincronización.
• Establecer ventana, comunicaciones y mesa de ayuda.

4. Ejecutar un piloto representativo

• Elegir un área con complejidad media y propietario comprometido.
• Migrar una copia inicial y medir errores.
• Probar permisos con usuarios autorizados y no autorizados.
• Validar búsqueda, versiones, sincronización y trabajo cotidiano.
• Registrar ajustes antes de ampliar el alcance.

5. Corte, validación y reversión

1. Congelar cambios o realizar sincronización incremental.
2. Completar migración y comparar conteos y errores.
3. Cambiar accesos de manera controlada.
4. Mantener origen en sólo lectura durante el período definido.
5. Cerrar únicamente después de aprobación y evidencia.

6. Gobierno después de migrar

• Revisar propietarios, invitados y permisos únicos.
• Controlar crecimiento, versiones y papelera.
• Definir retención y backup según necesidad.
• Capacitar sobre enlaces, sincronización y ubicación correcta.
• Actualizar documentación y retirar accesos al servidor cuando corresponda.

El resultado se valida con acceso positivo y negativo

No alcanza con comprobar que una persona puede abrir un documento. También hay que demostrar que quien no corresponde no puede acceder y que las aplicaciones críticas siguen funcionando.

Una migración profesional conserva evidencia de inventario, mapeo, errores, pruebas y aprobación del propietario de la información.

Cinco terabytes de datos productivos no equivalen a cinco terabytes de backup. La capacidad depende de cuánto cambia cada día, cuántos puntos se conservan, cuánto crece la información, qué reducción consigue la herramienta y cuántas copias existen.

Una estimación profesional expresa supuestos y márgenes. Los ratios comerciales de deduplicación no deberían reemplazar una medición sobre los datos reales.

Datos necesarios para calcular

• Volumen protegido real por sistema y tipo de dato.
• Tasa de cambio diaria y picos semanales o mensuales.
• Retención diaria, semanal, mensual y anual.
• Crecimiento esperado durante el horizonte de compra.
• Compresión y deduplicación observadas en una prueba.
• Cantidad de copias, repositorios y reserva operativa.

Modelo base de estimación

Como aproximación inicial: capacidad = copia completa efectiva + cambios retenidos + copias adicionales + crecimiento + margen. Cada componente debe calcularse después de reducción y con el comportamiento específico del producto.

• Partir de 5 TB usados, no de la capacidad nominal de los discos.
• Medir el cambio diario durante varias semanas.
• Multiplicar el cambio efectivo por los puntos retenidos.
• Agregar fulls sintéticos, activas o independientes según arquitectura.
• Reservar espacio para consolidación, restauración y mantenimiento.

Ejemplo conceptual con 5 TB

Si el entorno cambia un 2 % diario, genera alrededor de 100 GB brutos por día antes de reducción. Treinta puntos diarios podrían representar hasta 3 TB adicionales, pero el resultado real depende de compresión, deduplicación, fulls y retención extendida.

• No usar el ejemplo como dimensionamiento final.
• Separar máquinas virtuales, bases, archivos y Microsoft 365.
• Revisar si datos cifrados o comprimidos reducen la eficiencia.
• Modelar qué ocurre al crecer o fallar un repositorio.

Cómo impactan retención e inmutabilidad

• La retención larga acumula cambios y versiones históricas.
• La inmutabilidad puede impedir liberar espacio hasta vencer el período.
• Las copias fuera de sitio pueden tener otra reducción y costo.
• Los fulls periódicos pueden ser lógicos o consumir capacidad física adicional.
• Una política GFS necesita modelar semanales, mensuales y anuales.

Margen y rendimiento también son capacidad

• Evitar operar repositorios permanentemente cerca del límite.
• Considerar espacio temporal para merges, synthetic full y recuperación.
• Validar rendimiento de escritura durante la ventana de backup.
• Validar lectura durante restauraciones simultáneas.
• Asegurar que red, proxy y almacenamiento no limiten el RTO.

Cómo validar la estimación

1. Ejecutar una prueba representativa.
2. Registrar reducción, cambio diario y duración.
3. Simular crecimiento y retención durante 12 a 36 meses.
4. Incluir falla de un componente y reserva operativa.
5. Revisar mensualmente tendencia y fecha estimada de agotamiento.

Dimensionar con evidencia y revisar con tendencia

La cifra de compra debería poder rastrearse hasta datos, supuestos y objetivos de recuperación. Después de implementar, las métricas reales reemplazan los supuestos y permiten ampliar capacidad antes de llegar a una situación crítica.

Microsoft protege la disponibilidad de su plataforma, pero cada organización sigue siendo responsable de configurar identidades, permisos, retención y procesos de recuperación. Papelera, versiones, retención y backup no son exactamente lo mismo.

La pregunta correcta no es si Microsoft 365 tiene protección, sino si los mecanismos disponibles permiten recuperar los datos correctos dentro del tiempo y período que necesita la empresa.

Qué protecciones ya existen en Microsoft 365

• Alta disponibilidad del servicio administrada por Microsoft.
• Papelera y recuperación según carga de trabajo y configuración.
• Versionado de documentos en SharePoint y OneDrive.
• Políticas de retención, archivo y conservación cuando fueron configuradas.
• Auditoría e investigación según licenciamiento y período disponible.

Por qué esas funciones pueden no reemplazar un backup

• Comparten identidad y administración con el entorno que se quiere recuperar.
• Los períodos disponibles pueden no coincidir con la necesidad del negocio.
• Una eliminación, cifrado o cambio de permisos puede propagarse.
• La restauración masiva o granular puede no cumplir el RTO esperado.
• Retener información no siempre permite restaurarla al estado operativo deseado.

Escenarios que conviene probar

• Correo eliminado por un usuario y detectado tarde.
• Buzón de una persona que salió de la empresa.
• Biblioteca de SharePoint eliminada o con permisos modificados.
• Archivos de OneDrive cifrados o sobrescritos.
• Sitio, Teams o configuración vinculada que necesita reconstrucción.
• Solicitud legal o de auditoría sobre información histórica.

Cuándo una copia independiente agrega valor

• Se necesita una retención distinta de la disponible en producción.
• La empresa quiere una frontera administrativa o proveedor separado.
• Existen objetivos exigentes de recuperación granular o masiva.
• Hay requisitos contractuales, regulatorios o de evidencia.
• La operación no dispone de personal para reconstruir manualmente estructuras y permisos.

Qué evaluar en una solución de backup SaaS

• Cobertura real de Exchange, OneDrive, SharePoint y Teams.
• Frecuencia, retención, ubicación y cifrado.
• Protección de cuentas administrativas y MFA.
• Búsqueda, restauración granular, masiva y a ubicaciones alternativas.
• Registro de auditoría, alertas y pruebas automáticas.
• Salida de datos, costos de almacenamiento y dependencia del proveedor.

Decidir mediante RPO y RTO

Definí cuánto dato puede perderse, cuánto tiempo puede durar la recuperación y qué escenarios deben cubrirse. Después probá los mecanismos nativos y compará la brecha. Si la brecha es relevante, una copia independiente forma parte del control.

No comprar backup sin probar recuperación

La decisión debe quedar respaldada por una matriz de escenarios, responsables, tiempos y evidencia. Tanto una estrategia basada en funciones nativas como una solución adicional necesitan pruebas periódicas.

Cuando el Wi-Fi funciona mal, la primera reacción suele ser agregar repetidores o aumentar potencia. Esa acción puede ayudar a la cobertura y empeorar la capacidad o el roaming.

El diagnóstico debe separar dónde ocurre la degradación: radio, asociación, autenticación, DHCP, DNS, red cableada, firewall, proveedor de Internet o aplicación.

Síntomas típicos de un problema de cobertura

• La falla se concentra en lugares físicos concretos.
• La señal y el SNR son bajos incluso con poca gente.
• El rendimiento mejora claramente al acercarse al AP.
• Los clientes se conectan en bandas o velocidades básicas poco eficientes.
• Existen obstáculos o atenuaciones que el diseño no contempló.

Síntomas típicos de un problema de capacidad

• La red funciona bien vacía y se degrada en reuniones u horarios pico.
• La señal parece correcta pero aumentan latencia, retransmisiones y uso de canal.
• Muchos clientes se concentran en uno o pocos APs.
• Videollamadas y voz fallan antes que navegación liviana.
• El problema coincide con interferencia o alta utilización de airtime.

Problemas que parecen Wi-Fi pero no lo son

• DHCP agotado o lento.
• DNS con latencia o fallas intermitentes.
• Uplink, switch o puerto con errores.
• Firewall saturado o políticas que inspeccionan demasiado tráfico.
• Internet insuficiente o proveedor inestable.
• Aplicación cloud o VPN con degradación propia.

Mediciones mínimas para aislar la causa

• Señal, ruido, SNR, canal, ancho y velocidad negociada.
• Utilización, interferencia, retransmisiones y clientes por AP.
• Latencia y pérdida hacia gateway, DNS, Internet y aplicación.
• Prueba cableada simultánea para separar la red inalámbrica.
• Horario, ubicación, dispositivo y actividad durante cada incidente.

Pruebas controladas

1. Repetir la misma prueba cerca y lejos del AP.
2. Comparar horario vacío y horario de alta ocupación.
3. Probar un cliente representativo y otro de referencia.
4. Comparar Wi-Fi y cable contra los mismos destinos.
5. Cambiar una sola variable y registrar el resultado.

Qué acción corresponde a cada causa

• Cobertura: reubicar o agregar AP después de modelar señal.
• Capacidad: redistribuir celdas, canales, potencia y clientes.
• Interferencia: identificar fuente y rediseñar espectro.
• Roaming: revisar cobertura, potencia, mínimos y capacidades de clientes.
• Backhaul o Internet: corregir switch, enlace, firewall o proveedor.
• Diseño: realizar site survey y establecer criterios de aceptación.

Qué no conviene hacer

• Instalar repetidores domésticos en una red empresarial.
• Subir potencia de todos los APs al máximo.
• Usar canales anchos sin considerar el espectro disponible.
• Culpar al proveedor de Internet sin probar el gateway local.
• Cambiar varias configuraciones simultáneamente y perder evidencia.

Diagnosticar por capas evita compras innecesarias

Registrá ubicación, hora, dispositivo, señal y una prueba hacia destinos internos y externos. Con pocos datos consistentes suele ser posible decidir si falta cobertura, capacidad o si la causa está fuera del Wi-Fi.

Cincuenta usuarios no equivalen a cincuenta dispositivos. Teléfonos, notebooks, salas, impresoras y equipos IoT pueden duplicar o triplicar la cantidad de clientes conectados.

La cantidad de puntos de acceso se define por cobertura y capacidad. Una oficina pequeña con alta densidad puede necesitar más APs que un espacio grande con pocos usuarios, pero instalarlos sin plan de canales también puede empeorar la red.

La respuesta corta

Como preestimación, una oficina de 50 usuarios suele requerir varios APs empresariales, no uno solo. La cantidad final debe validarse con plano, materiales, densidad, espectro y aplicaciones. Dar un número exacto sin esos datos sería una falsa precisión.

Variables que cambian la cantidad

• Superficie, divisiones, hormigón, vidrio y estanterías.
• Cantidad simultánea de usuarios y dispositivos por persona.
• Videollamadas, voz Wi-Fi, escritorios virtuales y transferencias.
• Bandas, canales y capacidades de los clientes.
• Redes vecinas, interferencia y ruido.
• Necesidad de roaming entre zonas.

Calcular por capacidad

• Estimar clientes simultáneos por zona, no promedio de toda la oficina.
• Definir rendimiento útil requerido por aplicación.
• Considerar airtime, retransmisiones y protocolos de clientes antiguos.
• Mantener margen para reuniones, visitas y crecimiento.
• Distribuir carga entre APs y bandas compatibles.

Calcular por cobertura

• Definir nivel de señal y SNR objetivo para aplicaciones críticas.
• Ubicar APs cerca de usuarios, no dentro de racks o extremos del edificio.
• Considerar atenuación real de paredes y mobiliario.
• Diseñar superposición suficiente para roaming sin celdas excesivas.
• Validar después de instalar con mediciones pasivas y activas.

Infraestructura que suele olvidarse

• Cableado por cada AP y capacidad de los switches.
• Presupuesto PoE y respaldo eléctrico.
• Uplinks, VLAN, DHCP, DNS y firewall.
• Gestión centralizada, actualizaciones y monitoreo.
• Internet suficiente para la suma de aplicaciones cloud.

Señales de que faltan o sobran APs

• Faltan: señal débil, baja SNR, clientes concentrados y rendimiento desigual.
• Sobran o están mal ajustados: muchos APs audibles, interferencia co-canal y roaming inestable.
• En ambos casos, subir potencia o agregar equipos sin medir puede ocultar la causa.

Proceso recomendado

1. Relevar plano, materiales, usuarios, dispositivos y aplicaciones.
2. Crear un diseño predictivo y plan de canales.
3. Validar cableado, PoE y capacidad de red.
4. Instalar y ajustar por etapas.
5. Realizar site survey de validación bajo condiciones representativas.

Primero dimensionar, después comprar

La mejor respuesta no es una marca o cantidad fija, sino un diseño con criterios de aceptación. NeWeL puede relevar el espacio, estimar capacidad y validar la instalación con mediciones.

La cantidad de usuarios no determina por sí sola la licencia. Una empresa de 25 personas puede combinar perfiles administrativos, comerciales, operativos, compartidos y externos con necesidades distintas.

Los nombres, precios y condiciones comerciales de Microsoft pueden cambiar. Antes de publicar o contratar, hay que validar la oferta vigente y las restricciones aplicables en Argentina. La decisión técnica debe partir de capacidades necesarias, no del nombre del plan.

Primero separar perfiles de usuario

• Personas que necesitan aplicaciones de escritorio completas.
• Usuarios que trabajan principalmente desde navegador o móvil.
• Equipos que requieren administración centralizada y políticas de cumplimiento.
• Administradores o perfiles con mayor riesgo y acceso privilegiado.
• Cuentas compartidas, buzones funcionales, salas, invitados y personal temporal.

Capacidades que cambian la decisión

• Aplicaciones de Office de escritorio y uso sin conexión.
• Correo, Teams, OneDrive y SharePoint.
• Administración de dispositivos mediante Intune.
• Acceso Condicional y controles de identidad.
• Protección avanzada de endpoints y datos.
• Necesidades de archivo, auditoría, retención o cumplimiento.

Cómo interpretar los planes Business

Como orientación general, Business Basic prioriza servicios cloud y aplicaciones web; Business Standard agrega aplicaciones de escritorio; Business Premium incorpora capacidades adicionales de administración y seguridad. La composición exacta debe verificarse en la documentación comercial vigente.

• No asumir que todos necesitan el mismo plan.
• No asignar licencias de usuario a recursos que pueden resolverse con funciones específicas.
• No elegir Premium si la empresa no implementará y operará sus controles.
• No elegir sólo por precio si faltan capacidades necesarias para el riesgo real.

Ejemplo de mezcla para 25 personas

Una matriz inicial podría separar dirección y administración, equipo comercial, puestos operativos y administradores técnicos. El ejemplo no es una recomendación automática: sirve para relevar necesidades.

• Dirección y administración: aplicaciones completas, protección de datos y acceso seguro.
• Comerciales: movilidad, colaboración y protección del dispositivo.
• Operativos: aplicaciones y acceso según tarea real.
• Administradores: identidad reforzada, estaciones seguras y privilegios separados.
• Recursos compartidos: revisar si requieren usuario, buzón o licencia específica.

Errores que encarecen o debilitan el entorno

• Comprar el mismo plan para todos sin analizar perfiles.
• Pagar capacidades que nunca se configuran.
• Usar cuentas compartidas para evitar licencias y perder trazabilidad.
• No revisar licencias de personas que cambiaron de función o salieron.
• Comparar solamente precio por usuario y omitir backup, soporte y operación.

Checklist antes de comprar

1. Inventariar personas, dispositivos y aplicaciones.
2. Definir requisitos de seguridad y cumplimiento.
3. Mapear cada perfil a capacidades necesarias.
4. Validar compatibilidad, límites y precios vigentes.
5. Planificar configuración, adopción, soporte y revisión trimestral.

La licencia correcta es la que se implementa y gobierna

Microsoft 365 genera valor cuando la licencia, la configuración y el proceso operativo están alineados. Una capacidad comprada pero no configurada no reduce riesgos.

NeWeL puede relevar perfiles y construir una matriz de licenciamiento antes de una migración o renovación.