PERGUNTAS E RESPOSTAS - CONSULTA PÚBLICA SOLUÇÃO INTEGRADA DE GESTÃO DE RECURSOS HUMANOS PARA O ESTADO DE MINAS GERAIS

(1)

GOVERNO DO ESTADO DE MINAS GERAIS

SECRETARIA DE ESTADO DE PLANEJAMENTO E GESTÃO

SUPERINTENDÊNCIA CENTRAL DE ADMINISTRAÇÃO DE PESSOAL

PERGUNTAS E RESPOSTAS - CONSULTA PÚBLICA

SOLUÇÃO INTEGRADA DE GESTÃO DE

RECURSOS HUMANOS PARA O

ESTADO DE MINAS GERAIS

PERGUNTAS

RESPOSTAS SEPLAG

1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

1) T.SOL.090 – A SOLUÇÃO deverá ser

disponibilizada junto ao manual do usuário, em português brasileiro, em cópias físicas e eletrônicas. Os manuais de usuários são gerados durante o projeto de implementação; portanto, entendemos que os manuais de usuários serão entregues ao

longo do projeto. Está correto o nosso

entendimento?

O entendimento está correto.

2) T.SOL.091 – A SOLUÇÃO deverá ser

disponibilizada junto ao manual técnico, em

português brasileiro, incluindo em formato

eletrônico, todos os seus componente

Os manuais técnicos de qualquer software de empresas internacionais são gerados em inglês e os técnicos de informática no Brasil não têm dificuldade com essa restrição. Assim solicitamos a aceitação dos manuais técnicos em inglês, visando aumentar a

competividade pela não inviabilização da

participação de fabricantes de software

internacionais no certame.

A sugestão será contemplada na versão final.

3) RESOLUÇÃO Nº 63 , DE 14 DE SETEMBRO DE

2011 da SEPLAG-MG

a. 4.2.4 Instruções de Execução dos

Para o 3º item (MDASS):

O Manual de Desenvolvimento e Aquisição de Sistemas Seguros não se aplica somente para

(2)

SERVIÇOS - h) Observar e respeitar as

instruções relacionadas aos

requerimentos de segurança de nível

2 contidas no Manual de

Desenvolvimento e Aquisição de Sistemas Seguros – MDASS, segundo RESOLUÇÃO Nº 63 , DE 14 DE SETEMBRO DE 2011 da SEPLAG-MG, disponível no sítio http://www.egov.mg.gov.br/Desenv olvimento_Seguro-63. b. 5.1.1 Requisitos Técnicos -

Especificamente em relação aos requisitos técnicos do grupo de Segurança e Acesso, a SOLUÇÃO deverá levar em consideração, além dos requisitos detalhados, todos os requerimentos de segurança de nível

2 elencados no Manual de

Desenvolvimento e Aquisição de

Sistemas Seguros – MDASS,

determinado segundo a RESOLUÇÃO Nº 63 , DE 14 DE SETEMBRO DE 2011 da SEPLAG-MG, e que se encontra

disponível no sítio

http://www.egov.mg.gov.br/Desenv olvimento_Seguro-63.

c.

O objeto da presente contratação consiste no fornecimento em caráter definitivo, não exclusivo, de licenças de uso de software para todos os ambientes computacionais previstos, com entrega do código fonte da SOLUÇÃO. Ou seja, não se trata

projetos de desenvolvimento de sistemas, mas também para a aquisição de ferramentas de mercado, como o próprio nome retrata. Reconhecemos que o documento estabelece uma série de requisitos voltados para atividades de desenvolvimento específico, mas muitas outras definições são aplicáveis ao projeto em questão.

Tomando como base o primeiro requisito detalhado, 3.3.2. Auditoria de Segurança, na página 54: exige-se que o sistema a ser fornecido possua a capacidade de registrar eventos que indicam violação de segurança e as falhas nos próprios eventos de auditoria também deverão ser registradas. Perceba que esta exigência se aplica perfeitamente a ferramentas adquiridas e customizadas.

Dessa forma, não entendemos ser uma exigência descabida e , em época de projeto serão excluídos apenas os itens não pertinentes ao escopo e natureza do objeto contratado.

(3)

de contratação de fábrica de software. Portanto, na aquisição de software de mercado não é razoável exigências sobre o processo de desenvolvimento. Os requisitos de segurança do software devem ser objetivamente definidos no Edital. À luz do exposto, solicitamos a exclusão dessas exigências.

