Contract

Subitem

Texto Original

Sugestão de Alteração /

Questionamento

Justificativa para Sugestão

Análise da Equipe de Contratação

Gostaríamos de saber se existe algum software de CTI/Telefonia/URA já existente para esta central de Compras? Se sim, deverá ser integrado com a nossa solução? Se não, não será considerado como meio de atendimento central telefônica?

Se a Telefonia for fazer parte do escopo, sugerimos que os requisitos abaixo façam parte deste Termo de Referência.

Telefonia não faz parte do escopo deste Termo de Referência.

A despeito disso, conforme disposto no parágrafo 8.6, a Contratada deve prover Central de Atendimento para abertura de chamados de assistência técnica por telefone.

5.1.5.

Algumas entregas consistem na disponibilização ou customização de sistemas, outras na elaboração de documentos. No caso de documentos, os produtos deverão ser disponibilizados em meio impresso e digital, em formato de arquivo que permita a leitura e edição por softwares livres ou que já sejam de propriedade da Contratante.

Algumas entregas consistem na disponibilização ou customização de sistemas, outras na elaboração de documentos. No caso de documentos, os produtos deverão ser disponibilizados em digital, em formato de arquivo que permita a leitura e edição por softwares livres ou que já sejam de propriedade da Contratante.

Atualmente os documentos sofrem modificações com regularidade, portanto “impressões” rapidamente passam a ficar desatualizadas, além disto o meio digital permite uma maior capilaridade de consulta pois pode ser mantido atualizado e disponibilizado na WEB para fácil consulta. Outro ponto é que o meio digital permite a economia de papel.

Acatado. Não será exigida cópia impressa dos produtos.

5.1.7.

As atividades necessárias à consecução dos itens objeto deste Termo de Referência serão executadas predominantemente em Brasília - DF, uma vez que os órgãos e entidades cujos serviços públicos serão objeto de automação localizam-se majoritariamente em Brasília - DF. Contudo, poderá haver a realização de trabalhos em outras Unidades da Federação, para o caso de órgãos e entidades que não se localizem em Brasília - DF.

Informar quais as possíveis cidades a considerar fora do DF e escopo do serviço das mesmas (quantidade de órgãos e Usuários Governo por exemplo).

As despesas de viagens precisam ser consideradas na proposta uma vez que foi informado na consulta pública que as mesmas devem ser absorvidas pelo prestador de serviços.

Correto. Serão fornecidas mais informações no Termo de Referência.

5.3.

Participação de consórcios no certame disciplinado pelo art. 33 da Lei nº 8.666/93.

(...)

Os consórcios constituem instrumentos de ampliação da competitividade, na medida em que possibilitam as empresas que os integram somar capacidades técnica, econômico-financeira e know- how para participar de procedimento licitatório.

Trata-se de instrumento prestante a ampliar a competitividade, dado que possibilita às empresas ou pessoas que se reúnam para atender às demandas do edital.

Acatado parcialmente. Não serão permitidos consórcios, mas será permitida subcontratação para o Item III, conforme definido em Edital.

5.3.3.

Portanto, é imperioso para o êxito desta contratação que seja a mesma empresa a fornecer os quatro itens que integram o lote único, o que justifica a adoção do critério de menor preço global.

Portanto, é imperioso para o êxito desta contratação que seja a mesma empresa ou consórcio de empresas a fornecer os quatro itens que integram o lote único, o que justifica a adoção do critério de menor preço global.

Eventualmente somente um fornecedor de serviços não conseguirá cumprir todos os atestados pedidos, implementações em vários órgãos ao mesmo tempo ou outros desafios que o contrato de serviço possa trazer uma vez que o escopo não está definido, somente o preço unitário dos itens será estipulado. Por este motivo pedimos que o consórcio de empresas seja permitido neste processo.

Acatado parcialmente. Não serão permitidos consórcios, mas será permitida subcontratação para o Item III, conforme definido em Edital.

6.2.5.

Para adaptação do processo referente ao serviço público, a Contratada deverá: (...)

- Conduzir análise qualitativa com usuários do serviço para coleta de informações a respeito de suas dificuldades e barreiras, incluindo a) Mapa de Jornada do Usuário contendo: etapas do serviço; atividades realizadas pelo usuário (antes, durante e depois da utilização), principais momentos de percepção de valor do serviço, dores identificadas, canais de comunicação, percepção da experiência do usuário; b) Registro de entrevistas aprofundadas, no contexto do usuário, com no mínimo 20 usuários a serem entrevistados de acordo com a estratégia para coleta de informações definida; c) Relatório de pesquisa de satisfação com os usuários realizada a partir de questionário para suporte a análise de: estratificação por tipo de usuário; principais dificuldades/barreiras para consumo do serviço; avaliação dos canais de comunicação utilizados; avaliação do serviço prestado.

- Realizar análise de tendências de comportamento dos usuários do serviço.

- Dimensionar a força de trabalho necessária para a realização do novo processo, considerando os ganhos com a adequação e implantação com o uso da solução tecnológica.

A adequação de serviços públicos e sua posterior inserção em plataformas digitais é uma mudança disruptiva na experiência do cidadão no exercício dos seus direitos.

Neste sentido, a sua participação direta na adequação do serviço deve ser uma componente fundamental do Item 2 do serviço a ser prestado pela contratada.

O CBOK 3.0 é Corpo Comum de Conhecimento que trata dos principais aspectos relacionados ao trabalho com processos e serviços. Os Capítulos 4, 5 e 7 do guia tratam da adequação de processos e serviços e discorrem, com grande destaque e profundidade, sobre a importância da interação com os usuários no contexto de adequação do processo.

Complementarmente, o NESTA, organização inglesa que é uma das principais referências mundiais em serviços públicos, em seu guia lançado no final de 2016, denominado Designing for Public Services, explicita a importância do envolvimento do usuário em quaisquer iniciativas de adequação de serviços. Principalmente no que tange a sua posterior implantação por meio de soluções digitais.

Por fim, a implantação de canais digitais para prestação de serviços públicos implicam em uma mudança expressiva na forma pela qual a organização se estrutura. Um dos impactos mais relevantes neste sentido é no contexto dos servidores que participarão da prestação de serviço. Dependendo do impacto da solução digital, o órgão necessitará dedicar mais ou menos serviços à sua execução ou manutenção. O TCU recomenda um diagnóstico da Força de Trabalho necessária para a perfeita prestação do serviço, de forma a garantir que a transição ocorra da forma adequada.

Não acatado. Melhoria de processos não faz parte do escopo deste Termo de Referência. O mapeamento e ajuste do processo descritos no Item II são inerentes ao trabalho de automação do serviço público.

6.2.6.

- representação do processo ajustado (mapa) em notação BPMN 2.0 ou similar, contemplando: entradas e saídas, atividades, executores, normativos, decisões e pontos de controle;

- representação do processo ajustado (mapa) em notação BPMN 2.0, contemplando: entradas e saídas, atividades, executores, normativos, decisões e pontos de controle;

A ABPMP é uma associação internacional de profissionais de BPM (Business Process Management), sem fins lucrativos e apresenta em seu site mais de 150 profissionais com certificação CBPP, na sua grande maioria servidores públicos conhecedores da notação BPMN, permitir que o governo Federal padronize uma única notação permite utilizar e compartilhar o conhecimento.

Não acatado. Tal imposição limitaria a concorrência.

6.3.1

(...) integrações ser feitas"

(...) integrações serem feitas"

Erro de ortografia

Não acatado. Não há erro de ortografia.

6.3.2.

Considerando, contudo, que customizações podem ser necessárias em sistemas e bases de dados do órgão ofertante para viabilizar as integrações, o objetivo deste item é que a Contratada desenvolva as interfaces de integração necessárias, sob a supervisão da equipe do órgão.

O nosso entendimento é que a Contratada desenvolverá as interfaces de integração na solução objeto deste contrato, e não nos sistemas do órgão. Está correto o nosso entendimento?

Não está correto. Interfaces de integração necessariamente deverão ser configuradas na solução tecnológica, quando da automação do serviço público, conforme descrito no Item II. Contudo, caso seja demandada, a Contratada também deverá desenvolver interfaces de integração em sistemas do órgão, conforme escopo do Item III.

6.3.2.

A Contratada desenvolva as interfaces de integração necessárias através do barramento de serviços.

Padronização.

Não acatado. Além do Barramento de Serviços, a solução tecnológica poderá se integrar diretamente a sistemas e bases de dados. Em qualquer caso, o Item III refere- se ao desenvolvimento de interfaces de integração em sistemas e bases de dados.

6.3.5

Realizada a integração, como produtos, a Contratada deverá entregar: - documentação completa referente às interfaces de integração construídas; - documentação relativa aos ajustes realizados nos sistemas e bases de dados do órgão, que explicite todas as alterações efetivadas.

“Realizada a integração, como produtos, a Contratada deverá entregar: - documentação completa referente às interfaces de integração construídas; - documentação relativa aos ajustes realizados nos sistemas e bases de dados do órgão, que explicite todas as alterações efetivadas. - Código fonte das integrações, se aplicável.

O item 6.3.5 apenas documentação? O código fonte, se aplicável, não precisa ser entregue?

Acatado. O texto será ajustado no Termo de Referência.

6.4.2.1 e 6.4.2.2

(...) precipuamente

???

Erro de ortografia

Não acatado. Não há erro de ortografia.

6.4.2.1.

Módulo de Configuração: (...)

- cada turma deste módulo atenderá a até 20 (vinte) alunos e terá duração estimada de 20 (vinte) horas.

Módulo de Configuração: (...)

- cada turma deste módulo atenderá a até 20 (vinte) alunos e terá duração estimada de 40 (quarenta) horas.

O nosso entendimento é que para esta turma o ideal são 40h de treinamentos.

Não acatado. Conforme o caso concreto, a carga horária dos módulos poderá ser ajustada, considerando que a precificação será com base na hora-aula.

6.4.2.1.

Módulo de Configuração: (...)

- cada turma deste módulo atenderá a até 20 (vinte) alunos e terá duração estimada de 20 (vinte) horas.

Módulo de Configuração: (...)

