Contratação de solução tecnológica para os canais do SIAC e digitalização de serviços públicos
Descrição
A Secretaria Municipal de Inovação e Tecnologia (SMIT) gerencia o Sistema Integrado de Atendimento ao Cidadão - SIAC com o objetivo de inovar na prestação de serviços à população, estimular a desburocratização e garantir o direito de um atendimento de qualidade, padronizado, ágil e acessível.
Nos próximos anos, a Prefeitura quer avançar na digitalização dos serviços públicos e caminhar na direção do estabelecimento de um Portal único de serviços (do termo, em inglês, “one-stop shop”). Além disso, a Prefeitura quer aprimorar, por meio do uso de um sistema tecnológico, os fluxos de trabalho internos dos serviços públicos solicitados nos canais que compõem o SIAC. Este é o objetivo do Edital de contratação aqui disponível em Consulta Pública.
Para isso, é necessário contratar uma nova solução tecnológica e serviços especializados de transformação, design e automação de serviços públicos. Desse modo, a análise e redesenho de processos e serviços serão realizados considerando as especificidades da solução tecnológica contratada e os novos fluxos de trabalho são implementados.
Espera-se alcançar como benefícios da nova contratação:
- Automação e digitalização ágil de serviços;
- Padronização e agilidade no atendimento, processamento e resposta ao cidadão;
- Facilidade no acompanhamento das solicitações por parte do cidadão, tendo clareza das etapas envolvidas;
- Sistema integrado de informação e base de dados unificada das solicitações;
- Disponibilização de informações e dados consistentes sistematizados;
- Gestão colaborativa, eficaz e efetiva da informação, com estruturação do conhecimento;
- Aumento da capacidade de atendimento ao cidadão;
- Melhoria da gestão dos serviços atendidos.
Previamente à Consulta Pública atual, a SMIT realizou os seguintes processos participativos:
- Prospecção de ferramentas disponíveis no mercado, por meio de um Pedido de Informação - RFI (Edital nº 02/2019/SMIT). Além de se comprovar a capacidade do mercado em fornecer este tipo de solução, constatou-se que a ferramenta poderia ser disponibilizada como SaaS (do inglês, "Software as a Service").
- Escuta aos usuários da solução tecnológica atual e de usuários potenciais, por meio de pesquisas e de entrevistas presenciais, de forma a identificar as principais dificuldades e necessidades.
- Consulta Pública inicial, disponível aqui. As contribuições recebidas já foram incorporadas nesta nova versão do Edital.
Informações adicionais
Segundo a Política de Atendimento ao Cidadão (Decreto Municipal nº 58.426/2018), a Prefeitura tem a responsabilidade de promover inovações na prestação dos serviços à população, estimular a desburocratização e assegurar o direito dos cidadãos ao atendimento de qualidade, padronizado, ágil e acessível.
Para isso, a Prefeitura institucionalizou o Sistema Integrado de Atendimento ao Cidadão – SIAC, reunindo os canais de atendimento para requisição de serviços e informações municipais. O SIAC é composto pelo portal eletrônico SP156, central SP156, aplicativo SP156, Chat, praças de atendimento das Subprefeituras, unidades do Descomplica SP e demais canais integrados ao SP156.
Atualmente a SMIT conta com um único contrato que inclui as Centrais de Atendimento e os canais digitais do Portal SP156 (online e aplicativo). A atual contratação já foi um grande avanço para a Prefeitura e para a construção de uma agenda de atendimento ao cidadão com qualidade. As principais conquistas desde a implantação da atual solução em 2016 são:
- A consolidação e aprimoramento dos canais de atendimento SP156;
- A reformulação de um Portal de Atendimento mais moderno e responsivo;
- A centralização de 11 centrais telefônicas na Central SP156;
- A institucionalização da Carta de Serviços como repositório de informações de mais de 1000 serviços públicos; e
- A geração de dados para aprimoramento da prestação dos serviços.
No entanto, considerando os novos desafios impostos pela digitalização e automação de serviços públicos, bem como os avanços tecnológicos, a Prefeitura considerou mais vantajoso dividir o serviço em dois contratos:
- Solução Tecnológica para os canais do SIAC e serviços de digitalização e automação de serviços públicos, de que trata essa Consulta Pública; e
- Centrais de Atendimento, disponível em Consulta Pública aqui.
Sugestões para o documento
SUGESTÃO: Contratação de empresa especializada em serviços de planejamento, implantação, operação, gerenciamento de central de atendimento humano e gestão de atendimento receptivo e ativo nas formas eletrônica e humana (contact center), compreendendo a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos, no modelo de Software como Serviço (SaaS), bem como a adequação e automação dos serviços públicos propriamente ditos, com o uso da solução tecnológica disponibilizada e utilizando métodos ágeis e design de serviço, incluindo também fornecimento de atendente virtual inteligente, suporte técnico e treinamento conforme condições e especificações contidas neste Termo de Referência e em seus Anexos. JUSTIFICATIVA: A análise dos documentos lançados com o objetivo de fazer frente às necessidades da Administração com relação ao aperfeiçoamento da disponibilização de seus serviços através da Central de Atendimento deixa claro que o objetivo não será alcançado, pois ao contrário do que se pretende o modelo proposto não visa o aperfeiçoamento dos serviços na medida em que desconsidera a atual realidade deste mercado, bem como premissas básicas para obtenção de melhoria de desempenho operacional e redução das despesas operacionais. Ao lançar Editais distintos, sendo um para tratar da “contratação de empresa especializada em serviços de planejamento, implantação, operação, gerenciamento de central de atendimento humano e gestão de atendimento receptivo e ativo nas formas eletrônica e humana (contact center)” e outro para “prestação de serviços compreendendo a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos.”, a Administração desconsidera que a maioria absoluta dos grandes prestadores de serviços desse segmento de mercado no país oferece os dois objetos, fato que, por si só, traz inúmeras vantagens, mais notadamente o ganho em escala, pois certamente haverá vantajosidade econômica para a Administração em função de uma empresa ofertar e operar os dois objetos, ou seja, o ganho em escala dessa empresa lhe possibilitará oferecer preços mais competitivos. Outro fator que também deve ser considerado é que a contratação única conferirá maior celeridade no processo de implantação, bem como garantirá maior qualidade ao longo da prestação dos serviços, pois a operação de Call Center, nesse cenário de contratação única, será suportada por elementos tecnológicos cujo operacionalização e detalhamento técnico é de pleno conhecimento dos responsáveis pela operação, ou seja, tal modelo, como aliás, é uma praxe de mercado, propicia mais qualidade com menores despesas operacionais, razão pela qual carece de lógica decisão que colide frontalmente com os próprios interesses da Administração e da sociedade de modo geral. Outra hipótese seria a contratação única, porém com a abertura da possibilidade de consórcio, como aliás está previsto no item 3.3 do Edital , mas inexplicavelmente tal possibilidade não foi tratada para que se realizasse os dois “lotes” em uma única contratação. Aqui ainda é importante considerar a ressalva de que mesmo na hipótese de se realizar a disponibilização dos dois lotes em consórcio ainda assim os preços praticados e o riscos com relação à agilidade de implantação e qualidade da operação seriam superiores àqueles que existiriam em um cenário que contemplasse apenas a contratação de uma única empresa. A inexistência da possibilidade de contratação única ou ainda da utilização do consórcio causa estranheza ainda mais quando analisamos trechos dos dois Editais em questão, senão vejamos: A) PROCESSO ADMINISTRATIVO ELETRÔNICO n° 6023.2019/0003107-0 – ITEM 8.2: “8.2. A eficácia do presente Contrato está sujeita à celebração do contrato que tem por objeto xxx (processo administrativo xxx / pregão eletrônico xxx). Dessa forma, até que haja a implementação da referida condição, a presente contratação não produzirá seus efeitos jurídicos típicos.” B) PROCESSO ADMINISTRATIVO ELETRÔNICO n° 6023.2019/0003628-4 – ITEM 8.1.10: “8.1.10. A eficácia do presente Contrato está sujeita à celebração do contrato que tem por objeto a prestação de serviços compreendendo a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos (processo administrativo nº. xxx / pregão eletrônico nº. xxx). Dessa forma, até que haja a implementação da referida condição, a presente contratação não produzirá seus efeitos jurídicos típicos.” Ora, a própria Administração trata dos dois assuntos como indissociáveis e indispensáveis entre si para consecução do projeto, entretanto assume posicionamento contraditório ao lançá-los em Editais separados, deixando de auferir economia com o ganho em escala, potencializando riscos qualitativos e ainda assumindo riscos de inviabilidade da nova implantação, pois como são processos separados, podem haver inúmeros problemas nos trâmites burocráticos do certamente com diferenças de tempo consideráveis entre a finalização dos dois processos.
1.11.6.3.
11.6.3. Qualificação econômico-financeira:
a) Certidão negativa de pedido de falência, expedida pelo distribuidor da sede da pessoa jurídica em data não superior a 60 dias da data da abertura do certame, se outro prazo não constar do documento.
a.1) Se a licitante não for sujeita ao regime falimentar, a certidão mencionada deverá ser substituída por certidão negativa de ações de insolvência civil, ou documento equivalente.
b) Balanço patrimonial e demonstrações contábeis do último exercício social, já exigíveis e apresentados na forma da lei, que comprovem a situação financeira da empresa, vedada sua substituição por balanço ou balancetes provisórios, podendo ser atualizados por índices oficiais quando encerrados há mais de três meses da data da apresentação da proposta;
b.1) Somente empresas que ainda não tenham completado seu primeiro exercício fiscal poderão comprovar sua capacidade econômico-financeira por meio de balancetes mensais, conforme disposto na Lei Federal nº 8.541, de 23 de dezembro de 1992;
c) No caso de sociedade simples, a proponente deverá apresentar certidão dos processos cíveis em andamento relativos à solvência ou não da licitante, expedido pelo distribuidor da sede de pessoa jurídica, em data não superior a 60 (sessenta) dias da data da abertura do certame, se outro prazo não constar do documento.
d) Comprovação da boa situação financeira da empresa mediante obtenção de índices de Liquidez Geral (LG), Solvência Geral (SG) e Liquidez Corrente (LC), superiores a 1 (um), obtidos pela aplicação das seguintes fórmulas:
LG = (Ativo Circulante + Realizável a Longo Prazo) / (Passivo Circulante + Passivo Não Circulante)
SG = Ativo Total / (Passivo Circulante + Passivo Não Circulante)
LC = Ativo Circulante / Passivo Circulante
d.1) As empresas que apresentarem resultado inferior ou igual a 1(um) em qualquer dos índices de Liquidez Geral (LG), Solvência Geral (SG) e Liquidez Corrente (LC), deverão comprovar patrimônio líquido de 10% do valor estimado da contratação.
A qualificação financeira exigida está muito aquém para a criticidade e complexidade desse tipo de serviço que exige grandes investimentos de infraestrutura, bem como capacidade financeira sólida para suprir custos de folha de pagamento de forma recorrente. Sugerimos alterar essa qualificação exigindo o patrimônio líquido de 10% do valor estimado da contratação "DE FORMA CONCOMITANTE" com os índices de Liquidez e Solvência, bem como exigir Índice de "Grau de Endividamento" menor que 0,7 que garanta a solidez da empresa para realização de objeto dessa monta, conforme tem sido adotado pelos órgãos públicos.
2.1.1.
1.1. Contratação de empresa especializada na prestação de serviços compreendendo a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos, no modelo de Software como Serviço (SaaS), bem como a adequação e automação dos serviços públicos propriamente ditos, com o uso da solução tecnológica disponibilizada e utilizando métodos ágeis e design de serviço, incluindo também fornecimento de atendente virtual inteligente, suporte técnico e treinamento conforme condições e especificações contidas neste Termo de Referência e em seus Anexos.
Nossa proposição de valor da corresponde à implantação de uma solução que tem o CRM de um grande provedor de software, como a plataforma principal para os diversos canais e usuários realizarem a solicitação de serviços aos órgãos governamentais, integrando a mesma às diversas aplicações que suportam os processos de negócio para oferecer uma experiência de ótima performance e com a maior conveniência possível para os interessados
2.2.1.
2.1. Necessidade do Objeto
No âmbito da Política Municipal de Atendimento ao Cidadão, instituída por meio do Decreto Municipal nº 58.426, de 18 de setembro de 2018, a Prefeitura de São Paulo deve, de acordo com o artigo 28 do referido decreto, dentre outras atribuições:
a. promover e incentivar projetos, programas e ações de inovação na prestação dos serviços públicos à população, inclusive os que contemplem investimentos em tecnologia da informação e em recursos de acessibilidade;
b. propiciar, aos agentes públicos, condições para exercerem com efetividade o seu papel de representantes da Administração Municipal no relacionamento com os cidadãos;
c. estimular a criação de alternativas e mecanismos para a desburocratização da prestação dos serviços públicos;
d. assegurar o direito dos cidadãos ao atendimento de qualidade, com procedimentos padronizados, ágeis e acessíveis;
e. assegurar aos cidadãos o direito ao acesso a informações sobre os serviços públicos de forma simples e clara, em conformidade com a Lei Federal nº 12.527, de 2011, e com o Decreto Municipal nº 53.623, de 12 de dezembro de 2012;
f. promover a cultura da avaliação do atendimento, da análise das necessidades e expectativas dos cidadãos, do conhecimento do perfil dos cidadãos e do conhecimento das experiências de atendimento aos cidadãos;
De acordo com o artigo 32 do Decreto Municipal nº 58.426/18, os órgãos e entidades prestadores de serviços públicos devem buscar oferecer aos cidadãos a possibilidade de formular sua solicitação por diferentes canais de atendimento, priorizando os meios eletrônicos. Os canais de atendimento deverão pautar-se em processos padronizados e uniformes, com vistas a possibilitar a mensuração de sua eficácia, eficiência e efetividade, permitindo a produção de indicadores que reflitam, prioritariamente, o comportamento da demanda e as necessidades do cidadão.
Conforme o artigo 37 do Decreto Municipal nº 58.426/18, cada solicitação de serviço público, qualquer que seja o canal de atendimento, deverá gerar um número de protocolo que retrate fielmente a manifestação, permitindo o seu acompanhamento pelo cidadão.
Nesse mesmo contexto, desde 2018, a Prefeitura tem investido na expansão do número de serviços online disponíveis no Portal de Atendimento SP156. Nos próximos anos, espera-se acelerar a digitalização de serviços públicos na Prefeitura, bem como caminhar na direção de um Portal de Serviços único, do tipo “one-stop shop”. Nesse sentido, é necessária a contratação de uma ferramenta tecnológica que permita integrações de sistema consistentes, que automatize serviços públicos e que forneça uma interface simples e amigável para o cidadão paulistano. Também se espera que a ferramenta dê autonomia à equipe da Prefeitura para disponibilização de novos serviços digitais, diminuindo a necessidade de desenvolvimentos técnicos.
Considerando esse conjunto, é essencial a contratação de uma solução tecnológica que forneça as ferramentas para a organização, o gerenciamento e a melhoria do atendimento ao cidadão, para cumprir os dispositivos legais que regulam essa relação e o dever da Administração Municipal.
Nesse contexto, a Secretaria Municipal de Inovação e Tecnologia atua como o órgão público que gerencia e coordena todos os canais de atendimento, bem como fornece para as demais secretarias uma solução tecnológica capaz de automatizar e facilitar a prestação de serviços públicos. Além disso, mesmo para secretarias que já possuem sistemas especialistas para prestação de serviços públicos, a solução tecnológica atua como porta de entrada dos serviços, garantindo que todo cidadão receba o mesmo tratamento e que a solução atue como um repositório único de informações e de dados sobre serviços públicos. Dessa forma, a solução tecnológica permeia a prestação de serviços públicos de grande parte dos órgãos municipais, necessitando robustez, performance e confiabilidade.
A contratação da solução atual já representou um avanço em relação ao sistema anterior. No entanto, a necessidade de digitalizar serviços e de implementar ferramentas de inteligência cognitiva, bem como o objetivo de melhorar de forma contínua o atendimento ao cidadão, têm motivado a contratação de uma nova solução, com características que atendam de forma mais adequada às necessidades atuais da Prefeitura de São Paulo.
Espera-se alcançar como benefícios da nova contratação:
● Automação e digitalização ágil de serviços;
● Padronização e agilidade no atendimento, processamento e resposta ao cidadão;
● Facilidade no acompanhamento das solicitações por parte do cidadão, tendo clareza das etapas envolvidas;
● Sistema integrado de informação e base de dados unificada das solicitações;
● Disponibilização de informações e dados consistentes sistematizados;
● Gestão colaborativa, eficaz e efetiva da informação, com estruturação do conhecimento;
● Aumento da capacidade de atendimento ao cidadão;
● Melhoria da gestão dos serviços atendidos;
● Avaliação da satisfação de usuários.
A solução a ser contratada deve contemplar uma plataforma multicanal integrada para atendimento, gerenciamento do relacionamento com o cidadão, digitalização e automação de serviços públicos, pois desta forma, com uma ferramenta que reúna todas essas funções, é possível garantir que o cidadão tenha igualdade de tratamento de suas demandas por serviços públicos e por informações, independentemente do canal utilizado para entrar em contato com a Prefeitura de São Paulo, em acordo com o artigo 33 e com os incisos I e II do artigo 34 do Decreto Municipal nº 58.426/18.
A solução deve possuir também um Atendente Virtual Inteligente (chatbot), de forma a oferecer mais uma opção rápida, simples e efetiva de atendimento ao cidadão, tendo em vista os princípios de eficiência e efetividade e o inciso IV do artigo 28 do Decreto Municipal nº 58.426/18, segundo o qual se deve promover e incentivar projetos, programas e ações de inovação na prestação dos serviços públicos à população, inclusive os que contemplem investimentos em tecnologia da informação e em recursos de acessibilidade.
Dada a quantidade considerável de servidores da Prefeitura de São Paulo e de atendentes (telefônicos e presenciais) que utilizarão a ferramenta contratada diariamente, bem como a relevância dos serviços prestados e das informações obtidas a partir dos canais de atendimento SP156 para a população da cidade de São Paulo, justifica-se a necessidade de um serviço de suporte a ser realizado por equipe especializada do fornecedor da solução, de forma a garantir a estabilidade do uso da ferramenta.
Para que a digitalização de serviços seja efetiva, faz-se necessária a contratação conjunta com a solução tecnológica de serviços especializados de transformação, design e digitalização de serviços públicos, de forma que a análise e redesenho de processos e serviços sejam realizados considerando as especificidades da solução tecnológica contratada, para que haja a efetiva implementação dos novos fluxos de trabalho.
Por fim, para garantir que os usuários da solução tecnológica conheçam suas funcionalidades e estejam em constante aprimoramento no uso da solução faz-se necessária a contratação de serviços de capacitação, por meio de treinamentos presenciais e de uma plataforma de capacitação permanente, de forma que os usuários consigam realizar o atendimento e o tratamento das demandas da população da cidade de São Paulo de modo cada vez mais eficiente, conforme inciso IV do artigo 28 do Decreto Municipal nº 58.426/18.
Nossa solução pode ser customizada para atender a distintas jornadas de serviços de atendimento ao cidadão através de canais físicos e digitais, ponta a ponta. Além disso, podemos prover todo o conjunto de treinamentos para implantação, customização e utilização da solução.
2.3.1.1.
3.1.1. O objeto deste Termo de Referência é composto por 6 itens que integram um único lote: (i) fornecimento de plataforma multicanal integrada para atendimento, gerenciamento do relacionamento com o cidadão, digitalização e automação de serviços públicos em modelo SaaS (Software as a Service); (ii) fornecimento de Atendente Virtual Inteligente - Chatbot - em modelo SaaS (Software as a Service); (iii) suporte técnico; (iv) serviços especializados, o que inclui os serviços de transformação, design, tecnologia e digitalização necessários para a disponibilização de serviços públicos digitais de qualidade com o uso da solução tecnológica; (v) fornecimento de plataforma virtual de capacitação permanente em modelo SaaS (Software as a Service) para utilização da solução tecnológica; (vi) capacitação e formação de usuários para utilização da solução tecnológica.
A Contratante deve alterar o objeto e também incluir a parte de serviços de planejamento, implantação, operação, gerenciamento de central de atendimento e gestão de atendimento , pois não há justificativa técnica/comercial para fazer essas duas contratações separadas em formato de serviço para tratar operacionalmente o mesmo fim. Essa separação vai ocasionar problemas operacionais entre os contratos além de elevar os preços dos serviços. Atualmente todas as grandes empresas de Call Center possuem a capacidade de ofertar a Solução de Atendimento e Digitalização de Serviços que será operacionaliada no atendimento nos termos solicitados pela contratante.
O objeto proposto nessa consulta pública que trata de somente da "Contratação de solução tecnológica para os canais do SIAC e digitalização de serviços públicos" com a segregação da parcela de relevância da "Contratação da Central de Atendimento do SP156", constantes da outra consulta pública publicada no link: "http://participemais.prefeitura.sp.gov.br/legislation/processes/4", NÃO FAZ O MENOR SENTIDO. A divisibilidade dessas parcelas de serviço acarretarão severos problemas de gestão de atendimentos, criando gargalos entre fornecedores. è fato notório que os principais players de mercado possuem amplo conhecimento e proficiência para a gestão end-to-end de atendimentos dentro da vanguarda do que chamamos "Customer Experience". A segmentação proposta supervaloriza eventual fornecimento direto de fabricantes de software (inclusive de pequeno porte) que não possui expertise operacional da gestão continuada de uma operação de atendimento com foco na jornada da experiência digital do cliente, que vai da automação de informações e serviços até os atendimentos humanos dentro do conceito Omnichannel. Importante destacar que todas as empresas de gestão de Operações de Customer Experience, de porte compatível com esse projeto, além da nossa, (p. ex. Atento, Liq, Teleperformance, Neobpo, Almaviva, dentre outras tantas), possuem competência para atuar de forma integrada nesse tipo de escopo. Portanto, entendemos que a divisibilidade proposta pela prefeitura paulista não efetiva nenhum ganho de eficiência, pelo contrário, só elevará os custos e patrocinará a gestão de problemas futuros, visto a dependência e associação dessas 2 (duas) parcelas de fornecimento para se alcançar a melhor experiência da jornada de atendimento aos clientes para essa prefeitura.
2.3.1.3.2.
3.1.3.2. Da mesma forma, para garantir a entrega fim a fim dos serviços públicos automatizados com menores riscos, maior agilidade e melhor qualidade, a empresa deverá também realizar a implementação das APIs de integração necessárias para a automação dos serviços públicos correspondentes, tanto para os serviços já incluídos na atual solução quanto para os novos serviços. Estas APIs permitirão a integração dos fluxos de automação de serviços públicos com sistemas e bases de dados governamentais.
Como integradora de soluções, possuimos ampla experiência em habilitar mecanismos que permitam a interoperabilidade entre aplicações. Atualmente, como padrão de mercado, a empresa cada vez mais se especializa em utilização de APIs Rest para expor ou consumir serviços e integrar-se com diferentes players do mercado.
2.3.1.3.4.
3.1.3.4. Igualmente, os profissionais que ministrarão os treinamentos deverão conhecer todos os aspectos técnicos e funcionais da solução aqui especificada, para que os órgãos e entidades abrangidos sejam capazes de absorver o conhecimento.
Nosso corpo de colaboradores possuem profissionais proficientes em todas as disciplinas de Engenharia de Software, capazes de atuar em todo o ciclo de de vida desenvolvimento de sistemas.
2.4.2.
4.2. Item 2 - Fornecimento de Atendente Virtual Inteligente - Chatbot - em modelo SaaS (Software as a Service)
Como integradora de soluções, possuimos ampla experiência em integração de ferramentas de desenvolvimento de chatbots para prover uma experiência de atendimento virtual baseada em IA.
2.4.2.1.
4.2.1. O Atendente Virtual Inteligente (Chatbot) consiste em uma solução de comunicação que permite a utilização de inteligência cognitiva para automatizar interações realizadas com cidadãos por meio de diferentes canais.
Os chatbots podem ser baseados em inteliência cognitiva, árvores de decisão, FAQ.
2.4.2.3.
4.2.3. O Chatbot será utilizado para aumentar a qualidade dos serviços públicos prestados e diminuir os tempos de respostas para atendimento.
As jornadas de usuário são mapeadas por uma equipe de UX de forma a prover a melhor experiência para o usuário final e otimizar o tempo de atendimento.
2.4.3.2.
4.3.2. As manutenções que farão parte do Suporte Técnico poderão ser de tipo Emergencial, Corretiva e Legal.
Este item menciona manutenção do tipo emergencial, corretiva e legal, cujas descrições estão apresentadas nos itens seguintes. Entretanto o item 4.3.3 considera manutenções corretivas, legais e evolutivas. Não apresenta a definição do que seria a manutenção evolutiva. Essa contradição deve ser revisada.
2.4.3.3.
4.3.3. A CONTRATADA deverá apresentar os planos de manutenção, contendo a política técnica e administrativa adotada pelo proponente para atualizações de versões e realização de manutenções corretivas, legais e evolutivas.
Este item menciona manutenção do tipo corretiva, legal e evolutiva, contradizendo com o item 4.3.2 que considera manutenção do tipo emergencial, corretiva e legal. Essa contradição deve ser revisada.
2.4.3.6.1.
4.3.6.1. Todo atendimento, por telefone ou web, deverá ser registrado em ferramenta de Service Desk que será disponibilizada pela CONTRATADA à CONTRATANTE para abertura de chamados e extração de relatórios.
Service Desk totalmente em português do Brasil.
2.4.3.6.4.
4.3.6.4. O serviço de suporte deverá ser prestado em idioma português padrão Brasil.
Nossa solução é customizável, podendo ser internacionalizada para qualquer idioma.
Ter suporte técnico realizado pelo próprio fabricante do software, com equipe de suporte especializada para atendimento em português do Brasil em todos os níveis, além de ter interface para recebimento de pedidos de suporte via ferramenta online, também totalmente em português do Brasil.
2.4.4.1.
4.4.1. Os serviços especializados exigem dedicação exclusiva dos profissionais e incluem a realização de integrações entre sistemas, a digitalização de novos serviços, a melhoria de serviços existentes, a transferência de conhecimentos e demais serviços de consultoria, design, processos e tecnologia que forem necessários para o aprimoramento dos serviços digitais da CONTRATANTE.
Este item menciona integrações do novo sistema com sistemas legados. É de extrema importância que o Termo de Referência informe as características tecnológicas mais importantes dos sistemas legados, tais como linguagens de programação, arquiteturas e bancos de dados. Essas informações têm impacto na formulação de preços, pois a empresa terá que contratar profissionais especializados em tecnologias específicas.
2.4.4.2.1.6.
4.4.2.1.6. Utilizar métodos ágeis: organizar em Sprints (de duas a quatro semanas), disponibilizando o serviço a usuários reais o mais rápido possível, gerar dados sobre como são usados e iterar o serviço com base nos aprendizados. Se possível, disponibilizar versões alfa e beta do serviços para aprimorar os serviços disponibilizados.
Nossa empresa há alguns anos já adota em seus projetos os métodos ágeis (Scrum, Kanban), inclusive de forma escalada, aliados a práticas de Design Thinking e DevOps.
2.4.4.2.2.1.
4.4.2.2.1. Persona: a persona ou perfil comportamental é uma construção a partir de padrões recorrentes, testados empiricamente, e que se tornam representativos de um grupo social.
Aplicamos em nosso processo de desenvolvimento de sistemas as técnicas de Design Thinking, que usam o poder da empatia para que um problema seja visualizado de diferentes perspectivas, gerando assim insumos para produzir as melhores soluções.
2.4.4.2.2.5.
4.4.2.2.5. Entrevista: entender com maior profundidade os comportamentos, sentimentos e opiniões da pessoa que utiliza o serviço e/ou do(a) atendente em relação ao serviço.
Da mesma forma que o item anterior, aplicamos em nosso processo de desenvolvimento de sistemas as técnicas de Design Thinking, que usam de técnicas de sombra, entrevista, empatia, blueprint e prototipação para que um problema seja visualizado de diferentes perspectivas, gerando assim insumos para produzir as melhores soluções.
2.4.4.5.
4.4.5. A CONTRATANTE garante demanda mínima de 6.336 UST por ano.
Seria importante informar uma demanda média de UST por ano para que a proponente possa dimensionar sua equipe e calcular os custos relativos para atender essa demanda média. Entretanto, a informação da demanda mínima deve ser mantida, pois é uma garantia para a proponente.
2.5.2.1.1.
5.2.1.1. O cálculo será realizado levando-se em consideração os quantitativos de interações realizadas entre Atendente Virtual Inteligente e cidadãos.
É necessário que sejam devidamente especificados o que abrange uma interação realizada. O Edital só aponta que uma interação equivale a uma sessão de atendimento, mas não define sequer o entendimento de "sessão". Qual o limite de mensagens de uma sessão? Qual o tempo máximo dessa sessão? Sem esse detalhamento não é possível dimensionar o custo da unidade interação.
2.5.4.
5.4. Item 4 - Serviços Especializados - Transformação, design e digitalização de serviços públicos digitais com o uso da solução tecnológica
No item 4.4.1 estão previstos nos serviços especializados as integrações entre sistemas. O Termo de Referência deve descrever os procedimentos técnicos para as integrações. Esclarecer se os Planos de Integração de Sistemas deverão ser elaborados conjuntamente pelos profissionais da Contratada e da Contratante. Considerando que a Contratada será responsável por codificar os programas de integração de dados com outros sistemas legados, quem será responsável pela conferência dos dados oriundos da integração entre os sistemas e informar as não conformidades oriundas de erros nos programas de integração para as providências de correções. A Contratante ou a Contratada?
2.9.2.
9.2. A implantação da solução será remunerada somente pela quantidade fixa de 6336 UST de serviços especializados previstos no item 4 e por horas-aula de capacitação dos usuários do item 6 - “Capacitação e Formação de Usuários para utilização da solução tecnológica”.
"As atividades de implantação requerem a migração do atual ambiente da prefeitura com aproximadamente 550 serviços solicitáveis na Plataforma, 300 serviços com fluxos de integração com sistemas legados, totalizando 13 sistemas integrados e 17 fluxos diferentes e outros 250 serviços com fluxos completos dentro da própria solução tecnológica, sendo 13 tipos possíveis de fluxos, incluindo ainda 1.100 Cartas de Serviço, 4.700 Perguntas Frequentes, organizadas em 300 grupos, cerca de 177 mil solicitações de serviço público em aberto ou em andamento que deverão ter todos os seus dados migrados para a nova solução, dentre outros detalhes. Desta forma, entendemos ser insuficientes as 6.336 UST’s para fazer frente à esse escopo. Assim, Sugerimos definir pelo menos 20.000 UST’s para a concretização da implantação inicial no prazo de até 6 meses."
Não ficou compreendido a lógica de estabelecer uma quantidade fixa de 6336 UST de serviços especializados para a execução dos serviços de Implantação. Ora, se há um Catalogo de Serviços por qual motivo as atividades de implantação também não são medidas pelo catálogo? O quantitativo adotado pelo Edital para a implantação é um mero chute e pode não representar o real esforço da atividade, podendo inclusive estar subdimensionada em desfavor da Contratada.
2.10.5.5.
10.5.5. Código-fonte das customizações e documentação das parametrizações realizadas na plataforma;
O objeto prevê a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos, no modelo de Software como Serviço (SaaS). Entretanto este item prevê a entrega de código-fonte das customizações. A entrega de códigos-fontes não é compatível com este modelo de serviço (SaaS), portanto este item deve ser excluído.
2.20.4.1.
20.4.1. Cada funcionário indicado pela CONTRATADA deverá passar por uma diligência prévia de capacidade técnica (DPC). A DPC visa a garantir que o funcionário indicado pela CONTRATADA possui a capacidade técnica e a experiência para o desempenho das atividades contratuais previstas. Objetivamente, a diligência consiste em uma apresentação de 30 a 60 minutos realizada pelo funcionário, para gestores da CONTRATANTE. O conteúdo da apresentação versará sobre um projeto/sistema em que o funcionário tenha trabalhado, e deverá realçar temas como: a natureza do problema negocial envolvido; a arquitetura da solução; desafios negociais e/ou técnico projeto; detalhes da implementação. O resultado da DPC será “satisfatório” ou “insatisfatório”. Apenas os funcionários que obtiverem grau “satisfatório” serão considerados aptos a serem alocados em contrato. Para garantir a transparência e a lisura da DPC, quatro medidas serão tomadas:
Sugerimos definir quais serão os criterios que serão avaliados em cada um pontos mencionados para o DPC.
2.22.2.1.
22.2.1. Atestados de Capacidade Técnica (ACT) em nome da licitante, em conjunto ou não, expedidos por pessoas jurídicas de direito público ou privado, do País ou do exterior, que comprovem fornecimento compatível com os serviços constantes deste Termo de Referência de forma satisfatória:
a) ACT comprovando a implementação da solução tecnológica descrita no item 1 em modelo SaaS (Software as a Service) (conforme requisitos do Anexo I) por um período mínimo de doze meses para pelo menos 1100 usuários internos à organização (excluídos, portanto, os munícipes ou clientes)e com o registro de pelo menos 500.000 solicitações/ano, contemplando a implantação da solução, manutenção corretiva e evolutiva, sustentação, desenvolvimento de novas funcionalidades e capacitação dos usuários.
a1) ACT comprovando a implementação da solução tecnológica descrita no item 2 - Fornecimento de Atendente Virtual Inteligente - Chatbot - em modelo SaaS (Software as a Service) (conforme requisitos do Anexo II) por um período mínimo de doze meses para pelo menos 720.000 interações/ano, contemplando a implantação da solução, manutenção corretiva e evolutiva, sustentação, desenvolvimento de novas funcionalidades e capacitação dos usuários.
b) ACT comprovando a prestação de serviços técnicos de transformação de processos utilizando métodos ágeis e design de serviços em um quantitativo de 20.592 UST durante um período de doze meses.
c) ACT comprovando a prestação de serviços de desenvolvimento de integração de aplicações com a solução integrada, por meio do uso do padrão SOA ("Services Oriented Architecture"), em um quantitativo de 20.592 UST durante um período de doze meses.
d) ACT comprovando a prestação de serviços de capacitação semelhante ao descrito no item 6 neste Termo de Referência, com o equivalente a pelo menos 532 horas-aula.
Em relação ao item b) consideramos essa exigência extremamente restritiva e que revela indícios de direcionamento, prejudicando a competitividade do certame. Em relação ao item c) o Termo de Referência não faz qualquer menção ao padrão SOA, portanto é uma incoerência exigir ACT relacionado a um padrão que sequer foi mencionado nas especificações técnicas.
Entendemos que no atestado a) não deveria ser obrigatória a execução no formato SaaS, pois existem diversas empresas que executam essa atividade em modalidade diferente de contratação, desta forma será restringida a participação de empresas. No mesmo caminho, entendemos que os quantitativos estão muito elevados, o que certamente afetara a capacidade de concorrência de empresas. Item a1) não deveria ser obrigatória a execução no formato SaaS, pois existem diversas empresas que executam essa atividade em modalidade diferente de contratação, desta forma será restringida a participação de empresas, bem como o quantitativo de interações certamente será um segundo fator de restrição de participantes. item d) o atestado não deveria apresentar um quantitativo mínimo de horas aula, pois esse critério é muito subjetivo, o importante é a efetividade do treinamento, entendemos que da forma proposta teremos uma grave limitação de concorrência.
2.22.2.3.
22.2.3. Certificados ou acreditações por organismo credenciado, expedidos por pessoas jurídicas competentes para tanto, que comprovem:
a) a conformidade da Solução Tecnológica ofertada com a ABNT NBR ISO/IEC 27001:2013, que especifica os requisitos para estabelecer, implementar, manter, melhorar e tratar riscos de forma continuada de um sistema de gestão da segurança da informação;
b) a conformidade da Solução Tecnológica ofertada com a ABNT NBR ISO/IEC 27017:2016, que fornece diretrizes para os controles de segurança da informação aplicáveis à prestação e utilização de serviços em nuvem, sendo excepcionalmente admitida uma auto declaração de conformidade com esta norma, por se tratar de certificação recente no País, e poderá ser realizada diligência, a qualquer tempo, para atestar que os requisitos e controles de segurança da informação prescritos pela norma ABNT NBR ISO/IEC 27017:2016 foram atendidos satisfatoriamente;
c) a disponibilidade dos serviços em conformidade com a certificação TIA 942 TIER II (data center uptime 99,741%) ou superior.
Consideramos que os itens b e c deveria deixar explicito que os atestados podem ser em nome do fornecedor da nuvem, pois em é muito comum que o detentor do sistema não seja o provedor da nuvem, pois são serviços completamente distintos, exigir que tudo seja feito pela mesma pessoa jurídica irá acarretar em séria dificuldade de competição.
3.2.1.2.
1.1.2. (Perfil Munícipe – OP) Permite que o munícipe se cadastre na solução via Portal de Atendimento WEB como pessoa física ou pessoa jurídica.
Com possibilidade de configuração de um processo de aprovação do usuário. Deve ser possível também o cadastro e autenticação integrado com a base única do cidadão do Governo Federal.
3.2.1.3.
1.1.3. (Perfil Munícipe – OP) Permite que o munícipe, previamente cadastrado e ativo na solução, consiga realizar login no Portal de Atendimento WEB utilizando usuário e senha cadastrados.
Permitir e para isso a plataforma deve possuir, nativamente a opção de autenticação do cidadão através do Login Único do Governo Federal (https://sso.acesso.gov.br/). Além disso, ao logar, deve possuir como padrão uma tela de relacionamento onde esse possa ter uma visão completa de todo o seu relacionamento com o órgão. Deve fazer parte dessa visão todos os processos que este tem permissão de visualização (participando ativamente ou não) e dados, não vinculados a processo, que o cidadão possui acesso e relacionamento. E o cidadão pode, a seu critério, poder ocultar informações que julgar não necessária de ser apresentada nessa visão inicial. Tal funcionalidade deve ter impacto exclusivamente na visão deste cidadão, não tendo impacto na visão dos demais usuários, e ser persistido sendo mantido nos próximos acessos do usuário. O cidadão pode, a seu critério, poder reordenar as informações apresentada nessa visão inicial, podendo definir a ordem que as informações devem ser apresentadas não necessitando seguir algum modelo padrão (como alfabético ou crescente). E também, após logar no sistema, deve conseguir alterar todos os seus dados definidos como editáveis pela Contratante. Além da visão inicial, a critério da Prefeitura, o cidadão pode ter acesso a dois outros tipos de visualizações, permitindo fácil troca entre essas, que são: (1) visão analítica, onde terá acesso a uma lista dashboards disponibilizados pela própria PREFEITURA, podendo o usuário criar novos gadgets caso este tenha permissão para tal. (2) visão processual, contendo o modelo de fila de instâncias de processos (modelo inbox) onde o usuário poderá ter uma visão por instância de processo o seu andamento. Para ambas as visões, só serão apresentadas informações a qual o usuário possui permissão de visualização.
3.2.1.4.
1.1.4. (Perfil Munícipe – OP) Permite que o munícipe realize solicitações de serviços públicos, elogios, sugestões, denúncias e reclamações, por meio do preenchimento de formulário do respectivo serviço.
O cidadão autenticado no sistema deve conseguir iniciar em qualquer ponto do sistema qualquer da solicitação a qual ele possua autorização para começar. Como existe uma tendência de existirem muitas possibilidades, o sistema deve prover dois recursos: (1) ter a inteligência de “sugestão inicial” de “ações mais comuns” realizadas pelo usuário direcionando o mesmo. Porém, deve ter a possibilidade do usuário ver todas as demandas. (2) possibilitar que o usuário faça uma pesquisa textual nos tipos de solicitação, trazendo as opções que contém o trecho pesquisável.
3.2.1.6.
1.1.6. (Perfil Munícipe – OI) Permite que o munícipe que reforçou uma solicitação já existente, conforme item 1.1.5, receba as atualizações da solicitação correspondente e possa acompanhar o andamento do atendimento da mesma forma que o solicitante original.
Para que o municipe consiga acompanhar melhor as suas solicitacoes, a solucao deve prover recursos de notificação ao usuário de duas formas: (1) alerta visual sistêmico de notificação apresentando a quantidade de mensagens na modalidade “visualizou finalizou”. (2) notificação individual que exigirá do usuário final a visualização e um “aceite” na comunicação, para encerramento.
3.2.1.8.
1.1.8. (Perfil Munícipe – OP) Permite que o munícipe que realizou a solicitação anonimamente consiga consultar o andamento da solicitação (pelo número de protocolo, por exemplo), sem precisar realizar nenhuma autenticação na solução.
Tal identificador (protocolo) deve ser uma chave não aleatória, não possibilitando assim que um usuário encontre a sequência e tenha acesso a outros serviços.
3.2.1.11.
1.1.11. (Perfil Munícipe – OP) Permite que o munícipe avalie o Portal de Atendimento WEB
Solução deve possuir nativamente avaliação dos serviços (NPS).
3.2.1.13.
1.1.13. (Perfil Configuração – OP) Permite configurar o Portal de Atendimento WEB ao munícipe, sem a necessidade de escrever código de programação, possibilitando a criação, edição, exclusão de componentes. Tais componentes podem ser, mas não se limitando a páginas HTML, menus de navegação, imagens, URLs, vídeos, áreas de texto, formulários, avisos (pop-ups), relatórios, gráficos, dashboards e tabelas.
Possibilitar, através de configuração, a criação de um ou mais portais de relacionamento com o cidadão, totalmente personalizado, e que seja possível gerir os conteúdos e serviços. O portal deve estar acessível na internet, e sua interface deve seguir os padrões de acessibilidade propostos pelo eMAG 3.1 (http://emag.governoeletronico.gov.br/) destacados: correção de tamanho de fonte, adequação para leitores de tela, tradução para libras, ajuste de contraste, atalhos de teclado. Permitir também organizar os conteúdos e serviços do portal em categorias e subcategorias sem limite mínimo de níveis de profundidade e permitir configuração de um controle de acesso personalizado em cada uma das categorias, subcategorias, conteúdos e/ou serviços. O controle de acesso deve ser calculado no momento da exibição, possibilitando que um mesmo portal possa ser acessado por perfis de usuários diferentes com acesso à conteúdos e serviços diferentes. Deve ser permitida a criação de seções para o portal com os conteúdos e serviços, contendo no mínimo: mais solicitados, últimos adicionados, últimos alterados, destacados. E também permitir solicitação de serviços através do portal com formulários personalizados por serviço, podendo assim iniciar processos dentro do BPMS
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.1.14.
1.1.14. (Perfil Configuração – OP) Permite configurar a obrigatoriedade e a ordem de preenchimento dos campos de cadastro do munícipe com autonomia e sem necessidade de programação
Além da ordem e se o campo é obrigatório ou não, deve ser permitido configurar se o campo é somente leitura, se trata de um campo múltiplo, se é um campo oculto, sem a necessidade de programação e que os campos possam ser configurados, no mínimo como do tipo: texto, data, data e hora, booleano, decimal, número inteiro, dinâmico, coordenada geográfica, arquivo e composto (tipo composto por vários campos correlacionado – Ex: Endereço).
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.1.15.
1.1.15. (Perfil Configuração – OI) Permite criar e configurar um tour guiado para auxiliar o munícipe durante a navegação do Portal de Atendimento WEB com autonomia e sem necessidade de programação.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.2.13.
1.2.13. (Perfil Configuração – OP) Permite gerenciar o conteúdo exibido no Aplicativo Móvel, possibilitando a criação, edição, exclusão de componentes, sem a necessidade de escrever código de programação. Tais componentes podem ser, mas não se limitando a páginas HTML, serviços públicos, menus de navegação, imagens, URLs, vídeos, áreas de texto, formulários, avisos (pop-ups), relatórios, gráficos, dashboards e tabelas.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.2.14.
1.2.14. (Perfil Configuração – OP) Permite configurar a obrigatoriedade e a ordem dos campos de cadastro dos formulários.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.3.1.
1.3.1. (Requisito Geral – OP) A solução deverá oferecer interfaces para atendimento assistido, permitindo registrar em cada solicitação o atendente e o canal assistido utilizado como porta de entrada da solicitação (Central Telefônica e Atendimento Presencial).
A solução deve possuir um módulo personalizado para as centrais (como 156) que receberão os cidadãos (telefone, presencialmente, etc.) contendo as mesmas visões que um cidadão possui, porém, não sendo limitado a um cidadão e sim a todos. Ou seja, deve disponibilizar para esses recursos as seguintes visões: (1) “Cidadãos”, possibilitando o acesso a todos os cidadãos, que ao escolher um cidadão deve ser apresentada a visão completa de todo o relacionamento do mesmo. (2) “Processo”, podendo ter uma visão mais orientada a processo e não a cliente. (3) “Analítica”, podendo ter uma visão vinculados a dashboards a qual possui acesso e com possibilidade de criação de novos, caso a Prefeitura possibilite tal recurso. Dada a existência das três formas de visualização disponíveis ( visão completa de todo seu relacionamento, visão analítica e visão processual) e dado o fato de termos usuários com perfis distintos onde cada visão atenderá mais um perfil que outro, toda vez que o usuário logar (seja cidadão ou usuário da Central) no sistema deve ser apresentada a última visão que esse usuário estava no último acesso, podendo assim dar continuidade ao seu trabalho facilmente. Permitir configurar que atividades sejam executadas offline (por exemplo, preencher um formulário, checklist, etc.), realizando o sincronismo das informações a partir do momento em que se estabelece novamente a conexão, por ser comum a necessidade de executar atividades em campo, onde pode não haver a disponibilidade de internet/conexão.
3.2.3.3.
1.3.3. (Perfil Atendimento – OP) Permite que o atendente registre todas as solicitações do munícipe em uma interface de atendimento, em nome do munícipe ou anonimamente, por meio do preenchimento de formulário do respectivo serviço, com a opção de upload e download de arquivos.
O usuário da central autenticado no sistema deve conseguir em qualquer ponto do sistema iniciar qualquer solicitação a qual ele possua autorização para tal. Complementar, caso ele esteja na tela de um cidadão específico e a solicitação em questão seja vinculada a aquela pessoa, o sistema deve interpretar isso automaticamente não necessitando de escolher novamente a pessoa. Como existe uma tendência de existirem muitas possibilidades, o sistema deve prover também para o usuário da central os mesmos recursos do cidadão, que são: (1) ter a inteligência de “sugestão inicial” de “ações mais comuns” realizadas pelo usuário direcionando o mesmo. Porém, deve ter a possibilidade do usuário ver todas as demandas. (2) possibilitar que o usuário faça uma pesquisa textual nos tipos de solicitação, trazendo as opções que contém o trecho pesquisável.
3.2.3.4.
1.3.4. (Perfil Atendimento – OP) Permite que o atendente crie um novo cadastro para o munícipe ainda não cadastrado na solução.
Além do cadastro, o usuário da central, ao acessar um cidadão pode alterar todos os dados que a PREFEITURA definiu como editável para esse perfil, além de possibilitar ter acesso as possíveis pendências do mesmo a fim de notificá-lo no próprio contato, podendo inclusive saná-la na própria ligação.
3.2.3.6.
1.3.6. (Perfil Atendimento – OP) Permite que o atendente consulte o histórico de solicitações de um munícipe, visualizando as informações relativas ao andamento do tratamento das solicitações.
Dada uma solicitação, que seja uma instância de um processo, permitir se disponível para o perfil específico do usuário, numa única tela: (1) acompanhar visualmente o caminho percorrido pela instância em questão, destacando, também visualmente, os casos em que foram executados repetidamente (seja por ser múltipla ou por passar várias vezes naquele ponto, por exemplo, em caso de reprovação e retorno); (2) dispor da documentação do processo e de todo elemento gráfico documentado. (3) possuir linha do tempo de execução do fluxo, destacando os principais eventos e podendo reproduzi-los novamente (voltar, play, pause, próximo, etc.); (4) para os casos de subprocessos embutidos ou referenciados no fluxo principal, deve ser possível adentrar com um clique (drill down) nos subprocessos e ter acesso às mesmas funcionalidades citadas anteriormente (1, 2 e 3).
3.2.3.12.
1.3.12. (Perfil Atendimento – OP) Permite que o atendente visualize os documentos atrelados às solicitações.
Permitir visualizar todos os dados atrelados às solicitações e ao solicitante, permitindo inclusive que o usuário da central, a seu critério e por cidadão, possa ocultar informações que julgar não necessária de ser apresentada. Tais informações, seja ela processo ou dado, deve ficar disponível em uma região de “ocultos” de fácil acesso e reversão da decisão (deixar de ser uma informação oculta). Tal funcionalidade deve ter impacto exclusivamente na visão deste usuário da central e para esse cidadão, não tendo impacto na visão dos demais, e ser persistido sendo mantido nos próximos acessos do mesmo.
3.2.3.14.
1.3.14. (Perfil Configuração – OP) Permite configurar as informações a serem apresentadas na interface do canal assistido, sem a necessidade de escrever código de programação, possibilitando a criação, edição, exclusão de componentes. Tais componentes podem ser, mas não se limitando a páginas HTML, menus de navegação, imagens, serviços públicos, URLs, vídeos, áreas de texto, formulários, avisos (pop-ups), relatórios, gráficos, dashboards e tabelas.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.3.15.
1.3.15. (Perfil Configuração – OP) Permite criar, editar e excluir scripts de atendimento no formato de fluxos executáveis para guiar os atendentes durante o atendimento ao munícipe.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.3.16.
1.3.16. (Perfil Configuração – OP) Permite configurar fluxos de aprovação para criação, edição e exclusão dos roteiros de atendimento (scripts).
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.2.5.1.
1.5.1. (Requisitos Gerais – OP) A solução deverá possuir integração com redes sociais que possuam APIs (no mínimo, Facebook, Facebook Messenger, Instagram, Twitter, Whatsapp, Telegram), possibilitando monitorar, detectar, engajar e publicar nessas redes, conforme suas políticas de privacidade e publicação.
Entendemos que o canal Instagram ainda não possui API oficial para integração. Solicitamos retirar tal rede da lista obrigatória, colocando-a como possibilidade de integração até a publicação e autorização de API oficial dessa rede social.
3.2.5.6.
1.5.6. (Perfil Munícipe – OI) Permite que o munícipe realize upload de arquivos sempre que a rede social em questão possuir este recurso.
Entendemos que o envio de documentos através de redes sociais causa risco de exposição de documentos e informações sigilosas dos cidadãos, o que contraria a LGPD.
3.2.5.8.
1.5.8. (Perfil Configuração – OI) Permite habilitar o registro de solicitações de serviços e a consulta da fase de atendimento por rede social.
Entendemos que o envio de informações pessoais através de redes sociais causa risco de exposição de informações sigilosas dos cidadãos, o que contraria a LGPD.
3.3.1.1.
2.1.1. (Requisito Geral – OP) A solução deverá possuir interfaces para construção de formulários que permitam a utilização sem a necessidade de código de programação e dando completa autonomia à CONTRATANTE.
Permitir configurar conteúdo com formulário definido por serviço (podendo existir também o formulário padrão), possibilitando ao usuário com respectivo acesso, preencher e submeter para atendimento, mas sem processo definido; e também conteúdo com formulário vinculado há algum processo de negócio (automatizado no BPMS), possibilitando assim um fluxo definido.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.4.
2.1.4. (Requisito Geral – OP) A solução deverá permitir o versionamento automático de formulários em produção e, caso necessário, o rollback para versões anteriores, sempre mantendo a integridade dos dados.
Permitir realizar a publicação de novas versões e o rollback para versões anteriores sem necessidade de downtime da aplicação e do serviço.
3.3.1.5.
2.1.5. (Perfil Munícipe - OP) Permite que os dados preenchidos no formulário pelo munícipe sejam validados, conforme regras definidas.
Inclusive permitindo aplicar regras complexas (scripts) ou integrações com outros sistemas para validação.
3.3.1.8.
2.1.8. (Perfil Munícipe - OI) Permite que o munícipe reutilize arquivos previamente carregados na solução em uma nova solicitação, como documentos de identificação, CPF, comprovante de endereço etc.
E para os arquivos carregados, possibilitar, a partir da existência de um padrão no documento, a identificação e preenchimento de campos automáticos (por exemplo, ao ser submetida uma carteira de habilitação, identificar nome, número da carteira, data de validade, etc.), por meio do recurso de OCR.
3.3.1.13.
2.1.13. (Perfil Operacional - OP) Permite que o servidor visualize e edite as informações contidas nos formulários preenchidos durante a solicitação pelo munícipe ou atendente, conforme regras definidas.
As alterações realizadas devem ser armazenadas em histórico, permitindo que sejam consultadas e confrontadas.
3.3.1.14.
2.1.14. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, o uso de diversos tipos de campos nos formulários como: caixa de texto, caixa de combinação, caixa de seleção, caixa de listagem, caixa de listagem suspensa, botão de comando, barra de rolagem, botão de opção, rótulo, imagem, dentre outros.
Além dos listados, possuir no mínimo: campo de data, campo de data e hora, campo numérico, arquivo, coordenada geográfica
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.15.
2.1.15. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, formulários com campos de upload e download de arquivos, possibilitando limitar extensões e tamanho dos arquivos a serem anexados.
Permitindo ser campo de arquivo múltiplo, com possibilidade de definir o mínimo e o máximo da multiplicidade do campo.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.16.
2.1.16. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, formulários com apresentação dinâmica de campos com base em condições (na medida em que itens do formulário são selecionados ou preenchidos, por exemplo)
Permitir que os campos seja dinamicamente alterados para no mínimo, obrigatório ou não, oculto ou não, somente leitura ou não.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.17.
2.1.17. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, a obrigatoriedade e a ordem de preenchimento dos campos dos formulários.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.18.
2.1.18. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, o permissionamento de visibilidade de campos e seus valores, conforme regras definidas.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.19.
2.1.19. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, o permissionamento de edição dos campos do formulário, mantendo o histórico de alterações realizadas, a data e o usuário que realizou a ação.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.20.
2.1.20. (Perfil Configuração - OP) Permite configurar, sem programação e com completa autonomia, o reuso do valor de um campo em outros campos do formulário.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.21.
2.1.21. (Perfil Configuração - OP) Permite criar e gerenciar, sem programação e com completa autonomia, modelos de formulários para reutilização.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.22.
2.1.22. (Perfil Configuração - OP) Permite criar banco de campos frequentes, facilitando a criação de novos formulários e garantindo a padronização.
Permitindo inclusive a definição de campo do tipo composto (tipo composto por vários campos correlacionados, por exemplo, endereço) frequente, como por exemplo endereço.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.23.
2.1.23. (Perfil Configuração - OP) Permite implementar validação nos campos dos formulários de acordo com formato, tipo do conteúdo, tamanho, máscaras de entrada de dados para campos específico (pelo menos CPF, CNPJ, CEP, telefone e e-mail), consulta em tabelas e bases de dados externas, scripts etc.
Permitindo inclusive, caso necessário, realizar integração com sistemas externos para implementar a validação dos campos dos formulários.
3.3.1.24.
2.1.24. (Perfil Configuração - OP) Permite inserir e configurar, sem programação e com completa autonomia, dicas (hints)nos campos dos formulários.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.25.
2.1.25. (Perfil Configuração - OI) Permite inserir e configurar imagens ou cores como opções selecionáveis de formulário (por exemplo, configurar um formulário cujas opções de seleção sejam imagens de diferentes tipos de árvores).
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.26.
2.1.26. (Perfil Configuração - OP) Permite atribuir peso aos campos e aos valores do formulário, possibilitando configurações de priorização e criticidade de serviços.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.27.
2.1.27. (Perfil Configuração - OI) Permite configurar formulários distintos para um mesmo serviço por canal de atendimento.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.1.28.
2.1.28. (Perfil Configuração - OP) Permite extrair relatórios, visualizar gráficos e dashboards sobre todos os itens do formulário, sem necessidade de programação ou customização.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.2.2.
2.2.2. (Perfil Munícipe – OP) Permite que o munícipe visualize no Portal de atendimento WEB e no Aplicativo Móvel o andamento atualizado da prestação do serviço e os respectivos prazos de atendimento por fase, conforme execução das etapas do fluxo de trabalho interno, graficamente em uma timeline (linha do tempo) com a duração da fase atual.
Sendo que nesta página o cidadão poderá consultar: o formulário de abertura da solicitação preenchido, o protocolo da solicitação, data de início, data de última atualização, situação da solicitação. O cidadão deve possuir uma visão simplificada e visual dos marcos do processo do serviço solicitado e quais desses marcos já foram concluídos para a solicitação em questão.
3.3.2.4.
2.2.4. (Perfil Munícipe – OP) Permite que o munícipe acrescente informações para complementar, cancelar ou reabrir uma solicitação nos diversos canais de atendimento.
A página de acompanhamento da solicitação deve apresentar uma linha do tempo do processo com os despachos e atividades do que o cidadão tenha permissão de acessar. Quando necessário, também nesta página, o cidadão poderá atender a atividades intermediárias do processo (Ex: diligências, solicitação de ajustes das informações, etc...), cada atividade com seu respectivo formulários de atendimento
3.3.2.5.
2.2.5. (Perfil Munícipe – OP) Permite que o munícipe retorne por e-mail as informações necessárias para resolver as pendências de uma solicitação. Qualquer retorno (reply) via e-mail deve ser inserido na respectiva solicitação original, bem como seus anexos.
A página de acompanhamento da solicitação deve apresentar uma linha do tempo do processo com os despachos e atividades do que o cidadão tenha permissão de acessar. Quando necessário, também nesta página, o cidadão poderá atender a atividades intermediárias do processo (Ex: diligências, solicitação de ajustes das informações, etc...), cada atividade com seu respectivo formulários de atendimento
3.3.2.7.
2.2.7. (Perfil Atendimento – OP) Permite que o atendente acompanhe o andamento atualizado dos serviços solicitados pelo munícipe com o detalhamento de todas as informações referentes à prestação do serviço, incluindo a execução das fases de atendimento (Visão Munícipe) e de etapas do fluxo de trabalho interno (Visão Prefeitura).
Permite que se configurado, um atendente possa assumir, devolver e transferir para outro usuário com permissão, o atendimento de uma solicitação.
3.3.2.8.
2.2.8. (Perfil Atendimento – OP) Permite que o atendente acrescente informações para complementar ou cancelar uma solicitação a pedido do munícipe no canal assistido.
Permite que o atendente realize comentários internos em uma solicitação que poderão ser visualizados por usuários com permissão.
3.3.2.11.
2.2.11. (Perfil Configuração – OP) Permite criar fases de atendimento, sem necessidade de programação e com autonomia, que serão exibidas por serviço e por perfil de usuário.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.3.1.
2.3.1. (Requisito Geral – OP) A solução deverá possuir um ambiente de desenvolvimento (parametrização) dos fluxos de trabalho interno de cada serviço e de suas respectivas regras de negócio para a prestação dos serviços que dê autonomia à CONTRATADA para cadastro e gestão dos fluxos.
Para isso a solução deve disponibilizar editor visual para modelagem de processos utilizando da notação BPMN 2.0, contendo, no mínimo, os seguintes elementos: evento de início, evento de fim, evento de tempo, tarefa de usuário, tarefa de serviço, múltiplas instâncias em sequência, subprocesso, gateway exclusivo, múltiplas instâncias em paralelo e raias na vertical e horizontal (não permitindo elementos fora dessas).
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.3.4.
2.3.4. (Perfil Operacional – OP) Permite que o servidor receba a solicitação do serviço e realize as atividades relacionadas a sua etapa do fluxo de trabalho, de acordo com regras definidas, dando andamento à solicitação para as etapas seguintes (por exemplo, aprovar ou reprovar uma documentação).
Possibilitar ao usuário na listagem de atividades: (1) aplicar filtros no resultado, tais como minhas atividades, criados por mim, em andamento, finalizados, todos; (2) criar filtros padrões adicionais na listagem para processos específicos (por exemplo, compras acima de R$ 1 milhão); (3) realizar pesquisa fulltext, pesquisando de uma só vez todos os campos pesquisáveis da listagem de instâncias; (4) realizar pesquisa direta em um campo (por exemplo, nome do cidadão), podendo ser combinada com outros campos (por exemplo, nome do cidadão e data de nascimento); (5) ordenar o resultado por qualquer informação existente no processo, como protocolo, data de criação, data da última alteração, processo, nome do cidadão, etc.
3.3.3.5.
2.3.5. (Perfil Operacional – OP) Permite que o servidor assuma a responsabilidade pelo tratamento de um protocolo de solicitação de serviço.
Permita também ao servidor, além de assumir, possibilidade de devolver ou transferir uma atividade de uma solicitação.
3.3.3.18.
2.3.18. (Perfil Configuração – OP) Permite a criação do fluxo de trabalho interno do serviço em notação BPMN ou notação similar com auxílio de modelador gráfico, sem necessidade de programação. O fluxo corresponde às etapas de tratamento do serviço, por exemplo “aprovação da documentação”, “emissão de ordem de serviço”, “aprovação do diretor”, etc.
A solução deve possuir editor de modelagem e automatização de processos unificado/integrado que permita: (1) estilizar as etapas do processo com cores diferentes, podendo assim definir um padrão visual organizacional. (2) poder inserir notas textuais em qualquer elemento gráfico ou sem vínculo a um elemento (“solta”). (3) possuir editor integrado ao fluxo que permita a documentação do processo como um todo e qualquer elemento gráfico do processo, contendo recursos de texto rico (HTML). (4) Possibilitar manipular vários elementos gráficos de uma só vez, através de recursos de múltipla seleção de objeto. Por ser um editor de modelagem e automatização totalmente WEB, é preciso conter recurso para desfazer ações equivocadas (ctrl Y e ctrl Z). Possuir recurso que possibilite agrupar processos em grupos específicos, como departamento/secretaria, possibilitando que apresente para o usuário final agrupado pelo mesmo.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.3.20.
2.3.20. (Perfil Configuração – OP) Permite configurar o fluxo de trabalho interno do serviço, sem necessidade de programação e com autonomia, estabelecendo prazos por etapa e alçadas de aprovação.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.3.3.24.
2.3.24. (Perfil Configuração – OP) Permite realizar o versionamento automático dos fluxos que estão sendo utilizados para prestação de serviços e, caso necessário, o rollback para versões anteriores, sempre mantendo a integridade dos dados.
Possibilitando, no mínimo: (1) criar nova versão a partir de uma pré-existente; (2) alterar a versão existente, sem necessidade de criar nova versão; e, para esse caso, (3) finalizar a alteração e publicação do processo de maneira independente; (4) implantar processo sem downtime da aplicação ou do processo; (5) duplicar um processo, criando, assim, uma versão independente a partir de outra pré-existente.
3.3.4.2.
2.4.2. (Requisito Geral – OP) A solução deverá oferecer, em sua interface, recursos para facilitar a organização das solicitações, conforme critérios, tais como, agrupamento de solicitações por munícipe, unidade de atendimento, etapas, fases, datas e horários, prazos de atendimento, pendências de análise e resolução, criticidade, tipo de serviço, endereço, etiquetas (tags), dentre outros critérios, exibidos de forma estruturada, em listas ou tabelas, por exemplo, e com a possibilidade de aplicação de filtros de pesquisa.
Possibilitar na listagem de instâncias: (1) aplicar filtros no resultado tais como minhas atividades, criados por mim, em andamento, finalizados, todos, etc. (2) pesquisa fulltext, pesquisando de uma só vez em todos os campos pesquisáveis da listagem de instâncias. (3) pesquisa direta em um campo (por exemplo, Nome do Cidadão), podendo ser combinada com outros campos (exemplo, Nome do Cidadão e Data de nascimento). (4) ordenar o resultado por qualquer informação existente no processo, como protocolo, data de criação, data da última alteração, processo, etc.
3.3.4.10.
2.4.10. (Perfil Configuração – OP) Permite configurar a pesquisa de solicitações nas interfaces dos usuários da solução, a partir de parâmetros fornecidos na solução, podendo incluir, mas não se limitando ao número de protocolo, nome, RG, CPF e endereço da solicitação.
Permitir buscar quaisquer campos pesquisáveis da solicitação
3.3.4.11.
2.4.11. (Perfil Configuração – D3) Permite configurar calendário e horário útil de trabalho da CONTRATANTE e de suas unidades e grupos de atendimento.
Considerando dias úteis, finais de semana, feriados nacionais, estaduais e municipais da unidade de atendimento.
3.3.5.3.
2.5.3. (Perfil Configuração – OP) Permite realizar a gestão do ciclo de vida de um serviço, possibilitando o agendamento da publicação e a retirada de um serviço no ambiente de produção, automaticamente de acordo com o período de vigência do serviço.
Permitir realizar a gestão do ciclo de vida de um serviço sem a necessidade de downtime na aplicação e do serviço.
3.3.5.4.
2.5.4. (Perfil Configuração – OP) Permite o retorno da configuração de um serviço para uma situação anterior (rollback), contendo o devido controle de versões e integridade dos dados.
Permitir realizar rollback sem a necessidade de downtime da aplicação e do serviço.
3.3.6.
2.6. GESTÃO DE USUÁRIOS
Permitir a sincronização dos usuários e grupos do usuário com AD/LDAP da prefeitura. Não necessitando portanto, realizar a gestão na própria aplicação.
3.4.1.22.
3.1.22. (Perfil Gerencial – OP) Permite cadastrar, alterar, excluir, publicar e gerenciar as Cartas de Serviços de forma autônoma pela CONTRATANTE, sem necessidade de programação.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.5.1.1.
4.1.1. (Requisito Geral – OP) A solução deverá possuir recursos que utilizam um gerador dinâmico de relatórios, gráficos e dashboards a partir de um filtro de especificações definido pelo usuário, sem necessidade de customização.
Permitir a criação nativa de dashboards/analytics, contendo qualquer dado configurado e instâncias de processo do BPMS, conforme filtros pré-definidos e com, no mínimo, os seguintes formatos: pizza, barras, pipeline (semelhante a ferramentas como Trello) e tabela. Apesar de um analytics ter um formato padrão, deve ser possível trocar a forma de visualização sem alterar o formato padrão. Permitir, para os formatos de pizza e de barras, criar múltiplos níveis (por exemplo: estado, cidade e bairro) de um analytics/dashboard, podendo ser feito o drilldown dos níveis até o último nível, em que também deve ser feito o drilldown para as instâncias (BPM) ou objetos (ECM) filtrados.
3.5.1.6.
4.1.6. (Perfil Munícipe – OI) Permite que o munícipe visualize dados agregados das solicitações por meio de uma interface gráfica com, pelo menos, filtros, gráficos, tabelas e mapas, como forma de transparência.
Permitir criar, para dados que possuem informações referentes à coordenada geográfica, uma visão de mapa (semelhante ao Google Maps), em que seja possível identificá-la pela região do mapa. Por exemplo, dada uma região, deve ser possível identificar todos os fornecedores específicos de um produto mais próximos dada a localização destes.
3.6.1.18.
5.1.18. (Perfil Configuração – OP) Permite configurar as regras de negócio da etapa de agendamento para atendimento presencial, sem necessidade de programação.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.11.1.5.
10.1.5. A solução e seus dados, em ambiente de produção, contingência e seus backups devem ser hospedados em Data(s) Center(s) em conformidade com a certificação TIA 942, no mínimo TIER II.
Possuir data center contingência localizado em local diferente do principal e possuir gestão total de infraestrutura, licenças, servidores, monitoramento e performance (realizada pela Contratada), evidenciando toda a gestão, incluindo, mas não se limitando-a: licença de banco de dados (caso não gratuito), licença de sistema operacional (caso não gratuito) e evidência de datacenter próprio em zonas distintas ou, em caso de terceiro, certificado de parceiro oficial e de profissionais certificados no mesmo.
3.11.1.6.
10.1.6. A solução deverá permitir a plena utilização em todos os canais de atendimento da CONTRATANTE, independente de sua localização física. O acesso à solução se dará por meio da Internet e pela Rede Corporativa da CONTRATANTE.
Além disso, não sendo necessária a instalação de nenhum framework, API ou aplicativo executável nas máquinas cliente (usuários).
3.11.1.7.
10.1.7. A solução deverá ser disponibilizada em ambientes de desenvolvimento (parametrização), homologação, treinamento e produção.
Além disso, com possibilidade de realizar a exportação/importação de processos entre esses ambientes sem necessidade de realizar downtime da aplicação.
3.11.1.8.
10.1.8. A solução deverá disponibilizar de forma nativa interfaces, módulos, add-ons e plug-ins, sem necessidade de customização, para os principais recursos de atendimento e prestação dos serviços públicos, tais como: Portal de Atendimento WEB, Aplicativo Móvel, chat, telas para o atendente presencial, atendente telefônico e servidor gerencial.
Possuir todos os módulos totalmente integrados, não necessitando assim de replicar informações entre os módulos.
3.11.1.16.
10.1.16. A solução deverá indexar todo o conteúdo da solução de forma automática durante o processo de inserção dos dados, independente da natureza (estruturada e não estruturada, sistêmica e não sistêmica), possibilitando a realização de buscas por palavras-chave.
Dada a grande volumetria de dados esperada e que a solução deve possuir mecanismo de busca fulltext em todos os dados a que o usuário possui acesso, sua arquitetura deve possuir recurso/tecnologia avançada de pesquisa textual e não realizar suas pesquisas direto em tabela (modelo tradicional de banco de dados).
3.11.2.7.
10.2.7. A solução deverá permitir autenticação por padrões Single Sign-On (SSO), Lightweight Directory Access Protocol (LDAP) e Active Directory (AD).
Ter nativamente configurada a autenticação de usuários com, no mínimo, AD/LDAP, Federada e serviço do Governo Federal (gov.br) para base única do cidadão.
3.11.3.2.
10.3.2. A solução deverá permitir a configuração das interfaces da solução para seguir os padrões de cores e a identidade visual da CONTRATANTE.
Permitindo personalizar, além de logotipo e cores também o nome das opções de menu que são exibidas ao usuário final.
3.11.4.1.
10.4.1. A solução deverá permitir que as parametrizações, configurações e ajustes a serem realizados pelo “Perfil Configurador” possam ser realizadas através de interface gráfica, sem a necessidade de escrever código de programação e dando autonomia à Prefeitura de São Paulo.
Entendemos que a exigência de não ser necessário de escrever código de programação para qualquer tipo de alteração é uma grave limitante, pois a necessidade é muito abrangente. Entendemos que deveria ser exigido uma fácil capacidade de adaptação e adequação da solução, par que seja possível a implementação de diferentes tipos de serviços e requerimentos.
3.11.5.3.
10.5.3. A solução deverá possuir a capacidade de sugestão para correção ortográfica no idioma português (Brasil), aplicando-se regras como de acentuação.
Ter toda a interface do sistema em português do Brasil.
3.11.7.4.
10.7.4. A solução deverá ter a capacidade de integrar-se com aplicações internas e externas da CONTRATANTE por meio de webservices ou APIs utilizando os padrões REST, XML, SOAP, WSDL, JSON, HTTP, HTTPS, SFTP, FTP, entre outros.
Possibilitar integração com outros sistemas, em qualquer ponto do processo ou conteúdo, através de tecnologias como SOAP, REST, Banco de dados e arquivos (FTP, email, etc.).
3.11.7.5.
10.7.5. A solução deverá ter a capacidade de integrar-se com sistemas de correio eletrônico através dos protocolos SMTP, IMAP e POP3.
Possuir integração com caixa de e-mail, possibilitando que um processo tome decisão a partir do recebimento de um e-mail em uma caixa monitorada.
3.11.7.7.
10.7.7. Disponibilizar API (Application Programming Interface) para integração com softwares de terceiros, sendo a API totalmente independente de aplicativos clientes e fornecida como um controle de Component Object Model (COM) separado.
Ter API REST nativa para integrar os dados da plataforma com de outros sistemas, sendo que tal API para um dado deve estar disponível automaticamente através de simples habilitação/configuração, não necessitando de programação.
3.11.8.1.
10.8.1. A solução deverá integrar-se à plataforma de telecomunicações da Central SP156 de atendimento telefônico da CONTRATANTE via webservices REST e XML RPC a fim de que as seguintes funcionalidades sejam providas:
a) Screen pop up: abertura da tela inicial de atendimento quando ocorrer o recebimento de uma chamada telefônica pelo atendente exibindo as informações de cadastro do munícipe com base no telefone do qual se originou a chamada;
b) Caso não haja nenhum cadastro relacionado ao telefone, a solução deverá apresentar uma tela em branco, com o número de telefone já preenchido, a fim de que seja possível o cadastro inicial do munícipe;
c) Caso exista mais de um cadastro com o mesmo telefone, deverá ser mostrada uma lista com todos munícipes vinculados ao número de telefone;
d) Em qualquer caso, a tela de atendimento deverá permitir a criação de um novo cadastro;
e) A tela de atendimento deverá exibir o caminho percorrido pelo munícipe na URA (Unidade de Resposta Audível).
A Contratante deve alterar o objeto e também incluir a parte de serviços de planejamento, implantação, operação, gerenciamento de central de atendimento e gestão de atendimento , pois não há justificativa técnica/comercial para fazer essas duas contratações separadas em formato de serviço para tratar operacionalmente o mesmo fim. Essa separação vai ocasionar problemas operacionais entre os contratos além de elevar os preços dos serviços. Atualmente todas as grandes empresas de Call Center possuem a capacidade de ofertar a Solução de Atendimento e Digitalização de Serviços que será operacionaliada no atendimento nos termos solicitados pela contratante.
Conforme defendido, a solução de Atendimento deverá estar integrada à esse objeto único, de forma a evitar gargalos na experiência de atendimento dos clientes com parâmetros operacionais que, para sua execução, utilizem de forma dependente e associada recursos geridos entre fornecedores distintos. Nesse caso em caso, se houver indisponibilidade da Solução haverá severos conflitos entre responsabilidade do link ou de um lado e da solução de atendimento por outro. Não faz nenhum sentido isso.
3.11.8.5.
10.8.5. Destaca-se que a implantação da plataforma de telecomunicações da Central SP156 não é de competência da CONTRATADA, estando, portanto, fora do escopo desta contratação. Compete à CONTRATADA tão-somente a integração à plataforma de telecomunicações da Central SP156 como um serviço de parametrização.
Conforme defendido, a solução de Atendimento deverá estar integrada à esse objeto único, de forma a evitar gargalos na experiência de atendimento dos clientes com parâmetros operacionais que, para sua execução, utilizem de forma dependente e associada recursos geridos entre fornecedores distintos. Nesse caso em caso, se houver indisponibilidade da Solução haverá severos conflitos entre responsabilidade do link ou de um lado e da solução de atendimento por outro. Não faz nenhum sentido isso.
A Contratante deve alterar o objeto e também incluir a parte de serviços de planejamento, implantação, operação, gerenciamento de central de atendimento e gestão de atendimento , pois não há justificativa técnica/comercial para fazer essas duas contratações separadas em formato de serviço para tratar operacionalmente o mesmo fim. Essa separação vai ocasionar problemas operacionais entre os contratos além de elevar os preços dos serviços. Atualmente todas as grandes empresas de Call Center possuem a capacidade de ofertar a Solução de Atendimento e Digitalização de Serviços que será operacionaliada no atendimento nos termos solicitados pela contratante.
10.6.1.1.
6.1.1 A eficácia do presente Contrato está sujeita à celebração do contrato que tem por objeto “Contratação de empresa especializada em serviços de planejamento, implantação, operação, gerenciamento de central de atendimento humano e gestão de atendimento receptivo e ativo nas formas eletrônica e humana (contact center)” (processo administrativo 6023.2019/0003628-4 / pregão eletrônico [A DEFINIR]). Dessa forma, até que haja a implementação da referida condição, a presente contratação não produzirá seus efeitos jurídicos típicos.
A Contratante admite categoricamente que o presente objeto de consulta pública possui dependência direta com outro objeto que trata de “Contratação de empresa especializada em serviços de planejamento, implantação, operação, gerenciamento de central de atendimento humano e gestão de atendimento receptivo e ativo nas formas eletrônica e humana (contact center)” (processo administrativo 6023.2019/0003628-4). Como ambos objetos são contratados em natureza de serviço, depedentes e associados em sua finalidade de fazer gestão de atendimento ao cidadão, sugerimos unificar tais contratações em uma só para mitigar riscos indevidos de execução indevidos para a administração pública.
10.6.9.
6.9. A remuneração se dará somente com a homologação da solução tecnológica com todos os serviços públicos, Base de Conhecimento (Carta de Serviços e FAQ), dados migrados e customização para atendimento dos requisitos classificados como “obrigatório para implantação” nos Anexos I e II do Termo de Referência.
A remuneração proposta é incompatível com o modelo dos fabricantes desse tipo de plataforma. As soluções SaaS possuem custo de licenciamento a partir da disponibilização de suas instâncias no ambiente Cloud dos fabricantes. Sugere-se a remuneração proporcional dessas instâncias disponibilizadas no período de implantação até a homologação do ambiente.
1.2.1.
2.1. A presente licitação tem por objeto a contratação de empresa especializada na prestação de serviços compreendendo a disponibilização de solução tecnológica para atendimento, gerenciamento do relacionamento com o cidadão e digitalização de serviços públicos, no modelo de Software como Serviço (SaaS), bem como a adequação e automação dos serviços públicos propriamente ditos, com o uso da solução tecnológica disponibilizada e utilizando métodos ágeis e design de serviço, incluindo também fornecimento de atendente virtual inteligente, suporte técnico e treinamento , conforme especificações constantes do Termo de Referência, Anexo I deste Edital e seus anexos.