4) Estamos avaliando as quase 300 páginas e identificando os pontos de atenção, porém existem diversos pontos que não conseguimos avaliar para chegarmos ao valor de nossa proposta.

Desta forma solicito a prorrogação do prazo para a próxima sexta-feira dia 20, para que tenhamos tempo hábil de concluir estas atividades.

O prazo foi prorrogado para o dia 19/12.

5) Cadastro único: Com a diversidade de tipos de servidores / dependentes e órgãos do Governo do Estado de Minas Gerais será fundamental que o novo sistema assegure que um servidor está presente com um único cadastro e este cadastro ligado com todos os seus vínculos.

Requisito atual:

F.GRH.316 - O SIGRH deve permitir o cadastro de vínculo de servidores (efetivos / estagiários /

comissionados / designados / contratados

temporários / prestadores de serviço) com o Governo de Minas Gerais, permitindo haver mais de um vínculo / lotações distintas (concomitante ou não) com registro funcional único, permitindo o registro de múltiplas admissões desses servidores, quando for o caso.

Sugestão de Requisito:

O SIGRH deve possuir um cadastro único de pessoas

(4)

que contemplem todos os servidores da

administração direta e indireta e seus dependentes, empregados públicos, terceirizados, inativos, pensionistas e entidades consignatárias. Nesse cadastro, mesmo que um servidor tenha vários vínculos com o Estado, não deve ser possível a inclusão em duplicidade de seus dados.

6) Criação de campos adicionais: Possibilitar a criação de outros campos, tantos quantos forem

necessários para recursos humanos e

processamento da folha de pagamento, até para suportar a migração dos sistemas legados.

Requisito atual: Não identificado.

O SIGRH deve possibilitar a criação de qualquer campo adicional com informações de dados pessoais, como também de dados funcionais que devem ter integração com o processamento da folha de pagamento.

A sugestão será parcialmente contemplada.

O SIGRH deve possibilitar a criação de campo adicional alfanumérico com informações de dados pessoais, como também de dados funcionais que devem ter integração com o processamento da folha de pagamento.

7) Opção de vencimentos: A solução deverá identificar no momento do cálculo se o servidor possui:

a. Opção de recebimento quando nomeado para cargo em comissão:

servidor titular de cargo

efetivo/função atividade e nomeado para o exercício do cargo em comissão ou designação. Neste caso a solução deverá gerar o pagamento com base nos dados do cargo

(5)

efetivo/função atividade, acrescido se for o caso, de determinadas parcelas remuneratórias do cargo

em comissão ou designação

exercida, a depender da opção escolhida pelo servidor:

b. Opção pelo símbolo do cargo comissionado: calcular os créditos financeiros das parcelas do cargo em comissão;

c. Opção pela diferença entre o cargo efetivo e o valor do cargo em comissão: gerar valor do cargo efetivo acrescido da diferença entre o cargo em comissão e o valor do cargo efetivo;

d. Opção pela gratificação equivalente a 30% (trinta por cento) do valor

correspondente ao símbolo

respectivo do cargo de provimento temporário: gerar valor do cargo efetivo acrescido do valor de 30% relativo ao símbolo do cargo em comissão.

O SIGRH deve efetuar os pagamentos das parcelas remuneratórias do servidor de acordo com a opção escolhida no momento de sua nomeação para cargo em comissão. Este pagamento deve ser efetuado

(6)

com base nos dados do cargo efetivo/função atividade, acrescido caso necessário, de verbas de remuneração do cargo em comissão ou designação exercida. 1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

8) Contracheque da Pensão Alimentícia: A

solução deve prever o cálculo dos valores devidos para fins de pensões alimentícias, descontos legais,

incidentes sobre as pensões, geração de

contracheque e crédito ao beneficiário.

O SIGRH deve garantir que os dependentes de pensão alimentícia receberão suas devidas verbas calculadas no processamento da folha de pagamento do servidor. Deve também efetuar a geração de contracheque individual para cada alimentando relacionado com o servidor processado.

9) Teste de conformidade (POC): A Prova terá duração máxima de 05 (cinco) dias úteis para a demonstração de até 100 (cem) requisitos funcionais e tecnológicos a serem selecionados aleatoriamente e divulgados no ato de convocação da Prova.