- cada turma deste módulo atenderá a até 16 (dezesseis) alunos e terá duração estimada de 20 (vinte) horas.

Para aumento da produtividade do curso, sugerimos turmas de 12 até 16 alunos.

Entendemos que um número acima disso diminui a concentração e produtividade da turma.

Não acatado. Cada turma atenderá a até vinte alunos.

6.4.2.1.

Módulo de Configuração: (...)

- ao final do treinamento, o aluno deverá estar apto a implantar, modificar e atualizar os processos referentes a serviços públicos com autonomia;

Módulo de Configuração: (...)

- ao final do treinamento, o aluno deverá estar apto a implantar, modificar, atualizar e automatizar os processos referentes a serviços públicos com autonomia;

O objetivo é deixar claro que ao final do treinamento o aluno terá total capacidade de configurar, implantar, modificar e automatizar os processos dentro da ferramenta (módulo administrador).

Acatado. O texto será ajustado para isso ficar claro.

6.4.2.2.

Módulo de Atendimento: (...)

- cada turma deste módulo atenderá a até 20 (vinte) alunos e terá duração estimada de 8 (oito) horas.

Módulo de Atendimento: (...)

- cada turma deste módulo atenderá a até 16 (dezesseis) alunos e terá duração estimada de 20 (vinte) horas.

Para aumento da produtividade do curso, sugerimos turmas de 12 até 16 alunos.

Entendemos que um número acima disso diminui a concentração e produtividade da turma.

Não acatado. Cada turma atenderá a até vinte alunos. O número de horas poderá ser ajustado conforme o caso concreto.

6.4.6.1.

Os programas de cada treinamento devem ser apresentados ao Contratante, para aprovação, em até 10 (dez) dias corridos antes do início da respectiva turma, bem como o material de apoio, que deverá ser fornecido pela Contratada e estar no idioma português.

O conteúdo dos cursos são desenvolvidos juntamente ao time de produto fora do Brasil, e constantemente atualizados. Por este motivo fica inviabilizado ter todos os cursos com o conteúdo traduzido para a língua portuguesa.

Não acatado. O material do curso deve estar no idioma português.

6.5.4.2.

A Contratada deverá instanciar no ambiente da solução tecnológica uma área específica para a realização do treinamento, em que serão carregadas as configurações referentes aos serviços públicos objeto de estudo.

A contratada deverá prover ambiente de treinamento, quando houver, com configurações similares às dos serviços públicos objetos de estudo, para aprendizado dos alunos.

É disponibilizado na maioria dos treinamentos oficiais da solução ofertada, ambiente próprio para treinamento e exercícios, não sendo necessária nenhuma intervenção no ambiente próprio do cliente para este fim, evitando possíveis imprevistos.

Acatado. Serão mantidas duas possiblidades: ambiente independente ou instância no ambiente da solução para treinamento.

PRECIFICAÇÃO DOS ITENS (...)

Licenciamento - Usuário Governo: Pago por usuário

PRECIFICAÇÃO DOS ITENS (...)

Licenciamento - Usuário Governo: Pago por ciclo (...)

A utilização baseada por Número de Usuário e/ou Processos, pode não ser o ideal quando não se tem o número exato, quando se tem um grande número de usuários ou até mesmo quando se tem usuários com pouca frequência utilização. O modelo proposto independe do número de usuários e do numero de tipos processos existentes pois é baseado no contabilização dos CICLOS (também conhecido como atividades ou tarefas), independente da complexidade dos processo.

Não acatado. O critério passível de estimativa e de mensuração para fins de precificação do Item I é a quantidade de Usuários Governo.

7.1.

O pagamento pelo Item I será realizado mensalmente, com base no número de usuários gestores dos serviços públicos automatizados por meio da solução tecnológica, aqui chamados de Usuários Governo, independentemente do número de usuários que consomem os serviços públicos, aqui chamados de Usuários Sociedade.

Licenciamento - Usuário Sociedade: Livre

Licenciamento - Usuário Sociedade: Quantidade de transações da Sociedade por Usuário Governo por mês

A quantidade de transações deverá ainda atender aos requisitos de tempo médio de atendimento, tempo de primeira resposta, tempo para conclusão, etc, descritos no tópico XX.XX.

A métrica ilimitada é uma ilusão pois sempre será necessária uma capacidade de processamento maior para atender a uma quantidade maior da população. Como está sendo contratado um SAAS de mercado a métrica deve ser baseada em transações como são licenciados estes sistemas, de acordo com a quantidade de interações demandada.

A quantidade de transações serve tanto para estimar o valor dos sistemas quanto para o sizing da máquina necessária para o hosting da solução. Entendemos que o contratante deseja que estes detalhes técnicos sejam transparentes e quantificados por usuário, daí a sugestão de tomar todas as transações de um mês e dividir pelo número de usuários governo que as tratarão e chegar em uma métrica de transações por usuário.

Esta alteração deve ser refletida em outras partes do documento (ex.: tópico 19).

Não acatado. O critério passível de estimativa e de mensuração para fins de precificação do Item I é a quantidade de Usuários Governo.

7.1.

Usuários Sociedade.”

O pagamento pelo Item I será realizado mensalmente, com base no número de usuários gestores dos serviços públicos automatizados por meio da solução tecnológica, aqui chamados de Usuários Governo, e também pelo de número de usuários que consomem os serviços públicos, aqui chamados de Usuários Sociedade.”

As soluções em nuvem, como neste objeto, são dimensionadas proporcionalmente ao número de acessos que recebem. O quantitativo de público interno e externo faz toda a diferença no dimensionamento da solução.

Não acatado. O critério passível de estimativa e de mensuração para fins de precificação do Item I é a quantidade de Usuários Governo.

7.1.

Usuários Sociedade -> Número ilimitado de usuários -> Licenciamento livre

Quantidade de acessos simultâneos (sessões)

Garantia de que a infraestrutura seja apropriada para o volume de acessos simultâneos.

Não acatado. O critério passível de estimativa e de mensuração para fins de precificação do Item I é a quantidade de

Usuários Governo.

7.3

Mensalmente, na oportunidade do fechamento de cada fatura, será verificado o número de Usuários Governo ativos, com base no que será feita a cobrança. Portanto, ainda que determinada quantidade de Usuários tenha sido solicitada em uma Ordem de Serviço específica, será considerado apenas o número de Usuários em utilização, para fins de faturamento.

Deve ser estudada uma carência de N meses quando da diminuição do número de usuários governo para que a quantidade seja mantida durante este período.

Minimizar impactos decorrentes da redução de usuários, para os quais houve investimento em infraestrutura (máquinas e pessoas) do fornecedor.

Não acatado. Não será garantida uma quantidade mínima de usuários.

7.3

O que caracteriza um usuário ativo? Se fizer login uma vez no mês, o usuário já é considerado ativo? É importante deixar claro o que caracteriza um usuário ativo. Nossa sugestão é que seja um usuário que efetivamente utilizou a solução.

Não acatado. Desnecessário, pois a ativação / desativação de usuários será comandada manualmente (usuário ativo é aquele que está habilitado e que pode fazer uso das funcionalidades da plataforma a qualquer tempo).

7.3.

Mensalmente, na oportunidade do fechamento de cada fatura, será verificado o número de Usuários Governo ativos, com base no que será feita a cobrança. Portanto, para fins de faturamento, serão considerados os usuários provisionados anteriormente em Ordem de Serviço.

A nossa sugestão é que neste item, sejam cobrados mensalmente na fatura os usuários provisionados e solicitados anteriormente em uma ordem de serviço. Sugerimos um modelo de licenciamento nomeado ou concorrente.

Não acatado. O pagamento mensal será feito com base no número de usuários governo ativos.

7.3.

Será considerado apenas o número de Usuários em utilização desde que seja garantido um volume mínimo de Usuários, para fins de faturamento.

Garantia de melhor custo.

Não acatado. O pagamento mensal será feito com base no número de usuários governo ativos, sem garantia de um quantitativo mínimo.

7.7.

Cada um dos fatores deverá ser pontuado conforme a tabela a seguir: (...)

A pontuação, ao menos para “1. Formulários de entrada” e “4. Interfaces de integração” devem considerar a complexidade, refletindo na contagem dos Itens II e III.

A quantidade simples de formulários e interfaces não reflete a complexidade dos mesmos, pois por exemplo um relatório que tem apenas nome e CPF de um indivíduo tem o mesmo peso de uma listagem de casal com filhos e netos para o qual seriam necessárias várias leituras e tratamentos. Talvez colunas como “Pontuação – Simples /

Pontuação – Média / Pontuação - Complexa” traduzam melhor o problema de dimensionamento.

Não acatado. Assim como haverá formulários e intefaces complexas, haverá também formulários e interfaces muito simples.

7.13

Para cada sistema de informação ou base de dados a ser integrado, será devida a quantidade de 50 USTI, acrescida de 10 USTI a cada nova interface de integração desenvolvida, limitado a 100 USTI por sistema ou base de dados. A contratante fica responsável por conceder os acessos necessários e fornecer os códigos fonte dos sistemas para que a contratante possa realizar engenharia reversa dos sistemas a serem integrados. O tempo necessário para conceder os acessos por parte da contratante não é contabilizado para efeito de prazo da atividade de integração.

O edital não fala sobre engenharia reversa de sistemas legados. Como serão feitas as integrações? Como o prazo é afetado caso a contratante não consiga disponibilizar alguém para fazer repasse dos sistemas? Não seria o caso de constar no edital que a engenharia reversas das bases e sistemas é de responsabilidade da contratada? Nesse caso a contratante ficaria obrigada apenas a prover os acessos necessários aos códigos fontes e base de dados (isso também deveria constar no edital).

Acatado parcialmente. O texto da descrição do Item III será complementado.

7.13

A definição de base de dados é ambígua. Por exemplo, no Oracle o banco todo é apenas uma base com subdivisões por schema. Dessa forma, um órgão com uso intensivo do Oracle teria todos os seus dados contados como apenas uma base. Uma medida mais proporcional seria fazer a análise por sistema, base de dados ou schema (valendo a de definição mais granular dependendo do contexto)

