Business Analysis Foundation em português - EXIN/BCS

Get Started. It's Free
or sign up with your email address
Rocket clouds
Business Analysis Foundation em português - EXIN/BCS by Mind Map: Business Analysis Foundation em português - EXIN/BCS

1. 3. Análise da estratégia

1.1. Contexto para a estratégia

1.1.1. Existem algumas grandes mudanças que as organizações enfrentam e que o desenvolvimento da estratégia tenta moderar:

1.1.1.1. Há as mudanças nas formas em que estamos empregados.

1.1.1.2. A sociedade mudou.

1.1.1.3. As organizações estão respondendo a essas mudanças ao fazer tudo o que podem para aumentar sua flexibilidade e capacidade de resposta.

1.1.1.4. O mundo é cheio de contradições

1.1.1.4.1. Global x local.

1.1.1.4.2. Estruturas de organização centralizadas x descentralizadas.

1.2. Definição de estratégia

1.2.1. É a direção e o escopo de uma organização no longo prazo, que confere vantagem em um ambiente de mudança através da configuração dos recursos e competências que ajudam a atender às expectativas das partes interessadas

1.3. Formas comuns de desenvolver estratégias

1.3.1. A partir de um indivíduo (fundador ou CEO)

1.3.2. A partir das experiências e pontos de vista dos gestores internos

1.3.3. A partir de ideias geradas pelas pessoas que fazem o trabalho

1.3.4. A partir de um processo formal de planejamento

1.4. Análise do ambiente externo

1.4.1. Análise PESTLE

1.4.1.1. Analisa os fatores

1.4.1.1.1. Político

1.4.1.1.2. Econômico

1.4.1.1.3. Sociocultural

1.4.1.1.4. Tecnológico

1.4.1.1.5. Legal

1.4.1.1.6. Ecológico

1.4.2. 5 forças de Porter

1.4.2.1. Ameaça de novos entrantes

1.4.2.1.1. Barreiras para novos entrantes: Economias de escala Investimento necessário Produto diferenciado Canais de distribuição Patentes Necessidade de aprovação regulamentar

1.4.2.2. Poder de barganha dos compradores

1.4.2.2.1. É alto quando: O cliente é grande Há fontes alternativas de abastecimento O custo do produto é alto Os custos de mudança são baixos

1.4.2.3. Ameaça de produtos ou serviços substitutos

1.4.2.3.1. É alto quando: A necessidade do produto pode ser substituída

1.4.2.4. Poder de barganha dos fornecedores

1.4.2.4.1. É alto quando: Há poucos fornecedores Os custos de mudar de fornecedor são elevados A marca do fornecedor é poderosa Os clientes não têm influência

1.4.2.5. Concorrentes da indústria – rivalidade entre as empresas

1.4.2.5.1. A rivalidade é alta quando: Há muitas empresas competindo Compradores podem facilmente migrar para elas A indústria tem custos fixos

1.4.3. Análise de cenários “E se”

1.4.3.1. Consideramos cenários que olham para o futuro a médio e longo prazos e, avaliando possíveis futuros diferentes, preparamos a organização e seus gerentes para lidar com eles.

1.4.3.2. É aplicada em conjunto com a análise PESTLE.

1.5. Análise do ambiente interno

1.5.1. Análise MOST

1.5.1.1. Serve para compreender o posicionamento dos negócios atuais.

1.5.1.2. Analista os fatores

1.5.1.2.1. Missão

1.5.1.2.2. Objetivos

1.5.1.2.3. Estratégia

1.5.1.2.4. Táticas

1.5.2. Auditoria de recursos

1.5.2.1. Analisa recursos da organização para identificar pontos fortes e fracos

1.5.2.2. Tipos de recursos a serem analisados

1.5.2.2.1. Tangíveis

1.5.2.2.2. Intangíveis

1.5.3. Matriz BCG

1.5.3.1. Desenvolvida pela Boston Consulting Group

1.5.3.2. Faz análise de portfólio de produtos para orientar as estratégias

1.5.3.3. Classificação dos produtos

1.5.3.3.1. Estrela

1.5.3.3.2. Gato selvagem (ou criança-problema)

1.5.3.3.3. Vaca leiteira

1.5.3.3.4. Cão (ou abacaxi para nós)

1.5.3.4. Matriz

1.5.4. Análise SWOT

1.5.4.1. Analisa forças, fraquezas, oportunidades e ameaças

1.5.4.2. Pode ser utilizada tanto para análise de ambiente externo como internos

1.5.4.3. Figura

1.6. Estratégia de execução

1.6.1. Modelo McKinsey 7-S

1.6.1.1. Supõe que todas as organizações são constituídas por 7 componentes

1.6.1.2. 7 Componentes

1.6.1.2.1. São as sete alavancas que podem ser utilizadas na execução da mudança estratégica e todas estão interligadas

1.6.2. Balanced Business Scorecard

1.6.2.1. Ajuda a estabelecer temas de metas estratégicas em 4 perspectivas

1.6.2.1.1. Financeiro

1.6.2.1.2. Cliente

1.6.2.1.3. Processos internos

1.6.2.1.4. Aprendizado & crescimento

1.6.3. Fatores Críticos de Sucesso e Indicadores de Desempenho (KPI)

1.6.3.1. Podem ser identificados com o uso do Balanced Scorecard

1.6.3.2. Critical success factors (CSFs)

1.6.3.2.1. São áreas críticas que onde o alto desempenho ou sucesso é importante, elas decidem o sucesso de uma organização.

1.6.3.3. Key performance indicators (KPIs)

1.6.3.3.1. Instrumentos usados para medir o desempenho de uma organização, vão indicar se o CSF está sendo atendido.

2. 4. O modelo de processo de análise de negócios

2.1. Abordagem para a resolução de problemas de Isaksen e Treffinger

2.1.1. Propósito

2.1.1.1. Fornece uma sequência lógica para resolve qualquer tipo de problema.

2.1.2. Imagem

2.1.3. Estágios deste modelo

2.1.3.1. Constatação de confusão (Mess finding)

2.1.3.1.1. Entende sobre a complexidade da situação problemática.

2.1.3.2. Exploração dos dados (Data finding)

2.1.3.2.1. Analisa opiniões, preocupações, conhecimentos e ideias descobertas na etapa anterior a fim de identificar dados de apoio obtidos e onde essa informação pode ser quantificada

2.1.3.3. Definição do problema (Problem finding)

