1. 14. Fornecendo a solução de negócio
1.1. Papel do AN no ciclo de vida da mudança de negócio
1.1.1. Figura
1.2. Papel do AN no estágio de desenho
1.2.1. Pode ter que construir casos e cenários de testes
1.3. Papel do AN no estágio de implementação
1.3.1. Precisa tentar superar os problemas antes que eles comecem e então fornecer suporte ao pessoal.
1.3.2. Modelo SARAH
1.3.2.1. Estabelece cinco fases das emoções experimentadas quando alguém é confrontado com uma mudança.
1.3.2.2. Figura
1.4. Papel do AN no estágio de realização
1.4.1. O AN cria um plano de benefícios
1.4.1.1. Plano de benefícios
1.4.1.1.1. O contexto ou a visão para a mudança, que descreve o pano de fundo para o projeto.
1.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”.
1.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.
1.4.1.1.4. As responsabilidades descrevem os proprietários dos benefícios e suas responsabilidades.
1.4.1.1.5. Os procedimentos de acompanhamento descrevem como os benefícios serão rastreados e o processo de relatório associado.
1.4.2. O AN cria um relatóriode benefícios
1.4.2.1. Relatório de realização de benefícios
1.4.2.1.1. Declara se os benefícios foram realizados e o que pode ser feito para remediar qualquer deficiência.
1.4.2.1.2. Fornece uma nova garantia para a gerência sênior de que o custo do projeto foi justificado.
1.4.2.1.3. Fornece entrada para business cases futuros e os ajuda a ter mais sucesso.
1.4.2.1.4. Ajuda a organização ao longo do tempo a aumentar sua habilidade de escolher qual projeto realizar.
2. 13. Fornecendo os requisitos
2.1. Questões a considerar para entregando a solução
2.1.1. Contexto
2.1.1.1. Descreve a natureza da organização e o projeto.
2.1.2. Papéis
2.1.2.1. Papéis-chave a serem executados durante o projeto.
2.1.3. Ciclo de vida
2.1.3.1. Processo usado para desenvolver e implementar a solução.
2.1.4. Entregas
2.1.4.1. Saídas ou produtos do projeto. Big Bang? Incrementos?
2.1.5. Abordagem
2.1.5.1. Cobre os métodos e padrões usados durante o ciclo de vida (scrum, por exemplo)
2.1.6. Técnicas
2.1.6.1. Descrevem as técnicas de gestão e desenvolvimento usadas para planejar e documentar o trabalho do projeto.
2.2. Contexto
2.2.1. O contexto para a organização é fundamental para determinar como o projeto será implementado.
2.2.2. Questões-chave a considerar
2.2.2.1. Cultura e filosofia da organização
2.2.2.2. Contexto do negócio para as mudanças propostas
2.2.2.3. Restrições
2.2.2.4. Necessidades para o negócio
2.2.2.5. Motivadores para o projeto
2.3. Ciclos de vida para entrega de soluções
2.3.1. Waterfall (cascata)
2.3.1.1. É uma sequência de estágios nos quais cada um é completado antes de irmos para o próximo.
2.3.1.2. A entrega da solução somente acontece no último estágio do ciclo.
2.3.1.3. Demora mais para a entrega da solução.
2.3.1.4. Figura
2.3.2. Modelo “V”
2.3.2.1. Relaciona os critérios de teste com cada etapa de desenvolvimento
2.3.2.2. Figura
2.3.3. Incremental
2.3.3.1. A entrega da solução é feita por incrementos
2.3.3.2. Figura
2.3.4. Modelo de desenvolvimento iterativo de sistemas
2.3.4.1. Permite que requisitos evoluam ao longo do projeto.
2.3.4.2. As equipes são empoderadas e mais colaborativas.
2.3.4.3. As entregas são mais adaptadas às necessidades atuais dos usuários.
2.3.4.4. As entregas incrementais possibilitam a realização de benefícios mais cedo.
2.3.4.5. Os eventos têm durações pré-determinadas (time-boxing).
3. 12. Requisitos de modelagem
3.1. Modelagem de funções de sistema
3.1.1. Serve para representar o que um sistema desempenha em termos de funcionalidades.
3.1.2. Diagramas de casos de uso
3.1.2.1. Descreve o que o sistema faz e não como se faz (funcional).
3.1.2.2. Elementos
3.1.2.2.1. Atores
3.1.2.2.2. Caso de uso
3.1.2.2.3. Limite do sistema
3.1.2.2.4. Associação
3.1.2.2.5. Inclusão
3.1.2.2.6. Extensão
3.2. Modelagem de dados
3.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.
3.2.2. Diagramas de relacionamento de entidade
3.2.2.1. A notação utilizada aqui para diagramas de entidade-relacionamento (ERDs) foi desenvolvida por Harry Ellis e Richard Barker.
3.2.2.2. Componentes
3.2.2.2.1. Entidade
3.2.2.2.2. Relacionamentos
3.2.3. Modelos de classe
3.2.3.1. Mostra graficamente as classes em um sistema e suas associações entre si.
3.2.3.2. Elementos
3.2.3.2.1. Objeto
3.2.3.2.2. Classe
3.2.3.2.3. Atributos
3.2.3.2.4. Associações
4. 11. Documentando e gerenciando requisitos
4.1. Catálogo de requisitos
4.1.1. Fornece estrutura e organização para os requisitos.
4.1.2. Categorias de requisitos
4.1.2.1. Geral
4.1.2.1.1. Definem políticas, normas e necessidades de negócio.
4.1.2.2. Técnico
4.1.2.2.1. Relacionados a políticas e restrições técnicas na organização.
4.1.2.3. Funcional
4.1.2.3.1. Quais coisas fazem e as funcionalidades que qualquer solução deveria fornecer.
4.1.2.4. Não-funcional
4.1.2.4.1. Quão bem a solução deve funcionar. Restringem os requisitos funcionais.
4.1.3. Hierarquia de requisitos
4.1.3.1. Figura
4.1.4. Informações de cada requisito
4.1.4.1. Identificação do requisito
4.1.4.1.1. Identificador único.
4.1.4.2. Nome do requisito
4.1.4.2.1. Frase indicando a área de ação.
4.1.4.3. Descrição do requisito
4.1.4.3.1. Definição clara do requisitos (agente + necessidade).
4.1.4.4. Fonte
4.1.4.4.1. Fonte original do requisito.
4.1.4.5. Proprietário
4.1.4.5.1. Tomador de decisão sobre o requisito.
4.1.4.6. Autor
4.1.4.6.1. Nome do analista envolvido na documentação do requisito.
4.1.4.7. Tipo de requisito
4.1.4.7.1. (geral, técnico, funcional, não funcional)
4.1.4.8. Prioridade
4.1.4.8.1. Usa-se a técnica MoSCoW
4.1.4.9. Área de negócio
4.1.4.9.1. Área a que pertence o requisito.
4.1.4.10. Stakeholders
4.1.4.10.1. Pessoas com interesse particular no requisito.
4.1.4.11. Requisito não-funcional associado
4.1.4.11.1. Quando relevante para o requisito funcional.
4.1.4.12. Critério de aceite
4.1.4.12.1. O que precisa ser demonstrado antes de o requisito ser atendido.
4.1.4.13. Requisitos relacionados
4.1.4.13.1. Identificadores de outros requisitos relacionados.
4.1.4.14. Documentos relacionados
4.1.4.14.1. Documentos relacionados.
4.1.4.15. Comentários
4.1.4.15.1. Informações úteis.
4.1.4.16. Justificativa
4.1.4.16.1. Justificativa de negócio para ter este requisito.
4.1.4.17. Resolução
4.1.4.17.1. Resultado do requisito.
4.1.4.18. Histórico de versões
4.1.4.18.1. Histórico do requisito.
4.2. Conteúdo do documento de requisitos
4.2.1. Introdução e plano de fundo
4.2.1.1. Esclarece os objetivos.
4.2.1.2. Declara o escopo do trabalho.
4.2.1.3. Assegura que os stakeholders estão conscientes do contexto do negócio.
4.2.2. Modelos de processo de negócio
4.2.2.1. Descreve as mudanças nos processos de negócio.
4.2.2.2. Modelos de processo “to-be” são relacionados/inseridos no documento.
4.2.3. Modelos de função
4.2.3.1. Mostra a funcionalidade da solução de software proposta (visão da solução).
4.2.3.2. Inclui modelos de contexto e diagramas de caso.
4.2.4. Modelo de dados
4.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.
4.2.5. Catálogo de requisitos
4.2.5.1. Descreve cada requisito em detalhes.
4.2.6. Glossário
4.2.6.1. Define terminologia específica ou jargões.
4.3. Gerenciando requisitos
4.3.1. Elementos do gerenciamento de requisitos
4.3.1.1. Identificação de requisitos
4.3.1.2. Referência cruzada de requisitos
4.3.1.3. Origem e propriedade dos requisitos
4.3.1.4. Gerenciamento de configuração
4.3.1.5. Controle de mudanças
4.3.1.6. Software para suportar os requisitos
5. 10. Estabelecendo os requisitos
5.1. Requisito
5.1.1. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.
5.1.2. Uma condição ou capacidade que deve ser suprida por um sistema para satisfazer um contrato ou um padrão.
5.1.3. É o que o sistema deve ter para atender plenamente ao propósito para o qual ele foi criado.
5.2. Engenharia de requisitos
5.2.1. Abordagem mais disciplinada e rigorosa para identificar/definir requisitos
5.3. Estrutura para engenharia de requisitos
5.3.1. Figura
5.3.2. Elicitação de requisitos
5.3.2.1. Faz extração de informações e de requisitos dos stakeholders.
5.3.3. Análise de requisitos
5.3.3.1. Analisa a fim de identificar requisitos conflitantes ou duplicados.
5.3.4. Validação de requisitos
5.3.4.1. Stakeholder revisam os requisitos a fim de acordar e assinam o documento de requisitos.
5.3.5. Documentação de requisitos
5.3.5.1. Preocupa-se com o desenvolvimento de um documento de requisitos bem organizado.
5.3.6. Gerenciamento de requisitos
5.3.6.1. Engloba as atividades necessárias para gerir quaisquer mudanças nos requisitos.
5.4. Atores na engenharia de requisitos
5.4.1. Representantes de negócio
5.4.1.1. Patrocinador do projeto
5.4.1.2. Especialista no assunto (subject matter expert- SME)
5.4.1.3. Usuários de negócio
5.4.2. A equipe do projeto
5.4.2.1. Gerente de projeto
5.4.2.2. Analista de negócio
5.4.2.3. Desenvolvedores
5.4.2.4. Testadores
5.5. Elicitação de requisitos
5.5.1. É uma abordagem proativa para descobrir os requisitos a partir das partes interessadas.
5.5.2. Tipos de conhecimentos das partes interessadas
5.5.2.1. Conhecimento explícito
5.5.2.1.1. É o conhecimento que pode ser facilmente formalizado.
5.5.2.1.2. Níveis
5.5.2.2. Conhecimento tácito
5.5.2.2.1. É o conhecimento que é difícil de ser formalizado, transformado em palavras.
5.5.2.2.2. Níveis
5.5.3. Técnicas de elicitação
5.5.3.1. Entrevista
5.5.3.2. Sombra (Shadow)
5.5.3.3. Workshops
5.5.3.4. Protótipos
5.6. Análise de requisitos
5.6.1. Inclui as seguintes tarefas
5.6.1.1. Categorizar os requisitos
5.6.1.2. Desenhar um conjunto de modelos que reflita os requisitos que foram induzidos
5.6.1.3. Aplicar uma série de filtros
5.6.2. Filtros de requisitos
5.6.2.1. Verificação de sobreposição ou requisitos duplicados
5.6.2.2. Verificação sobreposição ou requisitos duplicados
5.6.2.3. Endereça um problema em vez de um sintoma de problema.
5.6.2.4. Avalia a viabilidade técnica, de negócio ou financeira.
5.6.2.5. Remove conflitos
5.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
5.6.2.7. Confirma se os requisitos atendem aos critérios de qualidade
5.6.3. Requisitos precisam ser SMART
5.6.3.1. S - Específico
5.6.3.1.1. Descreve algo que apresenta um resultado observável.
5.6.3.2. M - Mensurável
5.6.3.2.1. Os requisitos precisam ser passíveis de medições e acompanhamento.
5.6.3.3. A - Alcançável
5.6.3.3.1. Os requisito consideram a viabilidade de negócio, técnica e financeira.
5.6.3.4. R - Relevante
5.6.3.4.1. Os requisitos estão alinhados à visão, missão e objetivos do negócio.
5.6.3.5. T - Tempestivo
5.6.3.5.1. Os requisitos têm uma janela de tempo definida que é consistente com as oportunidades e ou os problemas associados.
5.7. Validação de requisitos
5.7.1. Os requisitos precisam ser revisados e aprovados pelos representantes da empresa e do projeto
5.7.2. Podem ser feitas reuniões para validação.
6. 9. Montando um Business and Financial Case
6.1. Propósito de um business case
6.1.1. Serve para justificar uma iniciativa.
6.1.2. Importante que o seu conteúdo seja revisto conforme o projeto avança.
6.2. Identificando opções no business case
6.2.1. Tipos de opções
6.2.1.1. Opções de negócio
6.2.1.1.1. Exploram o que a solução proposta se destina a atingir, em termos de negócios
6.2.1.2. Opções técnicas
6.2.1.2.1. Consideram como a solução será implementada.
6.2.1.2.2. Muitas vezes isso é feito através do uso de tecnologia da informação.
6.2.2. Processo de identificação de opções
6.2.2.1. Identificar opções possíveis
6.2.2.2. Elaborar lista reduzida de opções
6.2.2.3. Avaliar opções
6.2.2.4. Desenvolver o business case considerando as opções
6.2.3. Lista de opções resultantes
6.2.3.1. Opção básica
6.2.3.1.1. Custo mínimo Tempo mínimo Recursos mínimos
6.2.3.2. Opção básica com alguns complementos
6.2.3.2.1. Considera recursos adicionais na opção; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.
6.2.3.3. Tudo
6.2.3.3.1. A solução inteira; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.
6.3. Avaliação da viabilidade do projeto
6.3.1. Tipos de questões para considerar na viabilidade
6.3.1.1. Viabilidade de negócio
6.3.1.1.1. Alinhamento estratégico
6.3.1.1.2. Condições do mercado
6.3.1.1.3. Oportunidade
6.3.1.1.4. Arquitetura corporativa
6.3.1.1.5. Alinhamento organizacional
6.3.1.1.6. Alinhamento cultural
6.3.1.1.7. Competências
6.3.1.1.8. Legalidade/regulamentos
6.3.1.2. Viabilidade técnica
6.3.1.2.1. Disponibilidade
6.3.1.2.2. Confiabilidade
6.3.1.2.3. Manutenabilidade
6.3.1.2.4. Desempenho
6.3.1.2.5. Segurança
6.3.1.2.6. Escalabilidade
6.3.1.2.7. Habilidades técnicas
6.3.1.2.8. Compatibilidade
6.3.1.2.9. Comprovação
6.3.1.3. Viabilidade financeira
6.3.1.3.1. Dentro do orçamento
6.3.1.3.2. Fundos disponíveis
6.3.1.3.3. Necessidade de empréstimo
6.3.1.3.4. ROI aceitável
6.3.1.3.5. Fluxo de caixa aceitável
6.3.1.3.6. Payback rápido
6.3.2. Usando a análise PESTLE
6.3.2.1. Pode ser usada na avaliação da viabilidade de negócio
6.3.2.2. Figura
6.3.3. Análise de campo de força
6.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.
6.3.3.2. Figura
6.3.3.3. Tem que ter certeza de que as forças positivas superam as negativas.
6.3.3.4. As forças podem incluir os fatores PESTLE e também os principais stakeholders da organização.
6.3.3.5. Se concluir que as forças negativas são muito fortes, a proposta não será viável.
6.4. Conteúdo de um business case
6.4.1. Introdução
6.4.1.1. Explica por que o caso de negócio está sendo apresentado.
6.4.2. Sumário executivo
6.4.2.1. Resume o que é mais importante para os tomadores de decisão.
6.4.3. Descrição da situação atual
6.4.3.1. Explica onde os problemas e as oportunidades se encontram.
6.4.4. Opções consideradas
6.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.
6.4.5. Análise de custos e benefícios
6.4.5.1. Apresenta os benefícios e custos envolvidos com o projeto
6.4.5.2. Classificação dos custos e benefícios
6.4.5.2.1. Tangíveis
6.4.5.2.2. Intangíveis
6.4.6. Avaliação de impacto
6.4.6.1. Impactos com a adoção da proposta.
6.4.7. Avaliação de risco
6.4.7.1. Apresenta um registro de riscos contendo:
6.4.7.1.1. Descrição do risco
6.4.7.1.2. Avaliação de impacto do risco
6.4.7.1.3. Probabilidade de acontecer
6.4.7.1.4. Contramedidas para evitar, reduzir, transferir o risco
6.4.7.1.5. Proprietário do risco que fica responsável por aplicar as contramedidas.
6.4.8. Recomendações
6.4.8.1. Resume o business case para facilitar a tomada de decisão.
6.5. Avaliação de investimento
6.5.1. Retorno (Payback)
6.5.1.1. Calcula em quanto tempo o investimento será pago sem considerar inflação.
6.5.2. Fluxo de caixa descontado
6.5.2.1. Leva em conta o valor do dinheiro tempo.
6.5.3. Taxa interna de retorno (TIR)
6.5.3.1. É elaborada com os cálculos de fluxo de caixa descontado e de valor presente líquido.
6.5.3.2. Quanto maior a TIR de um projeto, melhor ele é.
7. 8. Definindo a solução
7.1. Análise de lacunas (Gap analysis)
7.1.1. Utilizada para examinar
7.1.1.1. O modelo de processos de negócio atual e desejado
7.1.1.2. As competências atuais de um indivíduo e as necessárias para uma função específica
7.1.1.3. Os requisitos de sistema de TI e os recursos oferecidos por um software de prateleira
7.1.2. Usa como base
7.1.2.1. Modelo de Atividade de Negócio (BAM)
7.1.2.1.1. As atividades do BAM devem ser inspecionadas e categorizadas, a fim de identificar aquelas que requerem mais atenção.
7.1.2.2. Modelo POPIT
7.1.2.2.1. Garante que a análise considera todos os elementos necessários.
7.2. Formulando as opções
7.2.1. As propostas precisam ser viáveis em todos os aspectos
7.2.2. As propostas podem mudar aspectos do POPIT para endereçar as necessidades da organização.
7.3. Arquitetura de negócios
7.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.
7.3.2. Objetivos
7.3.2.1. Promover a saúde organizacional
7.3.2.2. Ajudar a cumprir as oportunidades não realizadas
7.3.2.3. Auxiliar o desempenho organizacional em um mercado competitivo
7.3.3. Documenta
7.3.3.1. Capacidades
7.3.3.2. Valores
7.3.3.3. Informação
7.3.3.4. Produtos
7.3.3.5. Fornecedores / parceiros
7.3.3.6. Motivações
7.3.3.7. Unidades de negócio
7.3.3.8. Políticas
7.3.4. Técnicas para definição
7.3.4.1. Modelagem da capacidade de negócio
7.3.4.2. Análise do fluxo de valor
8. 1. O que é análise de negócios
8.1. Origens da análise de negócios
8.1.1. Necessidade de ter maior retorno sobre os projetos de TI.
8.2. Desenvolvimento da análise de negócios
8.2.1. O impacto da terceirização
8.2.1.1. Para reduzir custos, muitas empresas tem terceirizados seus serviços de TI.
8.2.1.2. Porém, tem sido necessário gerenciar melhor os fornecedores.
8.2.2. Vantagem competitiva ao usar TI
8.2.2.1. Sistemas de TI tem possibilitado o negócio crescer.
8.2.2.2. Requisitos para novos sistemas de TI precisam ser melhor definidos.
8.2.3. Mudança de negócios bem sucedida
8.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.
8.2.4. A importância do analista de negócio
8.2.4.1. Vai ajudar as organizações a obter melhor retorno sobre os projetos de TI.
8.2.5. Analistas de negócios como consultores internos
8.2.5.1. Custam menos que consultores externos.
8.2.5.2. São mais rápidos na atuação, pois não precisam aprender sobre o negócio.
8.2.5.3. O conhecimento fica retido na organização.
8.3. Escopo de trabalho da análise de negócios
8.3.1. Análise estratégica e definição
8.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.
8.3.2. Análise de sistemas de TI
8.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.
8.3.3. Análise de negócio
8.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.
8.4. Adotando uma abordagem holística
8.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.
8.5. Papel e as responsabilidades de um analista de negócios
8.5.1. Definição do papel do analista de negócios
8.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.
8.5.2. Outros aspectos do papel do analista de negócios
8.5.2.1. Áreas de atuação
8.5.2.1.1. Implementação de estratégia
8.5.2.1.2. Elaboração de business case
8.5.2.1.3. Realização de benefícios
8.5.2.1.4. Especificação de requisitos de TI
8.5.2.2. Princípios que devem orientar o analista de negócios
8.5.2.2.1. Causas raiz e não sintomas.
8.5.2.2.2. Melhorias de negócio e não mudanças de TI.
8.5.2.2.3. Opções e não soluções.
8.5.2.2.4. Viabilidade, contribuindo com os requisitos e não atendendo a todas as solicitações.
8.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.
8.5.2.2.6. Negociar conflitos e não evita-los.
9. 2. As competências de um analista de negócios
9.1. Qualidades pessoais
9.1.1. Comunicação
9.1.2. Construção de relacionamentos
9.1.3. Influência
9.1.4. Trabalho em equipe
9.1.5. Consciência política
9.1.6. Habilidades analíticas e pensamento crítico
9.1.7. Atenção aos detalhes
9.1.8. Resolução de problemas
9.1.9. Liderança
9.1.10. Autoconfiança
9.1.11. Desenvolvimento profissional
9.2. Conhecimento de negócio
9.2.1. Finanças do negócio
9.2.2. Desenvolvimento de business case (caso de negócio)
9.2.3. Conhecimento na área
9.2.4. Especialidade no assunto
9.2.5. Princípios de TI
9.2.6. Estruturas organizacionais
9.2.7. Gestão de fornecedor
9.2.8. Arquitetura do negócio
9.3. Técnicas profissionais
9.3.1. Gestão de projetos
9.3.2. Análise de estratégias
9.3.3. Análise e gestão de stakeholders (partes interessadas)
9.3.4. Técnicas de investigação
9.3.5. Engenharia de requisitos
9.3.6. Modelagem de negócios
9.3.7. Modelagem de dados
9.3.8. Análise de gaps
9.3.9. Habilidades de facilitação
9.3.10. Gestão de portfólio
9.3.11. Gestão de benefícios
9.3.12. Pensamento ágil
9.4. Desenvolvimento de competências
9.4.1. Como desenvolver competências
9.4.1.1. Treinamento
9.4.1.2. Autoestudo
9.4.1.3. Experiência no trabalho
9.4.1.4. Certificação profissional
9.4.2. Framework SFIA
9.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.
10. 3. Análise da estratégia
10.1. Contexto para a estratégia
10.1.1. Existem algumas grandes mudanças que as organizações enfrentam e que o desenvolvimento da estratégia tenta moderar:
10.1.1.1. Há as mudanças nas formas em que estamos empregados.
10.1.1.2. A sociedade mudou.
10.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.
10.1.1.4. O mundo é cheio de contradições
10.1.1.4.1. Global x local.
10.1.1.4.2. Estruturas de organização centralizadas x descentralizadas.
10.2. Definição de estratégia
10.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
10.3. Formas comuns de desenvolver estratégias
10.3.1. A partir de um indivíduo (fundador ou CEO)
10.3.2. A partir das experiências e pontos de vista dos gestores internos
10.3.3. A partir de ideias geradas pelas pessoas que fazem o trabalho
10.3.4. A partir de um processo formal de planejamento
10.4. Análise do ambiente externo
10.4.1. Análise PESTLE
10.4.1.1. Analisa os fatores
10.4.1.1.1. Político
10.4.1.1.2. Econômico
10.4.1.1.3. Sociocultural
10.4.1.1.4. Tecnológico
10.4.1.1.5. Legal
10.4.1.1.6. Ecológico
10.4.2. 5 forças de Porter
10.4.2.1. Ameaça de novos entrantes
10.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
10.4.2.2. Poder de barganha dos compradores
10.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
10.4.2.3. Ameaça de produtos ou serviços substitutos
10.4.2.3.1. É alto quando: A necessidade do produto pode ser substituída
10.4.2.4. Poder de barganha dos fornecedores
10.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
10.4.2.5. Concorrentes da indústria – rivalidade entre as empresas
10.4.2.5.1. A rivalidade é alta quando: Há muitas empresas competindo Compradores podem facilmente migrar para elas A indústria tem custos fixos
10.4.3. Análise de cenários “E se”
10.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.
10.4.3.2. É aplicada em conjunto com a análise PESTLE.
10.5. Análise do ambiente interno
10.5.1. Análise MOST
10.5.1.1. Serve para compreender o posicionamento dos negócios atuais.
10.5.1.2. Analista os fatores
10.5.1.2.1. Missão
10.5.1.2.2. Objetivos
10.5.1.2.3. Estratégia
10.5.1.2.4. Táticas
10.5.2. Auditoria de recursos
10.5.2.1. Analisa recursos da organização para identificar pontos fortes e fracos
10.5.2.2. Tipos de recursos a serem analisados
10.5.2.2.1. Tangíveis
10.5.2.2.2. Intangíveis
10.5.3. Matriz BCG
10.5.3.1. Desenvolvida pela Boston Consulting Group
10.5.3.2. Faz análise de portfólio de produtos para orientar as estratégias
10.5.3.3. Classificação dos produtos
10.5.3.3.1. Estrela
10.5.3.3.2. Gato selvagem (ou criança-problema)
10.5.3.3.3. Vaca leiteira
10.5.3.3.4. Cão (ou abacaxi para nós)
10.5.3.4. Matriz
10.5.4. Análise SWOT
10.5.4.1. Analisa forças, fraquezas, oportunidades e ameaças
10.5.4.2. Pode ser utilizada tanto para análise de ambiente externo como internos
10.5.4.3. Figura
10.6. Estratégia de execução
10.6.1. Modelo McKinsey 7-S
10.6.1.1. Supõe que todas as organizações são constituídas por 7 componentes
10.6.1.2. 7 Componentes
10.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
10.6.2. Balanced Business Scorecard
10.6.2.1. Ajuda a estabelecer temas de metas estratégicas em 4 perspectivas
10.6.2.1.1. Financeiro
10.6.2.1.2. Cliente
10.6.2.1.3. Processos internos
10.6.2.1.4. Aprendizado & crescimento
10.6.3. Fatores Críticos de Sucesso e Indicadores de Desempenho (KPI)
10.6.3.1. Podem ser identificados com o uso do Balanced Scorecard
10.6.3.2. Critical success factors (CSFs)
10.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.
10.6.3.3. Key performance indicators (KPIs)
10.6.3.3.1. Instrumentos usados para medir o desempenho de uma organização, vão indicar se o CSF está sendo atendido.
11. 4. O modelo de processo de análise de negócios
11.1. Abordagem para a resolução de problemas de Isaksen e Treffinger
11.1.1. Propósito
11.1.1.1. Fornece uma sequência lógica para resolve qualquer tipo de problema.
11.1.2. Imagem
11.1.3. Estágios deste modelo
11.1.3.1. Constatação de confusão (Mess finding)
11.1.3.1.1. Entende sobre a complexidade da situação problemática.
11.1.3.2. Exploração dos dados (Data finding)
11.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
11.1.3.3. Definição do problema (Problem finding)
11.1.3.3.1. Define qual é o problema a ser resolvido.
11.1.3.4. Produção de ideias (Idea finding)
11.1.3.4.1. Gera ideias para resolver o problema.
11.1.3.5. Descoberta de soluções (Solution finding)
11.1.3.5.1. Encontra uma solução a partir das ideias geradas.
11.1.3.6. Construção de aceitação (Acceptance finding)
11.1.3.6.1. Obtém aceitação da solução proposta.
11.2. Modelo de processo de análise de negócios
11.2.1. Propósito
11.2.1.1. Define as principais estágios de um projeto de análise de negócios.
11.2.2. Imagem
11.2.3. Estágios deste modelo
11.2.3.1. Investigar a situação
11.2.3.1.1. Propósito
11.2.3.1.2. Procedimentos
11.2.3.1.3. Entradas
11.2.3.1.4. Saídas
11.2.3.1.5. Técnicas
11.2.3.2. Considerar as perspectivas
11.2.3.2.1. Propósito
11.2.3.2.2. Procedimentos
11.2.3.2.3. Entradas
11.2.3.2.4. Saídas
11.2.3.2.5. Técnicas
11.2.3.3. Analisar as necessidades
11.2.3.3.1. Propósito
11.2.3.3.2. Procedimentos
11.2.3.3.3. Entradas
11.2.3.3.4. Saídas
11.2.3.3.5. Técnicas
11.2.3.4. Avaliar as opções
11.2.3.4.1. Propósito
11.2.3.4.2. Procedimentos
11.2.3.4.3. Entradas
11.2.3.4.4. Saídas
11.2.3.4.5. Técnicas
11.2.3.5. Definir os requisitos
11.2.3.5.1. Propósito
11.2.3.5.2. Procedimento
11.2.3.5.3. Entrada
11.2.3.5.4. Saída
11.2.3.5.5. Técnicas
11.2.3.6. Entregar mudanças
11.2.3.6.1. Propósito
11.2.3.6.2. Procedimentos
11.2.3.6.3. Entradas
11.2.3.6.4. Saídas
11.2.3.6.5. Técnicas
12. 5. Técnicas de investigação
12.1. Técnicas qualitativas
12.1.1. Entrevistas
12.1.1.1. Propósito
12.1.1.1.1. Uma conversa para obter informações
12.1.1.2. Vantagens
12.1.1.2.1. Facilitam o relacionamento com as partes envolvidas
12.1.1.2.2. Ajudam a compreender a perspectiva das pessoas envolvidas com o sistema do negócio
12.1.1.2.3. Consideram o que as pessoas fazem, suas preocupações e o que elas querem dos novos processos ou sistemas
12.1.1.2.4. Exploram novas áreas conforme elas aparecem.
12.1.1.2.5. Permitem identificar e recolher documentação que os clientes usam.
12.1.1.2.6. Ajudam a entender diferentes pontos de vista das partes envolvidas.
12.1.1.2.7. Proporcionam uma oportunidade para estudar melhor o ambiente .
12.1.1.3. Desvantagens
12.1.1.3.1. Levam tempo para planejar e podem ser caras.
12.1.1.3.2. Tomam o tempo do entrevistado.
12.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.
12.1.1.4. Preparação para entrevistas
12.1.1.4.1. Identificar quem entrevistar em cada nível da organização
12.1.1.4.2. Escolher as pessoas a entrevistar.
12.1.1.4.3. Identificar o que perguntar.
12.1.1.4.4. Planejar local e agenda.
12.1.1.5. Condução da entrevista
12.1.1.5.1. Estrutura básica de execução
12.1.1.6. Acompanhamento da entrevista
12.1.1.6.1. Enviar anotações para os entrevistados confirmar o que foi falado.
12.1.1.6.2. Incluir as anotações aprovadas na documentação do projeto.
12.1.2. Observação
12.1.2.1. Propósito
12.1.2.1.1. Consistem em observar o local de trabalho e os funcionários realizando o seu trabalho para obter informações.
12.1.2.2. Vantagens
12.1.2.2.1. Fornece uma melhor compreensão dos problemas e dificuldades enfrentados.
12.1.2.2.2. Ajuda a preparar as perguntas apropriadas para uma entrevista mais aprofundada.
12.1.2.2.3. Ajuda a encontrar soluções viáveis que são mais propensas a serem aceitas.
12.1.2.3. Desvantagens
12.1.2.3.1. Ser observado pode ser irritante.
12.1.2.4. Abordagens
12.1.2.4.1. Observação formal
12.1.2.4.2. Análise de protocolo
12.1.2.4.3. Sombreamento/Sombra (shadowing)
12.1.2.4.4. Estudos etnográficos
12.1.3. Workshops (oficinas)
12.1.3.1. Propósito
12.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.
12.1.3.2. Vantagens
12.1.3.2.1. Fornecem uma visão ampla da área sob investigação.
12.1.3.2.2. Aumentam velocidade e produtividade na entrevistas.
12.1.3.2.3. Facilitam obter aceitação para o projeto.
12.1.3.2.4. Ajudam a obter uma visão de consenso ou acordo de grupo.
12.1.3.3. Desvantagens
12.1.3.3.1. Podem demorar para ser organizados.
12.1.3.3.2. Pode acontecer de um participante dominar a discussão.
12.1.3.3.3. Pode ser difícil garantir que os participantes tenham o nível necessário de autoridade.
12.1.3.4. Considerações para preparação de um workshop
12.1.3.4.1. O objetivo do workshop
12.1.3.4.2. As pessoas a serem convidadas
12.1.3.4.3. A estrutura e as técnicas a serem utilizadas
12.1.3.4.4. O local adequado
12.1.3.5. Realização do workshop
12.1.3.5.1. Começa discutindo os objetivos do workshop.
12.1.3.5.2. O facilitador precisa garantir que as questões sejam discutidas.
12.1.3.5.3. Registrar o que foi discutido.
12.1.3.6. Técnicas
12.1.3.6.1. Para facilitar a descoberta
12.1.3.6.2. Para facilitar a visualização do que foi discutido
12.1.4. Cenários
12.1.4.1. Propósito
12.1.4.1.1. Consiste em contar a história de uma tarefa ou transação
12.1.4.2. Vantagens
12.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
12.1.4.2.2. Ajuda a garantir que não existam elementos tomados como certos e o problema do conhecimento tácito é abordado
12.1.4.2.3. Ajuda ao usuário do negócio a visualizar todas as situações possíveis e remove a incerteza
12.1.4.3. Desvantagens
12.1.4.3.1. Pode ser de desenvolvimento demorado
12.1.4.3.2. Pode se tornar complexo, especialmente onde há vários caminhos alternativos
12.1.4.4. Processo para o desenvolvimento de cenários
12.1.4.4.1. Imagem do processo
12.1.5. Prototipagem
12.1.5.1. Propósito
12.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.
12.1.5.2. Vantagens
12.1.5.2.1. Esclarece qualquer incerteza por parte dos analistas e confirmar para o usuário que compreendemos o que pediram.
12.1.5.2.2. Ajuda o usuário a identificar novas exigências.
12.1.5.2.3. Demonstra a aparência do sistema proposto.
12.1.5.2.4. Valida os requisitos do sistema e identificar os eventuais erros.
12.1.5.2.5. Fornece um meio de avaliar caminhos de navegação e sistema de desempenho.
12.1.5.3. Desvantagens
12.1.5.3.1. O ciclo de prototipagem pode sair do controle com infinitas iterações ocorrendo.
12.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.
12.1.5.3.3. As expectativas dos usuários podem ser aumentadas desnecessariamente pela falta de limitação da aparência final do sistema.
12.2. Técnicas quantitativas
12.2.1. Pesquisas ou questionários
12.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.
12.2.2. Registros de propósito específico
12.2.2.1. São formas de coletar dados utilizados pelo analista.
12.2.3. Amostragem de atividade
12.2.3.1. Pode ser usada quando é necessário conhecer como as pessoas dividem o seu tempo de trabalho entre uma gama de atividades.
12.2.4. Análise de documentos
12.2.4.1. Envolve a análise de amostras de documentos originais para descobrir informações sobre uma organização, processo ou sistema.
12.3. Documentação da situação atual
12.3.1. Desenhos/imagens ricos (rich picture)
12.3.1.1. Fornecem uma visão geral de toda uma situação do negócio
12.3.1.2. Sem notação fixa.
12.3.1.3. Exemplo
12.3.2. Mapas mentais (Mind Maps)
12.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.
12.3.2.2. Exemplo
12.3.3. Modelo de negócio
12.3.3.1. Serve para mostrar as tarefas em um processo, os atores responsáveis pela sua execução e o fluxo do processo.
12.3.3.2. Exemplo
12.3.4. Mapa de espaguete
12.3.4.1. Serve para mostrar o movimento e as interações dos stakholders em um ambiente particular ao executar tarefas e processos particulares
12.3.4.2. Exemplo
12.3.5. Diagrama de espinha de peixe
12.3.5.1. Ajuda a explorar/compreender possíveis causas relacionadas a um problema.
12.3.5.2. Exemplo
13. 6. Análise e gestão de partes interessadas
13.1. Definição de stakeholder
13.1.1. Qualquer um que tem um interesse ou pode ser afetado por uma questão sob consideração.
13.2. Categorias de stakeholders
13.2.1. Clientes
13.2.2. Parceiros
13.2.3. Fornecedores
13.2.4. Concorrentes
13.2.5. Reguladores
13.2.6. Proprietários
13.2.7. Empregados
13.2.8. Gestores
13.3. Matriz de poder e interesse
13.3.1. Refere-se ao nível de influência que o stakeholder exerce sobre o projeto
13.3.2. Serve para definir as estratégias de gerenciamento de cada parte
13.3.3. Imagem
13.3.4. Classificação de atitude de cada stakeholder
13.3.4.1. Campeão
13.3.4.1.1. Trabalha ativamente para o sucesso do projeto
13.3.4.2. Apoiador
13.3.4.2.1. A favor do projeto, mas provavelmente não muito ativo na sua promoção
13.3.4.3. Neutro
13.3.4.3.1. Não expressa opinião a favor ou contra o projeto
13.3.4.4. Crítico
13.3.4.4.1. Não é a favor do projeto, mas provavelmente não se opõe ativamente
13.3.4.5. Opositor
13.3.4.5.1. Trabalha ativamente para atrapalhar, impedir ou inviabilizar o projeto
13.3.4.6. Bloqueador
13.3.4.6.1. Obstrui o progresso, possivelmente por razões fora do projeto em si
13.4. Plano/avaliação de partes interessadas
13.4.1. Define como cada parte interessada será abordada
13.4.2. Contém
13.4.2.1. Nome do stakeholder
13.4.2.2. Cargo
13.4.2.3. Poder e influência atual (alto, médio, baixo)
13.4.2.4. Atual interesse (alto, médio, baixo)
13.4.2.5. Questões de interesse
13.4.2.6. Atitude atual (campeão, apoiador...)
13.4.2.7. Apoio desejado (alto, médio, baixo)
13.4.2.8. Papel desejado (Podemos desejar ter essa parte interessada ativamente envolvida no projeto)
13.4.2.9. Ações desejadas (O que gostaríamos que a parte interessada faça)
13.4.2.10. Mensagens a transmitir (a ênfase que deve ser colocada em qualquer comunicação a esse público)
13.4.2.11. Ações e comunicados (definimos exatamente que ações vamos tomar em relação a essa parte interessada)
13.5. Matriz RACI
13.5.1. Define o envolvimento de cada parte interessada
13.5.2. Atribuições
13.5.2.1. R = Responsible
13.5.2.2. A = Accountable
13.5.2.3. C = Consulted
13.5.2.4. I = Informed
13.6. Metodologia soft systems (SSM)
13.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.
13.7. CATWOE
13.7.1. Técnica para analisar as perspectivas de cada skaholder
13.7.2. Elementos
13.7.2.1. Customers (clientes)
13.7.2.2. Actors (atores),
13.7.2.3. Transformation (transformação)
13.7.2.4. World View (visão de mundo)
13.7.2.5. Owner (proprierário)
13.7.2.6. Environmental (ambiente)
13.8. Modelos de atividade de negócios (BAM)
13.8.1. Fornecem um modelo conceitual do “o que” se espera a ser cumprido, em uma perspectiva particular das partes interessadas.
13.8.2. É elaborado um BAM para cada perspectiva de uma parte interessada.
13.8.3. Tipos de atividades mapeadas
13.8.3.1. Execução (Doing)
13.8.3.1.1. Derivadas do aspecto “Transformação” do CATWOE
13.8.3.2. Viabilização (Enabling)
13.8.3.2.1. Asseguram que os recursos e as instalações necessárias para as atividades de “execução" estão disponíveis
13.8.3.3. Planejamento (Planning)
13.8.3.3.1. Planejam as atividades de execução e biabilização.
13.8.3.4. Monitoramento (Monitoring)
13.8.3.4.1. Definem as expectativas de desempenho.
13.8.3.5. Controlling (Controle)
13.8.3.5.1. Revelam como está o desempenho.
14. 7. Modelagem de processos de negócios
14.1. Definição de processo de negócio
14.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.
14.2. Razões para criar um Modelo de processo de negócio
14.2.1. Entender como o processo existente funciona
14.2.2. Explicar aos funcionários o processo e como sua tarefa se relaciona às outras
14.2.3. Ajudar a garantir a coerência da abordagem
14.2.4. Identificar os problemas e fraquezas existentes
14.3. Tipos de visões de uma organização
14.3.1. Visão funcional
14.3.1.1. Organização estruturada por departamentos.
14.3.1.2. Cada departamento é especializado em algumas atividades.
14.3.1.3. Desvantagens
14.3.1.3.1. Não é orientada ao cliente.
14.3.1.3.2. Não facilita a comunicação entre o pessoal de diversos de departamentos.
14.3.1.3.3. Fornece uma visão estática não mostrando o que a empresa faz ao longo do tempo.
14.3.2. Visão por processo
14.3.2.1. Mostra como a empresa funciona por processos.
14.3.2.2. Vantanges
14.3.2.2.1. Orientada ao resultado para o cliente.
14.3.2.2.2. Elimina as barreiras de comunicação entre departamentos.
14.3.3. Visão alternativa
14.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
14.3.3.2. Figura
14.4. Mapa de processos
14.4.1. Mostra os processos de ponta a ponta que convertem entradas do fornecedor em saídas para o cliente.
14.5. Cadeia de valor de Porter
14.5.1. Designa uma série de atividades relacionadas e desenvolvidas pela empresa a fim de satisfazer as necessidades dos clientes
14.5.2. É um ponto de partida para elaborar um mapa de processos da organização.
14.5.3. Figura
14.5.4. Tipos de atividades representadas
14.5.4.1. Atividades primárias
14.5.4.1.1. Relacionadas diretamente com o que a empresa produz, vende ou transfere ao cliente e assistência pós venda.
14.5.4.1.2. Exemplos
14.5.4.2. Atividades de suporte
14.5.4.2.1. Sustentam as atividades primárias fornecendo insumos, tecnologia, recursos humanos e outras funções.
14.5.4.2.2. Exemplos
14.6. Proposta de valor
14.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
14.6.2. Atributos que compõem a proposta de valor
14.7. Modelo de processo de negócio
14.7.1. É uma representação simplificada de um processo
14.7.2. Componentes de um modelo
14.7.2.1. Tarefas
14.7.2.2. Fluxo do processo
14.7.2.3. Pontos de decisão
14.7.2.4. Agentes
14.7.2.5. Resultados do processo
14.7.3. Notações mais usadas
14.7.3.1. UML
14.7.3.2. BPMN
14.7.4. Eventos de negócio
14.7.4.1. Desencadeia um processo de negócio.
14.7.4.2. Tipos de eventos
14.7.4.2.1. Externos
14.7.4.2.2. Internos
14.7.4.2.3. Com base no tempo
14.8. Análise do processo atual (as-is)
14.8.1. Analisa handoffs entre as tarefas
14.8.1.1. Quando um agente do processo passa o trabalho a outro agente.
14.8.1.2. Podem causar atrasos, erros de comunicação e gargalos.
14.8.2. Analisa as próprias tarefas.
14.9. Melhorando os processos de negócio (to-be)
14.9.1. Consiste em remover os problemas que foram identificados no processo atual.
14.9.2. Revisa as regras de negócio
14.9.2.1. Classificação
14.9.2.1.1. Restrições (Constraints)
14.9.2.1.2. Orientação operacional (Operational guidance)
14.9.3. Abordagens usadas
14.9.3.1. Simplificar o processo
14.9.3.2. Estender o processamento
14.9.3.3. Remover gargalos
14.9.3.4. Alterar a sequência de tarefas
14.9.3.5. Redefinir o limite do processo
14.9.3.6. Automatizar o processamento
14.9.3.7. Redesenhar do processo