ANAIS FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA FÁBRICA DE SOFTWARE

Tamanho: px
Começar a partir da página:

Download "ANAIS FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA FÁBRICA DE SOFTWARE"

Transcrição

1 FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA FÁBRICA DE SOFTWARE FELIPE SANTOS BATISTA DE SOUZA ( ) USP - FEA - FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E C. CONTÁBEIS ALVAIR SILVEIRA TORRES JUNIOR ( ) USP - FEA - FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E C. CONTÁBEIS Resumo Este caso de ensino tem por objetivo retratar uma situação ocorrida em uma fábrica de software que se viu pressionada a reduzir custos. A solução adotada foi a utilização ferramentas do modelo de gestão Lean para aumentar a eficiência de seu processo produtivo e diminuir possíveis impactos sobre suas margens. Neste processo de implementação de melhorias foram utilizadas ferramentas como o Kaizen e também o formulário A3. Ao final do processo de implementação das melhorias foi possível verificar através de indicadores qual foi o ganho obtido com a utilização do modelo de gestão Lean e suas ferramentas. Palavras chave: Lean, Agile, TI, Fábrica de Software, Kaizen, Formulário A3 Introdução Este caso se passa em uma empresa brasileira especializada no desenvolvimento de software ou como alguns preferem Fábrica de software. Esta empresa, chamada aqui através do nome fictício Pontual, possuia uma estreita relação de mais de 10 anos com um grande cliente nacional (da área de Telefonia) que realiza o outsourcing da manutenção e evolução de alguns de seus sistemas de informação com a Pontual. Esta relação duradoura sempre foi marcada por grandes projetos, em geral de alta complexidade e prazos agressivos impostos pelo cliente dada a natureza de seu negócio. Neste contexto, dentro do portfólio de sistemas mantidos pela fábrica havia um deles (que será chamado Sistema ABC ) caracterízado pela sua alta complexidade e projetos de alto esforço de implementação e em geral com prazos curtos, estas características estiveram presentes desde que o sistema passou a ser mantido pela Pontual em meados de O time de desenvolvedores envolvido com o on-going (manutenção evolutiva e corretiva) do Sistema ABC era composto por cerca de 15 funcionários dedicados exclusivamente à manutenção da aplicação. Comparativamente em relação aos outros times da fábrica, estes funcionários possuiam razoável especialização (em média, indivíduos com mais de 3 anos de experiência no sistema). 1/16

2 O Desafio Em meados de Novembro de 2013 o cliente introduziu uma forte demanda para a redução dos custos dos contratos com os fornecedores (incluindo a Pontual). Desta forma, os gerentes se viram obrigados a cortar custos a fim de que as margens fossem mantidas sem que houvesse comprometimento com a qualidade e presteza na entrega do software ao cliente. Sendo assim, algumas medidas a nível gerencial foram tomadas para promover restruturações em todas as equipes tornando-as menos custosas. Porém, no caso da equipe dedicada ao Sistema ABC diversos recursos chave (em geral experientes) da equipe tiveram que ser mantidos o que dificultava economias relevantes para a gerência. A ideia dos gestores então foi a de aumentar a eficiência/produtividade dos processos envolvidos com a manutenção do Sistema ABC. Existia ainda um fator complicador à situação, a forte pressão da alta gerência da empresa para que alterações fossem realizadas em curto prazo (cerca de 3 meses no máximo) em função do fechamento dos resultados da Pontual para aquele ano fiscal (as alterações já deveriam surtir algum efeito nos resultados). Para implementar estas melhorias necessárias, algumas questões precisariam ser respondidas: Por onde começar? O que deveria ser feito? Existiria alguma metodologia que poderia ser utilizada para guiar o trabalho a ser realizado? A ideia da gerência então foi a de reunir dois dos líderes de desenvolvimento mais experientes da fábrica que atuam com o Sistema ABC e montar uma equipe que iria conduzir um programa de melhoria da eficiência da fábrica (porém neste primeiro momento restrito ao sistema ABC). O trabalho da equipe era o de propor alternativas viáveis e factíveis para melhoria dos processos da fábrica e implementá-las de tal forma que fossem gerados resultados concretos (que pudesem ser quantificados) e em curto espaço de tempo. O modelo de Gestão Lean Para responder às questões levantadas, uma das sugestões/alternativas que surgiu dentro da equipe do programa de melhoria, foi a de adotar algumas das ideias do modelo de gestão Lean e aplicá-las ao processo de desenvolvimento de software. O termo Lean foi criado por uma equipe de pesquisa liderada por Jim Womack Ph.D do MIT, para descrever o modelo/filosofia de produção existente (Toyota Production System - TPS) na companhia automotiva Toyota em meados do final da décade de Posteriormente, as características de uma organização Lean foram descritas por Womack e Dan Jones no livro Lean Thinking eles também foram os fundadores do Lean Enterprise Institute. O modelo de gestão LEAN propõe uma forma diferenciada de se enxergar as organizações procurando promover o fluxo de valor contínuo e a diminuição do desperdício, principalmente através do engajamento das pessoas. O objetivo, portanto, é maximizar o valor entregue enquanto o desperdício é reduzido, ou seja, com menor quantidade de recursos. Para tal, o modelo LEAN também apresenta algumas ferramentas e métodos. 2/16

3 Segundo este modelo, a forma ideal para se chegar ao melhor resultado (alto valor gerado e baixo desperdício), é procurar ao invés de atuar em pontos isolados da produção como máquinas ou tecnologias, melhorar todo o fluxo de produtos e serviços através de todo o fluxo de valor. Isto irá propiciar processos com menor dependência humana, esforço e tempo para produzir produtos com menor custo e maior qualidade (comparativamente à abordagem tradicional). Segundo Bell e Orzen (2011), o modelo de gestão Lean possui 5 princípios que podem ser usados em uma vasta gama de campos de atuação (de desenvolvimento de software à produção automotiva). São eles: Valor ao cliente (entender o que o cliente valoriza); Fluxo de Valor (processos que ligados geram o produto/serviço desejado pelo cliente); Fluxo Contínuo (manter o fluxo do processo de forma contínua evitando desperdícios e tempos de espera); Produção Puxada (fazer/produzir o que e quando o cliente demanda, evitando estoques); Perfeição (melhoria contínua dos processos). Uma das ferramentas mais importantes do modelo de gestão Lean é o Kaizen (que em japones significa melhoria) trata-se da ideia de que melhorias incrementais sejam realizadas nos processos de trabalho (BELL; ORZEN, 2011). Segundo Bell e Orzen (2011), existem duas categorias/tipos de Kaizen: O Kaizen de sistemas, em geral conduzido pela gerência, no qual se busca a melhoria no fluxo de valor como um todo, através de ajustes nos fluxos de materiais, informação, etc. O Kaizen de processos, realizado muitas vezes por times e indivíduos, no qual o foco é a redução do desperdício em áreas específicas dentro do fluxo de valor. Especificamente no contexto de uma fábrica de software, algumas formas de desperdício e suas consequências são: Defeitos, causados por má execução do trabalho e que podem ter como consequência a realização de re-trabalho; Espera, pode ser gerada por aplicações lentas e afeta a produtividade dos trabalhadores; Transporte, pode ocorrer em função do deslocamento excessivo de pessoas gerando custos altos; Conhecimento não utilizado, os funcionários realizam tarefas que não agregam valor ou atividades repetitivas. Isto os previne de contribuir mais com seu conhecimento para atividades que poderiam gerar mais valor ao produto. 3/16

