Executando verificação de segurança...
1

Pitch: dProc - Gestão de processos administrativos digitais (uso SQL ou NoSQL?)

Olá gurizada!

Gostaria de opiniões sobre se seria melhor usar bancos de dados relacional (SQL) ou NoSQL (penso que um orientado a documentos seja uma boa alternativa).

PITCH: dProc - Gestão de processos administrativos digitais

Problema:

A gestão de processos administrativos em organizações frequentemente enfrenta desafios como excesso de papelada, falta de padronização, dificuldade no acompanhamento do andamento dos processos e risco de extravio de documentos. Esses problemas resultam em atrasos, retrabalho, baixa transparência e aumento de custos operacionais, dificultando a tomada de decisões e a eficiência administrativa.

Solução:

A solução proposta é o dProc, uma plataforma digital que centraliza e automatiza a gestão de processos administrativos. Com o dProc, todos os documentos e fluxos de trabalho são digitalizados, permitindo padronização, rastreabilidade e acesso rápido às informações. O sistema oferece funcionalidades como acompanhamento em tempo real, notificações automáticas, controle de versões e permissões de acesso, reduzindo o uso de papel, minimizando erros e aumentando a transparência. Dessa forma, o dProc otimiza o tempo dos colaboradores, reduz custos operacionais e proporciona maior segurança e eficiência na administração dos processos.

Termos e Definições

Processo
: Conjunto de etapas e ações administrativas organizadas para atingir um objetivo específico.

Etapa
: Fase individual de um processo, composta por uma ou mais ações a serem realizadas.

Ação
: Operação específica executada em uma etapa, como aprovar, reprovar ou emitir parecer.

Ato
: Registro de qualquer operação realizada no sistema, incluindo execução de ações, anexos ou comentários.

Agente
: Usuário ou entidade responsável por executar atos em um processo. Pode ser uma unidade, cargo ou pessoa.

Interessado
: Pessoa interna ou externa ao sistema que acompanha o andamento do processo e recebe notificações.

Unidade
: Setor ou departamento organizacional ao qual agentes e cargos devem estar vinculados.

Cargo
: Função ocupada por um agente dentro de uma unidade.

Documento
: Arquivo ou informação anexada ao processo, podendo ser interno (criado no sistema) ou externo.

Template
: Modelo pré-definido de etapas, agentes e ações para padronizar tipos de processos.

Macroprocesso
: Agrupamento de vários processos relacionados, gerenciados como uma unidade.

Assinatura Digital
: Mecanismo de validação de atos e documentos, realizado por senha ou certificado digital.

Captura de Etapa
: Ato de um agente do tipo pessoa assumir a responsabilidade por uma etapa.

Redesignação
: Transferência da responsabilidade de uma etapa para outro agente.

Estado do Processo
: Situação atual do processo (iniciado, concluído, arquivado).

Estado da Etapa
: Situação atual da etapa (não capturada, capturada, ação realizada, concluída).