Duvidas:

Não está claro no edital se os requisitos dos sistemas de apoio podem estar contidos nos requisitos selecionados da POC. Os sistemas de apoio serão considerados como requisitos para a POC?

Comentários:

Esse trecho será reescrito de forma a não gerar interpretações divergentes.

Quanto ao item a:

O universo de requisitos que deverão ser atendidos nativamente será identificado apenas quando da publicação do edital, sendo, portanto, esses requisitos os passíveis de testes via prova de conceito.

Quanto ao item b:

Os sistemas de apoio não serão contemplados na prova de conceito, haja vista que é esperado que os

(7)

Com o cenários previsto para a POC, só saberíamos os requisitos a serem apresentados 2 dias antes do início da apresentação da POC, inviabilizando

qualquer tempo de preparo mínimo para

atendermos aos requisitos selecionados para apresentação.

Sugestões:

a. Definição dos 100 requisitos que serão apresentados na POC no edital,

viabilizando a preparação de

informações e configurações para apresentação;

b. Restringir a apresentação aos

requisitos do sistema “Core” de RH, não considerando os sistemas de apoio na apresentação;

c. Realizar testes diretamente pela CONTRATANTE e se possível com script de testes (com expectativa de

resultados esperados) para os

principais cenários que existem no estado de MG. Certamente este processo daria segurança para a

CONTRATANTE, que o sistema

atenderá os principais requisitos do Edital.

requisitos desses sistemas sejam completamente atendidos. Durante a recepção técnica das soluções de apoio serão conferidos tais requisitos, tendo em vista que são referentes a soluções amplamente parametrizáveis, não necessitando de customizações para atendimento ao modelo de RH proposto.

Quanto ao item c:

Os scripts de testes serão de uso interno da Comissão Técnica e serão usados para conduzir e subsidiar as decisões acerca da Prova de Conceito.

10) Incorporar a identidade visual do

contratante:

Requisito atual:

T.SOL.050 - A SOLUÇÃO deve permitir que a camada de apresentação possa incorporar a identidade

O requisito será mantido e detalhado, haja vista que a solução de RH será utilizada por todos os servidores do Estado e deverá seguir normas e padrões estabelecidos pela área de comunicação do Governo.

(8)

visual da CONTRATANTE.

Comentário:

O requisito está abrangente, pois não identifica o nível de incorporação da identidade visual, e pode gerar um custo adicional de customização do software, sem trazer nenhum benefício funcional para a CONTRATANTE.

Sugestão:

Retirar o requisito ou explicar o nível de adaptação esperado pelo CONTRATANTE.

11) Item: 5.1 - Sub Item: 5.1.1 - Grupo: Grupo Arquitetura Técnica

Requisito:

A SOLUÇÃO deve ser executável em processadores de arquitetura X86 (Intel e AMD) e MainFrame IFL (Integrated Facility for Linux), independente do número de processadores e núcleos.

Comentários/Sugestão:

Entendemos que a definição pelas plataformas

Intel/AMD e IBM/Mainframe restringe a

participação da proponente no que tange ao fornecimento de equipamentos.

...

Face ao exposto, solicitamos a SEPLAG que avalie remover essa restrição quanto a plataforma ofertada para garantir que os fornecedores possam escolher a solução que seja mais adequada e com melhor relação custo beneficio para o projeto em questão.

O objeto sob consulta não contempla a aquisição de equipamentos.

Os requisitos de infraestrutura tecnológica e sistema operacional foram definidos com base nas possíveis tecnologias disponíveis no ambiente da PRODEMGE.

(9)

Arquitetura Técnica

Requisito:

A SOLUÇÃO deve executável nos sistemas operacionais SO Linux Red Hat Enterprise V.5 ou superior (incluindo Linux em System Z) e Windows Server 2008 ou superior.

Entendemos que a definição pelas plataformas RedHat, zLinux e Windows 2008 restringe a participação da proponente no que tange ao fornecimento de equipamentos.

...

Face ao exposto, solicitamos a SEPLAG que avalie remover essa restrição quanto ao Sistema Operacional ofertado para garantir que os fornecedores possam escolher a solução que seja mais adequada e com melhor relação custo beneficio para o projeto em questão.

