Desarrollo, automatización e infraestructura para dependencias, entidades, ayuntamientos y órganos autónomos. Un sistema se paga con dinero público y tiene que seguir funcionando cuando cambian el titular, el área y el proveedor.
Falla en la entrega-recepción. Cuando el área que lo pidió cambia de titular y nadie sabe dónde se modifica una tarifa o un requisito. Cuando la contraseña del servidor estaba en el correo personal de quien ya se fue. Cuando el dominio quedó a nombre del proveedor y la nueva administración tiene que contratar otra vez lo que ya se había pagado.
No es un problema técnico. Es lo que ocurre cuando un sistema se contrata como si fuera a durar lo mismo que el periodo de gobierno. Las administraciones cambian y la institución permanece, así que el sistema tiene que quedarse con la institución.
Por eso trabajamos al revés. Cada cuenta se abre a nombre de la institución y con correo institucional, cada entrega se documenta para que alguien más pueda continuarla y el código queda en condiciones de compartirse con otras instituciones, como hoy prevé la política federal de compartición de soluciones tecnológicas.
Un sistema pagado con recursos públicos no es del proveedor ni de la administración. Es de la institución.
Antes de cotizar revisamos si el problema se resuelve sin construir nada. A veces otra institución ya lo resolvió y puede compartir su solución. A veces lo que falla es el trámite, y llevarlo a internet tal como está solo cambia la ventanilla por una pantalla.
Cuatro frentes, cubiertos por la misma gente. El área usuaria no tiene que coordinar al del portal con el del correo y con el del sistema, ni servir de intermediaria entre ellos cuando algo falla.
Sitios oficiales y portales de trámites y servicios en línea, con dominio, correo y certificado de seguridad configurados a nombre de la institución.
Control de expedientes, oficialía de partes, inventarios, padrones y registros, para los casos en que ninguna herramienta existente resuelve lo que el área necesita.
Conexión entre los sistemas que ya operan para eliminar la captura doble, los reportes armados a mano y la información que hoy circula por correo en hojas de cálculo.
Servidores, dominios, cuentas y respaldos administrados, con monitoreo y un plan de continuidad para cuando algo se cae.
Revisión de exposición, control de accesos, doble factor, protección de correo y respuesta ante incidentes y ransomware.
Migración a Google Workspace o Microsoft 365, con la configuración y la asistencia necesarias para que el personal la use de verdad y no vuelva al método anterior.
Integración de los trámites en línea con los medios de pago de la tesorería y con la emisión de comprobantes fiscales a través del proveedor de certificación de CFDI que la institución tenga contratado.
Mantenimiento, actualizaciones y mejoras cuando el sistema ya está en producción, de forma remota o con personal en sitio, bajo un contrato independiente del desarrollo.
Formación práctica para servidores públicos en las herramientas que usan a diario, con material que se queda en la institución cuando el personal cambia.
Suministro, configuración y puesta en marcha, dimensionados a lo que el área exige y no a lo que conviene vender.
Análisis de lo que la institución ya tiene y hoja de ruta antes de comprometer presupuesto en licencias, sistemas o desarrollos que quizá no necesita.
Para áreas y ayuntamientos que hoy operan con papel y mensajería. Ordenamos lo esencial desde el inicio, sin tecnicismos y sin exigir un área de sistemas propia.
El expediente del contrato se integra desde la primera entrega, con constancia de recepción, documentación y relación de accesos. Con eso el administrador del contrato tramita el pago y atiende una auditoría sin reconstruir nada.
La operación de la institución no vive dentro de Trexter. Vive en servicios de terceros, con sus propios contratos y su propio soporte, contratados a nombre de la institución. Esta es la configuración de partida cuando el área no tiene una propia.
Ninguno de estos renglones está cerrado. Si la institución ya cuenta con infraestructura propia, un contrato marco vigente o lineamientos de su área de tecnologías, se trabaja sobre eso. Lo que no cambia es que todo quede a nombre de la institución.
Sin dependencias escondidas que aparecen el día de la entrega-recepción. Esto es lo que recibe siempre, además de lo que fije el contrato.
Nada de esto depende de que la institución vuelva a contratarnos. Es la única manera de que el sistema siga siendo público el día que dejemos de estar en la conversación.
Licitación pública, invitación a cuando menos tres personas, adjudicación directa, acuerdos marco o el procedimiento que corresponda según el monto y la normativa federal, estatal o municipal aplicable. Presentamos la documentación que exige cada convocatoria, incluidas las opiniones de cumplimiento de obligaciones fiscales y de seguridad social vigentes, y cada contrato queda abierto a la revisión de los órganos de control.
Si un proveedor esquiva alguna de estas, el área ya sabe algo importante sobre él.
Sigue operando. Las cuentas son institucionales, los manuales ya están en el expediente y quien llegue recibe accesos y código sin tener que buscar a nadie.
De la institución, con correo institucional de recuperación. Ni del proveedor ni del servidor público que firmó la solicitud, porque quien la firma puede dejar el cargo y la institución sigue.
Sí. Se entrega con su documentación y sin licencias que lo amarren a Trexter, de modo que la institución puede compartirlo o integrarlo a un repositorio público cuando así lo decida.
La institución, que es la responsable. Trexter los trata como encargado, solo para lo que establece el contrato y conforme a sus instrucciones, y al terminar los devuelve o los suprime según lo que la institución disponga.
Sí, y suelen ser las que más lo necesitan. En ayuntamientos pequeños dejamos una operación que el personal administrativo pueda sostener, con capacitación y manuales escritos para quien no es técnico.
Un portal institucional, unas semanas. Un sistema con integraciones, meses. No comprometemos una fecha antes de conocer el alcance, porque una fecha sin alcance no se cumple.
Describa el problema, no la solución. Si tiene arreglo sin desarrollo de por medio, se lo diremos. Y si no somos el proveedor adecuado para su caso, también.
