Tema 5.8 — Tecnología

Ruta académica

Programa: Business Administration
Bloque 1: Fundamentos de administración
Unidad 2: La empresa como sistema
Tema 5: Áreas funcionales de la empresa
Subtema: Tecnología

Objetivos de aprendizaje

Al finalizar este subtema deberás ser capaz de:

1. Explicar tecnología como capacidad empresarial y no solamente como soporte técnico.
2. Distinguir IT, software engineering, product technology y digital operations.
3. Comprender build vs. buy, arquitectura, seguridad y continuidad.
4. Analizar el papel de datos, integraciones y automatización.
5. Identificar métricas básicas de servicio y entrega tecnológica.
6. Relacionar tecnología con estrategia, procesos y gobierno.

1. Tecnología como función empresarial

Durante décadas, muchas organizaciones trataron tecnología como un área de soporte:

"necesitamos computadoras"
"necesitamos correo"
"necesitamos reparar sistemas"

Hoy, en muchas empresas, la tecnología también define:

• el producto;
• el canal;
• la experiencia del cliente;
• los procesos internos;
• la velocidad de aprendizaje;
• la capacidad de escalar.

Por eso, administrar tecnología es una cuestión empresarial.

2. IT no es exactamente software engineering

Information Technology

Puede incluir:

• dispositivos;
• redes;
• identidades;
• SaaS corporativo;
• infraestructura;
• help desk;
• seguridad.

Software Engineering

Diseña, construye, prueba y mantiene software.

Product Technology

Tecnología que forma parte directa de la propuesta de valor al cliente.

En una empresa digital estas fronteras pueden superponerse.

3. Tecnología y estrategia

La dirección debe responder:

• ¿qué capacidades tecnológicas diferencian al negocio?;
• ¿qué debe ser commodity?;
• ¿qué tecnología limita crecimiento?;
• ¿qué riesgos aceptamos?;
• ¿qué inversión requiere la estrategia?

La tecnología debe derivarse del modelo operativo y estratégico, no de modas.

4. Build vs. Buy

Una decisión frecuente:

CONSTRUIR
vs.
COMPRAR / SUSCRIBIR

Build puede ser razonable cuando

• la capacidad es diferenciadora;
• existen requisitos muy particulares;
• se dispone de talento y tiempo.

Buy puede ser razonable cuando

• el problema es común;
• existe solución madura;
• velocidad importa;
• mantener software propio no genera ventaja.

No existe respuesta universal.

5. Total Cost of Ownership

El precio de licencia no representa todo el costo.

TCO puede incluir:

• implementación;
• integración;
• migración;
• capacitación;
• soporte;
• personal;
• upgrades;
• seguridad;
• switching cost.

Una herramienta “barata” puede resultar costosa si genera trabajo manual permanente.

6. Arquitectura empresarial

La arquitectura busca coherencia entre:

• procesos;
• aplicaciones;
• datos;
• integraciones;
• infraestructura.

Ejemplo:

CRM
 ↓
ORDER MANAGEMENT
 ↓
ERP
 ↓
BILLING
 ↓
FINANCE
 ↓
ANALYTICS

Si cada sistema define al cliente de forma distinta, la integración se vuelve frágil.

7. Sistemas of Record

Un system of record es una fuente autorizada para cierto tipo de dato.

Ejemplo:

Empleado → HRIS
Factura → ERP
Oportunidad → CRM
Código → Git repository

Definir ownership evita múltiples “verdades” incompatibles.

8. Master Data

Datos maestros suelen incluir:

• clientes;
• proveedores;
• productos;
• empleados;
• cuentas;
• ubicaciones.

Una mala gobernanza produce duplicidad y errores que se propagan entre funciones.

9. Integraciones

Los sistemas intercambian información mediante:

• APIs;
• eventos;
• archivos;
• ETL/ELT;
• middleware.

Una integración debe definir:

• fuente;
• destino;
• contrato de datos;
• frecuencia;
• errores;
• reintentos;
• ownership.

10. Automatización

Automatizar significa trasladar ejecución repetible a software.

Ejemplo:

Pedido aprobado
      ↓
crear orden
      ↓
generar factura
      ↓
notificar cliente

Pero primero debe entenderse el proceso.

MAL PROCESO + AUTOMATIZACIÓN
=
MAL PROCESO MÁS RÁPIDO

11. Workflow

Un workflow coordina estados, reglas y participantes.

Ejemplo:

BORRADOR
  ↓
REVISIÓN
  ↓
APROBACIÓN
  ↓
EJECUCIÓN
  ↓
CERRADO

Los workflows materializan políticas empresariales.

12. Identity and Access Management

Tecnología debe responder:

• quién es el usuario;
• a qué tenant pertenece;
• qué rol tiene;
• qué recurso puede consultar;
• qué acción puede ejecutar.

Conceptos:

• authentication;
• authorization;
• RBAC;
• MFA;
• least privilege;
• lifecycle de acceso.

13. Seguridad

Security no es una función aislada del negocio.

Riesgos tecnológicos pueden afectar:

• ingresos;
• continuidad;
• reputación;
• datos personales;
• contratos;
• regulación.

La seguridad debe equilibrar protección y operación.

14. Continuidad y resiliencia

Preguntas básicas:

• ¿qué pasa si un sistema falla?;
• ¿cuánto tiempo podemos operar sin él?;
• ¿cuánto dato podemos perder?;
• ¿qué dependencias externas existen?

Conceptos frecuentes:

• backup;
• disaster recovery;
• RTO;
• RPO;
• redundancy.

15. Service Management

IT también opera servicios internos.

