1. 1. O que é análise de negócios
1.1. Origens da análise de negócios
1.1.1. Necessidade de ter maior retorno sobre os projetos de TI.
1.2. Desenvolvimento da análise de negócios
1.2.1. O impacto da terceirização
1.2.1.1. Para reduzir custos, muitas empresas tem terceirizados seus serviços de TI.
1.2.1.2. Porém, tem sido necessário gerenciar melhor os fornecedores.
1.2.2. Vantagem competitiva ao usar TI
1.2.2.1. Sistemas de TI tem possibilitado o negócio crescer.
1.2.2.2. Requisitos para novos sistemas de TI precisam ser melhor definidos.
1.2.3. Mudança de negócios bem sucedida
1.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.
1.2.4. A importância do analista de negócio
1.2.4.1. Vai ajudar as organizações a obter melhor retorno sobre os projetos de TI.
1.2.5. Analistas de negócios como consultores internos
1.2.5.1. Custam menos que consultores externos.
1.2.5.2. São mais rápidos na atuação, pois não precisam aprender sobre o negócio.
1.2.5.3. O conhecimento fica retido na organização.
1.3. Escopo de trabalho da análise de negócios
1.3.1. Análise estratégica e definição
1.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.
1.3.2. Análise de sistemas de TI
1.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.
1.3.3. Análise de negócio
1.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.
1.4. Adotando uma abordagem holística
1.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.
1.5. Papel e as responsabilidades de um analista de negócios
1.5.1. Definição do papel do analista de negócios
1.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.
1.5.2. Outros aspectos do papel do analista de negócios
1.5.2.1. Áreas de atuação
1.5.2.1.1. Implementação de estratégia
1.5.2.1.2. Elaboração de business case
1.5.2.1.3. Realização de benefícios
1.5.2.1.4. Especificação de requisitos de TI
1.5.2.2. Princípios que devem orientar o analista de negócios
1.5.2.2.1. Causas raiz e não sintomas.
1.5.2.2.2. Melhorias de negócio e não mudanças de TI.
1.5.2.2.3. Opções e não soluções.
1.5.2.2.4. Viabilidade, contribuindo com os requisitos e não atendendo a todas as solicitações.
1.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.
1.5.2.2.6. Negociar conflitos e não evita-los.
2. 2. As competências de um analista de negócios
2.1. Qualidades pessoais
2.1.1. Comunicação
2.1.2. Construção de relacionamentos
2.1.3. Influência
2.1.4. Trabalho em equipe
2.1.5. Consciência política
2.1.6. Habilidades analíticas e pensamento crítico
2.1.7. Atenção aos detalhes
2.1.8. Resolução de problemas
2.1.9. Liderança
2.1.10. Autoconfiança
2.1.11. Desenvolvimento profissional
2.2. Conhecimento de negócio
2.2.1. Finanças do negócio
2.2.2. Desenvolvimento de business case (caso de negócio)
2.2.3. Conhecimento na área
2.2.4. Especialidade no assunto
2.2.5. Princípios de TI
2.2.6. Estruturas organizacionais
2.2.7. Gestão de fornecedor
2.2.8. Arquitetura do negócio
2.3. Técnicas profissionais
2.3.1. Gestão de projetos
2.3.2. Análise de estratégias
2.3.3. Análise e gestão de stakeholders (partes interessadas)
2.3.4. Técnicas de investigação
2.3.5. Engenharia de requisitos
2.3.6. Modelagem de negócios
2.3.7. Modelagem de dados
2.3.8. Análise de gaps
2.3.9. Habilidades de facilitação
2.3.10. Gestão de portfólio
2.3.11. Gestão de benefícios
2.3.12. Pensamento ágil
2.4. Desenvolvimento de competências
2.4.1. Como desenvolver competências
2.4.1.1. Treinamento
2.4.1.2. Autoestudo
2.4.1.3. Experiência no trabalho
2.4.1.4. Certificação profissional
2.4.2. Framework SFIA
2.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.
3. 3. Análise da estratégia
3.1. Contexto para a estratégia
3.1.1. Existem algumas grandes mudanças que as organizações enfrentam e que o desenvolvimento da estratégia tenta moderar:
3.1.1.1. Há as mudanças nas formas em que estamos empregados.
3.1.1.2. A sociedade mudou.
3.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.
3.1.1.4. O mundo é cheio de contradições
3.1.1.4.1. Global x local.
3.1.1.4.2. Estruturas de organização centralizadas x descentralizadas.
3.2. Definição de estratégia
3.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
3.3. Formas comuns de desenvolver estratégias
3.3.1. A partir de um indivíduo (fundador ou CEO)
3.3.2. A partir das experiências e pontos de vista dos gestores internos
3.3.3. A partir de ideias geradas pelas pessoas que fazem o trabalho
3.3.4. A partir de um processo formal de planejamento
3.4. Análise do ambiente externo
3.4.1. Análise PESTLE
3.4.1.1. Analisa os fatores
3.4.1.1.1. Político
3.4.1.1.2. Econômico
3.4.1.1.3. Sociocultural
3.4.1.1.4. Tecnológico
3.4.1.1.5. Legal
3.4.1.1.6. Ecológico
3.4.2. 5 forças de Porter
3.4.2.1. Ameaça de novos entrantes
3.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
3.4.2.2. Poder de barganha dos compradores
3.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
3.4.2.3. Ameaça de produtos ou serviços substitutos
3.4.2.3.1. É alto quando: A necessidade do produto pode ser substituída
3.4.2.4. Poder de barganha dos fornecedores
3.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
3.4.2.5. Concorrentes da indústria – rivalidade entre as empresas
3.4.2.5.1. A rivalidade é alta quando: Há muitas empresas competindo Compradores podem facilmente migrar para elas A indústria tem custos fixos
3.4.3. Análise de cenários “E se”
3.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.
3.4.3.2. É aplicada em conjunto com a análise PESTLE.
3.5. Análise do ambiente interno
3.5.1. Análise MOST
3.5.1.1. Serve para compreender o posicionamento dos negócios atuais.
3.5.1.2. Analista os fatores
3.5.1.2.1. Missão
3.5.1.2.2. Objetivos
3.5.1.2.3. Estratégia
3.5.1.2.4. Táticas
3.5.2. Auditoria de recursos
3.5.2.1. Analisa recursos da organização para identificar pontos fortes e fracos
3.5.2.2. Tipos de recursos a serem analisados
3.5.2.2.1. Tangíveis
3.5.2.2.2. Intangíveis
3.5.3. Matriz BCG
3.5.3.1. Desenvolvida pela Boston Consulting Group
3.5.3.2. Faz análise de portfólio de produtos para orientar as estratégias
3.5.3.3. Classificação dos produtos
3.5.3.3.1. Estrela
3.5.3.3.2. Gato selvagem (ou criança-problema)
3.5.3.3.3. Vaca leiteira
3.5.3.3.4. Cão (ou abacaxi para nós)
3.5.3.4. Matriz
3.5.4. Análise SWOT
3.5.4.1. Analisa forças, fraquezas, oportunidades e ameaças
3.5.4.2. Pode ser utilizada tanto para análise de ambiente externo como internos
3.5.4.3. Figura
3.6. Estratégia de execução
3.6.1. Modelo McKinsey 7-S
3.6.1.1. Supõe que todas as organizações são constituídas por 7 componentes
3.6.1.2. 7 Componentes
3.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
3.6.2. Balanced Business Scorecard
3.6.2.1. Ajuda a estabelecer temas de metas estratégicas em 4 perspectivas
3.6.2.1.1. Financeiro
3.6.2.1.2. Cliente
3.6.2.1.3. Processos internos
3.6.2.1.4. Aprendizado & crescimento
3.6.3. Fatores Críticos de Sucesso e Indicadores de Desempenho (KPI)
3.6.3.1. Podem ser identificados com o uso do Balanced Scorecard
3.6.3.2. Critical success factors (CSFs)
3.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.
3.6.3.3. Key performance indicators (KPIs)
3.6.3.3.1. Instrumentos usados para medir o desempenho de uma organização, vão indicar se o CSF está sendo atendido.
4. 4. O modelo de processo de análise de negócios
4.1. Abordagem para a resolução de problemas de Isaksen e Treffinger
4.1.1. Propósito
4.1.1.1. Fornece uma sequência lógica para resolve qualquer tipo de problema.
4.1.2. Imagem
4.1.3. Estágios deste modelo
4.1.3.1. Constatação de confusão (Mess finding)
4.1.3.1.1. Entende sobre a complexidade da situação problemática.
4.1.3.2. Exploração dos dados (Data finding)
4.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
4.1.3.3. Definição do problema (Problem finding)
4.1.3.3.1. Define qual é o problema a ser resolvido.
4.1.3.4. Produção de ideias (Idea finding)
4.1.3.4.1. Gera ideias para resolver o problema.
4.1.3.5. Descoberta de soluções (Solution finding)
4.1.3.5.1. Encontra uma solução a partir das ideias geradas.
4.1.3.6. Construção de aceitação (Acceptance finding)
4.1.3.6.1. Obtém aceitação da solução proposta.
4.2. Modelo de processo de análise de negócios
4.2.1. Propósito
4.2.1.1. Define as principais estágios de um projeto de análise de negócios.
4.2.2. Imagem
4.2.3. Estágios deste modelo
4.2.3.1. Investigar a situação
4.2.3.1.1. Propósito
4.2.3.1.2. Procedimentos
4.2.3.1.3. Entradas
4.2.3.1.4. Saídas
4.2.3.1.5. Técnicas
4.2.3.2. Considerar as perspectivas
4.2.3.2.1. Propósito
4.2.3.2.2. Procedimentos
4.2.3.2.3. Entradas
4.2.3.2.4. Saídas
4.2.3.2.5. Técnicas
4.2.3.3. Analisar as necessidades
4.2.3.3.1. Propósito
4.2.3.3.2. Procedimentos
4.2.3.3.3. Entradas
4.2.3.3.4. Saídas
4.2.3.3.5. Técnicas
4.2.3.4. Avaliar as opções
4.2.3.4.1. Propósito
4.2.3.4.2. Procedimentos
4.2.3.4.3. Entradas
4.2.3.4.4. Saídas
4.2.3.4.5. Técnicas
4.2.3.5. Definir os requisitos
4.2.3.5.1. Propósito
4.2.3.5.2. Procedimento
4.2.3.5.3. Entrada
4.2.3.5.4. Saída
4.2.3.5.5. Técnicas
4.2.3.6. Entregar mudanças
4.2.3.6.1. Propósito
4.2.3.6.2. Procedimentos
4.2.3.6.3. Entradas
4.2.3.6.4. Saídas
4.2.3.6.5. Técnicas
5. 5. Técnicas de investigação
5.1. Técnicas qualitativas
5.1.1. Entrevistas
5.1.1.1. Propósito
5.1.1.1.1. Uma conversa para obter informações
5.1.1.2. Vantagens
5.1.1.2.1. Facilitam o relacionamento com as partes envolvidas
5.1.1.2.2. Ajudam a compreender a perspectiva das pessoas envolvidas com o sistema do negócio
5.1.1.2.3. Consideram o que as pessoas fazem, suas preocupações e o que elas querem dos novos processos ou sistemas
5.1.1.2.4. Exploram novas áreas conforme elas aparecem.
5.1.1.2.5. Permitem identificar e recolher documentação que os clientes usam.
5.1.1.2.6. Ajudam a entender diferentes pontos de vista das partes envolvidas.
5.1.1.2.7. Proporcionam uma oportunidade para estudar melhor o ambiente .
5.1.1.3. Desvantagens
5.1.1.3.1. Levam tempo para planejar e podem ser caras.
5.1.1.3.2. Tomam o tempo do entrevistado.
5.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.
5.1.1.4. Preparação para entrevistas
5.1.1.4.1. Identificar quem entrevistar em cada nível da organização
5.1.1.4.2. Escolher as pessoas a entrevistar.
5.1.1.4.3. Identificar o que perguntar.
5.1.1.4.4. Planejar local e agenda.
5.1.1.5. Condução da entrevista
5.1.1.5.1. Estrutura básica de execução
5.1.1.6. Acompanhamento da entrevista
5.1.1.6.1. Enviar anotações para os entrevistados confirmar o que foi falado.
5.1.1.6.2. Incluir as anotações aprovadas na documentação do projeto.
5.1.2. Observação
5.1.2.1. Propósito
5.1.2.1.1. Consistem em observar o local de trabalho e os funcionários realizando o seu trabalho para obter informações.
5.1.2.2. Vantagens
5.1.2.2.1. Fornece uma melhor compreensão dos problemas e dificuldades enfrentados.
5.1.2.2.2. Ajuda a preparar as perguntas apropriadas para uma entrevista mais aprofundada.
5.1.2.2.3. Ajuda a encontrar soluções viáveis que são mais propensas a serem aceitas.
5.1.2.3. Desvantagens
5.1.2.3.1. Ser observado pode ser irritante.
5.1.2.4. Abordagens
5.1.2.4.1. Observação formal
5.1.2.4.2. Análise de protocolo
5.1.2.4.3. Sombreamento/Sombra (shadowing)
5.1.2.4.4. Estudos etnográficos
5.1.3. Workshops (oficinas)
5.1.3.1. Propósito
5.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.
5.1.3.2. Vantagens
5.1.3.2.1. Fornecem uma visão ampla da área sob investigação.
5.1.3.2.2. Aumentam velocidade e produtividade na entrevistas.
5.1.3.2.3. Facilitam obter aceitação para o projeto.
5.1.3.2.4. Ajudam a obter uma visão de consenso ou acordo de grupo.
5.1.3.3. Desvantagens
5.1.3.3.1. Podem demorar para ser organizados.
5.1.3.3.2. Pode acontecer de um participante dominar a discussão.
5.1.3.3.3. Pode ser difícil garantir que os participantes tenham o nível necessário de autoridade.
5.1.3.4. Considerações para preparação de um workshop
5.1.3.4.1. O objetivo do workshop
5.1.3.4.2. As pessoas a serem convidadas
5.1.3.4.3. A estrutura e as técnicas a serem utilizadas
5.1.3.4.4. O local adequado
5.1.3.5. Realização do workshop
5.1.3.5.1. Começa discutindo os objetivos do workshop.
5.1.3.5.2. O facilitador precisa garantir que as questões sejam discutidas.
5.1.3.5.3. Registrar o que foi discutido.
5.1.3.6. Técnicas
5.1.3.6.1. Para facilitar a descoberta
5.1.3.6.2. Para facilitar a visualização do que foi discutido
5.1.4. Cenários
5.1.4.1. Propósito
5.1.4.1.1. Consiste em contar a história de uma tarefa ou transação
5.1.4.2. Vantagens
5.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
5.1.4.2.2. Ajuda a garantir que não existam elementos tomados como certos e o problema do conhecimento tácito é abordado
5.1.4.2.3. Ajuda ao usuário do negócio a visualizar todas as situações possíveis e remove a incerteza
5.1.4.3. Desvantagens
5.1.4.3.1. Pode ser de desenvolvimento demorado
5.1.4.3.2. Pode se tornar complexo, especialmente onde há vários caminhos alternativos
5.1.4.4. Processo para o desenvolvimento de cenários
5.1.4.4.1. Imagem do processo
5.1.5. Prototipagem
5.1.5.1. Propósito
5.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.
5.1.5.2. Vantagens
5.1.5.2.1. Esclarece qualquer incerteza por parte dos analistas e confirmar para o usuário que compreendemos o que pediram.
5.1.5.2.2. Ajuda o usuário a identificar novas exigências.
5.1.5.2.3. Demonstra a aparência do sistema proposto.
5.1.5.2.4. Valida os requisitos do sistema e identificar os eventuais erros.
5.1.5.2.5. Fornece um meio de avaliar caminhos de navegação e sistema de desempenho.
5.1.5.3. Desvantagens
5.1.5.3.1. O ciclo de prototipagem pode sair do controle com infinitas iterações ocorrendo.
5.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.
5.1.5.3.3. As expectativas dos usuários podem ser aumentadas desnecessariamente pela falta de limitação da aparência final do sistema.
5.2. Técnicas quantitativas
5.2.1. Pesquisas ou questionários
5.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.
5.2.2. Registros de propósito específico
5.2.2.1. São formas de coletar dados utilizados pelo analista.
5.2.3. Amostragem de atividade
5.2.3.1. Pode ser usada quando é necessário conhecer como as pessoas dividem o seu tempo de trabalho entre uma gama de atividades.
5.2.4. Análise de documentos
5.2.4.1. Envolve a análise de amostras de documentos originais para descobrir informações sobre uma organização, processo ou sistema.
5.3. Documentação da situação atual
5.3.1. Desenhos/imagens ricos (rich picture)
5.3.1.1. Fornecem uma visão geral de toda uma situação do negócio
5.3.1.2. Sem notação fixa.
5.3.1.3. Exemplo
5.3.2. Mapas mentais (Mind Maps)
5.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.
5.3.2.2. Exemplo
5.3.3. Modelo de negócio
5.3.3.1. Serve para mostrar as tarefas em um processo, os atores responsáveis pela sua execução e o fluxo do processo.
5.3.3.2. Exemplo
5.3.4. Mapa de espaguete
5.3.4.1. Serve para mostrar o movimento e as interações dos stakholders em um ambiente particular ao executar tarefas e processos particulares
5.3.4.2. Exemplo
5.3.5. Diagrama de espinha de peixe
5.3.5.1. Ajuda a explorar/compreender possíveis causas relacionadas a um problema.
5.3.5.2. Exemplo
6. 6. Análise e gestão de partes interessadas
6.1. Definição de stakeholder
6.1.1. Qualquer um que tem um interesse ou pode ser afetado por uma questão sob consideração.
6.2. Categorias de stakeholders
6.2.1. Clientes
6.2.2. Parceiros
6.2.3. Fornecedores
6.2.4. Concorrentes
6.2.5. Reguladores
6.2.6. Proprietários
6.2.7. Empregados
6.2.8. Gestores
6.3. Matriz de poder e interesse
6.3.1. Refere-se ao nível de influência que o stakeholder exerce sobre o projeto
6.3.2. Serve para definir as estratégias de gerenciamento de cada parte
6.3.3. Imagem
6.3.4. Classificação de atitude de cada stakeholder
6.3.4.1. Campeão
6.3.4.1.1. Trabalha ativamente para o sucesso do projeto
6.3.4.2. Apoiador
6.3.4.2.1. A favor do projeto, mas provavelmente não muito ativo na sua promoção
6.3.4.3. Neutro
6.3.4.3.1. Não expressa opinião a favor ou contra o projeto
6.3.4.4. Crítico
6.3.4.4.1. Não é a favor do projeto, mas provavelmente não se opõe ativamente
6.3.4.5. Opositor
6.3.4.5.1. Trabalha ativamente para atrapalhar, impedir ou inviabilizar o projeto
6.3.4.6. Bloqueador
6.3.4.6.1. Obstrui o progresso, possivelmente por razões fora do projeto em si
6.4. Plano/avaliação de partes interessadas
6.4.1. Define como cada parte interessada será abordada
6.4.2. Contém
6.4.2.1. Nome do stakeholder
6.4.2.2. Cargo
6.4.2.3. Poder e influência atual (alto, médio, baixo)
6.4.2.4. Atual interesse (alto, médio, baixo)
6.4.2.5. Questões de interesse
6.4.2.6. Atitude atual (campeão, apoiador...)
6.4.2.7. Apoio desejado (alto, médio, baixo)
6.4.2.8. Papel desejado (Podemos desejar ter essa parte interessada ativamente envolvida no projeto)
6.4.2.9. Ações desejadas (O que gostaríamos que a parte interessada faça)
6.4.2.10. Mensagens a transmitir (a ênfase que deve ser colocada em qualquer comunicação a esse público)
6.4.2.11. Ações e comunicados (definimos exatamente que ações vamos tomar em relação a essa parte interessada)
6.5. Matriz RACI
6.5.1. Define o envolvimento de cada parte interessada
6.5.2. Atribuições
6.5.2.1. R = Responsible
6.5.2.2. A = Accountable
6.5.2.3. C = Consulted
6.5.2.4. I = Informed
6.6. Metodologia soft systems (SSM)
6.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.
6.7. CATWOE
6.7.1. Técnica para analisar as perspectivas de cada skaholder
6.7.2. Elementos
6.7.2.1. Customers (clientes)
6.7.2.2. Actors (atores),
6.7.2.3. Transformation (transformação)
6.7.2.4. World View (visão de mundo)
6.7.2.5. Owner (proprierário)
6.7.2.6. Environmental (ambiente)
6.8. Modelos de atividade de negócios (BAM)
6.8.1. Fornecem um modelo conceitual do “o que” se espera a ser cumprido, em uma perspectiva particular das partes interessadas.
6.8.2. É elaborado um BAM para cada perspectiva de uma parte interessada.
6.8.3. Tipos de atividades mapeadas
6.8.3.1. Execução (Doing)
6.8.3.1.1. Derivadas do aspecto “Transformação” do CATWOE
6.8.3.2. Viabilização (Enabling)
6.8.3.2.1. Asseguram que os recursos e as instalações necessárias para as atividades de “execução" estão disponíveis
6.8.3.3. Planejamento (Planning)
6.8.3.3.1. Planejam as atividades de execução e biabilização.
6.8.3.4. Monitoramento (Monitoring)
6.8.3.4.1. Definem as expectativas de desempenho.
6.8.3.5. Controlling (Controle)
6.8.3.5.1. Revelam como está o desempenho.
7. 7. Modelagem de processos de negócios
7.1. Definição de processo de negócio
7.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.
7.2. Razões para criar um Modelo de processo de negócio
7.2.1. Entender como o processo existente funciona
7.2.2. Explicar aos funcionários o processo e como sua tarefa se relaciona às outras
7.2.3. Ajudar a garantir a coerência da abordagem
7.2.4. Identificar os problemas e fraquezas existentes
7.3. Tipos de visões de uma organização
7.3.1. Visão funcional
7.3.1.1. Organização estruturada por departamentos.
7.3.1.2. Cada departamento é especializado em algumas atividades.
7.3.1.3. Desvantagens
7.3.1.3.1. Não é orientada ao cliente.
7.3.1.3.2. Não facilita a comunicação entre o pessoal de diversos de departamentos.
7.3.1.3.3. Fornece uma visão estática não mostrando o que a empresa faz ao longo do tempo.
7.3.2. Visão por processo
7.3.2.1. Mostra como a empresa funciona por processos.
7.3.2.2. Vantanges
7.3.2.2.1. Orientada ao resultado para o cliente.
7.3.2.2.2. Elimina as barreiras de comunicação entre departamentos.
7.3.3. Visão alternativa
7.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
7.3.3.2. Figura
7.4. Mapa de processos
7.4.1. Mostra os processos de ponta a ponta que convertem entradas do fornecedor em saídas para o cliente.
7.5. Cadeia de valor de Porter
7.5.1. Designa uma série de atividades relacionadas e desenvolvidas pela empresa a fim de satisfazer as necessidades dos clientes
7.5.2. É um ponto de partida para elaborar um mapa de processos da organização.
7.5.3. Figura
7.5.4. Tipos de atividades representadas
7.5.4.1. Atividades primárias
7.5.4.1.1. Relacionadas diretamente com o que a empresa produz, vende ou transfere ao cliente e assistência pós venda.
7.5.4.1.2. Exemplos
7.5.4.2. Atividades de suporte
7.5.4.2.1. Sustentam as atividades primárias fornecendo insumos, tecnologia, recursos humanos e outras funções.
7.5.4.2.2. Exemplos
7.6. Proposta de valor
7.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
7.6.2. Atributos que compõem a proposta de valor
7.7. Modelo de processo de negócio
7.7.1. É uma representação simplificada de um processo
7.7.2. Componentes de um modelo
7.7.2.1. Tarefas
7.7.2.2. Fluxo do processo
7.7.2.3. Pontos de decisão
7.7.2.4. Agentes
7.7.2.5. Resultados do processo
7.7.3. Notações mais usadas
7.7.3.1. UML
7.7.3.2. BPMN
7.7.4. Eventos de negócio
7.7.4.1. Desencadeia um processo de negócio.
7.7.4.2. Tipos de eventos
7.7.4.2.1. Externos
7.7.4.2.2. Internos
7.7.4.2.3. Com base no tempo
7.8. Análise do processo atual (as-is)
7.8.1. Analisa handoffs entre as tarefas
7.8.1.1. Quando um agente do processo passa o trabalho a outro agente.
7.8.1.2. Podem causar atrasos, erros de comunicação e gargalos.
7.8.2. Analisa as próprias tarefas.
7.9. Melhorando os processos de negócio (to-be)
7.9.1. Consiste em remover os problemas que foram identificados no processo atual.
7.9.2. Revisa as regras de negócio
7.9.2.1. Classificação
7.9.2.1.1. Restrições (Constraints)
7.9.2.1.2. Orientação operacional (Operational guidance)
7.9.3. Abordagens usadas
7.9.3.1. Simplificar o processo
7.9.3.2. Estender o processamento
7.9.3.3. Remover gargalos
7.9.3.4. Alterar a sequência de tarefas
7.9.3.5. Redefinir o limite do processo
7.9.3.6. Automatizar o processamento
7.9.3.7. Redesenhar do processo
8. 8. Definindo a solução
8.1. Análise de lacunas (Gap analysis)
8.1.1. Utilizada para examinar
8.1.1.1. O modelo de processos de negócio atual e desejado
8.1.1.2. As competências atuais de um indivíduo e as necessárias para uma função específica
8.1.1.3. Os requisitos de sistema de TI e os recursos oferecidos por um software de prateleira
8.1.2. Usa como base
8.1.2.1. Modelo de Atividade de Negócio (BAM)
8.1.2.1.1. As atividades do BAM devem ser inspecionadas e categorizadas, a fim de identificar aquelas que requerem mais atenção.
8.1.2.2. Modelo POPIT
8.1.2.2.1. Garante que a análise considera todos os elementos necessários.
8.2. Formulando as opções
8.2.1. As propostas precisam ser viáveis em todos os aspectos
8.2.2. As propostas podem mudar aspectos do POPIT para endereçar as necessidades da organização.
8.3. Arquitetura de negócios
8.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.
8.3.2. Objetivos
8.3.2.1. Promover a saúde organizacional
8.3.2.2. Ajudar a cumprir as oportunidades não realizadas
8.3.2.3. Auxiliar o desempenho organizacional em um mercado competitivo
8.3.3. Documenta
8.3.3.1. Capacidades
8.3.3.2. Valores
8.3.3.3. Informação
8.3.3.4. Produtos
8.3.3.5. Fornecedores / parceiros
8.3.3.6. Motivações
8.3.3.7. Unidades de negócio
8.3.3.8. Políticas
8.3.4. Técnicas para definição
8.3.4.1. Modelagem da capacidade de negócio
8.3.4.2. Análise do fluxo de valor
9. 9. Montando um Business and Financial Case
9.1. Propósito de um business case
9.1.1. Serve para justificar uma iniciativa.
9.1.2. Importante que o seu conteúdo seja revisto conforme o projeto avança.
9.2. Identificando opções no business case
9.2.1. Tipos de opções
9.2.1.1. Opções de negócio
9.2.1.1.1. Exploram o que a solução proposta se destina a atingir, em termos de negócios
9.2.1.2. Opções técnicas
9.2.1.2.1. Consideram como a solução será implementada.
9.2.1.2.2. Muitas vezes isso é feito através do uso de tecnologia da informação.
9.2.2. Processo de identificação de opções
9.2.2.1. Identificar opções possíveis
9.2.2.2. Elaborar lista reduzida de opções
9.2.2.3. Avaliar opções
9.2.2.4. Desenvolver o business case considerando as opções
9.2.3. Lista de opções resultantes
9.2.3.1. Opção básica
9.2.3.1.1. Custo mínimo Tempo mínimo Recursos mínimos
9.2.3.2. Opção básica com alguns complementos
9.2.3.2.1. Considera recursos adicionais na opção; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.
9.2.3.3. Tudo
9.2.3.3.1. A solução inteira; Leva mais tempo; Custa mais; Tem maior complexidade para implementar.
9.3. Avaliação da viabilidade do projeto
9.3.1. Tipos de questões para considerar na viabilidade
9.3.1.1. Viabilidade de negócio
9.3.1.1.1. Alinhamento estratégico
9.3.1.1.2. Condições do mercado
9.3.1.1.3. Oportunidade
9.3.1.1.4. Arquitetura corporativa
9.3.1.1.5. Alinhamento organizacional
9.3.1.1.6. Alinhamento cultural
9.3.1.1.7. Competências
9.3.1.1.8. Legalidade/regulamentos
9.3.1.2. Viabilidade técnica
9.3.1.2.1. Disponibilidade
9.3.1.2.2. Confiabilidade
9.3.1.2.3. Manutenabilidade
9.3.1.2.4. Desempenho
9.3.1.2.5. Segurança
9.3.1.2.6. Escalabilidade
9.3.1.2.7. Habilidades técnicas
9.3.1.2.8. Compatibilidade
9.3.1.2.9. Comprovação
9.3.1.3. Viabilidade financeira
9.3.1.3.1. Dentro do orçamento
9.3.1.3.2. Fundos disponíveis
9.3.1.3.3. Necessidade de empréstimo
9.3.1.3.4. ROI aceitável
9.3.1.3.5. Fluxo de caixa aceitável
9.3.1.3.6. Payback rápido
9.3.2. Usando a análise PESTLE
9.3.2.1. Pode ser usada na avaliação da viabilidade de negócio
9.3.2.2. Figura
9.3.3. Análise de campo de força
9.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.
9.3.3.2. Figura
9.3.3.3. Tem que ter certeza de que as forças positivas superam as negativas.
9.3.3.4. As forças podem incluir os fatores PESTLE e também os principais stakeholders da organização.
9.3.3.5. Se concluir que as forças negativas são muito fortes, a proposta não será viável.
9.4. Conteúdo de um business case
9.4.1. Introdução
9.4.1.1. Explica por que o caso de negócio está sendo apresentado.
9.4.2. Sumário executivo
9.4.2.1. Resume o que é mais importante para os tomadores de decisão.
9.4.3. Descrição da situação atual
9.4.3.1. Explica onde os problemas e as oportunidades se encontram.
9.4.4. Opções consideradas
9.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.
9.4.5. Análise de custos e benefícios
9.4.5.1. Apresenta os benefícios e custos envolvidos com o projeto
9.4.5.2. Classificação dos custos e benefícios
9.4.5.2.1. Tangíveis
9.4.5.2.2. Intangíveis
9.4.6. Avaliação de impacto
9.4.6.1. Impactos com a adoção da proposta.
9.4.7. Avaliação de risco
9.4.7.1. Apresenta um registro de riscos contendo:
9.4.7.1.1. Descrição do risco
9.4.7.1.2. Avaliação de impacto do risco
9.4.7.1.3. Probabilidade de acontecer
9.4.7.1.4. Contramedidas para evitar, reduzir, transferir o risco
9.4.7.1.5. Proprietário do risco que fica responsável por aplicar as contramedidas.
9.4.8. Recomendações
9.4.8.1. Resume o business case para facilitar a tomada de decisão.
9.5. Avaliação de investimento
9.5.1. Retorno (Payback)
9.5.1.1. Calcula em quanto tempo o investimento será pago sem considerar inflação.
9.5.2. Fluxo de caixa descontado
9.5.2.1. Leva em conta o valor do dinheiro tempo.
9.5.3. Taxa interna de retorno (TIR)
9.5.3.1. É elaborada com os cálculos de fluxo de caixa descontado e de valor presente líquido.
9.5.3.2. Quanto maior a TIR de um projeto, melhor ele é.
10. 10. Estabelecendo os requisitos
10.1. Requisito
10.1.1. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.
10.1.2. Uma condição ou capacidade que deve ser suprida por um sistema para satisfazer um contrato ou um padrão.
10.1.3. É o que o sistema deve ter para atender plenamente ao propósito para o qual ele foi criado.
10.2. Engenharia de requisitos
10.2.1. Abordagem mais disciplinada e rigorosa para identificar/definir requisitos
10.3. Estrutura para engenharia de requisitos
10.3.1. Figura
10.3.2. Elicitação de requisitos
10.3.2.1. Faz extração de informações e de requisitos dos stakeholders.
10.3.3. Análise de requisitos
10.3.3.1. Analisa a fim de identificar requisitos conflitantes ou duplicados.
10.3.4. Validação de requisitos
10.3.4.1. Stakeholder revisam os requisitos a fim de acordar e assinam o documento de requisitos.
10.3.5. Documentação de requisitos
10.3.5.1. Preocupa-se com o desenvolvimento de um documento de requisitos bem organizado.
10.3.6. Gerenciamento de requisitos
10.3.6.1. Engloba as atividades necessárias para gerir quaisquer mudanças nos requisitos.
10.4. Atores na engenharia de requisitos
10.4.1. Representantes de negócio
10.4.1.1. Patrocinador do projeto
10.4.1.2. Especialista no assunto (subject matter expert- SME)
10.4.1.3. Usuários de negócio
10.4.2. A equipe do projeto
10.4.2.1. Gerente de projeto
10.4.2.2. Analista de negócio
10.4.2.3. Desenvolvedores
10.4.2.4. Testadores
10.5. Elicitação de requisitos
10.5.1. É uma abordagem proativa para descobrir os requisitos a partir das partes interessadas.
10.5.2. Tipos de conhecimentos das partes interessadas
10.5.2.1. Conhecimento explícito
10.5.2.1.1. É o conhecimento que pode ser facilmente formalizado.
10.5.2.1.2. Níveis
10.5.2.2. Conhecimento tácito
10.5.2.2.1. É o conhecimento que é difícil de ser formalizado, transformado em palavras.
10.5.2.2.2. Níveis
10.5.3. Técnicas de elicitação
10.5.3.1. Entrevista
10.5.3.2. Sombra (Shadow)
10.5.3.3. Workshops
10.5.3.4. Protótipos
10.6. Análise de requisitos
10.6.1. Inclui as seguintes tarefas
10.6.1.1. Categorizar os requisitos
10.6.1.2. Desenhar um conjunto de modelos que reflita os requisitos que foram induzidos
10.6.1.3. Aplicar uma série de filtros
10.6.2. Filtros de requisitos
10.6.2.1. Verificação de sobreposição ou requisitos duplicados
10.6.2.2. Verificação sobreposição ou requisitos duplicados
10.6.2.3. Endereça um problema em vez de um sintoma de problema.
10.6.2.4. Avalia a viabilidade técnica, de negócio ou financeira.
10.6.2.5. Remove conflitos
10.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
10.6.2.7. Confirma se os requisitos atendem aos critérios de qualidade
10.6.3. Requisitos precisam ser SMART
10.6.3.1. S - Específico
10.6.3.1.1. Descreve algo que apresenta um resultado observável.
10.6.3.2. M - Mensurável
10.6.3.2.1. Os requisitos precisam ser passíveis de medições e acompanhamento.
10.6.3.3. A - Alcançável
10.6.3.3.1. Os requisito consideram a viabilidade de negócio, técnica e financeira.
10.6.3.4. R - Relevante
10.6.3.4.1. Os requisitos estão alinhados à visão, missão e objetivos do negócio.
10.6.3.5. T - Tempestivo
10.6.3.5.1. Os requisitos têm uma janela de tempo definida que é consistente com as oportunidades e ou os problemas associados.
10.7. Validação de requisitos
10.7.1. Os requisitos precisam ser revisados e aprovados pelos representantes da empresa e do projeto
10.7.2. Podem ser feitas reuniões para validação.
11. 11. Documentando e gerenciando requisitos
11.1. Catálogo de requisitos
11.1.1. Fornece estrutura e organização para os requisitos.
11.1.2. Categorias de requisitos
11.1.2.1. Geral
11.1.2.1.1. Definem políticas, normas e necessidades de negócio.
11.1.2.2. Técnico
11.1.2.2.1. Relacionados a políticas e restrições técnicas na organização.
11.1.2.3. Funcional
11.1.2.3.1. Quais coisas fazem e as funcionalidades que qualquer solução deveria fornecer.
11.1.2.4. Não-funcional
11.1.2.4.1. Quão bem a solução deve funcionar. Restringem os requisitos funcionais.
11.1.3. Hierarquia de requisitos
11.1.3.1. Figura
11.1.4. Informações de cada requisito
11.1.4.1. Identificação do requisito
11.1.4.1.1. Identificador único.
11.1.4.2. Nome do requisito
11.1.4.2.1. Frase indicando a área de ação.
11.1.4.3. Descrição do requisito
11.1.4.3.1. Definição clara do requisitos (agente + necessidade).
11.1.4.4. Fonte
11.1.4.4.1. Fonte original do requisito.
11.1.4.5. Proprietário
11.1.4.5.1. Tomador de decisão sobre o requisito.
11.1.4.6. Autor
11.1.4.6.1. Nome do analista envolvido na documentação do requisito.
11.1.4.7. Tipo de requisito
11.1.4.7.1. (geral, técnico, funcional, não funcional)
11.1.4.8. Prioridade
11.1.4.8.1. Usa-se a técnica MoSCoW
11.1.4.9. Área de negócio
11.1.4.9.1. Área a que pertence o requisito.
11.1.4.10. Stakeholders
11.1.4.10.1. Pessoas com interesse particular no requisito.
11.1.4.11. Requisito não-funcional associado
11.1.4.11.1. Quando relevante para o requisito funcional.
11.1.4.12. Critério de aceite
11.1.4.12.1. O que precisa ser demonstrado antes de o requisito ser atendido.
11.1.4.13. Requisitos relacionados
11.1.4.13.1. Identificadores de outros requisitos relacionados.
11.1.4.14. Documentos relacionados
11.1.4.14.1. Documentos relacionados.
11.1.4.15. Comentários
11.1.4.15.1. Informações úteis.
11.1.4.16. Justificativa
11.1.4.16.1. Justificativa de negócio para ter este requisito.
11.1.4.17. Resolução
11.1.4.17.1. Resultado do requisito.
11.1.4.18. Histórico de versões
11.1.4.18.1. Histórico do requisito.
11.2. Conteúdo do documento de requisitos
11.2.1. Introdução e plano de fundo
11.2.1.1. Esclarece os objetivos.
11.2.1.2. Declara o escopo do trabalho.
11.2.1.3. Assegura que os stakeholders estão conscientes do contexto do negócio.
11.2.2. Modelos de processo de negócio
11.2.2.1. Descreve as mudanças nos processos de negócio.
11.2.2.2. Modelos de processo “to-be” são relacionados/inseridos no documento.
11.2.3. Modelos de função
11.2.3.1. Mostra a funcionalidade da solução de software proposta (visão da solução).
11.2.3.2. Inclui modelos de contexto e diagramas de caso.
11.2.4. Modelo de dados
11.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.
11.2.5. Catálogo de requisitos
11.2.5.1. Descreve cada requisito em detalhes.
11.2.6. Glossário
11.2.6.1. Define terminologia específica ou jargões.
11.3. Gerenciando requisitos
11.3.1. Elementos do gerenciamento de requisitos
11.3.1.1. Identificação de requisitos
11.3.1.2. Referência cruzada de requisitos
11.3.1.3. Origem e propriedade dos requisitos
11.3.1.4. Gerenciamento de configuração
11.3.1.5. Controle de mudanças
11.3.1.6. Software para suportar os requisitos
12. 12. Requisitos de modelagem
12.1. Modelagem de funções de sistema
12.1.1. Serve para representar o que um sistema desempenha em termos de funcionalidades.
12.1.2. Diagramas de casos de uso
12.1.2.1. Descreve o que o sistema faz e não como se faz (funcional).
12.1.2.2. Elementos
12.1.2.2.1. Atores
12.1.2.2.2. Caso de uso
12.1.2.2.3. Limite do sistema
12.1.2.2.4. Associação
12.1.2.2.5. Inclusão
12.1.2.2.6. Extensão
12.2. Modelagem de dados
12.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.
12.2.2. Diagramas de relacionamento de entidade
12.2.2.1. A notação utilizada aqui para diagramas de entidade-relacionamento (ERDs) foi desenvolvida por Harry Ellis e Richard Barker.
12.2.2.2. Componentes
12.2.2.2.1. Entidade
12.2.2.2.2. Relacionamentos
12.2.3. Modelos de classe
12.2.3.1. Mostra graficamente as classes em um sistema e suas associações entre si.
12.2.3.2. Elementos
12.2.3.2.1. Objeto
12.2.3.2.2. Classe
12.2.3.2.3. Atributos
12.2.3.2.4. Associações
13. 13. Fornecendo os requisitos
13.1. Questões a considerar para entregando a solução
13.1.1. Contexto
13.1.1.1. Descreve a natureza da organização e o projeto.
13.1.2. Papéis
13.1.2.1. Papéis-chave a serem executados durante o projeto.
13.1.3. Ciclo de vida
13.1.3.1. Processo usado para desenvolver e implementar a solução.
13.1.4. Entregas
13.1.4.1. Saídas ou produtos do projeto. Big Bang? Incrementos?
13.1.5. Abordagem
13.1.5.1. Cobre os métodos e padrões usados durante o ciclo de vida (scrum, por exemplo)
13.1.6. Técnicas
13.1.6.1. Descrevem as técnicas de gestão e desenvolvimento usadas para planejar e documentar o trabalho do projeto.
13.2. Contexto
13.2.1. O contexto para a organização é fundamental para determinar como o projeto será implementado.
13.2.2. Questões-chave a considerar
13.2.2.1. Cultura e filosofia da organização
13.2.2.2. Contexto do negócio para as mudanças propostas
13.2.2.3. Restrições
13.2.2.4. Necessidades para o negócio
13.2.2.5. Motivadores para o projeto
13.3. Ciclos de vida para entrega de soluções
13.3.1. Waterfall (cascata)
13.3.1.1. É uma sequência de estágios nos quais cada um é completado antes de irmos para o próximo.
13.3.1.2. A entrega da solução somente acontece no último estágio do ciclo.
13.3.1.3. Demora mais para a entrega da solução.
13.3.1.4. Figura
13.3.2. Modelo “V”
13.3.2.1. Relaciona os critérios de teste com cada etapa de desenvolvimento
13.3.2.2. Figura
13.3.3. Incremental
13.3.3.1. A entrega da solução é feita por incrementos
13.3.3.2. Figura
13.3.4. Modelo de desenvolvimento iterativo de sistemas
13.3.4.1. Permite que requisitos evoluam ao longo do projeto.
13.3.4.2. As equipes são empoderadas e mais colaborativas.
13.3.4.3. As entregas são mais adaptadas às necessidades atuais dos usuários.
13.3.4.4. As entregas incrementais possibilitam a realização de benefícios mais cedo.
13.3.4.5. Os eventos têm durações pré-determinadas (time-boxing).
14. 14. Fornecendo a solução de negócio
14.1. Papel do AN no ciclo de vida da mudança de negócio
14.1.1. Figura
14.2. Papel do AN no estágio de desenho
14.2.1. Pode ter que construir casos e cenários de testes
14.3. Papel do AN no estágio de implementação
14.3.1. Precisa tentar superar os problemas antes que eles comecem e então fornecer suporte ao pessoal.
14.3.2. Modelo SARAH
14.3.2.1. Estabelece cinco fases das emoções experimentadas quando alguém é confrontado com uma mudança.
14.3.2.2. Figura
14.4. Papel do AN no estágio de realização
14.4.1. O AN cria um plano de benefícios
14.4.1.1. Plano de benefícios
14.4.1.1.1. O contexto ou a visão para a mudança, que descreve o pano de fundo para o projeto.
14.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”.
14.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.
14.4.1.1.4. As responsabilidades descrevem os proprietários dos benefícios e suas responsabilidades.
14.4.1.1.5. Os procedimentos de acompanhamento descrevem como os benefícios serão rastreados e o processo de relatório associado.
14.4.2. O AN cria um relatóriode benefícios
14.4.2.1. Relatório de realização de benefícios
14.4.2.1.1. Declara se os benefícios foram realizados e o que pode ser feito para remediar qualquer deficiência.
14.4.2.1.2. Fornece uma nova garantia para a gerência sênior de que o custo do projeto foi justificado.
14.4.2.1.3. Fornece entrada para business cases futuros e os ajuda a ter mais sucesso.
14.4.2.1.4. Ajuda a organização ao longo do tempo a aumentar sua habilidade de escolher qual projeto realizar.