<div dir="ltr"><div><div>Hola!<br>Busco sistemas de gestión para ISPs para países hispanohablantes de América Latina y Caribe.</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>P.S.: Reflexioné mucho sobre si este mensaje era inapropiado para un Grupo de Operadores de Red.</div></div></blockquote><div><blockquote style="margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:currentcolor;padding:0px"><div>¡Y llegué a la conclusión de que es sumamente on-topic!</div></blockquote></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:currentcolor;padding:0px"><div>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.</div></blockquote></div></blockquote><div><br></div><div><br></div><div>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.</div><div><br>¿Por qué excepto Brasil?<br><br>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.<br>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.<br>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.</div><div><br></div><div><br></div><div>A continuación se muestra una breve lista de requisitos (no creo que sea posible llamarla lista de requisitos ya que es muy embrionaria).</div><div><br></div><div>Aspectos generales de la regionalización:<br><ul><li>Que esté bien traducido al español.</li><li>Países de mayor interés: Argentina, Perú, Colombia, Paraguay, México.</li><li>Integraciones con organismos reguladores (p. ej., Mintic, Antel, etc.).</li><li>Documentación contable que cubra posibles integraciones con entidades contables.</li><li>Integraciones bancarias, ya sea integradas en el sistema o mediante integraciones con terceros. Siempre se priorizará evitar cargos adicionales.</li></ul><br>Aspectos generales de la arquitectura:<br><ul><li>Debe haberse construido con un buen modelado de datos en el ámbito del cliente, el contrato, los elementos contractuales, el producto y los servicios.</li><ul><li>Cada elemento contractual debe tener su propio ciclo de aprovisionamiento o integración, así como la medición y validación de lo entregado.</li><ul><li>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.</li></ul></ul><li>Es deseable que sean soportados campos personalizables adicionales.</li><ul><li>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.</li></ul><li>Es deseable el sistema ya estuviera integrado con algún sistema NSOT - Network Source of Truth. Por ejemplo, NetBox, Nautobot o Infrahub.</li><li>Es deseable que sean soportados TAGs creados/añadidos/removidos en vivo para la mayoría de los objetos representados en sistema.</li><ul><li>El filtrado de informes, acciones masivas, etc., debe incluir el uso de filtros.</li></ul><li>Debe contar con API y webhooks accesibles para todo el ámbito del proveedor de servicios de Internet (ISP) del cliente del sistema.</li><ul><li>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.</li></ul><li>El modelo de hosting del servicio puede ser local, en la nube, híbrido o SaaS.</li><ul><li>En el caso de SaaS, es obligatorio demostrar que la infraestructura de acceso y persistencia de datos no se comparte con otras empresas.</li><li>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.</li></ul><li>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.</li><ul><li>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.</li><ul><li>No se aceptarán proxy o NAT para este validar este tipo de integración.</li></ul></ul><li>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.</li></ul></div><div><br></div><div>Servicio Radius<br>No es obligatorio que el sistema incluya recursos de servidor Radius en su conjunto de funcionalidades. Sin embargo, <b>si los incluye, se aplican los siguientes requisitos</b>:<br><ul><li>Los servidores Radius deben poder ejecutarse en servidores virtualizados, containers, o en Bare Metal.</li><ul><li>En todos los casos, deben estar en las instalaciones del cliente(on-Premise).</li></ul><li>Debe soportar una arquitectura de alta disponibilidad para el protocolo Radius y bancos de datos relacionados al radius.</li><li>Debe soportar picos de consultas elevados debido a interrupciones masivas del servicio de los suscriptores.</li><li>Radius Accounting debe ser 100% funcional y confiable.</li><ul><li>Debe tener el mismo nível de criticidad que Radius Authentication y Authorization.</li><li>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).</li><li>Debe admitir múltiples protocolos de entrega de servicios finales, siendo IPoE y PPPoE obligatorios, y Catpive-Portal deseable.</li><li>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 <a href="http://broadband-forum.org">broadband-forum.org</a> como referencia).</li><li>Debe contar con soporte nativo para el diccionario AV-Pair de los principales fabricantes del sector ISP.</li><li>Debe permitir la importación de un diccionario AV-Pair específico para cada proveedor.</li><li>Debe permitir la creación de pares AV-pair personalizados.</li></ul></ul><br>Aprovisionamiento xPON<br>No es obligatorio que el sistema incluya recursos de aprovisionamiento xPON. Sin embargo, <b>si los incluye, se aplican los siguientes requisitos</b>:<br><ul><li>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.</li><li>La personalización debe incluir variables relacionadas con el contexto de configuración (similar a Jinja2 o equivalente).</li><li>Estos scripts personalizables deben ser accesibles para el operador del sistema sin necesidad de autorización por parte del fabricante.</li><li>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.</li></ul><br><div><br></div>Interfaz gráfica para usuarios del sistema.<br><ul><li>Interfaces de aplicaciones desktop están fuera de discusión.</li><li>Debe contar con una interfaz web intuitiva y fluida.</li><ul><li>Preferiblemente en una aplicación de una sola página siempre que sea posible.</li></ul><li>Control de acceso al sistema por parte de usuarios operadores (empleados de la empresa).</li><ul><li>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.</li><ul><li>Los protocolos permitidos en este mecanismo de autenticación externa son: LDAPS, Kerberos, SAML, Radius, OAuth2 y OpenID.</li></ul></ul></ul></div><div><br>Gestión de servicios de campo<br></div><ul><li>Debe contar con una aplicación móvil (Android e iPhone) para servicios de campo.</li><li>Debe incluir rutinas personalizables, como la activación de circuitos de clientes, órdenes de reparación, etc.</li><li>Debe interactuar automáticamente con la gestión de la cola de tickets de soporte, el control de inventario, etc.</li><li>Debe generar rutas de servicio considerando el tiempo de actividad, el tiempo y el costo de desplazamiento, y la prioridad del servicio.</li></ul><div><br>Contexto CRM<br><ul><li>Gestión de leads comerciales.</li><li>Gestión de tickets de soporte.</li><li>Portal del cliente.</li><li>Integración con sistemas omnichannel</li><li>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</li></ul><br>IMPORTANTE:<br>Esta lista de requisitos no es exhaustiva!</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>No incluye varios temas relevantes para la integración, como la integración de SIG y CGNAT.</div><div>Me vi obligado a acortar mucho la lista para que no diera tanto miedo la primera lectura.</div></blockquote><div><br>Obviamente, se centra principalmente en el aspecto técnico, donde los operadores de red podemos colaborar.<br><br></div><div>Cualquiera que quiera contribuir es bienvenido.<br><br>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.<br>Por eso pido ayuda para crear esto juntos precisamente para evitar que otras personas tengan que sufrir lo que nosotros ya hemos sufrido.</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;word-wrap:break-word;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div></div></div>