4 Processos de Desenvolvimento Ágeis Uma abordagem alternativa e/ou complementar ao Lean que também foi sugerida para se aumentar a eficiência da fábrica de software é a utilização de metodologias de desenvolvimento de software ágeis (amplamente conhecidas como metodologias Agile ) que vem tendo uma rápida disseminação desde os anos A filosofia de desenvolvimento Agile compreende um conjunto de metodologias/técnicas que se baseiam em desenvolvimento iterativo e incremental em que os requerimentos e soluções são analisados e pensados dentro de equipes que em geral são autogeridas e com diferentes bagagens funcionais (desenvolvedores, especialistas no negócio relacionado ao software sendo desenvolvido, etc.). Os valores, princípios e métodos do Agile foram compilados e publicados em 2001 no Manifesto Agile que entre outras coisas diz que Indivíduos e Interações são mais importantes que processos e ferramentas. A colaboração do cliente é mais importante que a negociação de um contrato. Software funcionando é mais importante que uma documentação completa. (BECK et al., 2001). O Scrum, particularmente, é um das formas de implementação do processo de desenvolvimento de software Agile, com um foco direcionado para a flexibilidade em que a realidade de que o cliente pode desejar alterar requisitos ou a sequencia em que os mesmos devem ser entregues é incluída no processo de desenvolvimento de software. Isto é possível através da característica do Scrum (derivada da filosofia Agile) de ser um modelo de desenvolvimento iterativo (com feedbacks/testes frequentes para cada um dos requisitos sendo implementados) e incremental (em que os requisitos podem ser desenvolvidos e entregues de forma menos acoplada, ou seja, o cliente não recebe uma versão final do software com todos os requisitos implementados, mas sim versões que vão agregando mais requisitos/funcionalidades com o decorrer do processo de desenvolvimento). Estas características permitem uma maior flexibilidade nas decisões sobre o que e quando os requisitos devem ser implementados. Comparação entre os modelos Agile e Lean Duas questões que surgiram dentro da equipe do programa de melhoria ao analisar os diferentes modelos: Até que ponto um modelo se relaciona com o outro e qual seria o mais adequado em cada situação. Realizando-se uma análise entre as abordagens Agile e Lean, concluiu-se que existiam algumas características que determinariam qual das duas mais se adequaria a uma determinada necessidade. O modelo de gestão Lean seria mais amplo abrangendo toda a cadeia de valor dentro de um processo organizacional focando na redução ou remoção de tarefas que não agregam valor ao produto (inclusive em áreas de apoio). De forma similar, o modelo/técnica Agile busca otimizar (através de boas práticas e métodos parecidos com aqueles presentes no modelo Lean como redução do desperdício de esforço em atividades que não agregam valor), porém especificamente no processo de desenvolvimento do software em si, ou seja, um escopo mais restrito. 4/16

5 Em uma situação hipotética em que uma fábrica de software necessita entender como o todo está funcionando, o mapeamento do fluxo de valor (proposto pela modelo de gestão Lean) poderia permitir identificar etapas que geram desperdício e que, mesmo com a implementação de processos de desenvolvimento Agile, poderiam fazer com que o resultado final (software a ser produzido) ainda fosse criado/desenvolvido de forma ineficiente. A ideia de utilizar a metodologia Lean Levando-se em consideração todas as características mencionadas acima, a equipe do programa de melhoria concluiu que a alternativa de utilização de metodologia Agile não seria a mais adequada pois o modelo de desenvolvimento por si só não era um ofensor à eficiência da fábrica, já que vinha sendo utilizado e aperfeiçoado há muitos anos. Não que isso excluísse qualquer possibilidade de uma mudança futura. Restava então, como uma saída, analisar o processo de desenvolvimento de software como um todo (não apenas a metodologia de desenvolvimento) na busca de possíveis melhorias para o aumento da eficiência da fábrica de software. Sendo assim, o modelo de gestão Lean (pelas suas características já mencionadas acima) e suas ferramentas permitiria realizar este estudo de forma orientada e sistemática. A utilização do modelo Lean aplicado à Tecnologia da Informação se mostrou interessante por algumas razões principais, como: sua ampla utilização em outras áreas relacionadas à produção (e geração de valor); possuir uma metodologia bem definida direcionando as etapas a serem seguidas desde a identificação das possíveis fontes de desperdício até a forma com que a implementação de melhorias poderia ser realizada. Através desta metodologia, portanto, seria possível obter todo um direcionamento para o trabalho a ser realizado e com relativo baixo custo já que os conceitos são amplamente divulgados e não seria necessário (pelo menos para a adoção da metodologia) a adoção de ferramentas ou softwares específicos. As considerações foram então coletadas pela equipe do programa de melhoria e levadas à gerência, como uma forma de mostrar que o trabalho estava sendo realizado e também para obter o consentimento (e também comprometimento) dos gerentes sobre o caminho a ser seguido. Tomada a decisão conjunta (equipe do programa de melhoria e gerência) pela utilização da metodologia Lean para a resolução do referido problema, passouse a verificar quais características/aspectos do Lean Thinking poderiam ser transportados para a realidade da fábrica de software e em particular para a equipe do Sistema ABC. Aplicando o Lean Thinking O Lean Thinking é um forma de se pensar subjacente ao modelo Lean segundo à qual, deve-se buscar, entre outras coisas: a definição de valor sob a ótica do cliente, alinhar da melhor forma possível as atividades que criam valor para o cliente e realizar estas atividades da forma mais eficiente (menor desperdício) possível. Inicialmente, como prega a abordagem de desenvolvimento Lean, o primeiro passo foi realizar o Genchi Genbutsu, ou seja, a equipe do programa de melhoria voltou seus olhos para o processo de desenvolvimento atualmente utilizado pela equipe que mantém o Sistema ABC. Procurou-se neste momento abrir um canal de comunicação com os desenvolvedores e 5/16

6 entender quais eram suas maiores dificuldades e colher sugestões sobre como seu trabalho poderia se tornar mais eficiente/produtivo. Esta interação preliminar se mostrou fundamental, pois os desenvolvedores se engajaram com o esforço da gerência pela redução dos custos. Buscou-se então verificar quais das ferramentas deste modelo melhor se aplicariam à situação enfrentada pela empresa. O modelo de gestão Lean apresenta duas ferramentas que, na visão da equipe do programa de melhoria, poderiam ser utilizadas para que as fontes de desperdício fossem identificadas: o formulário A3 e o mapeamento do fluxo de valor. A questão que se seguiu foi então qual ferramenta utilizar: ambas ou apenas uma delas? O mapeamento do fluxo de valor consiste em mapear através de um diagrama os fluxos de informação, materiais e trabalho que ocorrem entre células funcionais do processo sob análise, incluindo-se outros dados como a qualidade e o tempo necessário para cada processo. Além disso, durante sua concepção é possível, e por vezes necessário, envolver e integrar equipes de áreas funcionais distintas na tarefa de caracterizar e posteriormente melhorar os processos existentes. Já o A3 não é apenas um formulário, mas antes um modelo/framework de pensamento que acaba por forçar a utilização de um método estruturado científico para a resolução de problemas. Este método inclui as fases de observação, descrição de causa e efeito (hipótese), predição, teste e avaliação. Alguns dos benefícios do A3 são: decisões baseadas em fatos, consenso entre as áreas envolvidas na análise do problema, definição de metas e formas de acompanhamento para garantir que as melhorias serão alcançadas. A partir das conversas preliminares com os desenvolvedores, foi constatado que o problema principal não era externo ao ambiente de desenvolvimento do software, ou seja, não envolvia outros entes como o cliente, processos/procedimentos internos da empresa, problemas com transferência de informação (requisitos de software, por exemplo) entre diferentes elementos do processo de desenvolvimento, etc. Aparentemente o gargalo existia dentro dos times de desenvolvimento na rotina de trabalho que os mesmos realizavam. Sendo assim, entendeu-se que o mapeamento de todo o fluxo de valor do processo de desenvolvimento, apesar de válido, poderia representar um esforço maior, dada sua abrangência, do que o necessário para o problema de eficiência atualmente existente dentro da fábrica. Parecia claro para a equipe após a analise realizada até o momento que, dentro da caixa de ferramentas Lean, uma forma de realizar este trabalho seria a execução de um Kaizen de processos, já que seria envolvido um escopo menor (interno ao fluxo de valor) buscando-se a redução de desperdício. Esta atividade então, poderia seria suportada pela criação de um formulário A3, pois a partir do mesmo seria possível entender quais as possíveis fontes de desperdício, soluções e um plano de mudança (inclusive com indicadores que permitiriam acompanhar a transição). Identificando as fontes de desperdício A partir do retorno recebido durante as interações preliminares com os envolvidos no processo de desenvolvimento, foi possível identificar algumas reclamações recorrentes e que indicavam possíveis fontes de desperdício. 6/16