2.1.3.3.1. Define qual é o problema a ser resolvido.

2.1.3.4. Produção de ideias (Idea finding)

2.1.3.4.1. Gera ideias para resolver o problema.

2.1.3.5. Descoberta de soluções (Solution finding)

2.1.3.5.1. Encontra uma solução a partir das ideias geradas.

2.1.3.6. Construção de aceitação (Acceptance finding)

2.1.3.6.1. Obtém aceitação da solução proposta.

2.2. Modelo de processo de análise de negócios

2.2.1. Propósito

2.2.1.1. Define as principais estágios de um projeto de análise de negócios.

2.2.2. Imagem

2.2.3. Estágios deste modelo

2.2.3.1. Investigar a situação

2.2.3.1.1. Propósito

2.2.3.1.2. Procedimentos

2.2.3.1.3. Entradas

2.2.3.1.4. Saídas

2.2.3.1.5. Técnicas

2.2.3.2. Considerar as perspectivas

2.2.3.2.1. Propósito

2.2.3.2.2. Procedimentos

2.2.3.2.3. Entradas

2.2.3.2.4. Saídas

2.2.3.2.5. Técnicas

2.2.3.3. Analisar as necessidades

2.2.3.3.1. Propósito

2.2.3.3.2. Procedimentos

2.2.3.3.3. Entradas

2.2.3.3.4. Saídas

2.2.3.3.5. Técnicas

2.2.3.4. Avaliar as opções

2.2.3.4.1. Propósito

2.2.3.4.2. Procedimentos

2.2.3.4.3. Entradas

2.2.3.4.4. Saídas

2.2.3.4.5. Técnicas

2.2.3.5. Definir os requisitos

2.2.3.5.1. Propósito

2.2.3.5.2. Procedimento

2.2.3.5.3. Entrada

2.2.3.5.4. Saída

2.2.3.5.5. Técnicas

2.2.3.6. Entregar mudanças

2.2.3.6.1. Propósito

2.2.3.6.2. Procedimentos

2.2.3.6.3. Entradas

2.2.3.6.4. Saídas

2.2.3.6.5. Técnicas

3. 5. Técnicas de investigação

3.1. Técnicas qualitativas

3.1.1. Entrevistas

3.1.1.1. Propósito

3.1.1.1.1. Uma conversa para obter informações

3.1.1.2. Vantagens

3.1.1.2.1. Facilitam o relacionamento com as partes envolvidas

3.1.1.2.2. Ajudam a compreender a perspectiva das pessoas envolvidas com o sistema do negócio

3.1.1.2.3. Consideram o que as pessoas fazem, suas preocupações e o que elas querem dos novos processos ou sistemas

3.1.1.2.4. Exploram novas áreas conforme elas aparecem.

3.1.1.2.5. Permitem identificar e recolher documentação que os clientes usam.

3.1.1.2.6. Ajudam a entender diferentes pontos de vista das partes envolvidas.

3.1.1.2.7. Proporcionam uma oportunidade para estudar melhor o ambiente .

3.1.1.3. Desvantagens

3.1.1.3.1. Levam tempo para planejar e podem ser caras.

3.1.1.3.2. Tomam o tempo do entrevistado.

3.1.1.3.3. As informações prestadas podem ser um opinião do ponto do vista do entrevistado e não representar um fato.

3.1.1.4. Preparação para entrevistas

3.1.1.4.1. Identificar quem entrevistar em cada nível da organização

3.1.1.4.2. Escolher as pessoas a entrevistar.

3.1.1.4.3. Identificar o que perguntar.

3.1.1.4.4. Planejar local e agenda.

3.1.1.5. Condução da entrevista

3.1.1.5.1. Estrutura básica de execução

3.1.1.6. Acompanhamento da entrevista

3.1.1.6.1. Enviar anotações para os entrevistados confirmar o que foi falado.

3.1.1.6.2. Incluir as anotações aprovadas na documentação do projeto.

3.1.2. Observação

3.1.2.1. Propósito

3.1.2.1.1. Consistem em observar o local de trabalho e os funcionários realizando o seu trabalho para obter informações.

3.1.2.2. Vantagens

3.1.2.2.1. Fornece uma melhor compreensão dos problemas e dificuldades enfrentados.

3.1.2.2.2. Ajuda a preparar as perguntas apropriadas para uma entrevista mais aprofundada.

3.1.2.2.3. Ajuda a encontrar soluções viáveis que são mais propensas a serem aceitas.

3.1.2.3. Desvantagens

3.1.2.3.1. Ser observado pode ser irritante.

3.1.2.4. Abordagens

3.1.2.4.1. Observação formal

3.1.2.4.2. Análise de protocolo

3.1.2.4.3. Sombreamento/Sombra (shadowing)

3.1.2.4.4. Estudos etnográficos

3.1.3. Workshops (oficinas)

3.1.3.1. Propósito

3.1.3.1.1. Fornecem um excelente fórum de colaboração em que as questões podem ser discutidas, os conflitos resolvidos e requisitos elucidados.

3.1.3.2. Vantagens

3.1.3.2.1. Fornecem uma visão ampla da área sob investigação.

3.1.3.2.2. Aumentam velocidade e produtividade na entrevistas.

3.1.3.2.3. Facilitam obter aceitação para o projeto.

3.1.3.2.4. Ajudam a obter uma visão de consenso ou acordo de grupo.

3.1.3.3. Desvantagens

3.1.3.3.1. Podem demorar para ser organizados.

3.1.3.3.2. Pode acontecer de um participante dominar a discussão.

3.1.3.3.3. Pode ser difícil garantir que os participantes tenham o nível necessário de autoridade.

3.1.3.4. Considerações para preparação de um workshop

3.1.3.4.1. O objetivo do workshop

3.1.3.4.2. As pessoas a serem convidadas

3.1.3.4.3. A estrutura e as técnicas a serem utilizadas

3.1.3.4.4. O local adequado

3.1.3.5. Realização do workshop

3.1.3.5.1. Começa discutindo os objetivos do workshop.

3.1.3.5.2. O facilitador precisa garantir que as questões sejam discutidas.

3.1.3.5.3. Registrar o que foi discutido.

3.1.3.6. Técnicas

3.1.3.6.1. Para facilitar a descoberta

3.1.3.6.2. Para facilitar a visualização do que foi discutido

3.1.4. Cenários

3.1.4.1. Propósito

