Ir al contenido principal

Analista de TI

Pedro HenriqueMoreno

Trabajo con soporte de sistemas, ERP, MES, bases de datos y automatización. Tengo experiencia en entornos multiplanta, con foco en la estabilidad de los servicios y la mejora de los procesos.

Retrato de Pedro Henrique Moreno
Desplázate para empezar
Quién soy

Del primer empleo en TI a Analista, en la misma empresa.

Cuatro años, tres cargos y un alcance que solo creció. No cambié de empresa para crecer: cambié de problema.

Grupo Umaflex fue mi primer empleo en TI. Entré en junio de 2022 como Asistente de TI Junior, mientras cursaba Análisis y Desarrollo de Sistemas en la FATEC Arthur de Azevedo y estaba a punto de titularme. Era la oportunidad de descubrir, en la práctica, si lo que estudiaba resolvía problemas reales. Y los resolvía.

Mi trabajo empezó en el nivel 1: mantener en pie un parque de unos 285 equipos repartidos en tres plantas — São Paulo, Paraná y Pernambuco — y operar el help desk en ManageEngine. Registrar, categorizar, resolver. Ahí aprendí lo primero que todavía guía mi trabajo. Estructuré la base de conocimiento del help desk, con manuales y artículos de resolución, y los tickets repetidos empezaron a caer.

En diciembre de 2023 asumí como Asistente de TI Sénior y el alcance pasó de la máquina al sistema. Empecé a atender nivel 2 y 3 en ERP y MES — unos 20 tickets por semana, con troubleshooting y análisis de causa raíz — y descubrí que la respuesta a la mayoría no estaba en la pantalla del usuario: estaba en la base de datos. Comencé a escribir consultas en SQL y PL/SQL sobre la base Oracle para demostrar hipótesis con datos. Lo que nació como herramienta de diagnóstico se convirtió en entrega: más de 50 informes de gestión para fiscal, comercial, compras, planificación de producción y finanzas, la mayoría incorporados a la rutina de decisión de esas áreas.

En ese mismo periodo salí de la sala de TI y bajé a la planta. Implementé el sistema de etiquetado de productos y el proyecto de picking de carga, formé a los equipos y acompañé la implantación: los errores de carga y entrega cayeron drásticamente. También desarrollé la intranet corporativa en PHP y JavaScript, que centralizó comunicados, acceso a sistemas, extensiones telefónicas y el menú del comedor de las tres plantas. En paralelo, administraba Active Directory con GPO, unas 200 licencias de Microsoft 365, Entra ID y Exchange Online.

Desde julio de 2025 soy Analista de TI. Sostengo los servicios de las tres plantas con foco en disponibilidad y continuidad, monitorizo el entorno con Zabbix y Grafana para tratar la alerta antes de que se convierta en caída, y dirijo proyectos de mejora continua que eliminaron retrabajos y tickets recurrentes en las áreas de negocio. Hoy mi prioridad se inclina cada vez más hacia sistemas: acompaño las formaciones de las áreas para sostener el nuevo ERP en la migración de Focco a SAP.

La formación acompañó el camino: terminé el título de Tecnólogo en Análisis y Desarrollo de Sistemas en la FATEC y seguí con el posgrado en Sistemas de Gestión con énfasis en SAP, en FETES. Cuatro años en la misma empresa no fueron acomodarse: fueron el tiempo necesario para entender el negocio desde dentro. Es lo que me permite hablar con el desarrollador, con el DBA, con el gestor y con el operario de planta sin cambiar de vocabulario a mitad de frase.

El mismo ticket apareciendo por quinta vez no es un problema de atención. Es un problema de proceso.

Cómo resuelvo problemas

Un ticket cerrado no es el objetivo. Es el principio.

El soporte que solo atiende tickets se convierte en una cola infinita. Lo que aplico es un ciclo: entender, demostrarlo con datos, automatizar, implantar junto al área de negocio y monitorizar — para que el problema no haya que resolverlo dos veces.

De dónde salió este método