Acatado parcialmente. Alteração no texto para deixar a regra atual mais clara.

7.13

No caso de integrações de Banco de Dados ou chamadas a serviço de outros sistemas, a contratada apenas fara consulta e chamada sem efetuar evoluções no BD ou sistema do orgão, correto? Por gentileza, explicitar no edital.

O entendimento está correto, mas o texto do Termo de Referência já deixa isso explícito, não sendo necessária alteração.

7.20.

Não serão aceitas propostas cujo valor unitário do Usuário Governo seja maior que o dobro do valor unitário da Unidade de Serviço Técnico de Automação (USTA). Os licitantes deverão considerar isso no preenchimento da Planilha de Formação de Preços.

Pedimos a retirada do requisito.

O valor do software ofertado como serviço e o valor da implementação do sistema são variáveis independentes não relacionadas entre si. Não está claro se a correlação entre as duas métricas será satisfeita pela precificação e julgamos esta correlação desnecessária, pois o que importa para o pregão é o preço global da proposta.

Por este motivo pedimos a retirada da exigência, por entendermos que o preço global que definirá a classificação dos licitantes.

A exigência em questão será reanalisada.

8.2.7

“(...) item 8.2.2”

“(...)item 8.2.6"

Referência incorreta. Aparece que o texto "item

8.2.2" deveria ser "item 8.2.6"

Acatado. A referência será ajustada no

Termo de Referência.

8.2.9

"(...) ajustado o preço final da OS"

"(...) ajustado o preço e prazo final da OS"

O prazo também é afetado pela recontagem da OS.

Acatado. O texto será ajustado no Termo

de Referência.

8.3.1

"(...) os produtos deverão ser disponibilizados em meio impresso e digital, (...)"

"(...) os produtos deverão ser disponibilizados digital, e eventualmente o órgão poderá solicitar em formato impresso, (...)"

Da forma em que está redigido, todos os documentos deverão ser impressos gerado grande volume. Eventualmente o órgão terá que fazer guarda dos mesmos. Diante da iniciativa de reduzir o papel nos órgão (por exemplo, o SEI).

Acatado. Não será exigida cópia impressa dos produtos.

8.3.1.

Algumas entregas consistem na disponibilização ou customização de sistemas, outras na elaboração de documentos. No caso de documentos, os produtos deverão ser disponibilizados em digital, em formato de arquivo que permita a leitura e edição por softwares livres ou que já sejam de propriedade da Contratante.

Acatado. Não será exigida cópia impressa dos produtos.

8.3.7.

A partir da data de recebimento dos produtos, o Gestor Setorial tem o prazo de 15 (quinze) dias corridos para se manifestar pela aceitação, rejeição ou devolução para ajustes.

A partir da data de recebimento dos produtos, o Gestor Setorial tem o prazo de 15 (quinze) dias corridos para se manifestar pela aceitação, rejeição ou devolução para ajustes. Não havendo manifestação, os produtos serão considerados entregues.

Nossa sugestão é que, passados estes 15 dias sem manifestação do Gestor Setorial, os produtos serão considerados entregues, evitando assim atrasos no processo de pagamento.

Acatado parcialmente. Será explicitado no Termo de Referência que o prazo total para Recebimento Definitivo não pode ultrapassar noventa dias, em conformidade com a Lei nº 8.666/93.

8.5.6

Fórmula matemática

A formula matemática está com a divisão por 30 no lugar errado (deveria ser no expoente). Além disso, a formula não se aplica adequadamente se o atraso se der entre uma data no meio de um mês indo para a data no meio de outro mês. Além disso, está incidindo apenas o IPCA, falta a mora.

Acatado. O texto será ajustado no Termo de Referência.

8.6.1

.serviços públicos, disponível 24 (vinte e quatro) horas por dia, 7 (sete) dias por semana, inclusive feriados

A Contratada deve prover Central de Atendimento para abertura de chamados de assistência técnica por telefone, sem custos (tipo 0800) para o Contratante e os órgãos e entidades responsáveis pela prestação dos serviços públicos, disponível 24 (vinte e quatro) horas por dia, 7 (sete) dias por semana, inclusive feriados. O serviço deve ser prestado em português do Brasil.

A central de atendimento 0800 pode ser em qualquer língua? O edital não especifica português do Brasil.

Acatado. O requisito será explicitado no Termo de Referência.

9.2.

A Qualificação Técnica será comprovada mediante os seguintes documentos: (...)

Atestado de Capacidade Técnica fornecido por pessoa jurídica de direito público ou privado, a sua experiência técnica na execução dos serviços de características técnicas iguais ou semelhantes a da contratação em referência, conforme previsto no art. 30 da Lei 8.666/93, comprovando que a licitante possui capacidade operacional para prestar o volume de serviços solicitados dentro do prazo previsto. Esta comprovação deve ser realizada por meio de atestado(s) técnico(s) detalhado(s) que comprove(m) que a licitante executou os serviços de gestão por processos de características técnicas iguais ou semelhantes a da contratação em referência, evidenciando uso de metodologia aderente ao CBOK e notação Business Process Modelling Notation - BPMN. (...)

A exigência de Atestados Técnicos aumenta a garantia de bons serviços prestados por profissionais competentes.

Não acatado. Não é exigido o uso de metodologia aderente ao CBOK nem de BPMN na execução dos serviços objeto deste Termo de Referência.

9.2.

A Qualificação Técnica será comprovada mediante os seguintes documentos: (...)

9.2.4. Comprovação de ser a única e exclusiva detentora da propriedade industrial e intelectual do software ofertado, através de registro de programa de computador (software) junto ao INPI, ou documento equivalente ao registro, na forma do parágrafo 2º, do artigo 2º, da Lei Nº 9.609/98, que dispõe sobre a proteção da propriedade intelectual de programa de computador.

O Ministério da Indústria, Comércio e Registros através do INPI incentiva o registro de patentes como forma de certificar a conformidade dos produtos com determinadas normas ou especificações técnicas.

Não acatado. A licitante não precisa deter a propriedade industrial e intelectual do software ofertado.

9.2.1.

a) ACT comprovando o fornecimento da mesma Solução Tecnológica ofertada no Item I, disponibilizada no modelo Software como Serviço (SaaS), para pelo menos 500 (quinhentos) usuários atendentes (usuários que acessam funcionalidades das interfaces de atendimento e/ou configuração, definidos neste Termo de Referência como Usuários Governo);

a) ACT comprovando o fornecimento da mesma Solução Tecnológica ofertada no Item I, disponibilizada no modelo Software como Serviço (SaaS);

A nossa sugestão é que neste item não seja solicitado quantitativo mínimo de usuários, visto que, independente do número de usuários, todas as configurações são realizadas por padrão.

Tratando-se de solução em nuvem, o quantitativo de usuários só será relevante para a infraestrutura provisionada pelo Fabricante, de forma automática.

Não acatado. O quantitativo mínimo de usuários está associado com a capacidade operacional de a licitatante prestar o serviço.

9.2.1.

Atestados de Capacidade Técnica (ACT) em nome da licitante, expedidos por pessoas jurídicas de direito público ou privado, que comprovem fornecimento compatível com os serviços constantes deste Termo de Referência:

Atestados de Capacidade Técnica (ACT) em nome da licitante ou da fabricante

Garantia de que a infra-estrutura seja apropriada para o volume de acessos simultâneos.

Não acatado. Atestados de Capacidade Técnica devem ser em nome da licitante.

9.2.1.

Serão aceitos atestados de empresas/ órgãos sediados em outros países?

Sim, serão aceitos atestados emitidos por empresas estrangeiras, desde que em nome da licitante.

10.11.

Constatado o atendimento aos requisitos funcionais avaliados durante a sessão, a licitante deverá implementar na ferramenta, em até 05 (cinco) dias corridos:

- a automação completa de um serviço público selecionado ela equipe técnica do Ministério do Planejamento, a partir de documentação entregue à licitante ao final da sessão, com a complexidade de até 06 (pontos), conforme tabela de pontuação referente ao Item II;

- a adequação à IDG (Identidade Padrão de Comunicação Digital do Governo Federal) (xxx.xxxxx.xxx.xx) e à atual identidade visual do Portal de Serviços (xxx.xxxxxxxx.xxx.xx) com interface de acesso em idioma português padrão Brasil.

Constatado o atendimento aos requisitos funcionais avaliados durante a sessão, a licitante deverá implementar na ferramenta, em até 15 (quinze) dias corridos:

- a automação completa de um serviço público selecionado pela equipe técnica do Ministério do Planejamento, a partir de documentação entregue à licitante no início da sessão, com a complexidade de até 06 (pontos), conforme tabela de pontuação referente ao Item II;

O prazo inicialmente proposto é pequeno e traz grande risco ao licitante, uma vez que é esperado que interfaces com os sistemas atuais sejam pedidas, além de identidade visual, parametrização do processo, workflows, enfim um miniprojeto completo. Entregar estes requisitos antecipadamente também viabiliza mais horas de trabalho para a equipe de construção.

Pelos motivos expostos buscamos um maior tempo de preparação.

Acatado parcialmente. A adequação da identidade visual será solicitada apenas após a contratação, não mais na Prova de Conceito. Contudo, é imperioso que a licitante demonstre, na Prova de Conceito, que é capaz de automatizar um serviço nos prazos que constarão do contrato.

10.11.

Constatado o atendimento aos requisitos funcionais avaliados durante a sessão, a licitante deverá implementar na ferramenta, em até 05 (cinco) dias corridos: - a automação completa de um serviço público selecionado pela equipe técnica do Ministério do Planejamento, a partir de documentação entregue à licitante ao final da sessão, com a complexidade de até 06 (pontos), conforme tabela de pontuação referente ao Item II; - a adequação à IDG (Identidade Padrão de Comunicação Digital do Governo Federal) (xxx.xxxxx.xxx.xx) e à atual identidade visual do Portal de Serviços (xxx.xxxxxxxx.xxx.xx) com interface de acesso em idioma português padrão Brasil