7 Historicamente, o Sistema ABC sofre diversas modificações ao longo de cada ano sendo que em média 20 projetos inserem alterações no código fonte do sistema. Sendo assim, o código-fonte da aplicação posssui milhares de alterações realizadas ao longo do tempo. Em fábricas de software uma atividade crucial é o versionamento do código-fonte, ou seja, armazenar as alterações realizadas no código da aplicação em um repositório (servidor) e disponibilizar o acesso a estas alterações, através deste repositório (que contém a última versão do código), para todos os outros desenvolvedores envolvidos em um dado projeto/desenvolvimento. No dia-a-dia cada desenvolvedor deve obter a versão mais atual do código-fonte e realizar a suas alterações e ao final do dia subir, ou seja, atualizar o código contido no repositório com suas alterações de tal forma que os outros desenvolvedores possam considerálas também em seu trabalho. Esta atividade é ainda mais crítica no caso do Sistema ABC devido ao alto paralismo de trabalho entre desenvolvedores (em média, 10 desenvolvedores realizam alterações simultâneas no mesmo código-fonte). Uma consequência destas características foi a de que o repositório se tornou lento, tornando o trabalho dos desenvolvedores menos eficiente. A equipe do programa de melhoria então entendeu que o repositório do código-fonte, poderia ser uma das fontes de desperdício dentro do processo. Outro ponto destacado pelos desenvolvedores foi o tempo necessário para que a aplicação fosse executada na estação de trabalho dos mesmos. Isto ocorria pois o servidor de aplicação (software/sistema utilizado para executar aplicações) utilizado nos ambientes de desenvolvimento era o mesmo utilizado pelo cliente no ambiente de produção (que é efetivamente aquele utilizado pelos usuários finais do sistema). A cada vez que o sistema era executado nos ambientes de desenvolvimento, o desenvolvedor precisava esperar 10 minutos para que pudesse realizar seus testes. Adicionalmente, a estação de trabalho como um todo fica em seu limite de consumo de memória RAM, o que dificultava ao programador realizar outras tarefas de forma paralela. Este foi outro ponto identificado como um ofensor à eficiência do trabalho dos desenvolvedores. As duas fontes de despedício identificadas podem ser enquadradas na categoria de Espera em uma das categorias de desperdício em desenvolvimento mencionadas por Taiichi Ohno. A Erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.figura 1 apresenta de forma macro as atividades que compõem a rotina do desenvolvedor, conforme descrito acima. 7/16

8 Cliente Envia requisitos do software a ser desenvolvido Servidor de Aplicação Realiza testes Codifica o software e o executa Programador Atualiza o repositório com códigofonte alterado Obtém o código-fonte mais atualizado Repositório Cliente Software desenvolvido é entregue ao cliente Figura 1: Fluxo do processo de Desenvolvimento de Software Elaboração do A3 Para a elaboração do A3, foram promovidos alguns encontros no decorrer de duas semanas entre um representante da equipe que estava envolvida com a condução do programa de melhoria e os desenvolvedores (não líderes) mais experientes da fábrica. Vale ressaltar que o contato poderia ter sido realizado apenas com os líderes de desenvolvimento, mas houve o entendimento que essa abordagem poderia inserir filtros entre o chão de fábrica e os gestores o que não seria ideal do ponto de vista do Gemba. Após o entendimento de que algumas atividades específicas poderiam ser as fontes de desperdício no processo, foram definidas variáveis que permitiriam avaliar quantitativamente qual seria esse desperdício e se de fato estas atividades seríam responsáveis por uma perda de eficiência da fábrica: Tempo médio para a realização do gravação de um arquivo no repositório (T gravação ); Tempo médio para download de um arquivo do repositório (T download ); Tempo médio de inicialização da aplicação (T inicializaçao ); Consumo médio de memória RAM da estação do desenvolvedor com a aplicação sendo executada (C estação ). A partir daí realizaram-se as medições necessárias para a aferição de cada uma delas. Para tal, foi solicitado que alguns dos desenvolvedores medissem os tempos envolvidos nas atividades durante 3 dias (a escolha por medir os tempos durante mais de um dia, foi feita para que se evitasse que circunstâncias/instabilidades de infra-estrutura pudessem contaminar os resultados medidos). Os dados obtidos foram: 8/16

9 Variável T gravação Resultados antes da implementação das mudanças 85 segundos (s) T download 45 s* T inicializaçao 10 min 1 Gbyte C estação Tabela 1: Métricas anteriores ao processo de melhoria de eficiência * Tempo para o download de um arquivo individualmente, quando o download era de todo o código-fonte a taxa era de aproximadamente 0,2 segundos por arquivo Com os dados em mãos era necessário compreender qual o impacto que estas esperas causavam na eficiência da fábrica. Isto pôde ser realizado através da análise da frequência com que cada uma destas atividades era realizada. Foram então, identificados os seguintes números: A partir de uma extração das métricas do repositório de código que estava sendo utilizado, foi identificado que para cada novo projeto do sistema são realizadas em média aproximadamente 0,6 gravações de código / hora de desenvolvimento; Desenvolvedores atuando num mesmo projeto precisam sempre atualizar o códigofonte presente em suas máquinas a cada novo arquivo que é criado/atualizado no repositório por outro desenvolvedor, como em geral os projetos são desenvolvidos por 2 desenvolvedores cada gravação no repositório gera a necessidade de pelo menos um download, ou seja, 2 x 0,6 downloads / hora de desenvolvimento (já que um desenvolvedor precisa se atualizar com o código gerado pelo outro). Ao se analisar o histórico de projetos desenvolvidos pela fábrica chegou-se à conclusão que são realizadas em média aproximadamente horas de desenvolvimento mensal. Neste ponto já se poderia estimar o tempo total de espera causado pelo repositório: Tempo Total de Espera de Gravação por Mês: T gravação x 0,6 x = 28 horas mensais ou aproximadamente 1,8 horas mensais por desenvolvedor; Tempo Total de Espera de Download por Mês: T download x 1,2 x = 30 horas mensais ou aproximadamente 2 horas mensais por desenvolvedor. Ou seja, duas das atividades que poderiam estar tornando o processo ineficiente consumiam no total 58 horas mensais (ou aproximadamente 4 horas mensais por desenvolvedor). Faltava ainda analisar o tempo de espera gerado pelas variáveis T inicializaçao e C estação. Através das observações realizadas durante a coleta de informações junto aos desenvolvedores foi possível verificar que em média a aplicação era inicializada no ambiente de cada desenvolvedor 4 vezes por dia. Logo, 9/16