Características

  • Cada processo é vinculado a um tipo de processo;
  • Ao processo são vinculados um ou mais agentes. Obrigatoriamente o usuário que criar o processo será um agente;
  • Apenas os agentes podem efetuar ações sobre o processo;
  • Aos processos podem ser vinculados interessados, sendo externos aqueles que não são usuários do sistema (vinculados por e-mail ou telefone), e internos aqueles que são usuários do sistema;
  • Os interessados recebem notificações de cada ato praticado;
  • Cada operação feita no sistema é um ato e é registrado no processo e notificado a todos os interessados;
  • Cada processo tem uma ou mais etapas;
  • Cada etapa tem uma ou mais ações. Quando existir mais de uma ação em determinada etapa, elas são excludentes;
  • Os agentes podem ser de três tipos:
    • Unidade: representa uma unidade organizacional 9setor, departamento etc.);
    • Cargo: representa o cargo do agente;
    • Pessoa: é o usuário específico;
  • Cada cargo precisa estar vinculado a pelo moenos uma unidade;
  • Cada pessoa precisa estar vinculada a pelo menos um cargo (e por consequência, a pelo moenos uma unidade);
  • Ao atribuir um agente a uma etapa de um determinado processo, deve-se especificar uma unidade, ou unidade+cargo ou unidade+cargo+pessoa;
  • Se apenas a unidade for atribuída a etapa, qualquer cargo ou pessoa vinculada a unidade pode atuar na etapa;
  • Se apenas o cargo de uma unidade estiver atribuído, qualquer pessoa daquele cargo da unidade pode atuar;
  • Se uma pessoa+cargo+unidade for designada para a etapa, apenas ela pode atuar naquela etapa;
  • Cada tipo de processo pode possuir um template com as etapas, agentes e ações, que não podem ser excluídas dquele processo;
  • É possível atribuir mais etapas com seus agentes e suas ações;
  • Para cada etapa podem ser vinculadas etapas requeridas, que precisam estar concluídas para liberar a conclusão da etapa vinculada;
  • Para cada ação pode estar vinculada uma etapa com seus agentes e suas ações que será liberada apenas se aquela ação específica for concluída na etapa;
  • Nenhum ato (executar e concluir uma ação também é um ato) pode ser feito por um agente que não seja uma pessoa. Isso quer dizer que, se em determinada etapa for designado apenas a unidade ou o cargo de uma unidade, antes de executar a ação é necessário que alguma pessoa que se enquadre como o agente designado capture a etapa para si;
  • O agente que tem capturada determinada etapa pode realizar outros atos diferentes das ações especificadas, mas não pode modificar as ações. Se quiser realizar outra ação, precisará incluir nova etapa;
  • São exemplos de ações: aprovar, reprovar, emitir parecer, emitir relatório, despachar etc;
  • São exemplos de atos: anexar arquivo, incluir comentário, referenciar outro processo, etapa de outro processo ou etapa do processo atual etc;
  • Cada tipo de ação pode requerer ou não a anexação de um documento. Por exemplo, a ação de aprovação não precisa requerer documento, mas a reprovação pode requerer um documento com as razões;
  • Documentos podem ser internos ou externos;
  • Documentos internos são elaborados com ferramenta própria do dProc que poderá fornecer templates prontos;
  • Uma vez que um ato tenha sido registrado ele não poderá ser alterado ou desfeito se a etapa for concluída;
  • Cada etapa possui três estados:
    • Não capturada: não foi capturada por nenhum agente do tipo pessoa;
    • Capturada: quando ela já tem o agente do tipo pessoa atribuída;
    • Ação realizada: quando a ação foi realizada (ainda pode aceitar modificações);
    • Concluída: quando a etapa foi finalizada e nenhuma modificação mais é possível;
  • Caso haja a captura de uma etapa por um agente do tipo pessoa e for detectado que a etapa deve ser capturada por outra pessoa, cargo de unidade ou unidade, pode haver a redesignação, sendo isso um ato da etapa;
  • O processo pode ter os seguintes estados:
    • Iniciado: quando tem etapas pendentes;
    • Concluído: quando não possuir etapas pendentes, mas ainda permite modificações pela inclusão de novas etapas;
    • Arquivado: quando não tiver mais etapas pendentes e não puder mais ser modificado;
  • Um processo concluído, ao receber uma nova etapa volta para o estado de iniciado;
  • É possível em dado processo, referenciar outros processos e etapas de outros processos e etapas do mesmo processo;
  • É possível agrupar vários processos eu um único processo (macroprocesso). O macroprocesso somente pode ser concluído se todos os processos agrupados estiverem concluídos. Ela voltará para o estado iniciado se um dos processos agrupados voltar para iniciado. Ela só será arquivada se todos os processos agrupados estiverem arquivados;
  • É possível encadear processos, colocando o processo anterior como requisito para o posterior. Somente posso concluir o processo atual se o anterior estiver arquivado;
  • Haverá um processo de assinatura digital que pode ser de duas formas:
    • Mediante credenciais de usuário e senha específica para assinatura;
    • Mediante certificado digital.
Carregando publicação patrocinada...
4