integrações os pontos não incluem ‘Interfaces de Integração’; - a adequação à IDG (Identidade Padrão de Comunicação Digital do Governo Federal) (xxx.xxxxx.xxx.xx) e à atual identidade visual do Portal de Serviços (xxx.xxxxxxxx.xxx.xx) com interface de acesso em idioma português padrão Brasil.

A prova de conceito fala sobre pontos para USTA mas não diz nada a respeito de pontos de USTI. Isso quer dizer que a POC não envolverá nenhuma integração? Sugerimos que não seja feita integração (texto alterado) ou que seja especificado quantas integrações e pontos de

‘Interface de Integração’ serão cobrados na POC.

Não acatado. A complexidade do que será pedido na Prova de Conceito será compatível com o tempo e os recursos disponíveis para o fornecedor, incluindo a chamada a interfaces de sistemas externos.

11.2.

t) comprovar, por ocasião da assinatura do contrato, que possui em seu quadro de pessoal pelo menos 10 (dez) profissionais capacitados na Solução Tecnológica ofertada. Deverá ser apresentado documento emitido pela empresa proprietária (desenvolvedora) da Solução em nome do profissional que comprove a capacitação, enquanto a comprovação do vínculo empregatício será feita por meio de cópias das Carteiras Profissionais de Trabalho e das Fichas de Registro de Empregado dos profissionais;

Ampliar a possibilidade de utilizações de profissionais, desde que os mesmo estejam de alguma forma vinculadas as empresas contratadas, permite manter a qualidade e garantia de bons serviços com valores competitivos.

Acatado. Serão ampliadas as possibilidades de vínculo de tais profissionais com a licitante.

11.2.

t) comprovar, por ocasião da assinatura do contrato, que os profissionais participantes do projeto sejam capacitados na Solução Tecnológica ofertada. Deverá ser apresentado documento emitido pela empresa proprietária (desenvolvedora) da Solução em nome do profissional que comprove a capacitação, enquanto a comprovação do vínculo empregatício será feita por meio de cópias das Carteiras Profissionais de Trabalho, das Fichas de Registro de Empregado dos profissionais, Contratos de Pessoa Jurídica e Contratos de Empregados Cooperados;

A nossa sugestão é que a equipe participante do projeto seja certificada, e não necessariamente 10 profissionais. Podemos utilizar 5,6,7 profissionais no projeto. Além disso, colocamos como sugestão que a comprovação do vínculo empregatício possa ser comprovada mediante Carteira de Trabalho, Contratos de Pessoa Jurídica e Contratos Cooperados.

Acatado parcialmente. Serão ampliadas as possibilidades de vínculo de tais profissionais com a licitante e será solicitado que toda a equipe alocada seja capacitada. Mas a quantidade mínima de profissionais será mantida.

11.2.

t) comprovar, por ocasião da assinatura do contrato, que possui em seu quadro de pessoal pelo menos 10 (dez) profissionais capacitados na Solução Tecnológica ofertada. De quadro proprio ou do quadro da empresa proprietária da solução e uma vez sendo de quadro proprio deverá ser apresentado documento emitido pela empresa proprietária (desenvolvedora) da Solução em nome do profissional que comprove a capacitação, enquanto a comprovação do vínculo empregatício será feita por meio de cópias das Carteiras Profissionais de Trabalho e das Fichas de Registro de Empregado dos profissionais;

Desta forma o parceiro de serviço poderá contar o expertise do time de serviços da empresa proprietária da Solução.

Acatado parcialmente. Serão ampliadas as possibilidades de vínculo de tais profissionais com a licitante, mas deve haver vínculo com a licitante.

13.4.

- as bases de dados em formato aberto, incluindo toda documentação correlata;

Definir o que é formato aberto.

Não está claro o que é formato aberto.

Acatado. Será incluída uma definição para formato aberto no Glossário.

13.6

Além disso, a Contratada deverá manter os dados em sua infraestrutura por até 12 (doze) meses após o encerramento do contrato, mantendo pelo menos 10% (dez por cento) dos Usuários Governo contratados ativos para acesso aos dados, como medida de apoio à migração dos serviços públicos automatizados para outra ferramenta.

Além disso, a Contratada deverá manter os dados em sua infraestrutura por até 12 (doze) meses após o encerramento do contrato, mantendo pelo menos 10% (dez por cento) por órgão segmentado (tenant) dos .Usuários Governo contratados ativos para acesso aos dados, como medida de apoio à migração dos serviços públicos automatizados para outra ferramenta. Os serviços não estarão mais disponívels na 'Interface Sociedade'

A plataforma deve continuar operacional para o público externo? Ou apenas para os usuários do governo? 10% por tenant (órgão segmentado) ou 10% do total geral?

Acatado. O texto será ajustado no Termo de Referência.

Anexo I, Item I

Tempo médio de resposta – Correspondente ao mínimo de 0,5 segundos para cada requisição realizada.

Tempo médio de resposta – Correspondente ao mínimo de 0,5 segundos para cada requisição XXXXXXX realizada.

A nossa sugestão é de que seja descrito exatamente qual teste será executado.

Acatado. O texto será adequado no termo de referência.

Anexo I, Item I

Tempo médio de resposta (Response Time Testing)

O TMR depende de cada tipo de requisição. Xxxxx descrever os tipos de requisição. Exemplo: se for feita uma consulta a uma base externa ou legada, o TMR pode ser comprometido.

O TMR deve ser definido caso a caso.

Não acatado. O fornecedor deverá obter a medida para as requisições realizadas ao software apenas em sua própria infraestrutura.

Anexo I, Item II

Prazo para adequação e atuomação de serviços públicos: (...)

11 ou mais (pontos) - 15 dias (entrega) - 10 dias (correção)

Prazo para adequação e atuomação de serviços públicos: (...) 11 ou 15 (pontos) - 15 dias (entrega) - 10 dias (correção)

15 ou mais (pontos) - 15 dias mais 1 dia por ponto (entrega) - 10 dias mais 1 dia por ponto (correção)

Desta forma possibilita uma estimativa de execução e entrega mais precisa.

Não acatado. Apesar de, excepcionalmente, a pontuação poder extrapolar a quantidade máxima de 15 pontos, o prazo de 15 dias deverá ser mantido.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

2. REQUISITOS TÉCNICOS (...)

1. CARACTERÍSTICAS DO LICENCIAMENTO

1.1. Permitir número de usuários ilimitados

1.2. Permitir número ilimitado de processos e atividades/tarefas

1.3. Permitir número ilimitado de execuções de instâncias de processos

1.4. Quando, para o funcionamento da solução, forem necessárias licenças de software de terceiros, essas devem ser fornecidas integralmente pela CONTRATADA, durante a vigência do contrato. Exceções a essa regra se fazem para os sistemas operacionais e sistema gerenciador de banco de dados

O texto não cita referencias técnicas da plataforma de processos, por se tratar de uso de “solução tecnológica para automação de serviços públicos, no modelo de Software como Serviço (SaaS)”, consideramos importante o detalhamento dos requisitos técnicos que suportarão a execução dos serviços, acrescentando os itens acima sugeridos.

Não acatado. A especificação dos requisitos técnicos não limita quantitativos para o processo de gestão do atendimento. A solução tecnológica deverá ser disponibilizada no modelo de Software como Serviço (SaaS), portanto qualquer custo de licença de software de terceiros será de responsabilidade da Contratada.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

2. REQUISITOS TÉCNICOS (...)

2. LINGUA

2.1. O sistema deve estar totalmente disponível em português do Brasil

2.2. Prover interfaces, telas, menus totalmente em língua portuguesa (Brasil)

2.3. Possuir funcionalidade de multi-idiomas, possibilitando que a interface seja traduzida pelo menos para os idiomas

Inglês e Espanhol

Não acatado. Já está previsto no Termo de Referência a disponibilização da solução tecnológica no idioma português padrão Brasil.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

2. REQUISITOS TÉCNICOS (...)

3. DOCUMENTAÇÃO

3.1. A contratada deve oferecer manuais de instalação do produto em português do Brasil

3.2. A contratada deve oferecer manuais de utilização do produto em português do Brasil

3.3. A contratada deve oferecer manuais de atualização do produto em português do Brasil

Não acatado. Está prevista a disponibilização da solução tecnológica no idioma português padrão Brasil, assim como os treinamentos e respectivo material de apoio. A opção de contratação pelo modelo de Software como Serviço (SaaS) dispensa qualquer atividade relacionada à instalação e/ou atualização do produto.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

2. REQUISITOS TÉCNICOS (...)

4. REQUISITOS TÉCNICOS E ARQUITETURA

4.1.1. Deve ser 100% baseada em web

4.1.2. Possuir integração entre todos os módulos componentes, isto é, não ser necessária importação e exportação manuais (ou seja, com intervenção do usuário) de dados, uma vez que a integração deve garantir que uma única transação desencadeie todas as ações a ela pertinentes, tornando os processos de negócio totalmente integrados entre si

4.1.3. Permitir que os componentes Web do sistema possam ser executados em ambiente seguro (HTTPS - HyperText Transfer Protocol Secure)

4.1.4. Permitir o uso de criptografia 256 bits SSL/TLS, a partir do momento da autenticação do usuário e durante toda a sessão estabelecida

4.1.5. Deve possuir um ambiente unificado para construção, execução, integração e monitoramento dos processos em tempo real

4.1.6. Deve ser homologado para assinatura via Certificação Digital

4.1.7. Realizar a persistência dos estados dos processos em base de dados relacional, registrando automaticamente o estado de execução das atividades e eventos

4.1.8. A solução deve possuir componentes (interfaces) para possibilitar que aplicações de terceiros abram novas instâncias de processos ou executem uma instância de processo, por meio de WebServices.

4.1.9. A ferramenta deve permitir que suas funcionalidades sejam estendidas/complementadas, através de JavaScrips.

4.1.10. A solução de possuir componente (APIs) que facilitem a customização da ferramenta, simplificando e padronizando os desenvolvimentos de JavaScripts.

Não acatado. Os requisitos sugeridos já estão contemplados no Termo de Referência, como requisitos de usabilidade, segurança, gestão do atendimento e geração de formulários.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5. REQUISITOS FUNCIONAIS