Nada de esto vino de un curso. Grupo Umaflex fue mi primer empleo en TI: entré en 2022 mientras terminaba la FATEC, atendiendo nivel 1 en tres plantas. Este ciclo se fue construyendo ticket a ticket, en el orden en que los problemas me obligaron a aprender: primero documentar, después investigar a fondo, después demostrar con datos, después automatizar. Cuatro años en la misma empresa me dieron algo que cambiar de trabajo no da: ver el efecto de mis propias decisiones de hace dos años.

  1. 01

    Problema

    El ticket describe el síntoma.

    Traduzco el relato del usuario a un hecho observable: qué se detuvo, desde cuándo, para quién y qué cambió antes. Sin eso, todo lo demás es una suposición con prisa.

  2. 02

    Investigación

    Reproducir antes de opinar.

    Reproduzco el escenario, leo los logs, reviso los paneles de Zabbix y Grafana y delimito el alcance: ¿es un usuario, una planta o las tres? El tamaño del problema cambia la prioridad y la solución.

  3. 03

    Análisis de causa raíz

    Separar el efecto del origen.

    Una solución que devuelve el servicio pero no explica el fallo solo aplaza el siguiente ticket. La pregunta que cierra la etapa es siempre la misma: ¿por qué esto fue posible?

  4. 04

    SQL

    La base de datos no opina.

    Consulto la base Oracle en SQL y PL/SQL para confirmar o descartar la hipótesis con datos, no con impresiones. Es donde la discusión entre TI y negocio deja de ser una opinión.

  5. 05

    Automatización

    Lo que se hizo a mano dos veces, se convierte en rutina.

    La tarea repetitiva pasa a ser un informe, una consulta o una rutina programada. Menos operación manual significa menos error humano y más tiempo para lo que sí exige análisis.

  6. 06

    Implementación

    Un cambio sin formación no es una entrega.

    Implanto junto al área, formo a quien va a usarlo y acompaño los primeros ciclos. Un sistema que el usuario no entiende vuelve como ticket la semana siguiente.

  7. 07

    Monitorización

    Enterarse antes que el usuario.

    Pongo lo corregido bajo monitorización en Zabbix y Grafana. El objetivo es tratar la alerta mientras todavía es una alerta, y no después, cuando ya es una caída.

  8. 08

    Mejora continua

    El mejor ticket es el que no vuelve.

    Lo documento en la base de conocimiento y reviso el proceso que generó el fallo. El soporte maduro se mide por el volumen que dejó de existir, no por el que se cerró.

Resultados

Un número sin contexto es un adorno.

Cada indicador viene de mi currículum y va acompañado de lo que significa en la operación diaria.

Los valores marcados con ≈ son aproximados, tal como constan en el currículum.

  • 4

    años en soporte de aplicaciones

    Cuatro años en el mismo grupo industrial y tres cargos: de soporte nivel 1 a Analista de TI, con un alcance creciente en cada etapa.

  • 3

    plantas sostenidas

    São Paulo, Paraná y Pernambuco en paralelo. Todo cambio tiene que funcionar en tres realidades operativas distintas.

  • 285

    usuarios y equipos atendidos

    El parque bajo mi responsabilidad: disponibilidad de hardware, software e impresión en las tres plantas.

  • 50 +

    informes de gestión desarrollados

    En SQL y PL/SQL sobre base Oracle, para fiscal, comercial, compras, planificación y finanzas. La mayoría pasó a la rutina de decisión.

  • 200

    licencias Microsoft 365 administradas

    Ciclo completo de identidad y comunicación: Active Directory con GPO, Entra ID y Exchange Online en tres plantas.

  • 20

    tickets de nivel 2/3 por semana

    Media de soporte avanzado a ERP y MES — el volumen que obligó a crear método en lugar de improvisar.

  • N1–N3

    niveles de soporte cubiertos

    Desde la primera atención hasta el análisis que cierra el problema, sin depender de un traspaso a otro nivel.

  • Focco → SAP

    migración de ERP en curso

    Acompaño las formaciones de las áreas para sostener el nuevo ERP — el proyecto de mayor impacto de mi función hoy.

Mucho más que soporte

Sostener bien exige ver el sistema entero.

Un problema de ERP casi nunca es solo del ERP: es la base de datos, los permisos, la red, el proceso y la interfaz a la vez. Estos son los frentes en los que trabajo, y la razón por la que cierro el diagnóstico en lugar de trasladar el problema.

Elige un frente para ver el detalle.

Soporte de Aplicaciones e ITSM