10 Tempo Total de Espera para Inicialização da Aplicação = 4 x T inicializaçao x ( h / 8 horas de trabalho diário) = 166 horas mensais (considerando-se toda a equipe de 15 desenvolvedores) ou 11 horas mensais por desenvolvedor. Com relação ao consumo de memória, o maior impacto era gerado pelo fato que os desenvolvedores tinham a capacidade das estações de trabalho comprometidas já que as mesmas contavam com 4 Gbytes de memória, quando considerado o consumo de memória do próprio sistema operacional, do ambiente de desenvolvimento e outras aplicações, a estações de trabalho tinham em média um consumo de cerca de 95% da memória Ram quando a aplicação era executada nas estações de desenvolvimento. A conclusão foi que aproximadamente 15 horas mensais (ou quase dois dias de trabalho) por desenvolvedor eram consumidas em espera (algo que não agrega valor ao produto a ser desenvolvido). Ficou mais claro então para todos os envolvidos que estas atividades elencadas pelos desenvolvedores representavam um volume de esforço/tempo relevante dentro do contexto da equipe de desenvolvimento. Porém, antes de continuar a busca pela eficiência combatendo o desperdício nestas atividades, foi necessário realizar uma consulta prévia junto à equipe de infra-estrutura para determinar o quanto seria possível melhorar em relação à situação atual. Após conversas com este time ficou claro que havia sim espaço para melhorias com uma possível troca do software utilizado para gerenciar o repositório do código-fonte. Esta sinalização foi importante para manter a confiança dos agentes responsáveis pelo programa de melhoria e também para justificar a continuidade da linha que vinha sendo seguida pela do programa de melhoria junto à gerência Foi interessante notar durante as interações com os desenvolvedores que a ideia de mudar a situação atual e implementar mudanças que facilitariam o trabalho dos mesmos foi muito bem aceita. Havia inclusive um sentimento de alívio por parte deles pois naquele momento eles poderiam externar todas as suas críticas e também propor sugestões. Em geral, havia abertura na fábrica de software para que as pessoas trouxessem novas ideias e formas de trabalho. Porém a diferença desta vez foi o comprometimento da gerência em patrocinar um programa estruturado de mudanças e que provavelmente (essa era a esperança de todos) seria aplicado, não se tratava mais, portanto, de uma conversa de corredor com o líder imediato ou com algum outro colega sobre ideias ou reclamações relacionadas à rotina de trabalho. Posteriormente, seguindo o plano de análise traçado anteriormente, passou-se a elaboração de um A3 focado nas duas fontes de desperdício mencionadas acima (o repositório e o servidor de aplicação). Mais importante do que a criação do A3 foi o processo para a análise das fontes de desperdício e quais as possíveis saídas para solucionar o problema, bem como o plano e cronograma para a implementação das mudanças. Como mencionado anteriormente, todo este processo permitiu um grande engajamento por parte das equipes envolvidas o que também gerou ganhos durante a criação efetiva do A3, pois todos já haviam tido algum contato com o trabalho que vinha sendo realizado, sabendo de sua importância no dia-a-dia da fábrica e também para com a gerência (que estava patrocinando esta iniciativa). 10/16

11 A seguir serão descritos brevemente alguns detalhes relacionados à cada uma das partes do formulário A3 criado durante este programa de melhoria da eficiência da fábrica. Condições Atuais Inicialmente foram identificadas as atividades que poderiam ser afetadas/impactadas pelos processos que haviam sido criticados pelos desenvolvedores. A partir deste ponto foram coletados os tempos necessários para a realização destas atividades (processo já descrito anterioremente neste texto). Metas e Objetivos De forma conjunta entre a equipe do programa de melhoria, desenvolvedores e equipe de infra-estrutura da empresa, procurou-se determinar quais seriam os tempos adequados para as atividades comprometidas com elevada espera. Análise Neste momento, o objetivo foi entender porque a situação havia chegado aquele ponto e quais os motivos principais levavam a fábrica a ainda utilizar ferramentas que não se mostram mais tão eficientes. A equipe de infra-estrutura trouxe à discussão, quais seriam as opções viáveis para a substituição das ferramentas atuais. Vale ressaltar que existe um conjunto limitado de ferramentas homologadas disponíveis para a utilização na fábrica de software. Isto poderia ter sido um complicador (restrição) à escolha da solução ótima. Os desenvolvedores também puderam coloborar na escolha de novas ferramentas, propondo opções com as quais já haviam trabalhado em outras ocasiões. Contramedidas propostas A partir do entendimento da situação atual e do que levou à mesma, foram analisadas as opções disponíveis e as contra-medidas foram acordadas entre a equipe do programa de melhoria e os desevolvedores, com uma definição clara do que deveria ser feito e quais os benefícios esperados pelas ações a serem tomadas. Isto também trouxe um maior engajamento entre os envolvidos. Plano Para a definição do plano a ser seguido foi necessário estabelecer quem seriam os responsáveis por cada uma das ações, prazo e como a execução das mudanças seria acompanhada (estabelecimento de indicadores). O envolvimento nas atividades anteriores fez com que o comprometimento dos envolvidos na execução do plano fosse conseguido com maior facilidade (logo não houve resistência ou conflito na atribuição das equipes responsáveis pelas ações) e como era de consentimento geral dos envolvidos que as melhorias trariam benefícios para todos, foi geral a determinação em fazer a mudança acontecer o mais rápido possível, desta forma o tempo para a implementação foi aquilo que todos entendiam como o sendo o melhor possível. Acompanhamento 11/16

12 Para a realização do monitoramento a proposta foi realizar reuniões com as equipes envolvidas e acompanhar os indicadores previamente estabelecidos. O A3 desenvolvido pode ser verificado na seção de anexos do presente trabalho. Implementação das mudanças Com a aprovação da gerência o plano contido no A3 foi colocado em prática pela equipe do programa de melhoria, as equipes envolvidas foram reunidas e com o suporte da gerência o processo de mudança foi iniciado. O acompanhamento por parte da equipe do programa de melhoria era diário e desde o início da implantação das alterações, foram realizadas análises dos tempos envolvidos nas atividades ofensoras. A melhora observada foi significativa em todas as variáveis. A seguir serão detalhados brevemente alguns aspectos do processo de mudança que foi realizado. Troca do Repositório Existia uma diferença conceitual na utilização do novo repositório em relação ao antigo, desta forma inicialmente foi necessário envolver os líderes de desenvolvimento para que fosse estabelecida uma política de utilização do novo repositório de acordo com suas características particulares (por exemplo, qual seria o procedimento em caso de projetos concorrentes entre si, qual seria o procedimento quando uma versão do software que estava sendo desenvolvida fosse colocada em produção pelo cliente, etc.). Isto foi importante para evitar que os líderes tomassem decisões divergentes quando situações como estas ocorressem. O que seria muito ruim pois abalaria a confiança dos desenvolvedores no trabalho que estava sendo realizado. Posteriormente foi elaborado um guia de utilização do novo repositório explicando como realizar as tarefas cotidianas. Após os devidos esclarecimentos junto aos desenvolvedores, o novo repositório do codigo-fonte foi liberado para utilização, e os desenvolvedores envolvidos com novos projetos foram solicitados a utilizar o novo repositório. Todo o trabalho preparatório contribuiu para que o nível de resistência à mudança fosse baixo. Os desenvolvedores perceberam que os líderes e os agentes responsáveis pelo programa de melhoria de eficiência sabiam o que estavam fazendo e propondo. Troca do Servidor de Aplicação A troca do servidor de aplicação foi mais tranquila, já que a nova aplicação era mais leve e simples. Logo no início da utilização do novo software os desenvolvedores perceberam o ganho de tempo obtido e se mostraram bastante satisfeitos com a nova situação. Como resultado a resistência à alteração foi mínima ou até inexistente. O papel da liderança no processo de implantação das mudanças O acompanhamento da transição pela gerência foi realizado através de reuniões com a equipe do programa de melhoria e os líderes de desenvolvimento onde eram revisados os 12/16