5.1. DESENHO DO PROCESSO DE NEGÓCIO

5.1.1. Deve possuir modelador gráfico de processos de negócio, compatível com a notação BPMN versão 2.0

5.1.2. Deve permitir a definição de processo de forma gráfica e amigável ao usuário. Facilidade de desenho através de

interface gráfica com “Drag-And-Drop”, sem codificação

5.1.3. Deve possibilitar a geração automática do modelo de processo a partir do diagrama (desenho)

5.1.4. Prover a funcionalidade de seleção dos elementos gráficos a partir de uma paleta ou barra de ferramentas

5.1.5. Possibilidade de importação do diagrama de outros modeladores por meio do padrão XPDL

5.1.6. Possibilidade de exportação do desenho em vários formatos de imagens, PDF e HTML

5.1.7. Deve possuir validações validar dos modelos de processos, alertando o usuário sobre os erros encontrados

5.1.8. Permitir desenhar as regras de negócio

5.1.9. Permitir que as atividades de modelagem sejam integralmente realizadas por profissionais sem formação técnica em Tecnologia da Informação, através de interfaces amigáveis e orientadas à gestão do processo

Acatado parcialmente. O Termo de Referência prevê a definição do fluxo de trabalho interno do serviço em notação BPMN ou similar. Foram acatadas as sugestões que permitem a modelagem do fluxo de trabalho com recursos adicionais de forma gráfica e amigável.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.2. AUTOMAÇÃO DO PROCESSO DE NEGÓCIO

5.2.1. A automação dos processos deverá obedecer ao modelo de processos desenhado pelo analista na ferramenta

5.2.2. Permitir que as tarefas sejam distribuídas com equilíbrio ou automaticamente roteadas usando critérios de competência, carga ou outros parâmetros personalizados

5.2.3. Deve permitir criação de funções que façam distribuição das transações para os usuários de acordo com informações do processo

5.2.4. Deve ser flexível a ponto de criar fluxos para várias áreas/departamentos da organização (por exemplo: administrativo, jurídico, financeiro, contratos, etc.)

5.2.5. Permitir que uma atividade possa ser executada mais de uma vez durante o processo, através de parametrização de laços de repetição ou construção de fluxos de retrabalho

5.2.6. Permitir que a lógica e comportamento do processo sejam estendidos através de linguagem de programação

5.2.7. Durante o desenvolvimento, permitir que os processos e serviços envolvidos, sejam executados e simulados com todas as suas características e definições, permitindo que o Gestor/Desenvolvedor do Processo assuma as mesmas definições dos Atores responsáveis por cada uma das etapas, permitindo a geração de instâncias dos processos para realização de testes e validações por completo antes da sua publicação.

5.2.8. Deve ter a capacidade de transferir tarefas para outros usuários

5.2.9. O sistema deve permitir avançar etapas dos processos com informações de outros sistemas / recursos externos / processos

5.2.10. Deve permitir o cancelamento de uma instância de processo, a qualquer momento, pelo gestor do processo

5.2.11. Permitir a definição de comportamentos dos processos através de propriedades dos componentes e não de codificação ou programação

5.2.12. Não necessitar a utilização de BPEL, XPDL ou qualquer outra linguagem intermediária para execução de processos, orquestrando as atividades no motor de workflow diretamente a partir do desenho realizado na ferramenta

5.2.13. Deve permitir o cadastro de feriados, cujas datas serão desconsideradas no controle de prazo do fluxo

5.2.14. Permitir clonagem de processos

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Funcionais - Gestão do Atendimento, Gerador de Formulários e Notificações. O Termo de Referência prevê a definição do fluxo de trabalho interno do serviço em notação BPMN ou similar.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.2.15. Permitir a importação e exportação de um processo e todos seus elementos, ou seja, criar um processo novo a partir de um já existente

5.2.16. Contar com serviço de instalação que agregue automaticamente todos os componentes necessários para a transferência do processo criado no ambiente de desenvolvimento para os ambientes de homologação e produção

5.2.17. Permitir a clonagem de uma tarefa do processo e as propriedades dos campos

5.2.18. Deve nativamente efetuar gerenciamento das versões dos processos

5.2.19. Permitir que múltiplas versões de processos coexistam no mesmo ambiente, sendo apenas uma permitirá a criação de novas instâncias

5.2.20. Permitir que as instâncias de processos que tenham sofrido alterações, se comportem da seguinte forma:

• Seguir de acordo com a versão anterior do processo, caso já tenham sido iniciados

• Seguir de acordo com a nova versão, caso não tenham sido iniciados"

5.2.21. Possuir a funcionalidade de hibernar uma tarefa/atividade do processo por um tempo determinado

5.2.22. Deve permitir o envio e-mails de notificação de nova atividade/pendência atribuída a um usuário

5.2.23. Possibilidade de parametrização de envio de aviso por e-mail durante o recebimento de uma atividade (follow-up)

5.2.24. Deve possuir um mecanismo que permita iniciar uma instancia de um processo quando um e-mail chegar em uma caixa pré-definida

5.2.25. Deve possuir mecanismos para permitir que processos sejam iniciados de forma manual /agendada / por e-mail / por outros processos / sistemas externos

/ através de mídia social

5.2.26. Possibilidade de parametrização de envio de aviso por e-mail para os gestores de processo quando da ocorrência de tarefas em atraso (escalonamento) de forma parametrizada sem necessidade de código.

5.2.27. Permitir definir, em cada etapa humana do fluxo de trabalho, um direcionador do fluxo, caso um prazo configurado se expire e nenhuma ação tenha sido tomada

5.2.28. Realizar a computação de contratos de nível de serviço (SLAs) parametrizados e vinculados às tarefas/atividades, na medida em que são executadas

5.2.29. Possibilitar o computo do tempo no formato que atenda horas, minutos e segundos (hhh:mm:ss), permitindo um controle mais preciso do tempo

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.2.30. Permitir, a partir da ocorrência de desvios nos prazos de execução, o disparo de ações de contingência, parametrizadas no desenho do processo, tais como, notificação do líder e troca de responsabilidade da atividade

5.2.31. Permitir paralelismo nos fluxos (duas ou mais etapas executadas em paralelo)

5.2.32. Permitir o encaminhamento simultâneo de um mesmo processo para vários usuários e funções previamente cadastradas.

5.2.33. Contar com ferramenta para criação e edição de formulários Web de forma visual, sem a necessidade de programação

5.2.34. Possibilitar a inclusão de normas, procedimentos e outras orientações nas telas do usuário final

5.2.35. Conter minimamente os seguintes componentes: entrada de texto em uma linha, entrada de texto em múltiplas linhas, entrada de valores numéricos, entrada de moeda, tabela, caixa de seleção simples, caixa para upload de arquivo

5.2.36. Deve possibilitar a inclusão de campos do tipo tabela, dentro do próprio formulário, com paginação e sem limite total de linhas

5.2.37. Deve permitir campos de preenchimento obrigatório / opcional / somente leitura por atividade e sem codificação

5.2.38. Deve permitir campos com indicação de valor padrão (default);

5.2.39. Deve possuir recurso de validação de campos

5.2.40. Deve possuir recurso de preenchimento com base em tabela de banco de dados

5.2.41. Permitir a extensão dos comportamentos nativos com código desenvolvido em linguagem javascript

5.2.42. Contar com controles de eventos realizados do lado cliente que possam ser processados com tecnologia AJAX, ou seja, sem novo carregamento de página

5.2.43. Contar com controles de eventos baseado em lógica “Server-side” ou “Client-side”

5.2.44. Contar com controles de visibilidade associados a cada controle, alterados dinamicamente

5.2.45. Possibilitar a inclusão de textos de ajuda específicos a cada campo do formulário

5.2.46. Possuir um ambiente WEB para consultar e gerenciar bibliotecas Java, JavaScript e Conexões com Banco de dados.

5.2.47. O sistema deve possibilitar as mensagens apresentadas após a aprovação/reprovação de um processo, possam ser configuradas

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.3. EXECUÇÃO DO PROCESSO DE NEGÓCIO

5.3.1. O sistema deve possuir uma Área de Trabalho (ou Mesa Virtual), onde o usuário receberá suas tarefas, e deve ser apresentada de acordo com os perfis de acesso definidos

5.3.2. A área de trabalho deverá identificar de forma visual os processos que já deveriam ter sido tratados e que continuam naquela pendentes após expirado o prazo

5.3.3. Deve ter a possibilidade de filtrar, ordenar e pesquisar lista de tarefas

5.3.4. Deve possuir área do usuário composta de pelo menos com as opções de Processos pendentes, Processos abertos pelo usuário, Processos para os quais o usuário é gestor, Painel de Gráficos, Diretórios e arquivos

5.3.5. Deve contar com portal de usuário web contendo uma lista de tarefas que possa ser personalizada, com campos que incluam dados de negócio

5.3.6. Permitir que o usuário final acompanhe o histórico completo de execução de tarefas, no mesmo portal

5.3.7. Permitir que o usuário final realize a visualização de um ponto específico do modelo de processo a partir da sua execução e monitoramento, ou seja, a partir do processo em tempo de execução, visualizar em que ponto do fluxo do processo se encontra graficamente

5.3.8. Possuir rastreabilidade de informações das instâncias dos processos de forma a conhecer, etapas já realizadas, executor e tempo de execução de cada etapa, etapa em que a instância esta parada e tempo consumido ou tempo de execução de toda a instância. A rastreabilidade e as informações de cada etapa, devem ser disponibilizadas em formato texto e também em formato gráfico (BPMN), que apresentará visualmente o percurso do Processo percorrido e a percorrer.

5.3.9. Permitir obter o registro de todos os dados de cada instância de todo o processo, tais como: data/hora de início e fim das atividades, autor que executou a atividade, início e conclusão do processo, entre outros

Acatado parcialmente. Os requisitos pertinentes se encontram definidos no Item Requisitos Funcionais - Gestão do Atendimento, Gerador de Formulários e Notificações. Foram acatadas as sugestões que permitem a organização e gestão do atendimento com a configuração do calendário útil de trabalho da equipe.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.3.10. Permite consulta de processos com possibilidade de exportação para planilha do Microsoft Excel

