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

Transcrição

1 PERGUNTAS E RESPOSTAS - CONSULTA PÚBLICA SOLUÇÃO INTEGRADA DE GESTÃO DE RECURSOS HUMANOS PARA O ESTADO DE MINAS GERAIS PERGUNTAS 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? 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. 3) RESOLUÇÃO Nº 63, DE 14 DE SETEMBRO DE 2011 da SEPLAG-MG a Instruções de Execução dos RESPOSTAS SEPLAG O entendimento está correto. A sugestão será contemplada na versão final. Para o 3º item (MDASS): O Manual de Desenvolvimento e Aquisição de Sistemas Seguros não se aplica somente para 1

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 olvimento_seguro-63. b 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 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, 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. 2

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. 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. O prazo foi prorrogado para o dia 19/12. Requisito atual: F.GRH 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. A sugestão será contemplada na versão final. Sugestão de O SIGRH deve possuir um cadastro único de pessoas 3

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. Sugestão de 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. 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 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. A sugestão será contemplada na versão final. 4

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. Requisito atual: Não identificado. Sugestão de 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 5

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. 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. Requisito atual: Não identificado. Sugestão de 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: A sugestão será contemplada na versão final. 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 6

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. 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. 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. 10) Incorporar a identidade visual do contratante: Requisito atual: T.SOL A SOLUÇÃO deve permitir que a camada de apresentação possa incorporar a identidade 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. 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. 7

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: Sub Item: Grupo: Grupo Arquitetura Técnica 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. O objeto sob consulta não contempla a aquisição de equipamentos. Os requisitos de infraestrutura tecnológica e sistema Entendemos que a definição pelas plataformas operacional foram definidos com base nas possíveis Intel/AMD e IBM/Mainframe restringe a tecnologias disponíveis no ambiente da PRODEMGE. 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. 12) Item: Sub Item: Grupo: Grupo Vide resposta item 11. 8

9 Arquitetura Técnica 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: Sub Item: Grupo: Segurança e Acesso 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. A sugestão será contemplada de maneira mais clara 9

10 Deverá ser feita a criptografia desses dados? Existe algum padrão de segurança (ex: wsisecurity) que as soluções devam atender? 14) Item: Sub Item: Grupo: Grupo conexão a bancos de dados na versão final. 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." 15) Item: Sub Item: Grupo: Grupo Funcionalidades Básicas 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. 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. A sugestão será contemplada na versão final. 10

11 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: Sub Item: Grupo: Processamento 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. 11

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. 12

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: Sub Item: N/A - Grupo: Métricas de dimensionamento da SOLUÇÃO 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 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. 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. 18) Item: 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 13

14 PRAZO PARA SOLUÇÃO DEFINITIVA retirada desse requisito, haja vista as necessidades inerentes ao escopo contratado. 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. 19) Item: Sub Item: Grupo: Grupo padronização 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. 20) Item: Sub Item: Grupo: Grupo A sugestão será contemplada na versão final. 14

15 Integração 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 , 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: Sub Item: Grupo: Grupo Inteligência e Relatórios Analíticos e Inteligência de Negócio 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. 22) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional 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.. A solicitação não será acatada haja vista essa funcionalidade ser necessária ao negócio a ser 15

16 A SGCC deve possuir funcionalidade para criar relacionamento (no mínimo, ao par e herança) entre documentos. suportado. Na versão final o requisito será melhor discriminado. 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". 23) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional A SGCC deve possuir recursos de visualização de imagem de documento digitalizado, contendo, no mínimo as funcionalidades de: Zoom-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. A sugestão será parcialmente atendida, uma vez que o suporte a miniaturas é necessário ao objeto ora proposto. 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". 24) Item: Sub Item: Grupo: Gestão do Conhecimento e Conteúdo Organizacional A sugestão será acatada. 16

17 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". 25) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional 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". 26) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional A SGCC deve permitir o refinamento das imagens com pelo menos os seguintes recursos "" A sugestão será contemplada na versão final. A sugestão não será acatada. É esperado que a as ferramentas que compõem o SGCC contemplem o processamento de imagens digitalizadas. 17

18 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. Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá-los como "não obrigatórios". 27) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional 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. Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá-los como "não obrigatórios". 28) Item: Sub Item: Grupo: Grupo Gestão do Conhecimento e Conteúdo Organizacional 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 Vide resposta item

19 documento. Com vistas a aumentar a competitividade, solicitamos remover tais requisitos ou classificá-los como "não obrigatórios". 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. A resposta está contemplada no item 9. 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). 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. 19

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 SOLUÇÃO DE APOIO DE GESTÃO DE CONTEÚDO CORPORATIVO (SGCC) A sugestão será acatada.... 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. 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. 20

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. 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, 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 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. 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 do projeto básico, que contém figura de sistemas a serem integrados, assim como aqueles que deverão ser substituídos e item 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. 21

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. 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. 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. Quanto ao item e e f : As sugestões serão acatadas. 22

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 A SOLUÇÃO deve possuir ferramenta gráfica para mapeamento das integrações (internas e externas à SOLUÇÃO). Grupo Integração T.SOL 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 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 23

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 24