13 indicadores principais delineados no A3 (como: percentual de sistemas migrados para o novo repositório e percentual de desenvolvedores utilizando o novo servidor de aplicação ). O suporte da gerência patrocinando a iniciativa foi de fundamental importância para a aceitação das alterações realizadas. Desde o início do processo a gerência deixou claro que os envolvidos na mudança que contribuíssem para que a mesma ocorresse de forma suave e com sucesso seriam reconhecidos. Adicionalmente, era clara a grande expectativa da liderança com relação ao sucesso da empreitada, o que motivou os envolvidos (desenvolvedores e equipe de infraestrutura) a trabalhar com afinco e dedicação nesta mudança. Resultados das alterações implementadas Apesar dos ajustes pontuais necessários no processo de trabalho para que os desenvolvedores passassem a utilizar as novas ferramentas (servidor de aplicação e repositório), a transição ocorreu dentro do cronograma previsto no A3, em cerca de um mês todos os desenvolvedores envolvidos com novos projetos para o Sistema ABC já estavam utilizando o novo ferramental. Na Tabela 2 é possível verificar os valores aferidos ao final do processo de implantação das mudanças para melhoria do processo de desenvolvimento: Variável Resultados antes da implementação das mudanças Resultados após a implementação das mudanças T gravação 85 segundos (s) 3 s T download 45 s 3 s T inicializaçao 10 min 3 min C estação 1 Gbyte 0,7 Gbyte Tabela 2: Comparação de métricas (antes x pós) processo de melhoria de eficiência Desta forma, os novos tempos totais mensais apurados foram: Tempo Total de Espera de Gravação por Mês: T gravação x 0,6 x = 1 hora mensais ou aproximadamente 4 minutos mensais por desenvolvedor; Tempo Total de Espera de Download por Mês: T download x 1,2 x = 2 horas mensais ou aproximadamente 8 minutos mensais por desenvolvedor; Tempo Total de Espera para Inicialização da Aplicação = 4 x T inicializaçao x ( h / 8 horas de trabalho diário) = 50 horas mensais (considerando-se toda a equipe de 15 desenvolvedores) ou 3 horas mensais por desenvolvedor. Na situação original, o tempo total de espera de cada desenvolvedor era de 15 horas mensais, após a implementação das melhorias este tempo caiu para 3 horas e 12 minutos mensais, uma redução de 80% no tempo de espera dos desenvolvedores, em outras palavras, os desenvolvedores tem agora pouco mais de 10 horas produtivas a mais por mês para trabalhar em atividades que irão agregar valor aos produtos (softwares) desenvolvidos pela fábrica. Adicionalmente, houve uma redução de 300 Mbytes no consumo de memória RAM das estações o que representa um ganho de 30% em relação à situação anterior e um 13/16

14 comprometimento da memória das estações de aproximadamente 87,5% (próximo ao objetivo inicial de 85% presente no A3). Os resultados impressionaram a gerência da fábrica. Apesar de o tempo de inicialização da aplicação não ter alcançado os 2 minutos estabelecidos como alvo no A3, a melhora nos indicadores e no tempo total foi bastante satisfatória. Os funcionários ficaram entusiasmados pelo fato de terem sido ouvidos, que melhorias em sua rotina de trabalho foram implementadas na prática e em um curto espaço de tempo. Isto pode trazer ganhos a longo prazo na medida em que eles agora entendem a importância de se fazerem ouvir e a gerência que agora entende a importância de ouvir os funcionários que estão na linha de frente no dia-a-dia. A utilização do formulário A3 (ferramenta obtida do modelo Lean) foi de importância vital para o processo, pois auxiliou a definir a linha de pensamento a ser seguida pelos agentes de mudança, auxiliou a engajar os funcionários e equipes envolvidos através do consenso do que precisava ser alterado, como, quando e por quem. Apesar de o processo ter sido aplicado pontualmente para a resolução de uma situação específica e não nos processos da fábrica como um todo, ficou evidente para a gerência que a adoção da metodologia Lean na fábrica (inclusive com o mapeamento do fluxo de valor e a realização de um Kaizen de sistema) pode trazer benefícios ainda maiores a médio e longo prazo através de ganhos de eficiência. Os funcionários agora estão mais motivados a realizar sugestões e os líderes de desenvolvimento entendem que a partir de ideias originadas no chão da fábrica podem surgir inovações que podem vir a gerar ganhos operacionais. Questões para Discussão Considerando os ganhos de eficiência obtidos na experiência de aplicação da metodologia Lean pela fábrica, pode se dizer que o processo foi exitoso? O mapeamento do fluxo de valor seria aplicável à esta situação? Além do A3 e do Mapeamento do Fluxo de Valor, existe alguma outra ferramenta Lean que poderia ter sido aplicada nesta situação? A razão para não utilização da metodologia Agile como uma possível forma de melhoria de eficiência é válida? Existem outras formas de desperdício mencionadas no caso que poderiam ser abordadas no programa de melhoria de eficiência? 14/16

15 Bibliografia BELL, Steven C.; ORZEN, Michael A.. Lean IT: Enabling and Sustaining Your Lean Transformation. Chicago: Productivity Press, p. BECK, Kent et al. Manifesto for Agile Software Development Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 04 mar LOCHAN, Rupesh. Lean or Agile? A Comparison of Approach Disponível em: <http://www.processexcellencenetwork.com/lean-six-sigma-businesstransformation/articles/using-lean-in-agile-software-development-a-compari/>. Acesso em: 25 fev /16

16 Anexos Formulário A3 Desenvolvido Título: Melhoria na eficiência do processo de Desenvolvimento de Software I. Contexto Existe uma previsão de desenvolvimento de projetos grandes com prazos agressivos. Porém existe baixa produtividade atualmente: Repositório de códigos fonte lento; Interface de desenvolvimento lenta e que demanda alto consumo computacional; Especificações com pouco nível de detalhe do que deve ser realizado. Problemas de produtividade podem comprometer os prazos e qualidade da entrega. II. Condições Atuais Dados sobre versionamento e ambiente de desenvolvimento Tempo médio para a realização do gravação de um arquivo no repositório: 1 min e 45 segundos Tempo médio para download de um arquivo do repositório: 45 segundos Tempo médio de inicialização da aplicação: 10 min Consumo de memória da estação do desenvolvedor com a aplicação sendo executada: 95% Alto custo (em termos de tempo) para a realização de análises (em que é necessário que a aplicação esteja sendo executada) pelo analista Alto custo (em termos de tempo) para a realização de testes pelo desenvolvedor 50% do tempo de correção de defeitos durante o projeto é devido à inicialização da aplicação para testes e versionamento no repositório. III. Metas e Objetivos Vesionamento: Download / Upload de arquivos em 5 s Ambiente de Desenvolvimento: Inicialização da aplicação em 2 min Máximo consumo de memória durante execução da aplicação: 85% Redução do tempo gasto com inicialização e versionamento durante correções em 50% IV. Análise V. Contramedidas propostas Causa Contramedida Descrição Benefício A B VI. Plano Troca da ferramenta de versionamento Troca do servidor de aplicação Efetuar a troca da ferramenta Migrar arquivos em manter histórico de versões com mais de 3 meses Melhoria no tempo necessário para versionamento dos arquivos. Responsável/ Suporte Aréa de Infraestrutura Não é necessária a utilização Redução no tempo necessário Equipe de do mesmo servidor de para a execução da aplicação no Desenvolvim aplicação da produção no ambiente de desenvolvimento. Portanto, pode ser utilizada uma alternativa mais "leve". ambiente de desenvolvimento ento Troca do repositório Responsável: Ação a ser realizada pela equipe de infra-estrutura Prazo: 100% migrado em 1 mês a partir da solicitação Indicador de progresso: Percentual de sistemas migrados para o novo repositório,. Alteração no ambiente de Desenvolvimento Responsável: Equipe de Desenvolvimento Prazo: 100% migrado em 1 mês a partir da solicitação Indicador de progresso: Percentual de desenvolvedores utilizando o novo servidor de aplicação. VI. Acompanhamento Monitorar semanalmente os indicadores de progresso; Manter reuniões com os líderes de desenvolvimento sobre o progresso da alteração. Vesionamento (Causa A): Ferramenta de Versionamento utrapassada e com histórico dos arquivos muito antigo o que aumenta o tempo necessário para a utilização dos mesmos. Ambiente de Desenvolvimento (Causa B): O servidor de aplicação* (mesmo utilizado no ambiente de produção) demanda muita capaciadade computacional para a execução da aplicação em ambiente de desenvolvimento. * Software utilizado para a execução de aplicações em ambiente WEB. Figura 2: A3 desenvolvido durante o programa de melhoria de eficiência 16/16

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação ITIL na Prática Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação 2010 Bridge Consulting

Leia mais

Lean IT Juliano Daniel Marcelino ( juliano@jmarcelino.com.br ) Orientador: Mehran Misaghi, Dr. ( mehran@sociesc.org.br )