13) Item: 5.1 - Sub Item: 5.1.1 - Grupo: Segurança e Acesso

Requisito: A SOLUÇÃO deve permitir que o código do usuário e senha possam ser informados por outra aplicação através de uma API ou WEB SERVICE.

Essa tipo de funcionalidade pode gerar brechas de segurança e possíveis vazamentos de dados sensíveis como usuários/senhas. Existe algum requisito quanto ao trafego seguro dessas informações?

O requisito que trata de criptografia e tráfego seguro de informações é o T.SOL.088 (“A SOLUÇÃO deve suportar SSL (Secure Sockets Layer) 128 bits para criptografia do canal de transmissão de dados.”). A WSS (Web Services Security) é um dos possíveis padrões que possibilita a implantação do T.SOL.081 (“A SOLUÇÃO deve estar em conformidade com padrão X509 de certificados digitais.”). Portanto, apesar de não estar explicitamente citado, um padrão de segurança é requerido para a implantação do referido requisito.

(10)

Deverá ser feita a criptografia desses dados? Existe algum padrão de segurança (ex: wsisecurity) que as soluções devam atender?

na versão final. 1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

14) Item: 5.1 - Sub Item: 5.1.2.4 - Grupo: Grupo conexão a bancos de dados

Requisito:

A SEQD deve permitir conexão com o DB2 de maneira transparente para os usuários nomeados da SEQD, sem necessidade de utilização de software adicional à SEQD.

Qual a justificativa para não permitir a utilização de software adicional (plugin ou adaptador) para conexão ao DB2? A única empresa que possui conectores nativos (próprios) para DB2 é a IBM e essa exigência limita a participação a apenas um fornecedor. Solicitamos, respeitosamente, que esse requisito seja revisado e que informe apenas" que a solução SEQD deve permitir a conexão com o DB2 de maneira transparente aos usuários nomeados do SEQD."

O requisito será reescrito de forma a ficar mais clara a possibilidade de uso de software adicional (plugin ou adaptador) para conexão ao DB2.

15) Item: 5.1 - Sub Item: 5.1.2.4 - Grupo: Grupo Funcionalidades Básicas

Requisito: A SEQD deve possuir funcionalidade que

permita a exportação e importação dos

componentes desenvolvidos armazenados em banco de dados, com o objetivo de que os componentes sejam totalmente portáveis entre SGBDs de diferentes fornecedores (no mínimo Oracle, Microsoft SQLServer, IBM DB2 baixa plataforma e Sybase), ainda que em plataformas distintas.

(11)

Comentários/Sugestão: A sintaxe e forma de construção dos componentes varia entre as distintas plataformas (Oracle, Microsoft, IBM, Sybase) e não e

possível migrar (portar) os objetos em

funcionamento em uma plataforma diretamente para outra sem revisão de código. A solução ORACLE permite que sejam importados objetos de outras tecnologias como DB2, Sybase, SQLSErver, etc, mas esses componentes so poderao ser executados em suas plataformas de origem. Caso seja mantido o requisito da forma que está, a Oracle fica impedida de participar e a competitividade desse processo fica prejudicada.

Além disso, como os BDs para o MASP foram limitados em Oracle e DB2, porque é exigida a importacão de dados de SQLServer e Sybase?

16) Item: 5.4 - Sub Item: 5.4.1 - Grupo: Processamento

Requisito:

Em caso da plataforma adotada ser do tipo alta, em IBM Mainframe:

o Processadores IFL (Integrated Facility for Linux) contendo, no mínimo, 23processadores;

o No mínimo, 800 Gb de memória RAM. Em caso da plataforma adotada ser do tipo distribuída (x86): o Sistema de servidores em lâmina contendo, no mínimo, 280 núcleos de processamento (14 lâminas de 2 CPU e 10 cores).

o No mínimo, 2,6 Tb de memória RAM.

Quanto ao item “a”, “c” e “d”:

Foram realizados estudos internos preliminares para determinar as equivalências ora propostas.

O dimensionamento de infraestrutura apresentado no projeto básico é de caráter preliminar e referencial. Em tempo de projeto o dimensionamento, bem como o projeto tecnológico para a plataforma definida, deverá ser validado e refinado em conjunto pelas PARTES.

Quanto ao item “b”´e “f”:

Os estudos internos demonstraram que as duas plataformas propostas são possíveis e aderentes para a implantação do projeto frente ao escopo objeto dessa contratação.