3.1.4.1.1. Consiste em contar a história de uma tarefa ou transação

3.1.4.2. Vantagens

3.1.4.2.1. Requer que o usuário inclua cada passo e as transições entre os passos, e como resultado a oportunidade para remover omissões

3.1.4.2.2. Ajuda a garantir que não existam elementos tomados como certos e o problema do conhecimento tácito é abordado

3.1.4.2.3. Ajuda ao usuário do negócio a visualizar todas as situações possíveis e remove a incerteza

3.1.4.3. Desvantagens

3.1.4.3.1. Pode ser de desenvolvimento demorado

3.1.4.3.2. Pode se tornar complexo, especialmente onde há vários caminhos alternativos

3.1.4.4. Processo para o desenvolvimento de cenários

3.1.4.4.1. Imagem do processo

3.1.5. Prototipagem

3.1.5.1. Propósito

3.1.5.1.1. Envolve simulações de construção de um processo ou sistema a fim de analisá-lo com os usuários para aumentar a compreensão sobre os requisitos.

3.1.5.2. Vantagens

3.1.5.2.1. Esclarece qualquer incerteza por parte dos analistas e confirmar para o usuário que compreendemos o que pediram.

3.1.5.2.2. Ajuda o usuário a identificar novas exigências.

3.1.5.2.3. Demonstra a aparência do sistema proposto.

3.1.5.2.4. Valida os requisitos do sistema e identificar os eventuais erros.

3.1.5.2.5. Fornece um meio de avaliar caminhos de navegação e sistema de desempenho.

3.1.5.3. Desvantagens

3.1.5.3.1. O ciclo de prototipagem pode sair do controle com infinitas iterações ocorrendo.

3.1.5.3.2. Se o propósito do exercício não foi explicado de forma clara, os usuários podem pensar que quando eles estão satisfeitos com o protótipo, o sistema está completo e pronto para uso.

3.1.5.3.3. As expectativas dos usuários podem ser aumentadas desnecessariamente pela falta de limitação da aparência final do sistema.

3.2. Técnicas quantitativas

3.2.1. Pesquisas ou questionários

3.2.1.1. Podem ser úteis se precisarmos obter uma quantidade limitada de informações de muitas pessoas e entrevistá-los individualmente ou em uma série de workshops não será prático ou rentável.

3.2.2. Registros de propósito específico

3.2.2.1. São formas de coletar dados utilizados pelo analista.

3.2.3. Amostragem de atividade

3.2.3.1. Pode ser usada quando é necessário conhecer como as pessoas dividem o seu tempo de trabalho entre uma gama de atividades.

3.2.4. Análise de documentos

3.2.4.1. Envolve a análise de amostras de documentos originais para descobrir informações sobre uma organização, processo ou sistema.

3.3. Documentação da situação atual

3.3.1. Desenhos/imagens ricos (rich picture)

3.3.1.1. Fornecem uma visão geral de toda uma situação do negócio

3.3.1.2. Sem notação fixa.

3.3.1.3. Exemplo

3.3.2. Mapas mentais (Mind Maps)

3.3.2.1. Serve para resumir informações em um formulário visual simples, estruturado para destacar as conexões entre diferentes ideias e temas.

3.3.2.2. Exemplo

3.3.3. Modelo de negócio

3.3.3.1. Serve para mostrar as tarefas em um processo, os atores responsáveis pela sua execução e o fluxo do processo.

3.3.3.2. Exemplo

3.3.4. Mapa de espaguete

3.3.4.1. Serve para mostrar o movimento e as interações dos stakholders em um ambiente particular ao executar tarefas e processos particulares

3.3.4.2. Exemplo

3.3.5. Diagrama de espinha de peixe

3.3.5.1. Ajuda a explorar/compreender possíveis causas relacionadas a um problema.

3.3.5.2. Exemplo

4. 6. Análise e gestão de partes interessadas

4.1. Definição de stakeholder

4.1.1. Qualquer um que tem um interesse ou pode ser afetado por uma questão sob consideração.

4.2. Categorias de stakeholders

4.2.1. Clientes

4.2.2. Parceiros

4.2.3. Fornecedores

4.2.4. Concorrentes

4.2.5. Reguladores

4.2.6. Proprietários

4.2.7. Empregados

4.2.8. Gestores

4.3. Matriz de poder e interesse

4.3.1. Refere-se ao nível de influência que o stakeholder exerce sobre o projeto

4.3.2. Serve para definir as estratégias de gerenciamento de cada parte

4.3.3. Imagem

4.3.4. Classificação de atitude de cada stakeholder

4.3.4.1. Campeão

4.3.4.1.1. Trabalha ativamente para o sucesso do projeto

4.3.4.2. Apoiador

4.3.4.2.1. A favor do projeto, mas provavelmente não muito ativo na sua promoção

4.3.4.3. Neutro

4.3.4.3.1. Não expressa opinião a favor ou contra o projeto

4.3.4.4. Crítico

4.3.4.4.1. Não é a favor do projeto, mas provavelmente não se opõe ativamente

4.3.4.5. Opositor

4.3.4.5.1. Trabalha ativamente para atrapalhar, impedir ou inviabilizar o projeto

4.3.4.6. Bloqueador

4.3.4.6.1. Obstrui o progresso, possivelmente por razões fora do projeto em si

4.4. Plano/avaliação de partes interessadas

4.4.1. Define como cada parte interessada será abordada

4.4.2. Contém

4.4.2.1. Nome do stakeholder

4.4.2.2. Cargo

4.4.2.3. Poder e influência atual (alto, médio, baixo)

4.4.2.4. Atual interesse (alto, médio, baixo)

4.4.2.5. Questões de interesse

4.4.2.6. Atitude atual (campeão, apoiador...)

4.4.2.7. Apoio desejado (alto, médio, baixo)

4.4.2.8. Papel desejado (Podemos desejar ter essa parte interessada ativamente envolvida no projeto)

4.4.2.9. Ações desejadas (O que gostaríamos que a parte interessada faça)

4.4.2.10. Mensagens a transmitir (a ênfase que deve ser colocada em qualquer comunicação a esse público)

4.4.2.11. Ações e comunicados (definimos exatamente que ações vamos tomar em relação a essa parte interessada)

4.5. Matriz RACI

4.5.1. Define o envolvimento de cada parte interessada

4.5.2. Atribuições

4.5.2.1. R = Responsible