El núcleo del puesto: mantener disponible el servicio de negocio con proceso, no con heroísmos.

  • Gestión de incidencias
  • Troubleshooting
  • Análisis de causa raíz (RCA)
  • Soporte nivel 1–3 / Service Desk
  • Gestión de colas y categorización
  • SLA
  • Base de conocimiento
ManageEngine ServiceDesk Plus ITIL 4

Bases de Datos

Donde vive de verdad la mayoría de los problemas de ERP. Uso la base tanto para diagnosticar como para entregar.

  • Consultas para diagnóstico de incidencias
  • Informes de gestión
  • Modelado y lectura de esquema
Oracle SQL Server MySQL SQL PL/SQL

Desarrollo

No me presento como desarrollador, pero saber programar cambia la naturaleza de mi soporte: leo el código que falló.

  • Desarrollo interno de sistemas
  • Mantenimiento de aplicación en producción
  • Control de versiones
PHP JavaScript Node.js jQuery Bootstrap Git GitHub

Infraestructura y Servidores

La capa donde nace la caída. Invisible cuando funciona, y detiene la fábrica cuando falla.

  • Servidor de archivos e impresión
  • Directorio y directivas de grupo
  • Virtualización
  • Rutinas de copia de seguridad
Windows Server Active Directory GPO Linux Proxmox Docker

Microsoft y Nube Corporativa

Identidad, correo y dispositivo son la puerta de entrada a todo lo demás: administrarlos bien elimina el riesgo de acceso.

  • Gestión de ≈200 licencias
  • Altas y bajas de usuarios
  • Política de acceso
Microsoft 365 Entra ID Exchange Online Intune

Monitorización y Observabilidad

La diferencia entre reaccionar y anticipar: la alerta llega antes que el usuario.

  • Tratamiento de alertas antes de la caída
  • Paneles de indicadores
  • Delimitación del alcance de la incidencia
Zabbix Grafana

ERP y Negocio

Sostener un ERP exige entender el proceso antes que el sistema: la mayoría de los tickets son reglas de negocio mal traducidas.

  • Soporte de ERP y MES
  • Migración de ERP en curso
  • Entorno multiplanta (SP/PR/PE)
  • Fiscal, comercial, compras, planificación y finanzas
Focco MES SAP SAP BTP

Experiencia del Usuario Interno

Un sistema que el usuario no entiende genera tickets, así que la interfaz es asunto del soporte.

  • Intranet corporativa
  • Tabletas de consulta en planta
  • Manuales y artículos de resolución
  • Formación de equipos en la implantación
jQuery Bootstrap

Elige un frente para ver el detalle.

Mapa de habilidades

Dónde soy profundo y dónde soy suficiente.

Un radar al máximo en todos los ejes no dice nada. Este tiene picos y valles a propósito: muestra que mi especialidad es el soporte de aplicaciones y las bases de datos, y que desarrollo e infraestructura son una base real, no una fachada.

  • Soporte e ITSM 92

    Cuatro años en la función, cobertura de nivel 1 a 3, análisis de causa raíz y base de conocimiento estructurada.

  • Bases de Datos 85

    Más de 50 informes en SQL y PL/SQL sobre Oracle, usados como diagnóstico y como entrega.

  • ERP y MES 80

    Soporte de Focco y MES en entorno multiplanta; migración a SAP en curso.

  • Microsoft y Nube 82

    Active Directory con GPO, ≈200 licencias Microsoft 365, Entra ID, Exchange Online e Intune en tres plantas.

  • Infraestructura 76

    Windows Server, Linux, Proxmox, Docker y rutinas de copia de seguridad.

  • Automatización y Monitorización 80

    Zabbix y Grafana en producción, automatización de informes y proyectos de mejora continua que eliminaron retrabajo.

  • Desarrollo 70

    PHP, JavaScript y Node.js — la intranet corporativa es mía. Es un diferencial, no mi función principal.

Casos reales

Problemas de operación, resueltos con tecnología.

Dos casos, descritos desde el problema hasta el aprendizaje. Ningún proyecto de escaparate: ambos ocurrieron en producción, con usuarios reales esperando al otro lado.

Completado 12/2023 – 07/2025

Etiquetado de productos y picking de carga

