[lacnog] ERP/CRM/Billing para países de LACNIC (Excepto Brasil pt_BR)

Mar Abr 21 13:12:50 -03 2026

Hola Douglas:

Te doy mi optica, quizas muy basada en mi propia experiencia y eso
claramente tiene sesgo respecto del tamano de empresa en la cual trabajo.

Tu approach es interesante porque refleja a mi manera de ver implicitamente
los conceptos de BSS/OSS o segregacion de dominios, modularidad y APIs.

En nuestro caso esos conceptos los alineamos a TM Forum. Se que TM Forum
puedes sonar a mucho para el mundo de los ISP ya que tiene mas adherencia
en el segmento de los grandes operadores. No obstante en nuestro caso
buscamos tomar los conceptos que aplican a nuestra escala y en ese caso
alinearnos.

Me parece dificil encontrar una oferta que cubra todas las funciones y creo
que el approach debiera ser modular.

En principio y sin ser exhaustivo, hago algunos aportes que espero sirvan:

CRM:
- Si lo analizamos desde el la optica TM Forum, se abriria en varios
modulos. No obstante si el ISP, mantiene pocos productos y simples, creo
que podria ir a CRMs que no son de la industria. Aca el secreto es no
complejizar los productos que requieran un Product Catalog compliant con la
industria.
- Me pregunto si las funciones de ticketing no conviene manejarlas en un
modulo separado y de eso en el mercado hay opciones.

Provisioning PON:
- Creo que el abordaje seria tener un SOM con un Service Catalog y la
plataforma de Provisioning que incluya ACS.
- Esto puede parecer soficticado para uns primera etapa, pero si hablamos
de multivendor y autosuficiencai del ISP creo que es clave.

Campo:
- Aca creo que hablamos de herramientas de Workforce Mgmt.
- Fundamental que puedan interactuar con el CRM, Incident Manager y SOM.

Finalmente no veo nada respecto de Billing.

Espero sirva el aporte.

Hernan Arcidiacono

CTO

+549 11 5025 5106

On Mon, Apr 20, 2026 at 10:57 PM Douglas Fischer <fischerdouglas en gmail.com>
wrote:

