Boa noite.
Gostaria de sugerir aos Dev do sistema algumas alterações com base nas dificuldades que as vezes enfrente.
Não vejo sentido em Pool está associado ao PLANO, uma vez que o IP nada tem a ver com velocidade.
Item 1 - Controle de Pools:
Seria uma boa se os Pools ( PROVEDOR -> CONTROLE DE POOLS ) fossem um objeto a ser utilizado no ramal.
Sendo assim, um ramal teria seu(s) pool(s) definidos como objeto, e você poderia fazer todo apontamento de um range inteiro para aquele POP, Cidade, Cliente Empresa, etc..etc...
Item 2 - Gestão de cliente e contrato
Indo mais a fundo, um cadastro tambem de um objeto chamado CONTRATO. E a esse contrato relacionado um outro objeto LOGIN (com todas suas correspondentes informações) que por sua vez estaria relacionado ao objeto CLIENTE.
Dessa forma ficaria:
Cadastrar CLIENTE
Relacionar o cliente a um contrato já cadastrado, gerando uma chave ID unica.
Criar um objeto LOGIN e associar a esse contrato.
Eliminar a coluna ADICIONAL, e cada login adicional seria um novo objeto associado a um novo contrato dentro de um objeto CLIENTE.
O financeiro seria gerado com base em cada contrato, ou seja...cliente com 10 logins, teria 10 contratos. Podendo ter 10 boletos ou apenas um boleto totalizado.
Item 3 - Taxa de instalação
A taxa de instalação estaria amarrada a cada template de contrato, e seria adicionada automaticamente na primeira fatura do cliente.
Item 4 - Retirar a busca de CEP
E de conhecimento de todos que muitos endereços estão desatualizados.
Seria interessante, um cadastro na própria empresa das cidades, ruas, ceps e estado que cada um trabalha.
Item 5 - Princing
Criar no item 4, uma referencia valores de instalação e de mensalidade.
Ou seja,
Cidade A teria aliquota de x% ou R$ x,00.
Ao cadastrar o cliente, na selação da cidade (pre cadastrada) os valores dos planos se ajustariam.
Essa necessidade atenderia ajustes manuais e criação de varios planos. Quem atende em varias cidades sabe como é isso. Se no site, for possivel a busca da cidade...e essa busca amarrada ao pricing..seria fantastico.
Analisem as ideias. Não conheço muito do mkauth, mas sou integrador de ERP com experiencia em OpenERP, OpenBravo e Adempire...e essas funcionalidades são básicas nesses sistemas (Sistemas ERP modulares mas NAO tem suporte a necessidade de provedor)
Espero que as dicas sejam validas.
Abraços
Paulo Cangussu
Respostas
A falta da opção de mudança do técnico no fechamento do chamado é um gargalo no meu workflow.
Chamados:
Incluir a opção de mudar o técnico do chamado na tela de fechamento do chamado. Atualmente eu tenho que selecionar o chamado, alterar o técnico, voltar à lista para depois fechar o chamado.
Um bom recurso seria ter modelos de permissões prontos para operadores, atendentes, caixa, financeiro e gerência.
Por exemplo, eu não posso habilitar que um atendente veja os carnês de um cliente sem que ele possa adicionar e remover os carnês. Baixar os carnês e criar novos não há problema, o problema é poder alterar e excluir os mesmos. Sem isso o atendente não pode dizer nem qual é a data de vencimento de um cliente que ligue perguntando.
Outro problema é a baixa granularidade das permissões. Eu não posso permitir que um usuário veja os carnês de um cliente, podendo imprimi-los, salvá-los, enviá-los por e-mail, sem que que esse usuário possa fazer novos lançamentos. Nem a data de vencimento do cliente fica disponível em modo somente leitura.
Gostei muito das observações do analista :D, quando eu instalei o Mk-Auth pela 1a vez eu já esperava algo do tipo. Confesso que eu fiquei muito confuso no início com a forma original. Tive essa necessidade em relação aos clientes logo de cara.
Esse ponto não depende de tamanho de rede é só uma questão de automação mesmo, seja pra 1 cliente, seja para 1000000, além, de agregar valor ao sistema tornando ele mais produtivo e seguro, parabéns Paulo.
Tenho uma pequena sugestão também em contas a pagar:
Inclusão da opção: Está conta se repete? Sim ou Não e a periodicidade se quinzenal, mensal, anual etc... e tempo de contrato. Nesse caso o mk-auth já lança por exemplo 2 anos de conta sem a necessidade de cadastrar mês a mês...
Isso muito me incomoda. As ações de cliente deveriam estar disponíveis em todas as páginas relativas a clientes.
E outra coisa, bem básica, os e-mails. Por que os e-mails não são "clicáveis"? Por que os telefones não são "clicáveis"?
Paulo Cangussu disse:
Tem muitas coisas no MK-AUTH que empacam meu workflow. A designação de IPs não é uma delas.
Qualquer rede é grande quando não há um plano de gerenciamento.
2 mil, 3 mil usuários não é grande e nem deve assustar. A solução é ser proativo. O chamado interno precisa ter prioridade máxima.
É preciso saber que o cliente está com problemas antes mesmo dele. Isso só é possível com monitoramento. Nenhuma rede é grande demais para ser monitorada.
Paulo Cangussu disse:
Marcos... a conversa está fungindo do seu proposito.
Não se trata de interpretação minha, sua, anatal ou quem seja...tambem não se trata de usar IP publico ou privado, rota estratica ou dinamica.. Tratase de processos, WORKFLOW... controle, praticidade.
Quando eu digo que um provedor com 1k cliente é pequeno, eh porque a quantidade de chamados, instalacoes que se tem diariamente da pra fazer manualmente.. com 2k ja começa a complicar. Ainda que voce tenha um unico POP, independente de fibra, utp, radio ou oq seja... um sistema de gestão tem que ter mais do que isso pra ser chamado de ERP.
Da uma olhadinha no OpenBravo e Odoo..e vai entender oq estou dizendo.
2 mil clientes é uma rede pequena. Até 5 mil clientes é pequeno, pelo critério da ANATEL.
Está muito difícil conseguir mais do que um /22 hoje em dia. A solução é o IPv6, que as grandes operadoras não querem funcionanado porque resolve a escassez que as favorece.
Paulo Cangussu disse:
Também faltou o monitoramento da rede, e a opção do cliente escolher a data e hora do chamado.
-
1
-
2
de 2 Próximo