O documento discute como selecionar a arquitetura de sistemas de uma empresa de forma correta. Primeiro, deve-se mapear completamente os processos de negócio e definir requisitos claros. Em seguida, usar um processo estruturado como RFP para solicitar propostas e selecionar fornecedores. Por fim, avaliar cuidadosamente as propostas considerando todos os custos e funcionalidades necessárias para o negócio.

1. SELECIONAR ARQUITETURA
DE SISTEMAS
O QUE FAZER E O QUE NÃO FAZER
QUEM TOMA AS DECISÕES / ONDE SÃO ORIGINADAS ?
CONSIDERA APENAS O PORTE DA EMPRESA E CUSTO DO PROJETO ?

2. COMO AS DECISÕES SÃO TOMADAS HOJE
?
 Quem toma as decisões atualmente ?
 Estamos adotando uma metodologia
correta para o processo de seleção
de todo o ecossistema de softwares
requeridos para o negócio ?
 Consideramos totalmente quais são
os nossos requisitos de negócio,
tecnologias, investimentos viáveis,
etc... ?
 Apenas pesquisamos no mercado ou
com nossos contatos, sobre
indicações de fornecedores ?
 Apenas solicitamos uma
demonstração geral – overview e
uma proposta comercial para validar
preços ?
 Estamos focando realmente em
funcionalidades críticas para o nosso
negócio e que serão efetivamente
utilizáveis ?

3. 1º. Passo : avaliar as necessidades para suporte
aos negócios de nossa empresa.
Temos um inventário completo de todo
nosso ecossistema de sistemas atual ?
O quanto está nos atendendo ?
Utilizamos eficientemente?
O que precisamos e que
poderá nos apoiar para um
crescimento sustentado ?
 Definir requisitos por processo
 Mapear e avaliar todos os processos
críticos de negócio
 Priorizar realmente o que serão
processos que nos diferenciam no
mercado (espinha dorsal de negócios
, a forma como trabalhamos nestes
processos críticos.

4. Quais são as perspectivas e demandas de nossos
principais usuários e gestores de processos críticos ?
(não somente do pessoal de TI).
 Comunicação entre todas as áreas (usuários focam requisitos funcionais ; TI foca na
estrutura física e tecnologias para suportar futuros sistemas e suas integrações,
demandas por infraestruturas, etc...)
 Comite de Sistemas (usuários – chave, equipe TI, contabilidade / fiscal, ...)
 Quem define requisitos são os usuários – chave, juntamente com os responsáveis
pelo projeto de seleção (validações em geral, importância, peso, obrigatoriedade
ou não, itens de melhoria, etc...)
 Quem faz o mapeamento de processos críticos – completo, com informações de
entrada / saída (em qualquer formato), que são requeridas para a execução de
cada etapa. (situação como é hoje –AS IS e como deve ser para atender ao projeto
– TO BE).

5. Utilize um adequado processo de RFP –
RFI – RFQ - .... para suporte a decisão
 A partir do mapeamento e definição de uma matriz de requisitos para o projeto, importante
trabalhar dentro do modelo de uma metodologia testada para RFP – Request for Proposal, que
inclui também um processo de busca de informações de mercado (RFI), envio e tabulação completa
do questionário de requisitos (RFP); solicitação de propostas comerciais completos e aderentes aos
requisitos (RFQ)
 Tabulação e pontuação do retorno dos questionários enviados aos players previamente
selecionados para participarem
 Solicitação de demonstrações somente aos players selecionados durante este processo, com foco
no roteiro de apresentação definido junto com os usuários – chave de cada processo de negócio /
back-office.
 Buscar consultorias especializadas / especialistas nestes processos, com isenção total de atuação no
mercado. Utilizar suas metodologias testadas para condução.
 Pode ser utilizado inclusive um modelo já desenvolvido de requisitos por processos e
complementado com os levantamentos realizados pelo responsável interno ou pelo Comite.

6. Demonstração de
produtos selecionados
pelo RFP
 Prepare um roteiro de requisitos a serem demonstrados /
detalhados pelos fornecedores (usuários – chave, incluindo
contabil / fiscal / rh, mesmo que terceirizados).
 Validar com o fornecedor, com foco naquilo que já está
disponível no produto e o que deverá ser desenvolvido ou
mesmo integrado com outras plataformas (custos ?)
 Validar tecnologias totalmente disponibilizadas e aderentes
pelos fornecedores (requeridas efetivamente para suportar
nossos negócios)
 Avalie sob um foco de 3 a 5 anos e como o fornecedor poderá
nos apoiar nesta jornada.
 O estilo do fornecedor, o estilo adotado para seus produtos, o
foco no cliente e sua participação no desenvolvimento do
produto, a preocupação em treinar e capacitor efetivament e
transferir conhecimentos para o pleno uso do sistema., etc…
são fatores muito importantes para tomarmos decisões.

7. Avaliando as propostas comerciais...
 Não se preocupe com os preços iniciais encaminhados, pois tudo deve ser renegociado e discutido
com calma.
 Avalie o TCO – Custo Total de Propriedade do projeto, com cada proposta apresentada.
 Avalie custo de utilização do produto (licença, subscrição, necessidade de outros produtos, cloud,
garantias, etc...)
 Avalie clientes – referencia / solicite lista de referencias para que possa ser escolhida uma ou mais
empresas
 Avalie impacto das funcionalidades apresentadas, facilidade de uso e de implementação, aderência
à cultura da empresa,
 Cuidado com escopo bem detalhado e entendido e parte integrante do contrato.
 Atenção à funcionalidades a serem desenvolvidas, devem fazer parte do escopo detalhado e ficar
claro a responsabilidade / prazos/ itens de aceitação / etc...
 Avalie custos mensais – recorrentes, fatores de cobrança, clausulas de suspensão / cancelamento,
etc...