4.5.2.2. A = Accountable

4.5.2.3. C = Consulted

4.5.2.4. I = Informed

4.6. Metodologia soft systems (SSM)

4.6.1. Seu uso é na análise de situações complexas onde há pontos de vista divergentes sobre a definição do problema ou da solução.

4.7. CATWOE

4.7.1. Técnica para analisar as perspectivas de cada skaholder

4.7.2. Elementos

4.7.2.1. Customers (clientes)

4.7.2.2. Actors (atores),

4.7.2.3. Transformation (transformação)

4.7.2.4. World View (visão de mundo)

4.7.2.5. Owner (proprierário)

4.7.2.6. Environmental (ambiente)

4.8. Modelos de atividade de negócios (BAM)

4.8.1. Fornecem um modelo conceitual do “o que” se espera a ser cumprido, em uma perspectiva particular das partes interessadas.

4.8.2. É elaborado um BAM para cada perspectiva de uma parte interessada.

4.8.3. Tipos de atividades mapeadas

4.8.3.1. Execução (Doing)

4.8.3.1.1. Derivadas do aspecto “Transformação” do CATWOE

4.8.3.2. Viabilização (Enabling)

4.8.3.2.1. Asseguram que os recursos e as instalações necessárias para as atividades de “execução" estão disponíveis

4.8.3.3. Planejamento (Planning)

4.8.3.3.1. Planejam as atividades de execução e biabilização.

4.8.3.4. Monitoramento (Monitoring)

4.8.3.4.1. Definem as expectativas de desempenho.

4.8.3.5. Controlling (Controle)

4.8.3.5.1. Revelam como está o desempenho.

5. 7. Modelagem de processos de negócios

5.1. Definição de processo de negócio

5.1.1. São os meios pelos quais uma organização realiza as operações internas e fornece seus produtos e serviços aos clientes.

5.2. Razões para criar um Modelo de processo de negócio

5.2.1. Entender como o processo existente funciona

5.2.2. Explicar aos funcionários o processo e como sua tarefa se relaciona às outras

5.2.3. Ajudar a garantir a coerência da abordagem

5.2.4. Identificar os problemas e fraquezas existentes

5.3. Tipos de visões de uma organização

5.3.1. Visão funcional

5.3.1.1. Organização estruturada por departamentos.

5.3.1.2. Cada departamento é especializado em algumas atividades.

5.3.1.3. Desvantagens

5.3.1.3.1. Não é orientada ao cliente.

5.3.1.3.2. Não facilita a comunicação entre o pessoal de diversos de departamentos.

5.3.1.3.3. Fornece uma visão estática não mostrando o que a empresa faz ao longo do tempo.

5.3.2. Visão por processo

5.3.2.1. Mostra como a empresa funciona por processos.

5.3.2.2. Vantanges

5.3.2.2.1. Orientada ao resultado para o cliente.

5.3.2.2.2. Elimina as barreiras de comunicação entre departamentos.

5.3.3. Visão alternativa

5.3.3.1. Paul Harmon (2007) desenvolveu o modelo que fornece uma visão alternativa de uma organização, fornecendo uma representação de ambos os processos internos e externos com os quais a organização opera

5.3.3.2. Figura

5.4. Mapa de processos

5.4.1. Mostra os processos de ponta a ponta que convertem entradas do fornecedor em saídas para o cliente.

5.5. Cadeia de valor de Porter

5.5.1. Designa uma série de atividades relacionadas e desenvolvidas pela empresa a fim de satisfazer as necessidades dos clientes

5.5.2. É um ponto de partida para elaborar um mapa de processos da organização.

5.5.3. Figura

5.5.4. Tipos de atividades representadas

5.5.4.1. Atividades primárias

5.5.4.1.1. Relacionadas diretamente com o que a empresa produz, vende ou transfere ao cliente e assistência pós venda.

5.5.4.1.2. Exemplos

5.5.4.2. Atividades de suporte

5.5.4.2.1. Sustentam as atividades primárias fornecendo insumos, tecnologia, recursos humanos e outras funções.

5.5.4.2.2. Exemplos

5.6. Proposta de valor

5.6.1. É uma definição de produto ou serviço de uma organização que irá demonstrar aos clientes que ela pode entender e satisfazer as suas necessidades

5.6.2. Atributos que compõem a proposta de valor

5.7. Modelo de processo de negócio

5.7.1. É uma representação simplificada de um processo

5.7.2. Componentes de um modelo

5.7.2.1. Tarefas

5.7.2.2. Fluxo do processo

5.7.2.3. Pontos de decisão

5.7.2.4. Agentes

5.7.2.5. Resultados do processo

5.7.3. Notações mais usadas

5.7.3.1. UML

5.7.3.2. BPMN

5.7.4. Eventos de negócio

5.7.4.1. Desencadeia um processo de negócio.

5.7.4.2. Tipos de eventos

5.7.4.2.1. Externos

5.7.4.2.2. Internos

5.7.4.2.3. Com base no tempo

5.8. Análise do processo atual (as-is)

5.8.1. Analisa handoffs entre as tarefas

5.8.1.1. Quando um agente do processo passa o trabalho a outro agente.

5.8.1.2. Podem causar atrasos, erros de comunicação e gargalos.

5.8.2. Analisa as próprias tarefas.

5.9. Melhorando os processos de negócio (to-be)

5.9.1. Consiste em remover os problemas que foram identificados no processo atual.

5.9.2. Revisa as regras de negócio

5.9.2.1. Classificação

5.9.2.1.1. Restrições (Constraints)

5.9.2.1.2. Orientação operacional (Operational guidance)

5.9.3. Abordagens usadas

5.9.3.1. Simplificar o processo

5.9.3.2. Estender o processamento

5.9.3.3. Remover gargalos

5.9.3.4. Alterar a sequência de tarefas

5.9.3.5. Redefinir o limite do processo

5.9.3.6. Automatizar o processamento

5.9.3.7. Redesenhar do processo

6. 8. Definindo a solução

6.1. Análise de lacunas (Gap analysis)

6.1.1. Utilizada para examinar

6.1.1.1. O modelo de processos de negócio atual e desejado

6.1.1.2. As competências atuais de um indivíduo e as necessárias para uma função específica

6.1.1.3. Os requisitos de sistema de TI e os recursos oferecidos por um software de prateleira

6.1.2. Usa como base

6.1.2.1. Modelo de Atividade de Negócio (BAM)