Ejemplo:

INCIDENT
 ↓
TRIAGE
 ↓
ASSIGN
 ↓
RESOLVE
 ↓
VERIFY
 ↓
CLOSE

La disciplina de IT service management busca consistencia en incidentes, cambios y solicitudes.

16. Incident vs. Problem

Incident

Interrupción o degradación que necesita restauración.

Problem

Causa subyacente de uno o más incidentes.

Resolver un incidente no significa eliminar su causa.

17. Change Management técnico

Cambiar software o infraestructura introduce riesgo.

Un proceso de cambio puede evaluar:

• impacto;
• reversibilidad;
• pruebas;
• ventana;
• rollback;
• comunicación.

Las organizaciones maduras buscan velocidad con controles proporcionales, no burocracia automática.

18. Tecnología y deuda técnica

Technical debt representa compromisos acumulados que encarecen cambios futuros.

Ejemplos:

• código difícil de mantener;
• integraciones frágiles;
• librerías obsoletas;
• arquitectura inconsistente;
• falta de pruebas.

Puede ser decisión deliberada, pero debe hacerse visible.

19. Cloud

Cloud computing transforma decisiones de infraestructura mediante servicios consumidos bajo demanda.

Beneficios posibles:

• elasticidad;
• velocidad;
• servicios administrados.

Riesgos:

• costos variables;
• dependencia de proveedor;
• configuración insegura;
• arquitectura poco portable.

Cloud no elimina necesidad de gobierno.

20. Datos y Analytics

La función tecnológica habilita pipelines que convierten eventos en información.

SISTEMAS OPERATIVOS
      ↓
DATA PLATFORM
      ↓
MODELOS / MÉTRICAS
      ↓
BI / ANALYTICS
      ↓
DECISIÓN

El valor depende de calidad semántica, no solo de almacenamiento.

21. Inteligencia artificial

AI puede participar en:

• clasificación;
• generación;
• forecasting;
• detección de anomalías;
• soporte a decisiones.

Antes de desplegarla deben definirse:

• propósito;
• datos;
• evaluación;
• supervisión;
• fallbacks;
• accountability.

22. Product Management y tecnología

En productos digitales, product management coordina:

CUSTOMER
   ↕
BUSINESS
   ↕
DESIGN
   ↕
ENGINEERING

Tecnología no debería recibir únicamente “requisitos terminados”; puede participar en descubrimiento y diseño de solución.

23. Tecnología y proveedores

Muchas capacidades dependen de terceros:

• cloud;
• pagos;
• mensajería;
• identidad;
• analytics;
• ERP.

Vendor management debe considerar:

• SLA;
• seguridad;
• continuidad;
• costo;
• exit strategy.

24. Tecnología y finanzas

Technology spending incluye:

• personal;
• cloud;
• licencias;
• hardware;
• consultoría;
• desarrollo.

FinOps, por ejemplo, busca mejorar la responsabilidad económica del uso cloud.

25. Métricas frecuentes

Dependiendo de la función:

• uptime;
• availability;
• incident volume;
• mean time to restore;
• deployment frequency;
• change failure rate;
• lead time for changes;
• cloud cost;
• ticket resolution time;
• security incidents.

Las métricas DORA son especialmente conocidas para software delivery.

26. Caso aplicado

Una empresa utiliza 40 aplicaciones SaaS. Nadie sabe cuál contiene el dato maestro del cliente y cada área compra herramientas sin revisión arquitectónica.

Analiza:

1. duplicidad;
2. costos;
3. seguridad;
4. integración;
5. ownership;
6. vendor risk;
7. propuesta de gobierno.

27. Preguntas de reflexión

1. ¿Cuándo tecnología es soporte y cuándo es producto?
2. ¿Qué criterios usarías para build vs. buy?
3. ¿Por qué master data es un problema empresarial?
4. ¿Qué diferencia existe entre incidente y problema?
5. ¿Qué riesgo genera una integración sin owner?
6. ¿Cómo se relaciona arquitectura tecnológica con arquitectura organizacional?

28. Ejercicio aplicado

Diseña un mapa de aplicaciones para una empresa.

Incluye:

• CRM;
• ERP;
• HRIS;
• soporte;
• identidad;
• analytics.

Para cada sistema define:

• función;
• datos maestros;
• integraciones;
• owner;
• riesgo principal;
• SLA esperado.

29. Ideas clave

• Tecnología es una capacidad empresarial.
• Build vs. buy debe evaluarse con estrategia y TCO.
• Datos e integraciones requieren ownership.
• Seguridad, continuidad y permisos son parte del diseño.
• Automatizar exige comprender primero el proceso.
• La arquitectura digital debe soportar procesos end-to-end.

30. Videos recomendados en YouTube

1. MIT OpenCourseWare — Information Technology / Digital Transformation
   Búsqueda directa: https://www.youtube.com/results?search_query=MIT+OpenCourseWare+information+technology+digital+transformation

2. Google Cloud Tech — Cloud Architecture
   Búsqueda directa: https://www.youtube.com/results?search_query=Google+Cloud+Tech+cloud+architecture

31. Bibliografía y fuentes verificables

• Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy. Harvard Business School Press.
• Weill, P., & Ross, J. W. (2004). IT Governance. Harvard Business School Press.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution.
• Kim, G., Humble, J., Debois, P., & Willis, J. (2021). The DevOps Handbook (2nd ed.). IT Revolution.

Fuentes abiertas

• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• DORA research: https://dora.dev/

Navegación

← Anterior: Recursos Humanos · Índice del Tema 5 · Siguiente: Compras →