ppKrauss
commented
8 years ago Adicionada a RFC 00 - Predefinições e modelo de maturidade na informatização da prefeitura... Aguardando votos para poder fechar esta issue.
Open ppKrauss opened 8 years ago
ppKrauss
commented
8 years ago Adicionada a RFC 00 - Predefinições e modelo de maturidade na informatização da prefeitura... Aguardando votos para poder fechar esta issue.
ghost
commented
8 years ago Peter, Não seria interessante saber se no portal spb não tem sistemas "erp" disponibilizado e ver se caberia "um modulo" que diminuísse os requerimentos de TI? Abs, Em 09/07/2016 12:56 PM, "Peter" notifications@github.com escreveu:
Adicionada a RFC 00 - Predefinições e modelo de maturidade na informatização da prefeitura https://github.com/CPT-PC/backend-portal-transparencia/blob/master/docs/predefinicoes.md... Aguardando votos para poder fechar esta issue.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CPT-PC/backend-portal-transparencia/issues/11#issuecomment-231541159, or mute the thread https://github.com/notifications/unsubscribe/AA-OQ-gKM_eJUXmm78FiZbyURt9LhN7sks5qT8SWgaJpZM4JIn7z .
ghost
commented
8 years ago Por exemplo (eu nunca testei) https://softwarepublico.gov.br/social/e-cidade/ Em 09/07/2016 2:31 PM, "Jaime Dias" jaime.dias@gmail.com escreveu:
Peter, Não seria interessante saber se no portal spb não tem sistemas "erp" disponibilizado e ver se caberia "um modulo" que diminuísse os requerimentos de TI? Abs, Em 09/07/2016 12:56 PM, "Peter" notifications@github.com escreveu:
Adicionada a RFC 00 - Predefinições e modelo de maturidade na informatização da prefeitura https://github.com/CPT-PC/backend-portal-transparencia/blob/master/docs/predefinicoes.md... Aguardando votos para poder fechar esta issue.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CPT-PC/backend-portal-transparencia/issues/11#issuecomment-231541159, or mute the thread https://github.com/notifications/unsubscribe/AA-OQ-gKM_eJUXmm78FiZbyURt9LhN7sks5qT8SWgaJpZM4JIn7z .
RESUMO: definir jargão e "menu" para posicionamento da prefeitura dentro de uma classificação de tipos de demanda e níveis de maturidade.
NOTA: a presente issue teve como resposta a RFC 00 - Predefinições e modelo de maturidade.
Algumas decisões de projeto dependem fundamentalmente da visão de "processo de publicação dos dados" e da realidade do município (ex. grau informatização), ou ainda de preferências da equipe de TI e da comunidade usuária.
Para descrever estas decisões é preciso antes estabelecer um modelo de referência da própria prefeitura... Trata-se da nossa hipotese de trabalho, e pode se basear em uma visão bem simples e realista da média delas:
Definidos os termos, algumas hipóteses (simplificadoras) de trabalho:
Tendo esse pequeno jargão descritivo das prefeituras, podemos então falar das decisões racionais que elas tenderiam a tomar:
Oferecer dados brutos tal qual entregues pelas secretarias
Uma das abordagens mais simples, consistente com casos de baixa maturidade informática e baixo grau de informatização, é oferecer os dados exatamente tal como entregues pelas secretarias. O CKAN é a arquitetura de referência para isso, não restando margem para outra coisa.
PS: em caso ideal, com alto grau de informatização, tudo já está num grande banco de dados, de modo que os datasets entregues no Portal da Transparência seriam gerados automaticamente por esse grande sistema... Mas não convém chamar isso de "dado bruto", usemos o termo "dado previamente consolidado" (o grande sistema atendendo aos requisitos do Portal).
Ser fiel ou adaptar?
Uma questão também relativa aos dados brutos é a fidelidade e o compromisso com os originais. Truncar ou arredondar valores no processo de consolidação, por exemplo, é uma forma de "perda da fidelidade com relação ao original".
No caso de conteúdos do Diário Oficial do Município (DOM), é bastante crítico: qualquer quebra, reformatação, etc. pode acarretar em perda de fidelidade, inclusive caracterizar-se como adulteração do conteúdo (leis e contratos por exemplo não podem ser adulterados nas suas cópias, transcrições ou compilações).
Como nem sempre é possível, há um balanço fidelidade/publicidade e fidelidade/consolidação a ser avaliado. Existem diretivas nacionais e internacionais, como o Open Contracting, estabelecendo regras mais claras, e portanto deixando de ser uma decisão da prefeitura.
Realizar consolidação dos dados das secretarias
Tratar os dados das secretarias e oferecê-los ao público em outra estrutura é sempre um risco: se o "tratar" falhar ou for pouco confiável, perde-se o investimento no Portal da Transparência. A consolidação não apresenta risco algum quando realizada por prefeituras com alta maturidade informática: nos demais casos convêm ser avaliada.
Há uma tendência no Brasil e no mundo de se padronizar os dados oferecidos ao público como dados abertos, de maneira que podemos supor que a consolidação é uma demanda. Num caso ideal (prefeitura com um ERP perfeito que abrange todas as secretarias e subprefeituras, e que entrega os dados no formato padronizado), a consolidação é dispensável: no Brasil desconhecemos tal caso.
Suposição de fontes padronizadas
As fontes de dados que abastecem o Portal da Transparência, ou seja, dados supridos pelas secretarias, tem sua estrutura padronizada e estável ao longo do tempo?
Em geral não há sequer uma referência de padrão, e quando há (por exemplo a CGM-SP estabelece recomendações) a resposta em geral é negativa, o que novamente cria riscos para o mecanismo de consolidação... Por isso toda prefeitura precisa de um CKAN.
Quando a resposta é positiva: a própria padronização, e o histórico de avaliações/auditorias da estabilidade desse padrão, deveriam ser dados abertos.
...
Enfim, é importante lembrar que a realidade de cada prefeitura já impõe certas decisões e limitações. Diferentes arquiteturas serão mais adequadas a diferentes realidades.