(12)

a. Solicitamos escalecer como foi estabelecida a equivalencia de 23 IFLs para 280 cores de x86. Foram realizados testes para subsidiar essa configuração minima de IFLs?

b. Tanto a PRODEMGE quanto a SEF tem plataforma RISC (SPARC) em suas bases. Qual a restrição pra não oferecer essa plataforma?

c. O Linux em Mainframe (zLinux) não apresenta nenhum algoritmo de compactacao de memoria. Isso posto, por que a plataforma intel deve ofercer 2,6 TB de RAM contra apenas 800 GB de Mainframe? Foram realizados testes para validar essa configuração?

d. Foram realizados testes para

comprovar que ambas configurações (intel e zLinux) entregam o mesmo

desempenho na configuração

sugerida (23 IFLs X 280 cores intel/amd)?

e. Em quais clientes (no brasil e no mundo) existem soluções de RH implantadas em plataforma IFL? f. As plataformas intel e AMD são

padrão de mercado adotados por todos os fornecedores (IBM, ORACLE, DELL, HP, FUJITSU, CISCO, etc) há bastante tempo. A plataforma zLinux, por sua vez, é relativamente nova e pelo fato de somente ser oferecida

Quanto ao item “e”:

Os estudos são baseados nas necessidades do Estado de Minas Gerais, e devido a especificidades não cabe comparação de escopos diferenciados de projeto.

(13)

pela IBM pode representar uma

vantagem competitiva a esse

fabricante e ferir a livre concorrência entre as demais. Caso seja mantido o suporte a zLinux, solicitamos avaliar

a inclusão da plataforma

Sparc/Solaris por também ser

utilizada em larga escala no governo de MG e perfeitamente aderente aos demais requisitos técnicos.

17) Item: 5.5 - Sub Item: N/A - Grupo: Métricas de dimensionamento da SOLUÇÃO

Requisito:

A contratação da SOLUÇÃO ofertada deverá englobar o fornecimento em caráter definitivo, não exclusivo, de licenças de uso de software para todos os ambientes computacionais previstos, com entrega do código fonte da SOLUÇÃO e de todas as suas integrações implementadas, transferíveis a qualquer tempo, incluindo as ferramentas, funções e bibliotecas utilizadas no seu desenvolvimento, parametrização e customização, compreendendo os processos e FERRAMENTAS descritos neste ANEXO.

A entrega do código fonte inclui também os softwares de apoio? Apesar de baseadas em padrões abertos de mercado como Java, a ORACLE não fornece o código fonte de suas soluções.

A entrega do código fonte se restringe ao SIGRH. As demais soluções de apoio não serão exigidas a entrega do código fonte. Esse item será melhor definido na versão final.

18) Item: 6.11 - Sub Item: N/A - Grupo: Garantia, Manutenção e Suporte Técnico da SOLUÇÃO IMPLANTADA

Os prazos para solução definitiva serão revisados de forma a compatibilizar o esforço envolvido na sua implementação, no entanto não há possibilidade de

(14)

Requisito:

PRAZO PARA SOLUÇÃO DEFINITIVA

Nao é possivel estipular prazo para solução definitiva pois o problema pode ser complexo e/ou estar relacionado a um BUG, o que requer tempo de análise e engenharia pra resolver. O prazo pra solução de contorno é razoavel e praxe de mercado. Com vistas a aumentar a competitividade, solicitamos remover o requisito de prazo para solução definitiva.

retirada desse requisito, haja vista as necessidades inerentes ao escopo contratado.

19) Item: 5.1 - Sub Item: 5.1.2.4 - Grupo: Grupo padronização

Requisito:

A SEQD deve possuir dicionários, regras e operações de validação pré configuradas referentes ao tratamento de dados de pessoas (no mínimo, variações fonéticas de nome e indicação de possível gênero), endereços e documentos de identificação (pelo menos, CPF e RG).

Não há regras pré configuradas para

nomes/documentos brasileiros.

Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá -los como "nao obrigatórios".

A sugestão não será acatada. A ferramenta deverá suportar essa funcionalidade, uma vez que a mesma será largamente utilizada para validação, saneamento e qualificação dos dados pessoais dos servidores do Estado.