> Hola!
> Busco sistemas de gestión para ISPs para países hispanohablantes de
> América Latina y Caribe.
>
> P.S.: Reflexioné mucho sobre si este mensaje era inapropiado para un Grupo
> de Operadores de Red.
>
> ¡Y llegué a la conclusión de que es sumamente on-topic!
>
> Cada comando que los operadores de red aplican a los equipos tiene la
> función, directa o indirecta, de hacer cumplir los contratos y servicios
> para los clientes de la empresa.
>
>
>
> Esta recopilación de "cosas a comprobar antes de contratar software"
> surgió de conversaciones entre amigos hablando sobre el dolor de
> interactuar con sistemas de gestión para explicar que las demandas que
> traemos tienen cierto sustento empírico y principalmente teórico basado en
> RFC, estándares de la UIT y legislación local.
>
> ¿Por qué excepto Brasil?
>
> La respuesta más correcta es porque conozco razonablemente bien los
> principales sistemas de gestión de los ISP que operan en Brasil. Y tengo la
> intención de agregar más detalles sobre las dificultades con ellos durante
> las próximas fases. Pero te aseguro que los dolores más dolorosos ya están
> mínimamente cubiertos en los requisitos ya descritos.
> Pero la segunda respuesta es que hasta ahora solo conozco 4 o 5 nombres de
> sistemas ERP para ISPs que son originarios de la región de LACNIC, y que
> hasta ahora por lo que he visto, todos tienen el mismo origen de haber
> mezclado lo que era ERP con DataPath durante un tiempo, y luego crear
> adaptaciones para alejarse de él. Pero casi todos terminan en
> arrendamientos estáticos o secretos estáticos no bendecidos. Los conceptos
> de OSS y BSS no están incluidos en estos sistemas.
> Y la tercera respuesta es que con prácticamente todas las Casas de
> Software de sistemas que consideran mínimamente buenas, con las que hablé
> sobre regionalizar sus soluciones para países específicos, siempre dijeron
> que hay algunas partes interesadas, pero nunca he visto que esto realmente
> entre en los sprints.
>
>
> A continuación se muestra una breve lista de requisitos (no creo que sea
> posible llamarla lista de requisitos ya que es muy embrionaria).
>
> Aspectos generales de la regionalización:
>
>    - Que esté bien traducido al español.
>    - Países de mayor interés: Argentina, Perú, Colombia, Paraguay, México.
>    - Integraciones con organismos reguladores (p. ej., Mintic, Antel,
>    etc.).
>    - Documentación contable que cubra posibles integraciones con
>    entidades contables.
>    - Integraciones bancarias, ya sea integradas en el sistema o mediante
>    integraciones con terceros. Siempre se priorizará evitar cargos adicionales.
>
>
> Aspectos generales de la arquitectura:
>
>    - Debe haberse construido con un buen modelado de datos en el ámbito
>    del cliente, el contrato, los elementos contractuales, el producto y los
>    servicios.
>       - Cada elemento contractual debe tener su propio ciclo de
>       aprovisionamiento o integración, así como la medición y validación de lo
>       entregado.
>          - Un ejemplo deseable de validación de la prestación del
>          servicio es que el cliente pague por recibir una dirección IPv4 pública
>          fija y que el sistema verifique, por todos los medios posibles, que esto se
>          está realizando correctamente.
>       - Es deseable que sean soportados campos personalizables
>    adicionales.
>       - Especialmente para cualquier objeto con algún tipo de integración
>       externa, permitiendo la inserción de atributos como el ID del objeto en la
>       otra plataforma con la que se integra el sistema.
>    - Es deseable el sistema ya estuviera integrado con algún sistema
>    NSOT - Network Source of Truth. Por ejemplo, NetBox, Nautobot o Infrahub.
>    - Es deseable que sean soportados TAGs creados/añadidos/removidos en
>    vivo para la mayoría de los objetos representados en sistema.
>       - El filtrado de informes, acciones masivas, etc., debe incluir el
>       uso de filtros.
>    - Debe contar con API y webhooks accesibles para todo el ámbito del
>    proveedor de servicios de Internet (ISP) del cliente del sistema.
>       - Es fundamental que estas API y webhooks estén bien documentados,
>       tanto en lo que respecta a la propia API como a cómo el objeto y el
>       atributo afectan al resto del sistema.
>    - El modelo de hosting del servicio puede ser local, en la nube,
>    híbrido o SaaS.
>       - En el caso de SaaS, es obligatorio demostrar que la
>       infraestructura de acceso y persistencia de datos no se comparte con otras
>       empresas.
>       - En los demás casos, es obligatorio que exista algún nivel de
>       segmentación de servicios de red de manera a evitar un escalado vertical
>       excesivo por tratarse de un monolito inmenso e intocable.
>    - La integración y el aprovisionamiento de configuraciones para
>    equipos de red deben realizarse desde al menos un servidor o contenedor
>    local dedicado a esta función.
>       - Cualquier tipo de integración, ya sea mediante API, Netconf,
>       Restconf o Wrapper a través de SSH/Telnet, debe ejecutarse dentro de este
>       contenedor o servidor.
>          - No se aceptarán proxy o NAT para este validar este tipo de
>          integración.
>       - Es deseable la compatibilidad con el procesamiento por lotes de
>    comandos/acciones de extracción, así como el mantenimiento de la misma
>    sesión de conexión activa para los equipos al aprovisionar múltiples
>    comandos.
>
>
> Servicio Radius
> No es obligatorio que el sistema incluya recursos de servidor Radius en su
> conjunto de funcionalidades. Sin embargo, *si los incluye, se aplican los
> siguientes requisitos*:
>
>    - Los servidores Radius deben poder ejecutarse en servidores
>    virtualizados, containers, o en Bare Metal.
>       - En todos los casos, deben estar en las instalaciones del
>       cliente(on-Premise).
>    - Debe soportar una arquitectura de alta disponibilidad para el
>    protocolo Radius y bancos de datos relacionados al radius.
>    - Debe soportar picos de consultas elevados debido a interrupciones
>    masivas del servicio de los suscriptores.
>    - Radius Accounting debe ser 100% funcional y confiable.
>       - Debe tener el mismo nível de criticidad que Radius
>       Authentication y Authorization.
>       - Debe contar con control y validación de sesión activos basados en
>       el radius Accounting, yo consultas al BNG través de SNMP o Wrapper
>       (Telnet/SSH).
>       - Debe admitir múltiples protocolos de entrega de servicios
>       finales, siendo IPoE y PPPoE obligatorios, y Catpive-Portal deseable.
>       - Debe permitir la autenticación mediante nombre de
>       usuario+contraseña, dirección MAC, circuit-id / remote-id de Option82/PITP
>       (tener TR-101 del broadband-forum.org como referencia).
>       - Debe contar con soporte nativo para el diccionario AV-Pair de los
>       principales fabricantes del sector ISP.
>       - Debe permitir la importación de un diccionario AV-Pair específico
>       para cada proveedor.
>       - Debe permitir la creación de pares AV-pair personalizados.
>
>
> Aprovisionamiento xPON
> No es obligatorio que el sistema incluya recursos de aprovisionamiento
> xPON. Sin embargo, *si los incluye, se aplican los siguientes requisitos*:
>
>    - Debe admitir scripts personalizables para cada acción de
>    configuración del cliente o cambio de estado. Estos scripts deben existir
>    para cada tipo de proveedor de equipo.
>    - La personalización debe incluir variables relacionadas con el
>    contexto de configuración (similar a Jinja2 o equivalente).
>    - Estos scripts personalizables deben ser accesibles para el operador
>    del sistema sin necesidad de autorización por parte del fabricante.
>    - Debe permitir la generación de un archivo de exportación con una
>    nueva representación de las configuraciones completas, basada en el estado
>    actual del sistema. La generación se permite por equipo, por ranura y por
>    interfaz.
>
>
>
> Interfaz gráfica para usuarios del sistema.
>
>    - Interfaces de aplicaciones desktop están fuera de discusión.
>    - Debe contar con una interfaz web intuitiva y fluida.
>       - Preferiblemente en una aplicación de una sola página siempre que
>       sea posible.
>    - Control de acceso al sistema por parte de usuarios operadores
>    (empleados de la empresa).
>       - Debe permitir la conexión a una base de usuarios externa con
>       soporte para un nivel mínimo de control de acceso basado en roles (RBAC)
>       mediante grupos de usuarios.
>          - Los protocolos permitidos en este mecanismo de autenticación
>          externa son: LDAPS, Kerberos, SAML, Radius, OAuth2 y OpenID.
>
>
> Gestión de servicios de campo
>
>    - Debe contar con una aplicación móvil (Android e iPhone) para
>    servicios de campo.
>    - Debe incluir rutinas personalizables, como la activación de
>    circuitos de clientes, órdenes de reparación, etc.
>    - Debe interactuar automáticamente con la gestión de la cola de
>    tickets de soporte, el control de inventario, etc.
>    - Debe generar rutas de servicio considerando el tiempo de actividad,
>    el tiempo y el costo de desplazamiento, y la prioridad del servicio.
>
>
> Contexto CRM
>
>    - Gestión de leads comerciales.
>    - Gestión de tickets de soporte.
>    - Portal del cliente.
>    - Integración con sistemas omnichannel
>    - Debe permitir la importación o integración del historial de
>    interacciones con el cliente en omnichannel dentro de la aplicación del
>    sistema. APLICACIÓN MÓVIL
>
>
> IMPORTANTE:
> Esta lista de requisitos no es exhaustiva!
>
> No incluye varios temas relevantes para la integración, como la
> integración de SIG y CGNAT.
> Me vi obligado a acortar mucho la lista para que no diera tanto miedo la
> primera lectura.
>
>
> Obviamente, se centra principalmente en el aspecto técnico, donde los
> operadores de red podemos colaborar.
>
> Cualquiera que quiera contribuir es bienvenido.
>
> Para cada línea de estos requisitos puedo compartir una historia
> ridículamente estúpida que ocurrió en interacciones con fabricantes de
> sistemas de gestión.
> Por eso pido ayuda para crear esto juntos precisamente para evitar que
> otras personas tengan que sufrir lo que nosotros ya hemos sufrido.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>