6.1.2.1.1. As atividades do BAM devem ser inspecionadas e categorizadas, a fim de identificar aquelas que requerem mais atenção.

6.1.2.2. Modelo POPIT

6.1.2.2.1. Garante que a análise considera todos os elementos necessários.

6.2. Formulando as opções

6.2.1. As propostas precisam ser viáveis em todos os aspectos

6.2.2. As propostas podem mudar aspectos do POPIT para endereçar as necessidades da organização.

6.3. Arquitetura de negócios

6.3.1. Um modelo da empresa que fornece um entendimento comum da organização que pode ser usado para alinhar objetivos estratégicos e demandas táticas.

6.3.2. Objetivos

6.3.2.1. Promover a saúde organizacional

6.3.2.2. Ajudar a cumprir as oportunidades não realizadas

6.3.2.3. Auxiliar o desempenho organizacional em um mercado competitivo

6.3.3. Documenta

6.3.3.1. Capacidades

6.3.3.2. Valores

6.3.3.3. Informação

6.3.3.4. Produtos

6.3.3.5. Fornecedores / parceiros

6.3.3.6. Motivações

6.3.3.7. Unidades de negócio

6.3.3.8. Políticas

6.3.4. Técnicas para definição

6.3.4.1. Modelagem da capacidade de negócio

6.3.4.2. Análise do fluxo de valor

7. 9. Montando um Business and Financial Case

7.1. Propósito de um business case

7.1.1. Serve para justificar uma iniciativa.

7.1.2. Importante que o seu conteúdo seja revisto conforme o projeto avança.

7.2. Identificando opções no business case

7.2.1. Tipos de opções

7.2.1.1. Opções de negócio

7.2.1.1.1. Exploram o que a solução proposta se destina a atingir, em termos de negócios

7.2.1.2. Opções técnicas

7.2.1.2.1. Consideram como a solução será implementada.

7.2.1.2.2. Muitas vezes isso é feito através do uso de tecnologia da informação.

7.2.2. Processo de identificação de opções

7.2.2.1. Identificar opções possíveis

7.2.2.2. Elaborar lista reduzida de opções

7.2.2.3. Avaliar opções

7.2.2.4. Desenvolver o business case considerando as opções

7.2.3. Lista de opções resultantes

7.2.3.1. Opção básica

7.2.3.1.1. Custo mínimo Tempo mínimo Recursos mínimos

7.2.3.2. Opção básica com alguns complementos

7.2.3.2.1. Considera recursos adicionais na opção; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.

7.2.3.3. Tudo

7.2.3.3.1. A solução inteira; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.

7.3. Avaliação da viabilidade do projeto

7.3.1. Tipos de questões para considerar na viabilidade

7.3.1.1. Viabilidade de negócio

7.3.1.1.1. Alinhamento estratégico

7.3.1.1.2. Condições do mercado

7.3.1.1.3. Oportunidade

7.3.1.1.4. Arquitetura corporativa

7.3.1.1.5. Alinhamento organizacional

7.3.1.1.6. Alinhamento cultural

7.3.1.1.7. Competências

7.3.1.1.8. Legalidade/regulamentos

7.3.1.2. Viabilidade técnica

7.3.1.2.1. Disponibilidade

7.3.1.2.2. Confiabilidade

7.3.1.2.3. Manutenabilidade

7.3.1.2.4. Desempenho

7.3.1.2.5. Segurança

7.3.1.2.6. Escalabilidade

7.3.1.2.7. Habilidades técnicas

7.3.1.2.8. Compatibilidade

7.3.1.2.9. Comprovação

7.3.1.3. Viabilidade financeira

7.3.1.3.1. Dentro do orçamento

7.3.1.3.2. Fundos disponíveis

7.3.1.3.3. Necessidade de empréstimo

7.3.1.3.4. ROI aceitável

7.3.1.3.5. Fluxo de caixa aceitável

7.3.1.3.6. Payback rápido

7.3.2. Usando a análise PESTLE

7.3.2.1. Pode ser usada na avaliação da viabilidade de negócio

7.3.2.2. Figura

7.3.3. Análise de campo de força

7.3.3.1. Considera forças dentro e fora da organização, aquelas que irão apoiar a proposta e aquelas que se opõem a ela.

7.3.3.2. Figura

7.3.3.3. Tem que ter certeza de que as forças positivas superam as negativas.

7.3.3.4. As forças podem incluir os fatores PESTLE e também os principais stakeholders da organização.

7.3.3.5. Se concluir que as forças negativas são muito fortes, a proposta não será viável.

7.4. Conteúdo de um business case

7.4.1. Introdução

7.4.1.1. Explica por que o caso de negócio está sendo apresentado.

7.4.2. Sumário executivo

7.4.2.1. Resume o que é mais importante para os tomadores de decisão.

7.4.3. Descrição da situação atual

7.4.3.1. Explica onde os problemas e as oportunidades se encontram.

7.4.4. Opções consideradas

7.4.4.1. Opções a serem consideradas são descritas com uma breve explicação do motivo pelo qual as não recomendadas estão sendo descartadas.

7.4.5. Análise de custos e benefícios

7.4.5.1. Apresenta os benefícios e custos envolvidos com o projeto

7.4.5.2. Classificação dos custos e benefícios

7.4.5.2.1. Tangíveis

7.4.5.2.2. Intangíveis

7.4.6. Avaliação de impacto

7.4.6.1. Impactos com a adoção da proposta.

7.4.7. Avaliação de risco

7.4.7.1. Apresenta um registro de riscos contendo:

7.4.7.1.1. Descrição do risco

7.4.7.1.2. Avaliação de impacto do risco

7.4.7.1.3. Probabilidade de acontecer

7.4.7.1.4. Contramedidas para evitar, reduzir, transferir o risco

7.4.7.1.5. Proprietário do risco que fica responsável por aplicar as contramedidas.

7.4.8. Recomendações

7.4.8.1. Resume o business case para facilitar a tomada de decisão.

7.5. Avaliação de investimento

7.5.1. Retorno (Payback)

7.5.1.1. Calcula em quanto tempo o investimento será pago sem considerar inflação.

7.5.2. Fluxo de caixa descontado

7.5.2.1. Leva em conta o valor do dinheiro tempo.

7.5.3. Taxa interna de retorno (TIR)

7.5.3.1. É elaborada com os cálculos de fluxo de caixa descontado e de valor presente líquido.