El error que sale del almacén vuelve como devolución. Lo atacamos en el origen: en la verificación.

El problema

Errores de carga y entrega. Un artículo equivocado en el camión no termina en el almacén: vuelve como devolución, flete rehecho, retrabajo de planificación y desgaste con el cliente.

Mi participación

  • Implementé el sistema de etiquetado de productos.
  • Implementé el proyecto de picking de carga.
  • Formé a los equipos en la nueva rutina de verificación.
  • Acompañé la implantación hasta que la rutina se sostuvo sola en la operación.

Resultado

Caída drástica de los errores de carga y entrega, con una verificación que dejó de depender de la memoria del operario.

Ver el caso completo

Contexto

Operación industrial en tres plantas (SP, PR y PE), con una verificación de carga que dependía de la lectura humana y del conocimiento acumulado del operario.

Un error de expedición es uno de los pocos problemas cercanos a TI cuyo coste aparece entero en el resultado de la empresa: flete, devolución, retrabajo y crédito al cliente. Y suele tratarse como un descuido, lo que garantiza que vuelva a ocurrir.

El enfoque fue sacar la verificación de la memoria del operario y ponerla en el proceso. Con etiquetado de producto y picking estructurado, la comprobación pasa a tener un paso auditable: el artículo que sale es el que se pidió, y eso se confirma antes de cerrar el camión.

La parte menos técnica fue la más decisiva. Expedición trabaja contrarreloj, y cualquier paso nuevo que retrase la carga se abandona el primer día difícil. Por eso la formación y el seguimiento de la implantación entraron en el alcance del proyecto: una solución solo existe de verdad cuando sobrevive al día en que nadie tiene tiempo.

Aprendizajes

  • Un proyecto de planta no se entrega en un entorno de pruebas: si el equipo de expedición no entiende el flujo, la rutina vuelve al papel en la primera semana de presión.
  • La formación y el seguimiento posterior a la implantación no son la fase final del proyecto: son parte de la solución.
  • La identificación física es control de proceso: donde hay etiqueta hay trazabilidad, y donde hay trazabilidad el error tiene dirección.
Completado 12/2023 – 07/2025

Intranet corporativa de tres plantas

La comunicación interna repartida entre correos, tablones y extensiones memorizadas — reunida en un único punto de acceso.

El problema

La información interna estaba repartida entre correos, tablones y el conocimiento de cada persona. Encontrar una extensión, conocer el comunicado de la semana o localizar el enlace de un sistema dependía de preguntar a alguien.

Mi participación

  • Desarrollé la intranet corporativa en PHP y JavaScript.
  • Centralicé comunicados, acceso a sistemas, extensiones telefónicas y el menú del comedor en un solo lugar.
  • Mantuve la aplicación en operación durante todo el periodo, evolucionándola según la demanda de las áreas.

Resultado

Comunicación interna de las tres plantas centralizada en un único punto de acceso, mantenido internamente y sin coste de licencia.

  • PHP
  • JavaScript
Ver el caso completo

Contexto

Tres plantas (SP, PR y PE) con unos 285 usuarios y ninguna puerta de entrada única para la información interna.

Flujo de la solución

  1. 1

    Punto único de acceso

    Una puerta de entrada para la información interna de las tres plantas.

  2. 2

    Comunicados

    Publicación centralizada, en lugar de depender del correo y del tablón.

  3. 3

    Acceso a sistemas

    Enlaces de los sistemas corporativos reunidos, reduciendo los tickets de "dónde está".

  4. 4

    Extensiones y menú

    Consulta rápida del día a día, lo que garantiza el acceso recurrente.

  5. 5

    Mantenimiento interno

    Evolución conducida internamente según lo que pedían las áreas.

Ningún usuario abre un ticket diciendo «la comunicación interna está fragmentada». Abre uno diciendo que no encontró la extensión, que no sabía del comunicado o que perdió el enlace del sistema. Son tickets pequeños, frecuentes e invisibles en el indicador, y sumados consumen una parte considerable del tiempo de soporte.

La intranet fue la respuesta estructural a esa categoría de ticket. PHP y JavaScript, sin licencia, sin proveedor y sin dependencia externa: una aplicación interna que resuelve lo que antes era una pregunta recurrente.