-- 
*No Imprimas Digitalizá*ESTE MENSAJE ES CONFIDENCIAL. Puede contener 
información amparada por el secreto profesional. Si usted ha recibido este 
e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y 
tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.

THIS 
MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged 
or otherwise legally exempt from disclosure. If you have received it by 
mistake please let us know by e-mail immediately and delete it from your 
system; should also not copy the message nor disclose its contents to 
anyone. Many thanks.

NSS S.A. – IPLAN | CUIT: 30-70265297-5 | IVA 
Responsable Inscripto | Ingr. Brutos: 901-033512-0 Inscripción I.G.J.: 
24/02/1999, N° 2588, libro 4, tomo - Sociedades por Acciones | Sede Social: 
Reconquista 865 2° Piso, CABA 
<https://maps.google.com/?q=Reconquista+865+2%C2%B0+Piso,+CABA&entry=gmail&source=g> 
C1003ABQ

Ley 25326 - art.27. - inc. 3. El titular podrá en cualquier 
momento solicitar el retiro o bloqueo de su nombre de los bancos de datos a 
los que se refiere el presente artículo.

Decreto 1558/01 - art. 27. - 
3er. párrafo. En toda comunicación con fines de publicidad que se realice 
por correo, teléfono, correo electrónico, Internet u otro medio a distancia 
a conocer, se deberá indicar, en forma expresa y destacada, la posibilidad 
del titular del dato de solicitar el retiro o bloqueo, total o parcial, de 
su nombre de la base de datos. A pedido del interesado, se deberá informar 
el nombre del responsable o usuario del banco de datos que proveyó la 
información.

El titular de los datos personales tiene la facultad de 
ejercer el derecho de acceso a los mismos en forma gratuita y a intervalos 
no inferiores a 6 meses, salvo que se acredite un interés legítimo al 
efecto conforme lo establecido por el artículo 14, inciso 3 de la ley 
25326.-

La Agencia de Acceso a la Información Pública , órgano de 
control de la ley Nº 25.326, tiene la atribución de atender las denuncias y 
reclamos que se interpongan con relación al incumplimiento de las normas 
sobre protección de datos personales.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260421/3be0890b/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : no disponible
Tipo       : image/png
Tamaño     : 7644 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20260421/3be0890b/attachment-0001.png>