5.3.11. Permitir a criação, implantação e gerenciamento de uma estrutura hierárquica e categorizada de processos que permitam organizar a visão corporativa dos processos

5.3.12. O sistema deve permitir a categorização de processos e aplicações externas.

5.3.13. Deve possibilitar anexar arquivos (documentos) à instância do processo, com base nos documentos armazenados no sistema, e/ou documentos locais do usuário

5.3.14. Ao acessar um processo, o sistema deve exibir eventuais mensagens/avisos vinculados ao processo

5.3.15. Possibilitar a assinatura digital de etapas/tarefas do processo

5.3.16. Possui funcionalidade na caixa de entrada de ações em lote nas instâncias como aprovação, rejeição e abertura múltipla de processos.

5.3.17. Possuir a funcionalidade para que o próprio usuário indique seu período de férias e um substituto, onde todas as atividades atribuídas a ele nesse período sejam redirecionadas ao substituto indicado

5.3.18. Permitir que o administrador do processo consulte as instâncias e estados dos processos e realoque atividades para outros usuários, se necessário

5.3.19. Deve ser possível a materialização de uma peça eletrônica específica ou de todo o processo, com a impressão de todas as peças (conteúdo dos arquivos anexados) que o compõem

5.3.20. Permitir a exportação dos relatórios/listagem dos processos nos formatos xml, csv, xls, txt e pdf

5.3.21. Permitir a exportação de um formulário (tarefa) em pdf.

5.3.22. Oferecer interface que permita a visualização do Fluxo de Trabalho

5.3.23. O sistema deve possibilitar a visualização gráfica do processo, exibindo o momento atual do processo, todas as tarefas executadas e as tarefas que estão por vir

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.4. MONITORAMENTO DO PROCESSO DE NEGÓCIO

5.4.1. O módulo de monitoramento deve gerar gráficos em vários formatos bem como acompanhar um processo passo a passo identificando as atividades executadas e as que estão por ocorrer

5.4.2. Deve possibilitar nativamente, sem necessidade de codificação, a criação de gráficos no mínimo os formatos Coluna, Linha, Barra e Pizza por qualquer usuário. Para sua construção, os gráficos, poderão usar qualquer dado de um Processo e ser salvos em um Dashboard e/ou compartilhado com outros usuários.

5.4.3. O modulo de monitoramento deve ser integrado a mesma interface de visualização de tarefas

5.4.4. Possuir uma área de análises com estatísticas, composta no mínimo de informações de status dos processos, status das etapas, processos por usuário, atrasos por usuário e tempo médio de atraso

5.4.5. Deve possuir uma área de gráficos com possibilidade de criar gráficos personalizados, gráficos pré-definidos, compartilhamento de gráficos, gráficos a partir de planilhas e gráficos a partir de classes Java

5.4.6. Deve possuir uma área de trabalho que reúna os gráficos criados e salvos, possibilitando a criação de segmentos/assuntos de interesse (Dashboard)

5.4.7. Deve possuir painel de atrasos com exibição das etapas e processos em atraso

5.4.8. Deve possuir função de inventário com exibição de informações sobre o ambiente, processos e usuários

5.4.9. O sistema deve possibilitar o acompanhamento do status da instância do processo

5.4.10. Possuir funcionalidade onde o usuário ou gestor possa verificar de forma gráfica, o fluxo percorrido pelo processo até o momento

5.4.11. Quantidade e porcentagem de transações distribuídas por etapa do processo

5.4.12. Gráfico de distribuição das transações do processo de acordo com o status (no prazo/em atraso)

5.4.13. Deve permitir a visualização e o acompanhamento de processos em todo o seu ciclo de vida (incluindo as instâncias já finalizadas)

5.4.14. Permitir a criação de outros painéis de desempenho personalizados, com visualizações gráficas e tabulares combinadas e filtros que se apliquem a dados de negócios combinados com dados de processos

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Funcionais - Gestão do Atendimento.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.5. AUTENTICAÇÃO, PERMISSÕES E AUDITORIA

5.5.1. Autenticação integrada com LDAP/AD em dois modos: Automática, usando as credenciais do usuário logado no Windows e Manual, por digitação das credenciais do usuário na tela de login

5.5.2. Deverá exigir que o usuário seja devidamente identificado e autenticado antes que este inicie qualquer operação no sistema

5.5.3. Deverá permitir acesso às funções do sistema somente a usuários autorizados e sob controle rigoroso da administração do sistema a fim de proteger a autenticidade dos conteúdos armazenados

5.5.4. Deve ativar e desativar de recursos e funcionalidades de acordo com as permissões de acesso dos usuários

5.5.5. Permitir o controle de acesso através da definição de perfis de acesso, de acordo com as funcionalidades da aplicação, nas formas de leitura e gravação e somente leitura de um determinado processo, dependente da autorização

5.5.6. Possibilitar perfis de acesso ao sistema com base em permissões por usuário, por grupo de trabalho e por papéis/funções

5.5.7. Suportar definições com múltiplos níveis de modo que um mesmo usuário possa participar de vários grupos

5.5.8. Permitir a participação de usuários ou grupos de usuários em vários processos de trabalho simultaneamente

5.5.9. O sistema deve permitir a alocação flexível de participantes a tarefas (por meio de grupos e/ou funções)

5.5.10. Somente administradores autorizados devem ser capazes de criar, alterar, remover ou revogar as permissões associadas a usuários, grupos ou funções

5.5.11. Prover ferramenta de auditoria, com visualização de todas as atividades executadas pelo usuário (login, abertura de arquivos, execução atividades, entre outros)

5.5.12. Trilha de auditoria (rastreabilidade) por processo, contendo minimamente a data, hora, operação e responsável pela ação

5.5.13. Toda exceção levantada pela aplicação deve ser registrada em log

5.5.14. Deve permitir a configuração do tamanho do arquivo de logs e quantidade de arquivos de log

5.5.15. Realizar automaticamente o encerramento da sessão do ambiente do usuário final (usuário de negócio) após um limite parametrizável de tempo de inatividade

5.5.16. Deve permitir que o usuário utilize a solução de qualquer computador, exigindo assim que as configurações do usuário e informações da fila de tarefas estejam armazenadas no servidor

5.5.17. Deve possuir a funcionalidade de recuperação de senha de forma automática, sem a necessidade de suporte técnico

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Técnicos de Segurança, Interoperabilidade e Autenticação/Autorização.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.6. INTEGRAÇÕES

5.6.1. A Solução deve permitir a integração com outros sistemas e/ou base de dados através de classes de integração Java

5.6.2. A Solução deve permitir robô de execução contínua com possibilidade de agendamento de parada

5.6.3. A Solução deve permitir a integração com outros sistemas e/ou base de dados através API JDBC

5.6.4. A Solução deve permitir a integração com outros sistemas e/ou base de dados através de Web Services (REST, SOAP, HTTP Request e RPC – Remote Procedure Call)

5.6.5. A solução deve permitir a integração com sistemas legados através de serviços SOA

5.6.6. A solução deve permitir a integração com mídias sociais, e com outros processos, mesmo em ambientes distintos

5.6.7. Integração nativa com LDAP

5.6.8. Integração nativa com MS Active Directory

5.6.9. Integração com bases de dados Oracle, Microsoft SQL Server, MySQL, Informix via JDBC

5.6.10. Permitir o cadastro de aplicações externas (web) que serão exibidas em um menu específico do sistema (Mashup)

5.6.11. Permitir que os processos modelados sejam expostos como Web Services nativamente

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Técnicos de Interoperabilidade.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.7. MOBILIDADE

5.7.1. Deve poder ser acessado via dispositivos móveis nativamente para iOS (App) e por meio da web para outras plataformas

5.7.2. Possibilitar o envio de notificações e atividades pendentes por e-mail

5.7.3. Possibilidade de aprovação de tarefas por e-mail

5.7.4. Possibilidade de aprovação de tarefas por dispositivos móveis (web e/ou dispositivo móvel)

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Técnicos de Usabilidade.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.8. COLABORAÇÃO

5.8.1. Permitir a troca de mensagens entre usuários ou grupos de usuários num processo de trabalho

5.8.2. Permitir o envio de mensagens vinculadas a um determinado processo

5.8.3. Permitir que mensagens sejam respondidas, dando continuidade a uma conversa

5.8.4. Permitir o envio de mensagens para o gestor do modelo e último aprovador

5.8.5. Permitir que mensagens sejam arquivadas

5.8.6. Permitir o controle de mensagens enviadas, restringindo a visualização ao destinatário, ou a todos os participantes do processo

5.8.7. Possibilitar a pesquisa de mensagens, incluindo filtros por usuário, status e conteúdo da mensagem

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Funcionais - Gestão do Atendimento e Notificação.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.9. GESTÃO DE DOCUMENTOS (ECM)

5.9.1. Oferecer funcionalidade de gestão de documentos com as seguintes características:

• Upload de arquivos e inclusão de arquivos

• Exclusão de arquivos

• Adição e remoção de diretórios

• Pesquisas com/sem uso de filtros

• Controle de permissão de acesso"

5.9.2. Manter registro (log) das operações realizadas para fins de auditoria e verificação de fraudes por prazos indeterminados

5.9.3. Possibilitar e controlar o versionamento dos documentos/arquivos inseridos

5.9.4. Deve ser possível a importação de outros tipos de documentos (figuras, arquivos texto, arquivos do Microsoft Office e Open Document File)

5.9.5. Deve permitir que todos os documentos assinados digitalmente possuam um carimbo (imagem/marca d´água), a numeração da página, e a identificação de quem realizou a assinatura do documento

5.9.6. A visualização dos documentos eletrônicos deve ser realizada no formato de uma árvore de documentos

5.9.7. Permitir que o usuário final crie novas pastas, filtradas de acordo com critérios parametrizados

5.9.8. Permitir iniciar processos a partir de documentos adicionados

5.9.9. Permitir a criação de categorias de documentos

5.9.10. Permitir a criação de templates (modelos) de documentos

5.9.11. Permitir o controle de check-in e check-out de documentos