Ademais, foi observado que essa exigência não restringe a participação e concorrência, uma vez que tal funcionalidade está presente em diversas ferramentas de mercado.

(15)

Integração

Requisito:

A SOLUÇÃO deve permitir o envio de alertas, SMS, Pager, WAP.

Solicitamos esclarecimento quanto a necessidade de envio de notificações via pager ou WAP. Ao longo dos anos a tecnologia evoluiu consideravelmente e o suporte a esses requerimentos não parece condizer com a inovação tecnológica e aos equipamentos utilizados na atualidade.

Nossa solução suporte envio de Email, IM (XMPP), SMS (SMPP), e Voice. Face ao exposto, solicitamos a exclusão de Pager e WAP por serem tecnologias em desuso e sem suporte no mercado.

21) Item: 5.1 - Sub Item: 5.1.2.4 - Grupo: Grupo Inteligência e Relatórios Analíticos e Inteligência de Negócio

Requisito:

A SAID deve possuir suporte para Drible Down e Drible (No Suggestions) deve ser nativo da solução, assim como links entre relatórios.

Solicitamos esclarecimento quanto a o que significa "Drible Down" e "Dribble (NO Suggestions". Favor citar exemplos.

O requisito será reescrito na versão final. Proposta de novo texto: “A SAID deverá suportar, de forma nativa, funcionalidades de DRILL DOWN, DRILL THROUGH e links entre relatórios.”.

22) Item: 5.1 - Sub Item: 5.1.2.8 - Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional

A solicitação não será acatada haja vista essa funcionalidade ser necessária ao negócio a ser

(16)

Requisito:

A SGCC deve possuir funcionalidade para criar relacionamento (no mínimo, ao par e herança) entre documentos.

Solicitamos remover relacionamento por herança. Com vistas a aumentar a competitividade, solicitamos remover relacionamento por herança ou classificá-lo como "não obrigatórios".

suportado. Na versão final o requisito será melhor discriminado. 1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

23) Item: 5.1 - Sub Item: 5.1.28 - Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional

Requisito:

A SGCC deve possuir recursos de visualização de imagem de documento digitalizado, contendo, no mínimo as funcionalidades de: • In e Zoom-Out; • Rotação de Imagens; • Alteração da largura e comprimento da imagem; • Rolamento da tela para visualização da imagem; • Visualização de miniaturas.

Não há como alterar a largura e comprimento de imagem, isso implicaria em editar a imagem. Não há suporte a miniaturas.

Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá-los como "não obrigatórios".

A sugestão será parcialmente atendida, uma vez que o suporte a miniaturas é necessário ao objeto ora proposto.

24) Item: 5.1 - Sub Item: 5.1.2.8 - Grupo: Gestão

(17)

Requisito:

A SGCC deve permitir a definição de quais usuários podem acessar versões anteriores de documentos, por tipo de documento e por documento específico.

Não há como restringir acesso a versões. Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá-los como "não obrigatórios". 1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

Requisito:

A SGCC deve possuir integração nativa com os principais equipamentos e softwares (no mínimo, HP, Fujitsu, Cannon, Epson, Xerox e Adobe) de captura e processamento de imagens do mercado.

Não certificamos scanners por fabricante em função da diversidade dos equipamentos. Contudo, certificamos os scanners que suportam o driver TWAIN (Padrão de mercado).

Em vistas a aumentar a competitividade, solicitamos remover o requisito ou classificá-lo como "não obrigatório".

Requisito:

A SGCC deve permitir o refinamento das imagens com pelo menos os seguintes recursos…""

A sugestão não será acatada. É esperado que a as ferramentas que compõem o SGCC contemplem o processamento de imagens digitalizadas.

(18)

Comentários/Sugestão: Neste item não atendemos: - Detecção automática de cores; - Remoção automática de cores; - Aplicação de filtros;

- Refinamento de caracteres; - Reescala de imagem.

Requisito:

A SGCC deve garantir que o documento seja mantido em cada DOSSIÊ (caso um documento estiver associado a mais de um dossiê e tiver prazos de guarda diferentes associados a ele) pelo tempo definido na sua tabela de temporalidade

A sugestão não será acatada, uma vez que tais regras estão definidas por Lei e devem ser seguidas pela solução prevista para gestão de conteúdo corporativo.

Requisito:

A SGCC deve garantir, se um documento estiver associado a mais de um DOSSIÊ (ou várias

referências armazenadas), que todas essas