Você deu bem mais detalhes, mas não todos que são necessários, e eu já dei a base e respondi em: https://www.tabnews.com.br/jonwlf/nosql-ou-postgresql-tenho-duvidas-sobre-o-que-e-melhor-para-o-meu-cenario.

O grosso de quase todos os sistemas são de dados estruturados, mais ainda, costumam ser tabulares, não tem porque usar outra coisa já que os relacionais conseguem lidar com dados não estruturados também. A pá de cal no assunto é o fato de ter muitas informações relacionadas, um modelo de documento é péssimo nisso e não ten solução boa, é bastante recomendado não fazer, apesar de possível.

Um erro que muitos cometem é seguir modinhas e ir para um modelo de documento sendo que ele não precisa nada disso ou em pequenos detalhes do sistema. Quase sempre pagam um preço pela flexibilidade que é pouco ou nada usada e não tem soluções tão boas quando se quer mais robustez.

Se não tiver um motivo forte para usar NoSQL, não use.

Porém, faltando informações, e aí é para ficar no relacional mais ainda, não sabemos toda a complexidade que isso poderá ter um dia. Ao mesmo tempo tenho que dizer que se for só isso mesmo, só com as informações que eu tenho, eu digo que tanto faz, parece um sistema simples demais para se preocupar com a ferramenta certa. Mas posso estar falando porque não sei tudo o que eu deveria saber, o que indica que o problema é mais embaixo.

Sim, este parece ser um sistema muito simples, as pessoas perderam a noção do que é complexo.

Claro que se você precisa de algum dado não estruturado, em formato de documento mesmo, que é diferente de armazenar um documento, seria bom ter um relacional mais poderoso, embora você consiga fazer até com o SQLite, é mais fácil no Oracle, SQL Server ou PostgreSQL. Parece que o MySQL estava melhorando bem nisso também.

Se você usa um tipo de dados não estruturado como JSON ou faz a normalização adequada no relacional você não tem dificuldades, se souber o que está fazendo. Se você precisa estruturar e relacionar uma parte dos dados um MongoDB. por exemplo, funcionará mas precisa muito saber o que está fazendo e não dará o resultado que teria em um relacional.

Sempre adote a mais simples solução que tiver disponível.

De qualquer forma, escolher a tecnologia que vai usar é fácil, saber usá-la da maneira correta é muito mais difícil, por isso eu sempre falo que a pessoa precisa de formação completa, não pode só decorar receitas de bolo, cada problema é diferente, receitas de bolo não funcionam a não ser para problemas muito simples.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

2

Abrindo um parênteses.

Eu acho que o "noSQL" é mais uma redescoberta do que uma modinha. Se for falar apenas em Redis, MongoDB, etc., até é aceitável a "modinha". Mas hoje em dia ainda existem sistemas de grande a enormes que usam noSQL.

Começou com MUMPS/M (a IBM também tinha um projeto) na década de 60. Mas o que não começou na década de 60 em TI?

Área médica:
Em 1978 foi lançado o VistA e roda redondo até hoje. Existem outros usuários grandes como Partners HealthCare, Meditech, GE Healthcare, EPIC, EMIS entre outros.

Área financeira:
Ameritrade com 12 bilhões de transações por dia, Banco da Inglaterra, Banco Barclays entre outros.

Diversas áreas como: mapear a via láctea, universidades/bibliotecas, etc..

O único problema que eu vejo: É muito mais fácil conseguir alguém que "entenda" de SQL do que alguém que entenda de noSQL(M).

Diferença de relacional e não relacional. Fonte: https://www.cs.uni.edu/~okane/

Teste de velocidade MUMPS/M (YottaDB) e Redis (teste local)

1

Eu sempre falei nisso. Eu nem gosto do termo NoSQL porque ele não quer dizer nada, hoje em dia é nada, porque esses DBs sequer ignoram SQL, pelo menos alguns, apesar de adotar outro modelo de armazenamento.

2

Meus 2 cents:

Me parece que o SQL estruturado eh mais adequado.

Entretanto - alguns detalhes no que se refere aos documentos (como armazenamento e busca) seriam mais eficientes usando bancos vetoriais (p.ex pgvector) e embeddings.