Software del agua

// El problema

Una empresa de agua y saneamiento envía las facturas por correo postal, cobra con cheque y en ventanilla, y anuncia los avisos de hervir el agua y los cortes por teléfono y redes sociales, así que los clientes llaman para preguntar qué pasa.

// Lo que construiríamos

Un portal de clientes con la marca de la propia empresa, donde los clientes ven su consumo y sus facturas, pagan en línea y se apuntan a los avisos por correo o SMS, con un mapa de cortes y avisos a partir del SIG de la empresa. Las facturas y las cuentas se leen del sistema de facturación a través de su API. Comprobamos el suyo antes de dar un precio. El texto de los avisos lo fijan las personas responsables en su empresa.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• API del sistema de facturación
• ArcGIS REST API
• Pasarela de pago alojada del procesador de pagos
• AWS Canada

// El problema

Una junta regional del agua factura desde una base de datos Access con macros escritas por un antiguo empleado, los lectores teclean las lecturas desde papel, y un cambio en la tabla de tarifas supone una semana de pruebas sobre una copia del archivo.

// Lo que construiríamos

Primero una revisión de arquitectura del sistema antiguo, con un plan por escrito, y después un nuevo sistema de facturación que conserva cada cuenta, tarifa e historial, una aplicación Android que los lectores usan sin conexión en su ruta, y ciclos de facturación cotejados con el sistema antiguo antes del cambio. Los asientos contables van a QuickBooks Online, construido sobre su API.

// Qué incluye

// Tecnologías

• Next.js
• Kotlin para Android
• PostgreSQL
• API de QuickBooks Online
• AWS Canada

// El problema

Los operadores de una empresa de agua solo ven SCADA en la sala de control, los resultados de laboratorio están en hojas de cálculo, y los datos del informe mensual y el panel del ayuntamiento se montan a mano con ambas fuentes.

// Lo que construiríamos

Un almacén de datos que lee los datos del historiador de SCADA mediante una conexión de solo lectura, incorpora los resultados de laboratorio y el consumo facturado, y muestra paneles para operadores, directivos y el ayuntamiento. Prepara los datos de los informes para que su operador responsable los revise y los presente. Nunca se escribe nada de vuelta en SCADA ni en ningún sistema de control.

// Qué incluye

// Tecnologías

• PostgreSQL
• dbt
• API del historiador (solo lectura)
• Next.js
• Apache Superset
• AWS Canada

// El problema

Las cuadrillas reciben las órdenes de trabajo en papel, las revisiones de las estaciones de bombeo están en un archivador, y el inventario de acometidas de plomo que la empresa debe mantener es una hoja de cálculo con huecos en la mitad de las direcciones.

// Lo que construiríamos

Un espacio de trabajo web y una aplicación iOS y Android que las cuadrillas usan sin conexión, sobre el SIG y el registro de activos de la empresa: órdenes de trabajo para tuberías, válvulas, hidrantes y bombas, rondas por las estaciones, y un inventario de acometidas con el material anotado en cada dirección, cómo se averiguó y fotos. Una consulta pública muestra a cada vecino lo que se sabe de su acometida.

// Qué incluye

// Tecnologías

• Next.js
• React Native
• PostgreSQL con PostGIS
• ArcGIS REST API
• AWS Canada

// El problema

Una empresa multiservicio que factura agua, alcantarillado y energía de distrito tiene un sistema de facturación, un sistema central de datos de contadores, un SIG, un sistema de órdenes de trabajo y un software financiero que no se comunican, así que el personal exporta e importa archivos cada noche.

// Lo que construiríamos

Un centro de integración interno que une los cinco sistemas a través de una sola API: las lecturas de contador llegan a la facturación, las cuentas nuevas llegan al sistema de órdenes de trabajo y las direcciones de suministro se mantienen al día con el SIG. Cada conector se construye sobre la API publicada o la exportación del sistema. Comprobamos el suyo antes de dar un precio. Lo gestionamos por usted, con monitorización y alertas.

// Qué incluye

// Tecnologías

• Node.js
• PostgreSQL
• OpenAPI
• API de facturación y de datos de contadores
• ArcGIS REST API
• AWS Canada

// El problema

Una empresa municipal atiende a clientes que hablan muchos idiomas, sus páginas de ayuda solo existen en inglés, y el centro de llamadas se llena con las mismas preguntas sobre facturas, mudanzas y avisos de calidad del agua.

// Lo que construiríamos

Un centro de ayuda en inglés, en francés y en los idiomas que hablan sus clientes, con un asistente que responde a partir de los artículos aprobados, los cita y pasa la conversación a una persona. Los avisos activos aparecen primero. El asistente responde a preguntas generales. No ve las cuentas y nunca da consejos de salud o seguridad más allá del propio aviso.

// Qué incluye

// Tecnologías

• Next.js
• Claude API
• PostgreSQL con pgvector
• Plataforma de gestión de traducciones
• AWS Canada

// El problema

Varios municipios compran agua tratada a una misma planta regional, las lecturas de los contadores generales y el reparto de costes se calculan en una hoja de cálculo que lleva la planta, y cada municipio lo comprueba a su manera.

// Lo que construiríamos

Un registro compartido donde se anotan y se acuerdan cada mes las lecturas de los contadores generales, los costes de inversión y de explotación y la parte de cada miembro, en un libro privado con permisos del que cada miembro tiene un nodo. Unos extractos mensuales firmados suelen bastar. El libro ayuda cuando varios miembros necesitan el mismo registro y ninguno quiere que lo guarde otro.

// Qué incluye

// Tecnologías

• Next.js
• Hyperledger Besu (privada, con permisos)
• PostgreSQL
• AWS Canada