referências sejam verificadas antes de eliminar o

(19)

documento.

29) Prazo de entrega dos requisitos

Segundo o TR, todos os requisitos funcionais e técnicos da Solução devem estar disponíveis

imediatamente, inclusive sendo objeto de

verificação (POC) durante o processo licitatório. Não acreditamos que exista uma solução no mercado que tenha todos esses requisitos disponíveis imediatamente. Alguns deles são muitos específicos do Governo do Estado de MG.

Sugerimos que seja definido um conjunto de requisitos a serem apresentados em um prazo imediato (para garantir que já existe uma solução aderente) e outro conjunto de requisitos a serem apresentados durante a execução do contrato (requisitos que podem ser ajustados / construídos como customização).

A resposta está contemplada no item 9.

30) Conjunto de requisitos na POC (Prova de Conceito)

O TR define que será feito um teste de aderência durante o processo licitatório para 100 (cem) requisitos a serem sorteados.

Sugerimos que o teste de aderência (POC) seja feito

com todos os requisitos obrigatórios de

apresentação imediata (conforme sugerido no item

A versão final do edital irá contemplar todas as regras aplicáveis durante a POC. O Governo do Estado considera inviável o teste de todos os requisitos obrigatórios, no entanto, qualquer um deles poderá ser objeto de teste.

(20)

acima a respeito dos prazos de entrega).

31) Serviços embutidos em funcionalidades

Para permitir que o Fornecedor estime de forma correta o seu custo, é importante identificar os

serviços a serem executados sob sua

responsabilidade.

Encontramos alguns serviços embutidos nas descrições de requisitos funcionais, como esse exemplo a seguir.

“5.1.2.8 SOLUÇÃO DE APOIO DE GESTÃO DE CONTEÚDO CORPORATIVO (SGCC)

...

A CONTRATADA deverá migrar todas as imagens, obtidas a partir da digitalização dos documentos realizadas pela CONTRATANTE para a SGCC, além de parametrizar rotinas de carga automatizada a partir de um padrão pré definido pelas PARTES.”

Sugerimos que os serviços sejam discriminados separadamente dos requisitos técnicos e funcionais.

A sugestão será acatada.

32) Sistemas a serem substituídos

A seção 5.2 relaciona os atuais sistemas a serem substituídos.

Não ficou claro se é desejado algum tipo de serviço relacionado a esses sistemas.

Sugerimos que seja definido claramente se existe algum serviço a ser executado.

O escopo dos serviços relacionados aos sistemas legados está discriminado no Capitulo 6. Não haverá intervenção direta em tais sistemas pela Contratada. O escopo se limita a integrações e migrações de dados.

(21)

33) Implantação da folha na quarta “onda” A seção 6. “Escopo dos serviços” sugere que a folha de pagamento seja implementada apenas na quarta onda.

Pela nossa experiência em implantação de soluções de RH e Folha em órgãos públicos, sugerimos que a folha seja implementada na segunda onda, junto com as demais funcionalidades básicas de RH. Essa é a forma usual para garantir que a alimentação dos dados seja feita de forma efetiva, pois assim eles serão utilizados efetivamente para produzir os pagamento.

O cronograma ora apresentado é um referencial para estimativa de esforços necessários à implantação do objeto. Conforme apresentado no item 6.2, poderá a contratada propor novo plano de trabalho e cronograma durante a etapa inicial do planejamento e acordar novo prazo de entrega para cada fase do projeto. 1 º LO TE DE R ES POS TA S AO S QUE ST IO N A M EN TOS

34) Definição do escopo dos serviços

Identificamos no TR diversos serviços sem um escopo claramente delimitado. Essa falta de delimitação gera uma insegurança no Fornecedor, impedindo a estimativa de custos.

A seguir elencaremos alguns desses serviços:

a. Integração com outros sistemas

A “integração com outros sistemas” é mencionadas em diversas seções (6.5, 6.5.2, 6.6.2 e 7).

Entretanto, não identificamos a relação dos sistemas a serem integrados ou qualquer outra definição de escopo que permita ao Fornecedor estimar seus esforços.

b. Suporte aos usuários na etapa de estabilização

A seção 6.9 estabelece como obrigação da

Quanto ao item “a”:

Já estão listados os sistemas que deverão ser substituídos e/ou integrados, assim como os tipos de informação e a arquitetura dos mesmos. Em época de projeto deverá ser traçado plano detalhado para cada necessidade.

Solicitamos atentar a seção 3.2.2 do projeto básico, que contém figura de sistemas a serem integrados, assim como aqueles que deverão ser substituídos e item 5.2.2 com listagem dos sistemas a serem substituídos.

Posto isso, entende-se que essas informações são suficientes para dimensionamento dos esforços necessários.

Quanto ao item “b”:

Espera-se que a contratada suporte os chamados apenas dos “usuários desenvolvedores, avançados e limitados (item 5.5.1)” apresentados no dimensionamento.

(22)

Contratada “Prestar suporte aos usuários na realização das suas atividades diárias através da resolução de chamados;”.

Não está claro qual o tipo de suporte a ser oferecido e qual a quantidade de usuários que poderá acionar esse serviço.

Portanto, não é possível que o Fornecedor determine o seu esforço nessa atividade.

c. Atendimento de “ajustes” na etapa de estabilização.

A seção 6.9 estabelece que a Contratada deverá “Proceder aos ajustes necessários identificados através dos chamados abertos.”

Não há um critério sobre qual tipo de “ajuste” pode ser solicitado.

Sabemos que a Folha de Pagamento, por exemplo, requer esforço contínuo de uma equipe de gestão para implementar todas as novas demandas que surgem diariamente, por exemplo por conta da mudança frequente na legislação.

d. Equipe mínima do projeto durante sua execução.

A seção 10.2 estabelece uma “equipe mínima que a Contratada deve manter”.

Não está clara a finalidade desse requisito. Entendemos que as obrigações da Contratada devem ser as entregas das funcionalidades, serviços e demais artefatos nos prazos definidos conforme o Termo de Referência.

Ademais, medidas preventivas como transferência de conhecimento, gestão da mudança, correção de bugs, entre outros, devem minimizar o número de chamados nessa etapa.

Quanto ao item “c”:

A sugestao não será acatada, uma vez que a responsabilidade da contratada é de garantir a aderência da solução implementada às especificações construídas nas etapas anteriores. Novas demandas que ocorram após a etapa de implantação serão contempladas por meio de banco de horas.

Quanto ao item “d”:

A sugestão não será acatada, haja vista que para a implantação desse projeto faz-se necessária à integração entre equipe do Governo de Minas, da PRODEMGE, da Contratada e demais fornecedores de outros projetos de RH. Nesse sentido, com vistas a promover o alinhamento e garantir a boa execução dos trabalhos é importante a alocação de uma equipe mínima ora proposta.

Quanto ao item “e” e “f”: As sugestões serão acatadas.

(23)

Analistas de Sistemas e Programadores, por

exemplo, normalmente ficam alocados nas

instalações do Fornecedor, conforme demanda em cada etapa do projeto.

e. Requisitos de integração

Existem diversos requisitos do “Grupo de Integração” da Solução que entendemos que deveriam ser atendidos pela “SOLUÇÃO DE APOIO DE INTEGRAÇÃO DE DADOS E SISTEMAS (SIDS):”

T.SOL.034 - A SOLUÇÃO deve possuir ferramenta gráfica para mapeamento das integrações (internas e externas à SOLUÇÃO). Grupo Integração

T.SOL.036 - A SOLUÇÃO deve suportar integrações entre as ferramentas (internas e externas à SOLUÇÃO, utilizando protocolo RPC), nas formas síncronas (best effort) e assíncronas (exactly-once, exactly-once in order).

T.SOL.038 - A SOLUÇÃO deve armazenar

MENSAGENS assíncronas em camada de persistência, suportando reprocessamento em caso de falhas.

f. Requisitos de Ciclo de Vida da Solução

Entendemos que todos os requisitos da solução do grupo “Grupo Ciclo de Vida da Solução - Suporte à implementação” deveriam ser atendidos pela “SOLUÇÃO DE APOIO DE GESTÃO DE CHAMADOS

(24)

(SGCH):” ou por solução específica de Gestão de Projetos, pois não estão relacionados direta ou indiretamente à gestão de RH.

COMISSÃO TÉCNICA

Cristiano de Magalhães Barros Membro da Comissão

Thaíse Amaranta Vilaça Membro da Comissão