Lean IT Juliano Daniel Marcelino ( juliano@jmarcelino.com.br ) Orientador: Mehran Misaghi, Dr. ( mehran@sociesc.org.br ) Lean IT Juliano Daniel Marcelino ( juliano@jmarcelino.com.br ) Orientador: Mehran Misaghi, Dr. ( mehran@sociesc.org.br ) Agenda Conceitos básicos Necessidade de usar Lean IT Ambiente Benefícios para melhoria

Leia mais

Gestão de Processos. Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL

Gestão de Processos. Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL Conhecimento em Tecnologia da Informação Gestão de Processos Principais etapas, decisões e desafios da implantação de processos de TI com base no ITIL 2011 Bridge Consulting Apresentação É comum que as

Leia mais

Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/

Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/ Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/ Muitas empresas se deparam com situações nas tarefas de previsões de vendas e tem como origem

Leia mais

Gestão estratégica por KPIs 1

Gestão estratégica por KPIs 1 Gestão estratégica por KPIs 1 Sumário Introdução 03 Por que usar indicadores na gestão 05 Dado, informação ou indicadores? 07 KPI: Os indicadores chave de desempenho 09 KPIs do PMO Conclusão Sobre a Project

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Comparando as metodologias Lean Enterprise, Six Sigma e de Gestão da Qualidade

Comparando as metodologias Lean Enterprise, Six Sigma e de Gestão da Qualidade Página 1 de 6 NOTÍCIAS CARREIRAS & GESTÂO CURSOS & SEMINÁRIOS LIVROS DANÇA DAS CADEIRAS PESQUISAS COMPRAS ENTREVISTAS EM VÍDEO LAZER & TURISMO HOME Artigos Comparando as metodologias Lean Enterprise, Six

Leia mais

PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS

PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS 2ª OFICINA MAPEAMENTO DO FLUXO DE VALOR Lean Manufacturing é a busca da perfeição do processo através da eliminação de desperdícios Definir Valor Trabalhar

Leia mais

Exame simulado. EXIN Lean IT Foundation

Exame simulado. EXIN Lean IT Foundation Exame simulado EXIN Lean IT Foundation Edição julho 2015 Copyright 2015 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação

LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação Serviços : Cursos e workshops especialmente criados para capacitar a sua organização no

Leia mais

Governança de TI. Por que a Governança de TI é vista como fator chave para criação de valor para o Negócio? Conhecimento em Tecnologia da Informação

Governança de TI. Por que a Governança de TI é vista como fator chave para criação de valor para o Negócio? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação Governança de TI Por que a Governança de TI é vista como fator chave para criação de valor para o Negócio? 2010 Bridge Consulting Apresentação A Governança de Tecnologia

Leia mais

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL Guilherme Vota Pereira guivotap@hotmail.com Prof. Pablo Schoeffel, Engenharia de Software Aplicada RESUMO: Este artigo irá efetuar uma abordagem

Leia mais

Vendas na Empresa Lean

Vendas na Empresa Lean Vendas na Empresa Lean Autor: Alexandre Cardoso Publicado: 29/04/2011 Introdução Em uma empresa, a área de Vendas é de extrema importância para o sucesso do negócio. Aprimorar o seu desempenho tem sido

Leia mais

Projetos na área de TI. Prof. Hélio Engholm Jr

Projetos na área de TI. Prof. Hélio Engholm Jr Projetos na área de TI Prof. Hélio Engholm Jr Projetos de Software Ciclo de Vida do Projeto Concepção Iniciação Encerramento Planejamento Execução e Controle Revisão Ciclo de Vida do Produto Processos

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Palestra de Introdução ao Lean IT

Palestra de Introdução ao Lean IT Palestra de Introdução ao Lean IT Conteúdo Sobre a Solvix Introdução ao Lean O Cenário Atual da TI O que é Lean IT Algumas ferramentas Lean IT Aplicação do Lean IT com outros frameworks de TI Gestão e

Leia mais

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4.

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4. Guia de Atualização PROJURIS WEB 4.5 Por: Fabio Pozzebon Soares Página 1 de 11 Sistema ProJuris é um conjunto de componentes 100% Web, nativamente integrados, e que possuem interface com vários idiomas,

Leia mais

Gerenciamento diário para executar a estratégia

Gerenciamento diário para executar a estratégia Gerenciamento diário para executar a estratégia José Roberto Ferro e Robson Gouveia Uma empresa tinha sua estratégia definida com metas e ações desdobradas para todas as áreas e níveis do negócio. O acompanhamento

Leia mais

A implantação de Lean Manufacturing implica em que TODA a empresa seja Lean, uma Lean Enterprise.

A implantação de Lean Manufacturing implica em que TODA a empresa seja Lean, uma Lean Enterprise. Lean Manufacturing A implantação do conceito de Lean Manufacturing em uma Empresa abrange todas as suas atividades operacionais, não se restringindo apenas à área Operacional. O sucesso da implantação

Leia mais

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Maturidade em Gerenciamento de Projetos" - 1ª Edição Versão do Modelo 1..0-01/Fev/008 - Editora INDG-Tecs - 008 WWW.MATURITYRESEARCH.COM

Leia mais

QUESTIONÁRIO LOGISTICS CHALLENGE 2015 PRIMEIRA FASE

QUESTIONÁRIO LOGISTICS CHALLENGE 2015 PRIMEIRA FASE QUESTIONÁRIO LOGISTICS CHALLENGE 2015 PRIMEIRA FASE *Envie o nome de seu grupo, dos integrantes e um telefone de contato junto com as respostas do questionário abaixo para o e-mail COMMUNICATIONS.SLA@SCANIA.COM*

Leia mais

SPEKX Platform DATA SHEET. Visão Resumida da Plataforma. Release 3.3. Versão 1.0

SPEKX Platform DATA SHEET. Visão Resumida da Plataforma. Release 3.3. Versão 1.0 SPEKX Platform DATA SHEET Visão Resumida da Plataforma Release 3.3 Versão 1.0 ÍNDICE ANALÍTICO Introdução... 3 Funcionalidade Modular... 4 de s SPEKX Platform...5 Funcionalidades Adicionais...7 Introdução

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

Gestão de Processos Estratégicos

Gestão de Processos Estratégicos Gestão de Processos Estratégicos Fevereiro/2014 DEFINIÇÕES Rede de Desenvolvimento Integrado Arranjos que estimulam e proporcionam um comportamento (em rede) cooperativo entre agentes governamentais e

Leia mais

Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil

Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil Ministério da Fazenda Banco Central do Brasil Responsável: José Clovis Batista Dattoli, Chefe do Departamento de Planejamento

Leia mais

(LOQ4208) Processos da Indústria de Serviços 05 Lean Office

(LOQ4208) Processos da Indústria de Serviços 05 Lean Office Processos da Indústria de Serviços (LOQ4208) 5 Lean Office Isto não é... LEAN OFFICE 1 Aqui parece ser... LEAN OFFICE Lean Thinking: Os 5 Princípios Fundamentais 1. Definir o que é VALOR sob a ótica do

