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

[Douglas Fischer]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260420/e000fd66/attachment.htm>