7.5.3.2. Quanto maior a TIR de um projeto, melhor ele é.

8. 10. Estabelecendo os requisitos

8.1. Requisito

8.1.1. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.

8.1.2. Uma condição ou capacidade que deve ser suprida por um sistema para satisfazer um contrato ou um padrão.

8.1.3. É o que o sistema deve ter para atender plenamente ao propósito para o qual ele foi criado.

8.2. Engenharia de requisitos

8.2.1. Abordagem mais disciplinada e rigorosa para identificar/definir requisitos

8.3. Estrutura para engenharia de requisitos

8.3.1. Figura

8.3.2. Elicitação de requisitos

8.3.2.1. Faz extração de informações e de requisitos dos stakeholders.

8.3.3. Análise de requisitos

8.3.3.1. Analisa a fim de identificar requisitos conflitantes ou duplicados.

8.3.4. Validação de requisitos

8.3.4.1. Stakeholder revisam os requisitos a fim de acordar e assinam o documento de requisitos.

8.3.5. Documentação de requisitos

8.3.5.1. Preocupa-se com o desenvolvimento de um documento de requisitos bem organizado.

8.3.6. Gerenciamento de requisitos

8.3.6.1. Engloba as atividades necessárias para gerir quaisquer mudanças nos requisitos.

8.4. Atores na engenharia de requisitos

8.4.1. Representantes de negócio

8.4.1.1. Patrocinador do projeto

8.4.1.2. Especialista no assunto (subject matter expert- SME)

8.4.1.3. Usuários de negócio

8.4.2. A equipe do projeto

8.4.2.1. Gerente de projeto

8.4.2.2. Analista de negócio

8.4.2.3. Desenvolvedores

8.4.2.4. Testadores

8.5. Elicitação de requisitos

8.5.1. É uma abordagem proativa para descobrir os requisitos a partir das partes interessadas.

8.5.2. Tipos de conhecimentos das partes interessadas

8.5.2.1. Conhecimento explícito

8.5.2.1.1. É o conhecimento que pode ser facilmente formalizado.

8.5.2.1.2. Níveis

8.5.2.2. Conhecimento tácito

8.5.2.2.1. É o conhecimento que é difícil de ser formalizado, transformado em palavras.

8.5.2.2.2. Níveis

8.5.3. Técnicas de elicitação

8.5.3.1. Entrevista

8.5.3.2. Sombra (Shadow)

8.5.3.3. Workshops

8.5.3.4. Protótipos

8.6. Análise de requisitos

8.6.1. Inclui as seguintes tarefas

8.6.1.1. Categorizar os requisitos

8.6.1.2. Desenhar um conjunto de modelos que reflita os requisitos que foram induzidos

8.6.1.3. Aplicar uma série de filtros

8.6.2. Filtros de requisitos

8.6.2.1. Verificação de sobreposição ou requisitos duplicados

8.6.2.2. Verificação sobreposição ou requisitos duplicados

8.6.2.3. Endereça um problema em vez de um sintoma de problema.

8.6.2.4. Avalia a viabilidade técnica, de negócio ou financeira.

8.6.2.5. Remove conflitos

8.6.2.6. Verifica se o requisito endereça uma necessidade de negócio em vez de uma necessidade de uma solução pré-determinada

8.6.2.7. Confirma se os requisitos atendem aos critérios de qualidade

8.6.3. Requisitos precisam ser SMART

8.6.3.1. S - Específico

8.6.3.1.1. Descreve algo que apresenta um resultado observável.

8.6.3.2. M - Mensurável

8.6.3.2.1. Os requisitos precisam ser passíveis de medições e acompanhamento.

8.6.3.3. A - Alcançável

8.6.3.3.1. Os requisito consideram a viabilidade de negócio, técnica e financeira.

8.6.3.4. R - Relevante

8.6.3.4.1. Os requisitos estão alinhados à visão, missão e objetivos do negócio.

8.6.3.5. T - Tempestivo

8.6.3.5.1. Os requisitos têm uma janela de tempo definida que é consistente com as oportunidades e ou os problemas associados.

8.7. Validação de requisitos

8.7.1. Os requisitos precisam ser revisados e aprovados pelos representantes da empresa e do projeto

8.7.2. Podem ser feitas reuniões para validação.

9. 11. Documentando e gerenciando requisitos

9.1. Catálogo de requisitos

9.1.1. Fornece estrutura e organização para os requisitos.

9.1.2. Categorias de requisitos

9.1.2.1. Geral

9.1.2.1.1. Definem políticas, normas e necessidades de negócio.

9.1.2.2. Técnico

9.1.2.2.1. Relacionados a políticas e restrições técnicas na organização.

9.1.2.3. Funcional

9.1.2.3.1. Quais coisas fazem e as funcionalidades que qualquer solução deveria fornecer.

9.1.2.4. Não-funcional

9.1.2.4.1. Quão bem a solução deve funcionar. Restringem os requisitos funcionais.

9.1.3. Hierarquia de requisitos

9.1.3.1. Figura

9.1.4. Informações de cada requisito

9.1.4.1. Identificação do requisito

9.1.4.1.1. Identificador único.

9.1.4.2. Nome do requisito

9.1.4.2.1. Frase indicando a área de ação.

9.1.4.3. Descrição do requisito

9.1.4.3.1. Definição clara do requisitos (agente + necessidade).

9.1.4.4. Fonte

9.1.4.4.1. Fonte original do requisito.

9.1.4.5. Proprietário

9.1.4.5.1. Tomador de decisão sobre o requisito.

9.1.4.6. Autor

9.1.4.6.1. Nome do analista envolvido na documentação do requisito.

9.1.4.7. Tipo de requisito

9.1.4.7.1. (geral, técnico, funcional, não funcional)

9.1.4.8. Prioridade

9.1.4.8.1. Usa-se a técnica MoSCoW

9.1.4.9. Área de negócio

9.1.4.9.1. Área a que pertence o requisito.

9.1.4.10. Stakeholders

9.1.4.10.1. Pessoas com interesse particular no requisito.

9.1.4.11. Requisito não-funcional associado

9.1.4.11.1. Quando relevante para o requisito funcional.

9.1.4.12. Critério de aceite

9.1.4.12.1. O que precisa ser demonstrado antes de o requisito ser atendido.

9.1.4.13. Requisitos relacionados