Leia mais

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL Gerenciamento de Serviços de TI com ITIL A Filosofia do Gerenciamento de Serviços em TI Avanços tecnológicos; Negócios totalmente dependentes da TI; Qualidade, quantidade e a disponibilidade (infra-estrutura

Leia mais

Definição. Kaizen na Prática. Kaizen para a Administração. Princípios do Just in Time. Just in Time 18/5/2010

Definição. Kaizen na Prática. Kaizen para a Administração. Princípios do Just in Time. Just in Time 18/5/2010 Uninove Sistemas de Informação Teoria Geral da Administração 3º. Semestre Prof. Fábio Magalhães Blog da disciplina: http://fabiotga.blogspot.com Semana 15 e 16 Controle e Técnicas de controle de qualidade

Leia mais

De Boas Ideias para Uma Gestão Baseada em Processos

De Boas Ideias para Uma Gestão Baseada em Processos De Boas Ideias para Uma Gestão Baseada em Processos O que você vai mudar em sua forma de atuação a partir do que viu hoje? Como Transformar o Conteúdo Aprendido Neste Seminário em Ação! O que debatemos

Leia mais

Toyota Way. FDEABrandão. (Fonte de Força Competitiva da Toyota) Antes de você dizer que não consegue fazer alguma coisa, experimente!

Toyota Way. FDEABrandão. (Fonte de Força Competitiva da Toyota) Antes de você dizer que não consegue fazer alguma coisa, experimente! (Fonte de Força Competitiva da Toyota) Antes de você dizer que não consegue fazer alguma coisa, experimente! Sakichi Toyoda - Fundador do grupo TOYOTA. (Fonte de Força Competitiva da Toyota) O é um Ideal,

Leia mais

Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio?

Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio? Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio? A Tecnologia da Informação vem evoluindo constantemente, e as empresas seja qual for seu porte estão cada

Leia mais

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor.

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor. Módulo 6 Módulo 6 Desenvolvimento do projeto com foco no negócio BPM, Análise e desenvolvimento, Benefícios, Detalhamento da metodologia de modelagem do fluxo de trabalho EPMA. Todos os direitos de cópia

Leia mais

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Gustavo Zanini Kantorski, Marcelo Lopes Kroth Centro de Processamento de Dados Universidade Federal

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

RELATÓRIO DE ENTREGA DO PROJETO DE BPM ADMINISTRATIVO-FINANCEIRO-EMPREL

RELATÓRIO DE ENTREGA DO PROJETO DE BPM ADMINISTRATIVO-FINANCEIRO-EMPREL Diretoria de Soluções em Tecnologia da Informação DSI Departamento Projetos, Processos e Requisitos - DEPR Unidade Operacional de Projetos e Processos UOPP RELATÓRIO DE ENTREGA DO PROJETO DE BPM ADMINISTRATIVO-FINANCEIRO-EMPREL

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Como Eu Começo meu A3?

Como Eu Começo meu A3? Como Eu Começo meu A3? David Verble O pensamento A3 é um pensamento lento. Você está tendo problemas para começar seu A3? Quando ministro treinamentos sobre o pensamento, criação e uso do A3, este assunto

Leia mais

DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE SISTEMAS Agência Nacional de Vigilância Sanitária METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS GGTIN GESIS Brasília, julho de 2006. Página: 1 Histórico de Revisões Data Versão Descrição Autor 12/06/2006 1.0.00 Criação

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

_aplicando ux design em. projetos digitais cases da Catarinas Design

_aplicando ux design em. projetos digitais cases da Catarinas Design _aplicando ux design em projetos digitais cases da Catarinas Design Esse ebook tem o objetivo de mostrar que é possível inserir UX design na sua empresa, startup ou projeto. Neste material apresentamos

Leia mais

Globalweb otimiza oferta e entrega de serviços a clientes com CA AppLogic

Globalweb otimiza oferta e entrega de serviços a clientes com CA AppLogic CUSTOMER SUCCESS STORY Globalweb otimiza oferta e entrega de serviços a clientes com CA AppLogic PERFIL DO CLIENTE Indústria: Serviços de TI Companhia: Globalweb Outsourcing Empregados: 600 EMPRESA A Globalweb

Leia mais

Gestão da Qualidade: Gerenciamento por Processos

Gestão da Qualidade: Gerenciamento por Processos Gestão da Qualidade: Gerenciamento por Processos Curso de Especialização em Gestão da Produção Prof. MSc. Artur Henrique Moellmann UNESP Universidade Estadual Paulista FEG Faculdade de Engenharia do Campus

Leia mais

1. Escopo ou finalidade da iniciativa

1. Escopo ou finalidade da iniciativa 1. Escopo ou finalidade da iniciativa Implantação de solução de armazém de dados, denominada SIJUD Sistema de Informações Estratégicas do Judiciário, seguindo os conceitos estabelecidos para esse tipo

Leia mais

Conhecimento em Tecnologia da Informação. Catálogo de Serviços. Conceitos, Maturidade Atual e Desafios. 2012 Bridge Consulting All rights reserved

Conhecimento em Tecnologia da Informação. Catálogo de Serviços. Conceitos, Maturidade Atual e Desafios. 2012 Bridge Consulting All rights reserved Conhecimento em Tecnologia da Informação Catálogo de Serviços Conceitos, Maturidade Atual e Desafios 2012 Bridge Consulting All rights reserved Apresentação Esta publicação tem por objetivo apresentar

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO CA IT Asset Manager como gerenciar o ciclo de vida de ativos, maximizar o valor dos investimentos em TI e obter uma exibição do portfólio de todos os meus ativos? agility made possible

Leia mais

SEMANA NACIONAL DE CONCILIAÇÃO 2013

SEMANA NACIONAL DE CONCILIAÇÃO 2013 SEMANA NACIONAL DE CONCILIAÇÃO 2013 RELATÓRIO DA PESQUISA DE SATISFAÇÃO CEJUSC-JEC/BSB DEZEMBRO, 2013. Apresentação O presente documento revela os resultados da Pesquisa de Satisfação do Usuário (PSU)

Leia mais

Expansão dos Projetos Kaizen para os Fornecedores: Estudo de Caso na Indústria Aeronáutica

Expansão dos Projetos Kaizen para os Fornecedores: Estudo de Caso na Indústria Aeronáutica Expansão dos Projetos Kaizen para os Fornecedores: Estudo de Caso na Indústria Aeronáutica Fernando Reimberg Syrio fernando_reimberg@hotmail.com ITA João Murta Alves murta@ita.br ITA Resumo:Este trabalho

Leia mais

Relatório A3: ferramenta para melhorias de processos*

Relatório A3: ferramenta para melhorias de processos* Relatório A3: ferramenta para melhorias de processos* Durward K. Sobek, II Montana State University Cindy Jimmerson Community Medical Center Tradução: Diogo Kosaka O relatório A3 é uma ferramenta que a

Leia mais

Lean manufacturing ou Toyotismo

Lean manufacturing ou Toyotismo ou Toyotismo Gestão da Qualidade Resultados impressionantes 1 Trimestre 2007 Toyota supera GM como líder mundial em vendas Vendas Mundiais 1º Trimestre Nº Carros Toyota 2.348.000 GM 2.260.000 2007 termina

Leia mais

Gestão Ágil de Requisitos e Scrum

Gestão Ágil de Requisitos e Scrum Gestão Ágil de Requisitos e Scrum Agilidade na gestão de requisitos e desenvolvimento de softwares... Trabalho apresentado na disciplina Introdução à Computação, curso de Tecnologia em Análise e Desenvolvimento

Leia mais

15/09/2011. Historico / Conceito. Lean Production é um programa corporativo ADMINISTRAÇÃO DA PRODUÇÃO II. Evolucao do Conceito LEAN THINKING

15/09/2011. Historico / Conceito. Lean Production é um programa corporativo ADMINISTRAÇÃO DA PRODUÇÃO II. Evolucao do Conceito LEAN THINKING Historico / Conceito Lean : década de 80 James Womack (MIT) Projeto de pesquisa: fabricantes de motores automotivos; ADMINISTRAÇÃO DA PRODUÇÃO II Lean Production é um programa corporativo composto por

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Declaração de Escopo

Declaração de Escopo 1/9 Elaborado por: Adriano Marra, Bruno Mota, Bruno Leite, Janaina Versão: 1.4 Lima, Joao Augusto, Paulo Takagi, Ricardo Reis. Aprovado por: Porfírio Carlos Roberto Junior 24/08/2010 Time da Equipe de

Leia mais

Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia.

Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia. Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia. Introdução Sávio Marcos Garbin Considerando-se que no contexto atual a turbulência é a normalidade,

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

A Cadeia de Ajuda para Manter a Estabilidade Produtiva

A Cadeia de Ajuda para Manter a Estabilidade Produtiva A Cadeia de Ajuda para Manter a Estabilidade Produtiva Sergio Kamada* Este artigo tem como objetivo descrever a importância da Cadeia de Ajuda no processo de estabilização produtiva e apresentar métodos

Leia mais

Estratégias em Tecnologia da Informação. Planejamento Estratégico Planejamento de TI

Estratégias em Tecnologia da Informação. Planejamento Estratégico Planejamento de TI Estratégias em Tecnologia da Informação Capítulo 7 Planejamento Estratégico Planejamento de TI Material de apoio 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Terceirização de Serviços de TI

Terceirização de Serviços de TI Terceirização de Serviços de TI A visão do Cliente PACS Quality Informática Ltda. 1 Agenda Terceirização: Perspectivas históricas A Terceirização como ferramenta estratégica Terceirização: O caso específico

Leia mais

Automação de Processos de Governança de TI. As diversas Gerações da Gestão Organizacional. A Quarta Geração é a da Gestão de Processos

Automação de Processos de Governança de TI. As diversas Gerações da Gestão Organizacional. A Quarta Geração é a da Gestão de Processos Automação de Processos de Governança de TI Autor: Omar Mussi A Governança Corporativa vem sendo adotada pelas organizações para atender às necessidades de um mercado cada vez mais competitivo e para enfrentar

Leia mais

CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS E ARQUITETURA SUBÁREA: ENGENHARIAS INSTITUIÇÃO: FACULDADE DE ENGENHARIA DE SOROCABA

CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS E ARQUITETURA SUBÁREA: ENGENHARIAS INSTITUIÇÃO: FACULDADE DE ENGENHARIA DE SOROCABA TÍTULO: UTILIZAÇÃO DE SOFTWARES DEDICADOS PARA O DESENVOLVIMENTO E ELABORAÇÃO DO MAPEAMENTO DO FLUXO DE VALOR (MFV) EM SISTEMAS DE PRODUÇÃO ENXUTA LEAN PRODUCTION CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS

Leia mais

Por que utilizar o modelo ITIL

Por que utilizar o modelo ITIL Por que utilizar o modelo ITIL... O que não é definido não pode ser controlado... O que não é controlado não pode ser medido... O que não é medido não pode ser melhorado Empregado para definir, controlar,

Leia mais

Como Configurar Tabelas Básicas do OASIS (Informações Básicas)

Como Configurar Tabelas Básicas do OASIS (Informações Básicas) Como Configurar Tabelas Básicas do OASIS (Informações Básicas) O OASIS foi desenvolvido de forma parametrizada para poder atender às diversas particularidades de cada usuário. No OASIS também, foi estabelecido

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,

Leia mais

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO Competências Analista 1. Administração de recursos de infra-estrutura de tecnologia da informação 2.

Leia mais

Metodologia de Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP

Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP Parceiros de serviços em nuvem gerenciada Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP Implemente a versão mais recente do software da SAP de classe mundial,

Leia mais

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO Controle de Versões Autor da Solicitação: Subseção de Governança de TIC Email:dtic.governanca@trt3.jus.br Ramal: 7966 Versão Data Notas da Revisão 1 03.02.2015 Versão atualizada de acordo com os novos

Leia mais

Governança e Qualidade em Serviços de TI COBIT Governança de TI

Governança e Qualidade em Serviços de TI COBIT Governança de TI Governança e Qualidade em Serviços de TI COBIT Governança de TI COBIT Processos de TI Aplicativos Informações Infraestrutura Pessoas O que é o CObIT? CObIT = Control Objectives for Information and Related

Leia mais

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 Capítulo 8 Gerenciamento da Qualidade do Projeto O Gerenciamento da Qualidade do Projeto inclui os processos necessários para garantir que o projeto irá satisfazer as necessidades para as quais ele foi

Leia mais

Estudo de Viabilidade

Estudo de Viabilidade Estudo de Viabilidade PGE: Plastic Gestor Empresarial Especificação de Requisitos e Validação de Sistemas Recife, janeiro de 2013 Sumário 1. Motivação... 1 2. Introdução: O Problema Indentificado... 2

Leia mais

Governo do Estado do Rio de Janeiro

Governo do Estado do Rio de Janeiro Governo do Estado do Rio de Janeiro Modelo de governança para contratos de desenvolvimento de software sob, no âmbito de programas financiados. Manual de Uso Histórico da revisão Data Versão Descrição

Leia mais

as cinco principais batalhas do monitoramento e como você pode vencê-las

as cinco principais batalhas do monitoramento e como você pode vencê-las DOCUMENTAÇÃO TÉCNICA Setembro de 2012 as cinco principais batalhas do monitoramento e como você pode vencê-las agility made possible sumário resumo executivo 3 efetivo do servidor: 3 difícil e piorando

Leia mais

Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa

Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa Edméia Leonor Pereira de Andrade Embrapa edmeia.andrade@embrapa.br AngélicaToffano Seidel Calazans Caixa Econômica Federal

Leia mais

Lean IT. Pensamento Enxuto para construção de times de TI de Alta Performance. www.livroleanit.com

Lean IT. Pensamento Enxuto para construção de times de TI de Alta Performance. www.livroleanit.com Lean IT Pensamento Enxuto para construção de times de TI de Alta Performance www.livroleanit.com ALINHAMENTO DE EXPECTATIVAS ALINHAMENTO 1 ( O Segredo ) ALINHAMENTO 2 ( Sem tradução simultânea ) AGENDA...Você

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO

JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO O presente artigo, mostra de forma clara e objetiva os processos da ferramenta Just in time, bem como sua importância para a área de produção.

Leia mais

Kanban na Fábrica de Software

Kanban na Fábrica de Software Kanban na Fábrica de Software Casimiro Beleze (UEM) casimirobeleze@hotmail.com Lafaiete H. R. Leme (UEM) lafaiete@din.uem.br Resumo: Este trabalho apresenta um enfoque diferenciado para o gerenciamento

Leia mais

DEFINIÇÃO DE LEAN MANUFACTURING

DEFINIÇÃO DE LEAN MANUFACTURING MANUFATURA ENXUTA DEFINIÇÃO DE LEAN MANUFACTURING A ORIGEM DA PALAVRA LEAN O termo LEAN foi cunhado originalmente no livro A Máquina que Mudou o Mundo de Womack, Jones e Roos, publicado nos EUA em 1990.

Leia mais

COMO MELHORAR O DESEMPENHO DAS LINHAS DE. Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software

COMO MELHORAR O DESEMPENHO DAS LINHAS DE. Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software COMO MELHORAR O DESEMPENHO DAS LINHAS DE PRODUÇÃO Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software Objetivo Apresentar conceitos e ferramentas atuais para melhorar eficiência da produção

Leia mais

Perfis Profissionais e Modelo de Carreira da Informática em Saúde. Versão 1.0 para CONSULTA PÚBLICA

Perfis Profissionais e Modelo de Carreira da Informática em Saúde. Versão 1.0 para CONSULTA PÚBLICA Perfis Profissionais e Modelo de Carreira da Informática em Saúde Versão 1.0 para CONSULTA PÚBLICA Janeiro de 2012 SUMÁRIO 1. Estrutura dos Perfis Funcionais... 5 2. Perfis Funcionais por Área de Domínio...

Leia mais

Aula Nº 10 Planejamento da Comunicação

Aula Nº 10 Planejamento da Comunicação Aula Nº 10 Planejamento da Comunicação Objetivos da Aula: Os objetivos desta aula visam analisar as necessidades de informação para se manter os stakeholders internos e externos bem como a equipe de projetos

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

Leia mais

Aquecimento para o 3º Seminário Internacional de BPM

Aquecimento para o 3º Seminário Internacional de BPM Aquecimento para o 3º Seminário Internacional de BPM É COM GRANDE PRAZER QUE GOSTARÍAMOS DE OFICIALIZAR A PARTICIPAÇÃO DE PAUL HARMON NO 3º SEMINÁRIO INTERNACIONAL DE BPM!! No ano passado discutimos Gestão

Leia mais