La decisión de diseño que mejor funcionó fue incluir lo que parecía menos importante. El comunicado corporativo tiene poca audiencia por naturaleza; el menú del comedor tiene audiencia diaria. Al ponerlos en el mismo sitio, el acceso recurrente arrastró al resto, y la intranet se volvió un hábito en lugar de un favorito olvidado.

Mantener la aplicación también cambió mi relación con el desarrollo. Cuando el error es tuyo, dejas de pensar en «arreglarlo» y empiezas a pensar en por qué ese estado era posible, que es exactamente el análisis de causa raíz aplicado al código.

Aprendizajes

  • Una herramienta interna se mide por la adopción espontánea: si hay que recordarle al usuario que la use, el problema nunca fue la falta de un sistema.
  • El elemento aparentemente banal — el menú del comedor — fue el que trajo el acceso diario. Es la visita recurrente la que hace que se lea el comunicado.
  • Construir y sostener la propia aplicación enseña el otro lado del ticket: pasé a ser el responsable del error que antes solo reportaba.
Experiencia profesional

La trayectoria en orden cronológico.

Tres cargos en el mismo grupo industrial, cada uno con un alcance mayor que el anterior.

  1. jul 2025 — actual · 1 año y 1 mes Actual

    Analista de TI

    Grupo Umaflex — Industria multiplanta — SP · PR · PE, Brasil

    Continuidad de los servicios de TI de tres plantas, con prioridad creciente hacia sistemas y hacia el proyecto de ERP.

    El reto

    Mantener disponibles tres plantas industriales mientras el principal sistema de negocio de la empresa está en migración.

    • Sostengo los servicios de TI de 3 plantas (SP/PR/PE), atendiendo a unos 285 usuarios y equipos, con foco en disponibilidad y continuidad.
    • Mantengo el soporte de nivel 1–2, el help desk en ManageEngine y la administración del entorno Microsoft (AD/M365), hoy con prioridad creciente hacia el área de sistemas y el proyecto de ERP.
    • Monitorizo el entorno con Zabbix y Grafana y trato las alertas antes de que se conviertan en caídas.
    • Acompaño las formaciones de las áreas de negocio en preparación para sostener el nuevo ERP en la migración de Focco a SAP.
    • Dirijo proyectos de mejora continua que eliminaron retrabajos y tickets recurrentes en las áreas de negocio.
    • Desarrollo informes y automatizaciones que sustituyeron tareas manuales y aceleraron la decisión de las áreas usuarias.

    El puesto cambió el eje del trabajo: de resolver lo que ya se rompió a evitar que se rompa. Con el entorno instrumentado en Zabbix y Grafana, la alerta llega antes que el usuario, y lo que habría sido una incidencia se convierte en mantenimiento programado.

    En paralelo, es el periodo en el que el área de sistemas pasa a pesar más que la de infraestructura en mi rutina: acompaño las formaciones de las áreas de negocio para sostener el nuevo ERP en la migración de Focco a SAP, y convierto la tarea manual en informe y automatización para que la decisión del área no dependa de una comprobación humana.

    • Zabbix
    • Grafana
    • ManageEngine ServiceDesk Plus
    • Active Directory / GPO
    • Microsoft 365
    • Oracle
    • SQL
    • PL/SQL
    • Focco
    • SAP
  2. dic 2023 — jul 2025 · 1 año y 7 meses

    Asistente de TI Sénior

    Grupo Umaflex — Industria multiplanta — SP · PR · PE, Brasil

    Soporte de nivel 2/3 a ERP y MES, desarrollo interno y administración del entorno Microsoft en las tres plantas.

    El reto

    Atender el volumen de soporte avanzado sin que el mismo problema volviera, y demostrar cada diagnóstico con datos y no con impresiones.

    • Presté soporte avanzado (nivel 2/3) a ERP y MES, atendiendo una media de 20 tickets por semana con troubleshooting y análisis de causa raíz.
    • Desarrollé más de 50 informes de gestión (fiscal, comercial, compras, planificación, finanzas) mediante consultas SQL y PL/SQL sobre base Oracle — la mayoría incorporados a la rutina de decisión de las áreas.
    • Implementé el sistema de etiquetado de productos y el proyecto de picking de carga, reduciendo drásticamente los errores de carga y entrega, con formación de los equipos y seguimiento de la implantación.
    • Instalé tabletas en los puestos de producción para que los responsables consultaran indicadores.
    • Administré Active Directory (GPO), unas 200 licencias de Microsoft 365, Entra ID y Exchange Online en las 3 plantas.
    • Desarrollé y mantuve la intranet corporativa (PHP/JS) — comunicados, acceso a sistemas, extensiones y menú del comedor, centralizando la comunicación interna.

    Es el periodo más denso de la trayectoria y el que definió al profesional que soy hoy. El soporte avanzado a ERP y MES me obligó a dejar de tratar síntomas: con unos veinte tickets por semana, solo el análisis de causa raíz reduce la cola.

    Fue también cuando la base de datos dejó de ser asunto del DBA y pasó a ser mi herramienta principal. Las consultas que escribía para diagnosticar se convirtieron en entrega: más de cincuenta informes de gestión que hoy sostienen decisiones en cinco áreas distintas.

    Y fue cuando salí de la sala de TI. Etiquetado y picking de carga son proyectos de planta: exigen entender el proceso antes que el sistema, formar al equipo y acompañar la implantación hasta que la rutina se sostenga sin mí.

    • Oracle
    • SQL
    • PL/SQL
    • PHP
    • JavaScript
    • Active Directory / GPO
    • Microsoft 365
    • Entra ID
    • Exchange Online
    • Focco
    • MES
  3. jun 2022 — dic 2023 · 1 año y 6 meses

    Asistente de TI Junior

    Grupo Umaflex — Industria multiplanta — SP · PR · PE, Brasil

    Mi primer empleo en TI, mientras terminaba la universidad: soporte de nivel 1 a unos 285 equipos en tres plantas y operación del help desk.

    El reto

    Absorber el volumen de nivel 1 en tres plantas y, al mismo tiempo, atacar la causa de los tickets que volvían siempre.

    • Atendí en nivel 1 un parque de unos 285 equipos en las 3 plantas, garantizando la disponibilidad de hardware, software e impresoras.
    • Operé el help desk en ManageEngine (ServiceDesk Plus): registro, categorización y resolución de tickets dentro del flujo de atención.
    • Estructuré la base de conocimiento del help desk, con manuales y artículos de resolución que redujeron los tickets repetidos.

    El punto de partida, y mi primer empleo en el sector, aceptado mientras terminaba el título de Tecnólogo en Análisis y Desarrollo de Sistemas en la FATEC. Atender nivel 1 en tres plantas enseña muy rápido la diferencia entre urgencia y prioridad, y a reconocer un patrón: un ticket es un ticket; el mismo ticket cinco veces es un proceso mal resuelto.

    Esa lectura fue la que me llevó a estructurar la base de conocimiento del help desk. Documentar una resolución no es burocracia: es la forma más barata de quitar volumen de la cola y de que la atención dependa menos de quién esté de guardia.

    • ManageEngine ServiceDesk Plus
    • Windows Server
    • Active Directory
    • Microsoft 365