9.1.4.13.1. Identificadores de outros requisitos relacionados.

9.1.4.14. Documentos relacionados

9.1.4.14.1. Documentos relacionados.

9.1.4.15. Comentários

9.1.4.15.1. Informações úteis.

9.1.4.16. Justificativa

9.1.4.16.1. Justificativa de negócio para ter este requisito.

9.1.4.17. Resolução

9.1.4.17.1. Resultado do requisito.

9.1.4.18. Histórico de versões

9.1.4.18.1. Histórico do requisito.

9.2. Conteúdo do documento de requisitos

9.2.1. Introdução e plano de fundo

9.2.1.1. Esclarece os objetivos.

9.2.1.2. Declara o escopo do trabalho.

9.2.1.3. Assegura que os stakeholders estão conscientes do contexto do negócio.

9.2.2. Modelos de processo de negócio

9.2.2.1. Descreve as mudanças nos processos de negócio.

9.2.2.2. Modelos de processo “to-be” são relacionados/inseridos no documento.

9.2.3. Modelos de função

9.2.3.1. Mostra a funcionalidade da solução de software proposta (visão da solução).

9.2.3.2. Inclui modelos de contexto e diagramas de caso.

9.2.4. Modelo de dados

9.2.4.1. Refina-se a um nível de detalhes que possibilite à solução ser construída e validada. Ex.: modelagem de relacionamento de entidades e modelagem de classe.

9.2.5. Catálogo de requisitos

9.2.5.1. Descreve cada requisito em detalhes.

9.2.6. Glossário

9.2.6.1. Define terminologia específica ou jargões.

9.3. Gerenciando requisitos

9.3.1. Elementos do gerenciamento de requisitos

9.3.1.1. Identificação de requisitos

9.3.1.2. Referência cruzada de requisitos

9.3.1.3. Origem e propriedade dos requisitos

9.3.1.4. Gerenciamento de configuração

9.3.1.5. Controle de mudanças

9.3.1.6. Software para suportar os requisitos

10. 12. Requisitos de modelagem

10.1. Modelagem de funções de sistema

10.1.1. Serve para representar o que um sistema desempenha em termos de funcionalidades.

10.1.2. Diagramas de casos de uso

10.1.2.1. Descreve o que o sistema faz e não como se faz (funcional).

10.1.2.2. Elementos

10.1.2.2.1. Atores

10.1.2.2.2. Caso de uso

10.1.2.2.3. Limite do sistema

10.1.2.2.4. Associação

10.1.2.2.5. Inclusão

10.1.2.2.6. Extensão

10.2. Modelagem de dados

10.2.1. Um modelo de dados permite que os grupos que utilizam o sistema obtenham informações a partir dele ou validem os dados que serão gravados e recuperados.

10.2.2. Diagramas de relacionamento de entidade

10.2.2.1. A notação utilizada aqui para diagramas de entidade-relacionamento (ERDs) foi desenvolvida por Harry Ellis e Richard Barker.

10.2.2.2. Componentes

10.2.2.2.1. Entidade

10.2.2.2.2. Relacionamentos

10.2.3. Modelos de classe

10.2.3.1. Mostra graficamente as classes em um sistema e suas associações entre si.

10.2.3.2. Elementos

10.2.3.2.1. Objeto

10.2.3.2.2. Classe

10.2.3.2.3. Atributos

10.2.3.2.4. Associações

11. 13. Fornecendo os requisitos

11.1. Questões a considerar para entregando a solução

11.1.1. Contexto

11.1.1.1. Descreve a natureza da organização e o projeto.

11.1.2. Papéis

11.1.2.1. Papéis-chave a serem executados durante o projeto.

11.1.3. Ciclo de vida

11.1.3.1. Processo usado para desenvolver e implementar a solução.

11.1.4. Entregas

11.1.4.1. Saídas ou produtos do projeto. Big Bang? Incrementos?

11.1.5. Abordagem

11.1.5.1. Cobre os métodos e padrões usados durante o ciclo de vida (scrum, por exemplo)

11.1.6. Técnicas

11.1.6.1. Descrevem as técnicas de gestão e desenvolvimento usadas para planejar e documentar o trabalho do projeto.

11.2. Contexto

11.2.1. O contexto para a organização é fundamental para determinar como o projeto será implementado.

11.2.2. Questões-chave a considerar

11.2.2.1. Cultura e filosofia da organização

11.2.2.2. Contexto do negócio para as mudanças propostas

11.2.2.3. Restrições

11.2.2.4. Necessidades para o negócio

11.2.2.5. Motivadores para o projeto

11.3. Ciclos de vida para entrega de soluções

11.3.1. Waterfall (cascata)

11.3.1.1. É uma sequência de estágios nos quais cada um é completado antes de irmos para o próximo.

11.3.1.2. A entrega da solução somente acontece no último estágio do ciclo.

11.3.1.3. Demora mais para a entrega da solução.

11.3.1.4. Figura

11.3.2. Modelo “V”

11.3.2.1. Relaciona os critérios de teste com cada etapa de desenvolvimento

11.3.2.2. Figura

11.3.3. Incremental

11.3.3.1. A entrega da solução é feita por incrementos

11.3.3.2. Figura

11.3.4. Modelo de desenvolvimento iterativo de sistemas

11.3.4.1. Permite que requisitos evoluam ao longo do projeto.

11.3.4.2. As equipes são empoderadas e mais colaborativas.

11.3.4.3. As entregas são mais adaptadas às necessidades atuais dos usuários.

11.3.4.4. As entregas incrementais possibilitam a realização de benefícios mais cedo.

11.3.4.5. Os eventos têm durações pré-determinadas (time-boxing).

12. 14. Fornecendo a solução de negócio

12.1. Papel do AN no ciclo de vida da mudança de negócio

12.1.1. Figura

12.2. Papel do AN no estágio de desenho

12.2.1. Pode ter que construir casos e cenários de testes

12.3. Papel do AN no estágio de implementação

12.3.1. Precisa tentar superar os problemas antes que eles comecem e então fornecer suporte ao pessoal.

12.3.2. Modelo SARAH

12.3.2.1. Estabelece cinco fases das emoções experimentadas quando alguém é confrontado com uma mudança.

12.3.2.2. Figura

12.4. Papel do AN no estágio de realização

12.4.1. O AN cria um plano de benefícios

12.4.1.1. Plano de benefícios

12.4.1.1.1. O contexto ou a visão para a mudança, que descreve o pano de fundo para o projeto.