5.9.12. Possibilidade de definir marca d´água por template, para que seja inserido automaticamente nos documentos que foram adicionados no sistema

5.9.13. Permitir que determinados documentos sejam anexados no processo mesmo antes da assinatura digital

5.9.14. Cada documento poderá ser configurado para ser assinado por mais de uma pessoa, não restringindo a possibilidade de assinatura ao funcionário que elaborou a peça, mas permitindo que seus superiores confiram e assinem a peça digitalmente de forma simultânea

5.9.15. Permitir o controle de processos, documentos e expedientes de forma totalmente eletrônica, com assinatura digital e verificação da assinatura digital legalmente reconhecidas em suas peças, sejam elas elaboradas ou anexadas, o que obriga a total aderência à MP 2.200/2001 e às normas e padrões definidos pelo ICP-Brasil.

5.9.16. A expedição de documentos utilizará um cadastro de modelos de textos que permitirá a emissão do documento de forma automática com a substituição de campos por valores do próprio processo ou com a complementação de lacunas em campos específicos do texto

5.9.17. Os documentos importados pelo sistema e cujo formato original seja estruturado (por exemplo, documentos padrão Office, como textos, planilhas e apresentações de slides) terão seu conteúdo indexado a partir da ferramenta responsável pela sua conversão em PDF, embutida na aplicação

Não acatado. Os requisitos pertinentes para manipulação de documentos (download/upload) se encontram definidos no Item Requisitos Funcionais - Construção de Formulários.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.9.18. Permitir a pesquisa de documentos pelas informações básicas do arquivo, como nome, autor, data de criação

5.9.19. Permitir a pesquisa de documentos pelas informações nos campos do template a qual o documento pertence

5.9.20. Permitir a pesquisa no conteúdo dos documentos indexados (full text search)

5.9.21. Suportar a pré-visualização (preview) de documentos dentro do próprio sistema sem a necessidade de armazená-los localmente

5.9.22. Permitir que os arquivos anexados sejam recuperados através de serviços externos, fora do contexto do processo

5.9.23. Deve ser possível a configuração de campos personalizados para a cada tipo de documento a ser cadastrado, de forma a indexar de forma mais coerente os diferentes tipos de documentos protocolados

5.9.24. Deve ser possível a materialização de uma peça eletrônica específica ou de todo o processo, com a impressão de todas as peças que o compõem.

5.9.25. Os documentos expedidos terão controle da tramitação da mesma forma que os processos e protocolos, com suporte a remessas entre os diversos órgãos, juntada de documentos anexos (gerados pelo sistema mediante assinatura digital ou advindos de um processo de digitalização)

5.9.26. Deverá ser possível a recuperação de um processo através de uma pesquisa textual pelo conteúdo de suas peças, a partir da indexação de seu conteúdo

5.9.27. Possibilitar exportação para arquivo pdf dos documentos gerados eletronicamente, com certificado de autenticidade

5.9.28. Deve ser possível baixar vários arquivos simultaneamente

5.9.29. Deve ser possível exportar uma consulta de arquivos (listagem), nos formatos xls e pdf

5.9.30. Deve ser possível conceder permissões por template

5.9.31. Deve possuir a funcionalidade de rendition (versões do documento em um formato diferente), que será disponibilizado a usuários que não tem permissão completa no documento

5.9.32. Deve possuir a funcionalidade de Dossiê, onde um conjunto de templates é definido como sendo um Dossiê, permitindo a realização de buscas unificadas por campos pré- definidos

5.9.33. O sistema deve possuir a funcionalidade de consistência ao incluir ou editar um documento, fazendo a conferência dos campos definidos, e evitando assim que haja duplicidade de documentos

Não acatado. Os requisitos pertinentes para manipulação de documentos (download/upload) se encontram definidos no Item Requisitos Funcionais - Construção de Formulários.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

5.10 MÓDULO DE CAPTURA

5.10.1. A solução deve possuir módulo de digitalização de documentos integrado ao ECM

5.10.2. A ferramenta deve possuir a mecanismos de reconhecimento ótico de caracteres – OCR

5.10.3. Os arquivos resultantes de processos de digitalização, devem ter o seu conteúdo indexado a partir da ferramenta de OCR embutida na aplicação.

5.10.4. A ferramenta deve possuir a funcionalidade de associar os documentos digitalizados a templates, já com a possibilidade de preenchimento dos campos associados

5.10.5. Suporte de imagens em branco e preto, colorido e tons de cinza

5.10.6. Suporte dos principais scanners e multifuncionais de mercado, através de driver ISIS/TWAIN

5.10.7. Adicionar e/ou remover paginas de documentos que foram digitalizados

5.10.8. As paginas digitalizadas devem poder ser rotacionadas (direita, esquerda, 180º, espelhar e inverter)

5.10.9. As paginas digitalizadas devem poder ser recortadas

5.10.10. Controle dos níveis de acesso aos templates para associação dos documentos digitalizados

5.10.11. A ferramenta deve possibilitar pesquisa Full Text Search, nos documentos texto que foram digitalizados.

Não acatado. Os requisitos propostos não possuem relação com o objeto do Termo de Referência.

Anexo II

REQUISITOS TÉCNICOS E FUNCIONAIS DA SOLUÇÃO TECNOLÓGICA (...)

6. SUPORTE TÉCNICO

6.1.1. A contratada deve oferecer suporte técnico ao sistema com abertura de Chamados por Telefone, Web ou E-mail, de segunda a sexta-feira, considerando o horário das 9:00 as 17:00, exceto feriados

6.1.2. A contratada deve oferecer suporte técnico em Português do Brasil, com equipe no Brasil

6.1.3. A contratada deve oferecer canal eletrônico web para abertura e controle dos chamados abertos

Não acatado. As regras para central de atendimento do fornecedor da solução tecnológica estão definidas no Parágrafo

8.6 do Termo de Referência.

Anexo II, 1.

CHAT:

Permite ao atendente envolver outros atendentes na demanda, inclusive para interação “on-line” com o cidadão.

Subsituir para: Permite ao atendente envolver outros atendentes na demanda por meio de encaminhamento de

mensagem, inclusive para interação “on-line” com o cidadão.

O chat por definição é entre 2 pessoas: cidadão e antendente. A base de conhecimento deve permitir diferentes perfis de visualização do conteúdo.

Não acatado. O software deverá permitir que o atendente atual insira um outro atendente à demanda para que este também possa interagir com o cidadão.

Anexo II, 1.

BASE DE CONHECIMENTO

Acrescentar: Incluir capacidade de consulta na base de conhecimento com visibilidade diferenciada para distintos perfis de acesso.

O chat por definição é entre 2 pessoas: cidadão e antendente. A base de conhecimento deve permitir diferentes perfis de visualização do

conteúdo.

Não acatado. As funcionalidades pertinentes a esta característica estão definidas no Termo de Referência.

Anexo II, 1.

Interface de Configuração: (...) Configura fluxo de fases, estabelece prazos e define metodologia de atendimento (especificação da equipe de atendimento, envolvimento de outras equipes, balanceamento dos recursos humanos etc.).

Interface de Configuração: (...)

Configura fluxo de fases, estabelece prazos e define metodologia de atendimento (especificação da equipe de atendimento, envolvimento de outras equipes, balanceamento dos recursos humanos).

O etc impossibilita a definição de escopo/preço.

Acatado. Este "etc." será retirado do texto.

Anexo II, 1.

Interface da Sociedade (...)

Apresenta graficamente alertas por fase (cores, marcações etc.) contendo um descritivo da pendência e orientação do ajuste necessário.

Interface da Sociedade (...)

Apresenta graficamente alertas por fase contendo um descritivo da pendência e orientação do ajuste necessário.

O etc impossibilita a definição de escopo/preço.

Não acatado. O conteúdo entre parênteses, neste caso, é útil para explicitar o requisito por meio de exemplos.

Anexo II, 1.

Interface de Configuração: (...) Configura integração dos campos do formulário com consulta de informações à bases de dados externas.

Interface de Configuração: (...)

Possibilita a configuração integração dos campos do formulário com consulta de informações à bases de dados externas.

Isso é um recurso da plataforma e a execução depende das OS.

Acatado. O texto será aprimorado para melhorar o entendimento do requisito.

Anexo II, 1.

GERADOR DE FORMULÁRIOS - INTERFACE DE CONFIGURAÇÃO (...)

Desenvolvimento de formulários de maneira gráfica e por meio de recursos de arrastar e soltar (Drag & Drop) sem necessidade de programação.

GERADOR DE FORMULÁRIOS - INTERFACE DE CONFIGURAÇÃO (...)

Desenvolvimento de formulários por meio de interface gráfica sem necessidade de programação.

O objetivo é eliminar a necessidade de programador. Soluções mistas (visuais e cadastrais) podem ser mais eficientes e extensíveis. Nem tudo é possível fazer via Drag & Drop.

Acatado. O texto será ajustado no Termo de Referência.

Anexo II, 1.

GERADOR DE FORMULÁRIOS - INTERFACE DE CONFIGURAÇÃO (...)

Acréscimo: A ferramenta deverá permitir a criação de formulário com vários níveis de agregação 1-N e 1-N-N

É muito recorrente a necessidade de cadastrar informações estruturadas. Por exemplo, em um pedido de bolsa, uma família pode precisar cadastrar todos os dependentes e para cada um deles uma lista de vacinas aplicadas. Em geral, o edital é bem claro quanto o que deseja de funcionalidade, mas detalha muito pouco as necessidades quanto a capacidade de montagem de formulário. Essa funcionalidade é fundamental para ampla aplicação da solução.

Acatado. O texto será ajustado no Termo de Referência.

Anexo II, 1.

GERADOR DE FORMULÁRIOS - INTERFACE DE CONFIGURAÇÃO (...)

Acréscimo: Permitir criar novo tipos de campo para reuso em vários formulários.

Por exemplo, viabilizar definir uma única vez um campo tipo telefone ou CPF. Havendo necessidade de evolução, seria necessário alterar apenas o componente padrão em vez de alterar todos os formulários.