Certificaciones y formación

La base formal detrás de la práctica.

Formación en análisis y desarrollo de sistemas, posgrado en sistemas de gestión con énfasis en SAP y certificaciones en las plataformas que sostengo.

Formación académica

Certificaciones

  • Completado

    Oracle Database Design

    Oracle

    La base formal de lo que más hago: entender el modelo de datos antes de consultarlo. Es lo que separa una consulta que responde a la pregunta de una consulta que solo devuelve filas.

  • Completado

    Desarrollador SAP BTP

    Megawork Consultoria

    Extensión e integración en la plataforma SAP. Elegida por la migración de ERP en curso: quien sostiene SAP tiene que saber discutir la personalización, no solo reportarla al proveedor.

  • En curso

    ITIL 4 Foundation

    Formalizar el vocabulario de gestión de servicios que ya practico: incidencia, cola, categorización, SLA y mejora continua. Un proceso bien nombrado es un proceso que no depende de quién esté de guardia.

Contacto

¿Construimos soluciones mejores?

Si buscas a alguien que entienda de soporte de aplicaciones, ERP, bases de datos y automatización — y que hable el idioma del negocio — merece la pena hablar.

Mogi Mirim · SP · Brasil Suelo responder el mismo día laborable.

O descarga el currículum en PDF