12.4.1.1.2. Os perfis de benefícios descrevem cada benefício, declarando o que ele é, o seu proprietário, como será medido e a diferença entre o estado “as-is” e ”to-be”.

12.4.1.1.3. A rede de dependência de benefícios mostra as mudanças habilitadoras e atuais requeridas para entregar a mudança.

12.4.1.1.4. As responsabilidades descrevem os proprietários dos benefícios e suas responsabilidades.

12.4.1.1.5. Os procedimentos de acompanhamento descrevem como os benefícios serão rastreados e o processo de relatório associado.

12.4.2. O AN cria um relatóriode benefícios

12.4.2.1. Relatório de realização de benefícios

12.4.2.1.1. Declara se os benefícios foram realizados e o que pode ser feito para remediar qualquer deficiência.

12.4.2.1.2. Fornece uma nova garantia para a gerência sênior de que o custo do projeto foi justificado.

12.4.2.1.3. Fornece entrada para business cases futuros e os ajuda a ter mais sucesso.

12.4.2.1.4. Ajuda a organização ao longo do tempo a aumentar sua habilidade de escolher qual projeto realizar.

13. 1. O que é análise de negócios

13.1. Origens da análise de negócios

13.1.1. Necessidade de ter maior retorno sobre os projetos de TI.

13.2. Desenvolvimento da análise de negócios

13.2.1. O impacto da terceirização

13.2.1.1. Para reduzir custos, muitas empresas tem terceirizados seus serviços de TI.

13.2.1.2. Porém, tem sido necessário gerenciar melhor os fornecedores.

13.2.2. Vantagem competitiva ao usar TI

13.2.2.1. Sistemas de TI tem possibilitado o negócio crescer.

13.2.2.2. Requisitos para novos sistemas de TI precisam ser melhor definidos.

13.2.3. Mudança de negócios bem sucedida

13.2.3.1. O analista de negócios precisa ajudar a identificar as causas dos problemas e as questões a serem resolvidas, e garantir que a solução atenderá às necessidades do negócio.

13.2.4. A importância do analista de negócio

13.2.4.1. Vai ajudar as organizações a obter melhor retorno sobre os projetos de TI.

13.2.5. Analistas de negócios como consultores internos

13.2.5.1. Custam menos que consultores externos.

13.2.5.2. São mais rápidos na atuação, pois não precisam aprender sobre o negócio.

13.2.5.3. O conhecimento fica retido na organização.

13.3. Escopo de trabalho da análise de negócios

13.3.1. Análise estratégica e definição

13.3.1.1. O analista de negócio deveria aconselhar como a tecnologia pode ser utilizada para guiar a mudança de negócio necessária.

13.3.2. Análise de sistemas de TI

13.3.2.1. Muito do trabalho de TI usa técnicas específicas para definir requisitos de TI e avaliar software e inclui modelagem de dados, modelagem funcional e definção de processos de sistema.

13.3.3. Análise de negócio

13.3.3.1. O analista de negócios pode ajudar a resolver questões de negócio locais e recomendar ações que contornam o problema ou alcançam os benefícios de negócio.

13.4. Adotando uma abordagem holística

13.4.1. O modelo POPIT mostra os diferentes pontos de vista que devem ser considerados na identificação de áreas para melhorar o sistema de negócios.

13.5. Papel e as responsabilidades de um analista de negócios

13.5.1. Definição do papel do analista de negócios

13.5.1.1. Um papel consultivo que tem a responsabilidade de investigar e analisar as situações de negócios, identificando e avaliando opções para melhorar os sistemas de negócios, elaborando e definindo requisitos para garantir efetiva implementação e utilização dos sistemas de informação, de acordo com as necessidades do negócio.

13.5.2. Outros aspectos do papel do analista de negócios

13.5.2.1. Áreas de atuação

13.5.2.1.1. Implementação de estratégia

13.5.2.1.2. Elaboração de business case

13.5.2.1.3. Realização de benefícios

13.5.2.1.4. Especificação de requisitos de TI

13.5.2.2. Princípios que devem orientar o analista de negócios

13.5.2.2.1. Causas raiz e não sintomas.

13.5.2.2.2. Melhorias de negócio e não mudanças de TI.

13.5.2.2.3. Opções e não soluções.

13.5.2.2.4. Viabilidade, contribuindo com os requisitos e não atendendo a todas as solicitações.

13.5.2.2.5. O ciclo de vida de toda a mudança nos negócios e não apenas a definição de requisitos.

13.5.2.2.6. Negociar conflitos e não evita-los.

14. 2. As competências de um analista de negócios

14.1. Qualidades pessoais

14.1.1. Comunicação

14.1.2. Construção de relacionamentos

14.1.3. Influência

14.1.4. Trabalho em equipe

14.1.5. Consciência política

14.1.6. Habilidades analíticas e pensamento crítico

14.1.7. Atenção aos detalhes

14.1.8. Resolução de problemas

14.1.9. Liderança

14.1.10. Autoconfiança

14.1.11. Desenvolvimento profissional

14.2. Conhecimento de negócio

14.2.1. Finanças do negócio

14.2.2. Desenvolvimento de business case (caso de negócio)

14.2.3. Conhecimento na área

14.2.4. Especialidade no assunto

14.2.5. Princípios de TI

14.2.6. Estruturas organizacionais

14.2.7. Gestão de fornecedor

14.2.8. Arquitetura do negócio

14.3. Técnicas profissionais

14.3.1. Gestão de projetos

14.3.2. Análise de estratégias

14.3.3. Análise e gestão de stakeholders (partes interessadas)

14.3.4. Técnicas de investigação

14.3.5. Engenharia de requisitos

14.3.6. Modelagem de negócios

14.3.7. Modelagem de dados

14.3.8. Análise de gaps

14.3.9. Habilidades de facilitação

14.3.10. Gestão de portfólio

14.3.11. Gestão de benefícios

14.3.12. Pensamento ágil

14.4. Desenvolvimento de competências

14.4.1. Como desenvolver competências

14.4.1.1. Treinamento

14.4.1.2. Autoestudo

14.4.1.3. Experiência no trabalho

14.4.1.4. Certificação profissional

14.4.2. Framework SFIA

14.4.2.1. É o principal framework para a definição de níveis de competências para a indústria de sistemas de informação ajudará a identificar o nível de analisa correto para cada situação.