Não acatado. As funcionalidades pertinentes já estão descritas no Termo de Referência.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

2. REQUISITOS TÉCNICOS (...) Requisitos do Ambiente em Nuvem

1. Possuir oferta da solução no modelo SaaS, oferecendo as mesmas funcionalidades, aplicabilidades e métricas que o modelo padrão, não havendo necessidade de compra definitiva da solução, instalação ou aquisição de infraestrutura;

2. A oferta em SaaS deve ser certificada em ISO 27001, norma padrão para sistema de gestão da segurança da informação, publicado em 2005 pela Organização Internacional de Padronização;

3. A instância da solução hospedada em SaaS deverá ser criada, mantida e gerenciada pela própria empresa formado por uma equipe especializada e por administradores da aplicação/ solução, não podendo ser realizada por instituições terceiras;

"4. O gerenciamento do serviço da instância deve prover:

a. Gestão e solução de incidentes 24x7 para tickets Severidade Nível 1;

b. Gestão e solução de problemas recorrentes;

c. Gestão e manutenção dos serviços dos servidores que hospeda a instância tais como OS/VM, compliance, health check do ambiente e atualizações de patch e versões;

d. Alta disponibilidade (99.8%), sistema de disaster recovery (DR), backups diários hospedados em diferentes datacenters, no Brasil, e performance aceitável por parte do cliente;

e. Provisionamento automático da instância de produção: o ambiente de Desenvolvimento deve ser fornecido no momento da requisição;

f. Gestão de mudança."

5. O sistema deve suportar multi-línguas;

6. O sistema deve suportar uso por dispositivo móvel, com enquadramento visual e funcional ao perfil do dispositivo;

7. O cliente deverá poder executar quaisquer tipo de parametrização/ configuração da mesma forma que executaria na modalidade padrão de obtenção; "8. Os serviços abaixo poderão ser requisitados:

a. Logs;

b. Configuração de LDAP;

c. Migração: Desenvolvimento para Produção e Produção para Desenvolvimento;

d. Integração com e-mail do Ministério;

e. Instâncias adicionais, caso necessário."

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Não acatado. A solução tecnológica deverá ser disponibilizada no modelo Software como Serviço (SaaS), contemplando Acordo de Nível de Serviço. Os requisitos pertinentes se encontram previstos no item Requisitos Técnicos, a saber, requisitos de segurança, usabilidade e interoperabilidade.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

Requisitos de Inteligência

9. A solução deve ser capaz de classificar a prioridade das requisições de serviços baseados no humor/tom de escrita do problema relatado pelo usuário.

10. O Portal de Auto serviço deve ser capaz de sugerir em tempo real soluções para o problema que o usuário esta relatando na abertura de um chamado , classificando e realizando um ranking das soluções mais utilizadas com maior assertividade

11. A solução deve ser capaz de ter o real entendimento do problema do cliente e através de inteligência buscar alternativas de soluções na intranet (inclusive dentro de documentos) e internet, trazendo dessa forma as soluções mais relevantes através de um modelo de ranking baseado na relevância e na semântica

12. A solução deve ser capaz de usar uma combinação de algoritmos de busca e aprendizado de máquina para detectar "sinais, palavras chaves , etc." nos dados

13. A solução deve ser capaz de treinar um modelo de aprendizado de máquina baseado em resultados relevantes conhecidos e, em seguida, alavancar esse modelo para fornecer melhores resultados aos seus usuários finais com base em sua pergunta ou consulta

14. Permitir a customização da análise de texto utilizado na busca da base de conhecimento, aumentando a eficiência na procura.

15. Permitir aos administradores desenvolverem customizações específicas como taxonomias e listas de terminologia para serem utilizadas na base de conhecimento.

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Não acatado. As características em questão, referentes a ferramenta de portal, não são objeto do presente Termo de Referência.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

Requisitos de Interoperabilidade

16. Oferecer ambiente de Gestão das APIs e Serviços utilizados pelo ambiente Móvel, Painéis e Portais Web permitindo a definição de políticas de segurança baseadas no padrão OAuth 2.0.

17. Fornecer plataforma de Modelagem e Execução de Processos de Negócio baseado em padrão BPMN.

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Não acatado. Os requisitos pertinentes já estão definidos no Termo de Referência.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

Requisitos de Interoperabilidade

18. A autenticação da plataforma de gestão e execução de processos deve suportar o padrão SAML.

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Acatado. O requisito será incorporado ao Termo de Referência.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

Requisitos de Segurança

19. A solução de Modelagem e Execução de Processos deve suportar pelo

menos as seguintes funcionalidades de segurança: (A) encriptação de

comunicação baseada no padrão FIPS 140-2; (B) encriptação de dados no

banco de dados da solução; (C) IP Whitelist; (D) Suportar comunicação via

VPN com os sistemas corporativos.

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Técnicos de Segurança.

Anexo II, 2.

REQUISITOS TÉCNICOS (...)

Requisitos de Usabilidade

20. Permitir a criação de interfaces compatíveis com o uso em dispositivos

moveis tais como smartphones e tablets.

Em anexo nossas contribuições para fortalecer a arquitetura funcional da solução.

Não acatado. Os requisitos pertinentes se encontram definidos no Item Requisitos Técnicos de Usabilidade (responsividade da interface).

Anexo II, 2.1.

- prover mecanismos de identificação por geolocalização para uma melhor prestação de serviço e maior satisfação dos clientes.

Pedimos por favor detalhar quais funcionalidades de geolocalização são necessárias, cenário de utilização e aplicação.

Acatado. Aprimorada a especificação do subitem.

Anexo II, 2.3.

Requisitos de Segurança (...)

No Termo de Referência é mencionado que “a solução deverá ser mantida em território nacional para garantir a residência de dados”. Portanto gostaríamos de saber se existe a possibilidade de “quebrarmos” essa exigência, e então prosseguir com o processo.

Não temos ainda Data Centers em território nacional.

Não acatado. A solução tecnológica deve residir exclusivamente em território nacional, em conformidade com o documento "Boas práticas, orientações e vedações para contratação de Serviços de Computação em Nuvem" , vinculado à Portaria MP/STI nº 20, de 14 de junho de 2016, disponível no link: xxxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx/xx cumentos-e- arquivos/Orientacao%20servicos%20em%2 0nuvem.pdf

Anexo II, 2.3.

Requisitos de Segurança (...)

Realizar a análise e gestão de riscos de segurança de informação, conforme dispõe a Norma Complementar 04/IN01/DSIC/GSI/PR de 15 de fevereiro de 2013.

Requisitos de Segurança (...)

Realizar a análise e gestão de riscos de segurança de informação, conforme dispõe a Norma Complementar 04/IN01/DSIC/GSI/PR de 15 de fevereiro de 2013. A análise deve ter periodicidade mensal e deve ser apresentando um plano de gestão de riscos contendo: os riscos identificados, a assunção ou não do risco, as medidas tomadas e outras informações pertinentes

O que caracteriza a realização da análise de risco? Quais são os entregáveis? A norma fala apenas de atividades mas não fala de periodicidade da análise?

Acatado. O texto será ajustado no Termo de Referência.

Anexo II, 2.4.

Requisitos de Interoperabilidade: (...)

A solução tecnológica deverá oferecer autenticação por padrões Single sign-on (SSO), Lightweight Directory Access Protocol (LDAP) e Active Directory (AD).

Requisitos de Interoperabilidade: (...)

A solução tecnológica deverá oferecer autenticação por padrões Single sign-on (SSO), Lightweight Directory Access Protocol (LDAP) ou Active Directory (AD).

Um ou outro.

Não acatado. São necessários os dois tipos.

Anexo III

A coluna "A" dos itens não é usada no cálculo.

Então deve ser retirada

Acatado. A tabela será revista.

Anexo III, Item I

Como o pagamento é mensal por usuário ativo, então o preço por usuário deve ser dado em termos mensais. Sendo assim, o título da coluna E deveria ser "Valor Mensal por Usuário Governo Ativo". O Cálculo de F seria F = D x E X 12. Não sendo o caso, mudar o título para "Valor Anual por Usuário Governo". Dependendo da resposta anterior, a regra do edital "o valor unitário do Usuário Governo não pode ser maior que o dobro do valor unitário da USTA " é referente ao valor mensal ou anual? Melhor ajustar e esclarecer o texto. No item 7.20 também.

Acatado. A tabela será revista.

Anexo VIII

ESPECIFICAÇÕES TÉCNICAS DO BARRAMENTO DE SERVIÇOS

Seguindo a mesma modalidade de SaaS o barramento de serviços deve ser ofertado como PaaS (Platform as a Service).

Não acatado. O modelo de negócio do Barramento de Serviço é irrelevante para fins deste Termo de Referência.

Anexo VIII

A Solução Tecnológica deve suportar, pelos menos, os seguintes padrões de Web Services: - SOAP 1.1/SOAP 1.2; - WSDL 1.1/WSDL 2.0; - WS-Addressing ; - WS-Security; - WS-Working; - WS-Policy;

- MTOM/SwA; - XML/HTTP e

JSON/HTTP; - formatos REST.

A Solução Tecnológica deve suportar, pelos menos, os seguintes padrões de Web Services: - SOAP 1.1/SOAP 1.2; - WSDL 1.1/WSDL 2.0; - WS-Addressing ; - WS-Security; - WS- Eventing; - WS-Policy; - MTOM/SwA; - XML/HTTP e JSON/HTTP; - formatos REST.

As features listadas são tradução direta da página de features do WSO2 ESB 4.9.0 (xxxxx://xxxx.xxx0.xxx/xxxxxxx/XXX000/Xxxxxxxx), entretanto o padrão WS-Working não existe e trata-se de uma nomenclatura específica do WSO2 ESB para o padrão de WS-Eventing conforme já consta na página de features das versões mais novas (xxxx://xxx0.xxx/xxxxxxxx/xxx/xxxx/xxxxxxxx).

Acatado. O texto será ajustado no Termo de Referência.

Anexo XII

Corrigir a figura

O gráfico do fluxo está cortado.

Acatado. A figura será ajustada.

Document Metadata

Table of Contents

Contract

Document Metadata