Pesquisar neste blog

30 de set de 2012

Os Gurus da Qualidade

Por: Zafenate Desidério
Em: http://www.qualidadebrasil.com.br/noticia/os_gurus_da_qualidade


Estes sãos os personagens que através de suas metodologias conseguiram transformar a Qualidade em algo mais objetivo, garantindo assim a sua definição clara. No meu entender muitos foram na sua época verdadeiros inovadores que através de uma necessidade buscaram uma solução e firmaram a mesma como uma permanente ideia que são aplicadas até hoje.
Portanto hoje vou apresentar cada um desses conhecidos gênios da Qualidade, com um resumo de suas histórias e claro, futuramente pretendo voltar na apresentação de cada um destes personagens que com certeza motivam o desenvolvimento da era moderna.
Walter Shewhart
Walter ShewhartFoi um físico, engenheiro e estatístico estadunidense, conhecido como o "pai do controle estatístico de qualidade". 
Foi consultor de várias organizações entre elas o departamento de guerra americano, as nações unidas e o governo indiano.
Ele também lecionou nas universidades de Harvard, Rutgers e Princeton. A contribuição mais importante de Shewhart tanto para a Estatística quanto para a indústria foi o desenvolvimento do Controle Estatístico de Qualidade. A idéia era incorporar o uso de vários aleatórias independentes e identicamente distribuídas.
O princípio geral por trás da idéia é que quando um processo está em estado de controle e seguindo uma distribuição particular com certos parâmetros o propósito é determinar quando o processo se afasta deste estado e as ações corretivas que devem ser tomadas.
Armand Feigenbaum
Armand FeigenbaumEm 1951, concluiu o doutorado em Ciências no Instituto Tecnológico de Massachusetts. Em 1958 foi nomeado diretor mundial de produção da GE e vice-presidente da American Society for Quality Control (ASQC). Em 1961 foi eleito presidente da ASQC. Em 1968 escreveu seu primeiro livro, que se tornou um best-seller e lhe conferiu notoriedade mundial, “Controle Total de Qualidade” . Neste mesmo ano fundou a General Systems , da qual é presidente.
Feigenbaum é considerado o “pai” da qualidade e afirma que esta é um trabalho de todos na organização, e que não é possível fabricar produtos de alta qualidade se o departamento de manufatura trabalha isolado. Segundo ele diferentes departamentos devem intervir nas parcelas do processo que resultam no produto, esta colaboração varia desde o projeto do produto ao controle pós-venda, para que assim não ocorram erros que prejudiquem a cadeia produtiva, causando finalmente problemas ao consumidor.
Feigenbaum é considerado o “pai” da qualidade e afirma que esta é um trabalho de todos na organização, e que não é possível fabricar produtos de alta qualidade se o departamento de manufatura trabalha isolado.
Segundo ele diferentes departamentos devem intervir nas parcelas do processo que resultam no produto, esta colaboração varia desde o projeto do produto ao controle pós-venda, para que assim não ocorram erros que prejudiquem a cadeia produtiva, causando finalmente problemas ao consumidor.
William Edwards Deming
William Edwards DemingFoi um estatístico, professor universitário, autor, palestrante e consultor estadunidense. Deming é amplamente reconhecido pela melhoria dos processos produtivos nos Estados Unidos durante a Segunda Guerra Mundial, sendo porém mais conhecido pelo seu trabalho no Japão. 
Deming é amplamente reconhecido pela melhoria dos processos produtivos nos Estados Unidos durante a Segunda Guerra Mundial, sendo porém mais conhecido pelo seu trabalho no Japão. Lá, a partir de 1950, ele ensinou altos executivos como melhorar projeto, qualidade de produto, teste e vendas (este último por meio dos mercados globais) através de vários métodos, incluindo a aplicação de métodos estatísticos como a análise de variantes e teste de hipóteses.
Deming fez contribuições significativas para o Japão tornar-se notório pela fabricação de produtos inovadores de alta qualidade. Deming é considerado o estrangeiro que gerou o maior impacto sobre a indústria e a economia japonesa no século XX.
Joseph Moses Juran
Joseph Moses JuranEle inicia sua carreira como gestor de qualidade na Western Electrical Company e, em 1926, é convidado a participar do Departamento de Inspeção Estatística da empresa no qual ficou responsável pela aplicação e disseminação das novas técnicas de controle estatístico de qualidade, possibilitando uma rápida ascensão na organização.
Como chefe do departamento, publicou seu primeiro artigo sobre qualidade relacionada à engenharia mecânica em 1935.
Para Juran a gestão da Qualidade tem 3 pontos fundamentais, a famosa trilogia: 
  1. O planejamento da qualidade
  2. A melhoria da qualidade
  3. O controle da qualidade
Em 1974, Juran funda o Juran Institute para facilitar a disseminação de suas idéias através de livros, vídeos e outros materiais. É considerada atualmente uma das mais importantes consultorias de gestão de qualidade do mundo. Mesmo após a morte de seu idealizador, em 2008, o instituto continua a auxiliar empresas na otimização da qualidade, além de manter acessíveis as contribuições de Joseph Juran.
Philip B. Crosby
Philip B. CrosbyComo pensador e filósofo da gestão empresarial moderna, Philip Crosby se fundamentou em mais de 40 anos de experiências vividas.
Em suas palestras, proporcionava uma discussão estimulante e reflexiva sobre o papel dos empresários e executivos em fazer que suas empresas, colaboradores, fornecedores e eles mesmos sejam bem sucedidos. Através de histórias do cotidiano dosadas de anedotas aplicáveis, o Sr. Crosby proporcionava uma atmosfera estimulante.
Como empresário, Philip Crosby começou sua carreira trabalhando na linha de montagem onde decidiu que seu objetivo seria ensinar ás gerência das empresas que a prevenção de problemas é mais rentável que ser competente em resolvé-los depois que ocorreram. Trabalhou na Croley entre 1952 e 1955, na Martin-Marietta entre 1957 e 1965 e na ITT entre 1965 e 1979. Foi como Gerente de Qualidade na Martin-Marietta , onde criou o conceito de "Zero Defeitos".
Enquanto exercia a função de Vice Presidente na ITT Corporation, responsável pela qualidade da empresa em todo o mundo, teve a oportunidade de implementar sua filosofía de gestão em diversas organizações industriais e de prestação de serviços e comprovou que funcionava perfeitamente em todas elas.
Kaoru Ishikawa
Kaoru IshikawaIshikawa aprendeu os princípios do controle estatístico da qualidade desenvolvido por americanos. Kaoru traduziu, integrou e expandiu os conceitos de gerenciamento do Dr. William Edwards Deming e do Dr. Joseph Moses Juran para o sistema japonês.
Talvez a contribuição a mais importante de Ishikawa foi seu papel chave no desenvolvimento de uma estratégia especificamente japonesa da qualidade. A característica japonesa é a ampla participação na qualidade, não somente de cima para baixo dentro da organização, mas igualmente começa e termina no ciclo de vida de produto. No final dos anos 50 e no início dos anos 60, Ishikawa desenvolveu cursos do controle da qualidade para executivos e gerentes. Igualmente ajudou o lançamento da Conferência Anual do Controle da Qualidade para gerência, diretores em 1963.
Kaoru Ishikawa quis mudar a maneira das pessoas pensarem a respeito dos processos de qualidade. Para Ishikawa, “a qualidade é uma revolução da própria filosofia administrativa, exigindo uma mudança de mentalidade de todos os integrantes da organização, principalmente da alta cúpula”. Sua noção do controle empresarial da qualidade era voltada ao atendimento pós venda. Isto significa que um cliente continuaria a receber o serviço mesmo depois de receber o produto. Este serviço se estenderia através da companhia em todos os níveis hierárquicos e até mesmo no cotidiano das pessoas envolvidas. De acordo com Ishikawa, a melhoria de qualidade é um processo contínuo, e pode sempre pode ser aperfeiçoada.
Ishikawa mostrou a importância das sete ferramentas da qualidade:
  • Diagrama de Pareto
  • Diagrama de causa e efeito
  • Histograma
  • Folhas de verificação
  • Gráficos de dispersão
  • Fluxograma
  • Cartas de Controle.
Genichi Taguchi
Genichi TaguchiTaguchi iniciou seus estudos - essencialmente em engenharia têxtil - na cidade de Tokamachi, no intuito de entrar para o ramo de criação e desenvolvimento de quimonos da família.
No entanto, com a eclosão da II Guerra Mundial, em 1942, ele foi convocado a participar no Departamento Astronômico do Instituto de Navegação da Marinha Imperial Japonesa.
Em 1950, ele aderiu à Electrical Communications Laboratory (ECL), da Nippon Telegraph and Telephone Corporation apenas no controle de qualidade estatística.
Taguchi começava a tornar-se popular no Japão sob a influência de W. Edwards Deming e da União Japonesa de Cientistas e Engenheiros. Taguchi passou doze anos no desenvolvimento de métodos para o aumento na qualidade.
Nesta altura, ele estava começando a dar consultoria a toda indústria japonesa, sendo inclusive o sistema Toyota influenciado por suas idéias.
Tom Peters
Tom PetersQuando lançou seu primeiro livro, em 1982, Tom Peters estava iniciando uma caminhada que o tornaria conhecido como continuador do trabalho de Peter Drucker, considerado por muitos como o papa da moderna administração de empresas.
Para o autor, a excelência nos negócios depende basicamente de oito ingredientes e as empresas que desejam ser excelentes em suas áreas de atuação devem buscar:
  1. A pró-atividade com incentivo às pessoas para melhorar o que se está fazendo através de uma fórmula de ensaio e erro: “fazem, consertam e tentam fazer melhor”.
  2. Aprender com os clientes. Empresas excelentes “aprendem com as pessoas que a estão servindo”
  3. Estimular a independência promovendo o empreendedorismo e a autonomia dos colaboradores.
  4. Gestão se aprende gerindo. Só fazendo se é possível aprender algo novo e capaz de movimentar a empresa no caminho da excelência.
  5. Produtividade só se alcança com trabalhadores motivados e produtivos, portanto eles são avaliados como peças-chave para o sucesso.
  6. Foco. Empresas excelentes se atêm às suas competências, e não saem atirando para todos os lados
  7. Simplicidade. Manter a forma simples e a equipe a mais enxuta possível.
  8. Mobilidade. As empresas excelentes podem sair de um formato compacto para a expansão rapidamente, adequando-se às necessidades do mercado e dos clientes.
Shigeo Shingo
Shigeo ShingoSeus estudos o levaram ao desenvolvimento do Sistema Toyota - em conjunto com Taiichi Ohno, e do SMED (Single Minute Exchange of Die) por ele concebido. Além disso, criou e formalizou o Sistema de Controle de Qualidade Zero, o qual ressalta a aplicação dos Poka-Yoke, também criado por Shingo. O Poka-yoke,um sistema de inspeção na fonte, envolve o controle de produtos e suas características em si ou do seu processo de obtenção, de modo a minimizar-se a ocorrência de erros através de ações simples. O método pode ser dividido nas seguintes fases.
  • Detecção: busca identificar o erro antes que este se torne um defeito.
  • Minimização: busca minimizar o efeito do erro.
  • Facilitação: busca adoção de técnicas que facilitem a execução das tarefas nos processos de manufatura ou no fornecimento de serviços.
  • Prevenção: busca ações para impedir que o erro ocorra.
  • Substituição: busca substituir processos ou sistemas por outros mais consistentes.
  • Eliminação: busca a eliminação da possibilidade de ocorrência de erros pelo redesenho do produto, do processo de obtenção ou da prestação de serviços.
Fonte: Wikipédia, Portal Qualidade Brasil

29 de set de 2012

Saiba Como Avaliar o Desempenho de Sua Equipe

Por: Julio Cesar S. Santos 
Em:http://www.qualidadebrasil.com.br/artigo/gestao/saiba_como_avaliar_o_desempenho_de_sua_equipe


Como Avaliar o Desempenho dos Colaboradores? Como Quantificar as Metas? Como Fugir das Armadilhas de Uma Avaliação de Desempenho?
Geralmente os funcionários precisam e querem um feedback sobre a qualidade de seu trabalho. A capacidade de o Gerente avaliar seus desempenhos tem um impacto tão importante no sucesso deles quanto no sucesso do próprio Gerente. Se a empresa tem um programa formal de avaliação, o Gerente deve seguir suas instruções em termos de tempo, classificação, promoção, treinamento, etc... Mas, se a política permitir, as sugestões abaixo podem tornar esse processo de avaliação mais eficaz:
  • Quantifique as metas de desempenho, se possível: “Eu planejo diminuir as reclamações dos clientes pelo menos 10% este Ana”. “Pretendo reduzir as perdas em 15% este trimestre”. Expressar as metas em números impede predisposições e permite aos funcionários avaliarem seu progresso, clara e precisamente.
  • Você deveria manter um diário? : Alguns Gerentes utilizam-no para registrar incidentes e exemplos do desempenho que podem ser esquecidos. O registro garante informações ao longo de todo período, produzindo uma avaliação mais completa.
  • Considere a auto-avaliação: Alguns Gerentes pedem a seus funcionários que se avaliem. Essa prática amplia as informações que o Gerente pode usar para preparar a avaliação. Quando funcionários se auto-avaliam, pensam criticamente sobre seu progresso e suas realizações; e elas podem informá-lo sobre realizações, reconhecimentos e problemas que o Gerente não conhecia. Mas, para evitar abusos, ele deve definir 2 regras: (1) exigir que eles forneçam apoio quantificável para suas próprias avaliações. Se não o fizer, podem dar a si próprios, classificações acima do merecido. Recuse os 100% que dizem de si mesmos. (2) “Essa oportunidade é um privilégio, não um direito”. As auto-avaliações do Gerente são apenas uma das informações que ele pode usar para uma avaliação mais completa.
  • Cortando os problemas pela raiz: Comportamentos ou desempenhos inaceitáveis devem ser informados no ato. Por exemplo, um funcionário que sempre volta do almoço atrasado, deve ser informado do problema e do seu impacto na revisão da avaliação. Essa prática é melhor do que deixar a situação arrastar-se até a avaliação.
Armadilhas das Avaliações de Desempenho
As avaliações estão sujeitas a riscos, mas podem ser evitados se soubermos quais são:
  • As impressões negativas: os Gerentes devem se prevenir contra a formação de opiniões positivas ou negativas baseadas na personalidade ou aparência pessoal. Dessa forma, ele deve se concentrar em avaliar se o funcionário cumpriu corretamente as metas.
  • Tolerância: alguns Gerentes tendem a ser permissivos porque se sentem constrangidos ao discutir as deficiências de seus funcionários e, embora isso às vezes seja compreensível, a maior responsabilidade gerencial é aconselho colaborador sobre como melhorar seu desempenho. Todos sofrem com uma avaliação tolerante, a organização não obtém retorno do investimento, os funcionários abaixo da média podem perder o respeito por seus chefes, ao mesmo tempo em que adquirem falsa segurança.
  • Tendência central: essa armadilha – que tem parentesco com a tolerância – é a inclinação do Gerente em avaliar como aceitáveis todos os desempenhos. Nesse caso, ele comete a injustiça com os que têm bom desempenho.
  • Concentrar em um comportamento recente: é mais fácil de lembrar; mas, conta apenas uma parte da história. Avaliações devem acessar o desempenho do período completo desde a última avaliação, não apenas os acontecimentos ou progressos recentes.
A Reunião de Avaliação
Alguns Gerentes consideram essa reunião “um mal necessário”, pois as informações trocadas entre ambos podem ser muito importantes para os avaliados. Dessa forma, os Gerentes devem definir data e hora convenientes para todos e informar ao avaliado que assuntos irão discutir, para que ele chegue preparado.
Rever as atribuições do cargo e os registros anteriores e refletir sobre as obrigações e responsabilidades do avaliado, os projetos completados ou pendentes, as metas acordadas para o período, o treinamento, a experiência, as habilidades de planejamento, a organização, a iniciativa, a capacidade de relações sociais e outros atributos baseados exclusivamente no desempenho.
Alguns Gerentes começam elogiando as realizações e as qualidades do avaliado, abordando as áreas que precisam melhorias e as ações que o avaliado pode realizar para corrigir ou aumentar o desempenho naquelas áreas. Diante disso, o Gerente deve evitar frases vagas. Deve apoiar sua avaliação citando incidentes, datas, horários e evidências objetivas do bom e do mau desempenho.
Além disso, o Gerente Jamais deve comparar os colaboradores, pois isso pode trazer problemas, pois indicar modelos pode criar ressentimentos. Em vez disso, deve se concentrar em saber se o avaliado atingiu – ou não – as metas estabelecidas.
LEMBRE-SE: as avaliações de desempenho são orientadas para o sucesso, confirmando os pontos fortes, revelando as deficiências e destacando as necessidades de treinamentos adicionais.

28 de set de 2012

Melhorias de Processos segundo o PDCA – Parte II

Por: José Luiz S. Messias 
Em:http://www.qualidadebrasil.com.br/artigo/qualidade/melhorias_de_processos_segundo_o_pdca_parte_ii?goback=%2Egde_1351_member_110830297


No artigo anterior, pude escrever sinteticamente sobre o método. Também, sobre as suas vantagens e a possibilidade de ganhos reais com a sua aplicação, quando bem gerenciado.
Dando continuidade ao artigo anterior, escreverei hoje e nos próximos artigos sobre a primeira fase da etapa P, sendo esta responsável por quatro fases na aplicação deste método, e, pela experiência adquirida, a etapa em que se deveria gastar mais tempo em um projeto de melhoria.
O objetivo deste artigo é auxiliar os leitores no entendimento para implantação deste método, sendo o foco deste artigo a primeira fase da etapa P, a etapa de Identificação do Problema.
Desenvolvimento
A etapa P inicia-se com a fase de Identificação do Problema, cujo objetivo principal é definir o problema, além de mostrar junto à organização que o problema definido deve ser resolvido com prioridade.
Como em todos os métodos, e não somente neste, devem ser coletados dados para confirmar a veracidade do problema, para não prevalecer o famoso “sentimento”. Lembram-se das sete ferramentas da qualidade? Hora de aplicá-las aqui e em todas as fases desta etapa.
Um gráfico visualizando o histórico do problema pode ser utilizado, como o apresentado abaixo:
No gráfico acima fica claro a perda de desempenho causada, e o efeito desta perda, o não atendimento aos clientes. De fato, outra forma que poderia ser aplicada para mostrar a importância do problema é como ele afeta as cinco dimensões da qualidade.
Na fase de Identificação do Problema pode ser utilizado pela primeira vez o Diagrama de Pareto para relacionar os principais motivos do problema em questão. Lembrando que nesta etapa não devem ser buscadas causas para o problema, e sim saber os motivos principais que impactam no problema.
Um Diagrama de Pareto, simples, rápido e objetivo como o apresentado abaixo:
Onde, no gráfico acima, poderia ser colocada também a % dos motivos perante a % total. Isto possibilita a estratificação dos motivos para a definição da(s) meta(s) do projeto.
Nesta fase inicial, cheia de motivação e um pouco de “ansiedade”, deve ser feita uma análise minuciosa pela equipe do projeto, afim de identificar quantos motivos poderão ser “atacados”. Em caso de dúvida, relate ao gestor do projeto a necessidade de uma nova equipe de projeto para atacar os outros motivos.
Na Identificação do Problema, como já foi citado no parágrafo anterior, é a fase para a definição da equipe de trabalho do projeto. Devem fazer parte da equipe pessoas pró-ativas, com facilidade para trabalhar com metodologias, que tenham conhecimento técnico do assunto a ser abordado no projeto, e que gostem de trabalhar em grupo.
Cabe ao líder do projeto manter a equipe de trabalho motivada e focada no resultado final (leia-se meta). A meta deverá ser definida pela equipe de trabalho, com base em todos os dados levantados, e deverá possuir:
  • a) Objetivo – Reduzir, Aumentar, Ampliar, ...;
  • b) Valor – Quantificação do que vai ser trabalhado no projeto;
  • c) Prazo – Prazo final previsto da conclusão do projeto.
A meta definida nos critérios técnicos do projeto, como neste exemplo – “Perdas Metálicas (kg/t)” deve ser convertida para um ganho financeiro, afim de mostrar à organização que, resolvendo um problema de médio ou grande porte, a empresa poderá melhorar o seu custo variável e assim ficar mais competitiva no setor em que atua.
A tabela-resumo abaixo orienta e exemplifica uma maneira de apresentar os ganhos previstos em um projeto:
Para concluir esta fase, é necessário entregar um cronograma com todos os prazos previstos iniciais e finais para a etapa P.
Observações finais
  • Use o maior número de ferramentas estatísticas, incluindo a utilização das 7 Ferramentas da Qualidade, para identificar o problema e motivo mais importante.
  • Quanto maior o impacto estratégico que for gerado no negócio com a resolução do problema, mais urgente o mesmo precisa ser resolvido.
  • A definição de um cronograma é importante, porém não se esqueça de levar em conta os recursos humanos e tecnológicos. Um bom trabalho em um projeto não será levado em consideração se o prazo de conclusão for ultrapassado.
Reforçando: utilize quantas ferramentas estatísticas, planilhas e informações forem necessárias para justificar adequadamente a escolha do projeto.
Até o próximo artigo! Com a fase 2 – Análise de Fenômeno



27 de set de 2012

Cuidado, não deixe o ERP perder a funcionalidade!

Por: 
Em: http://www.profissionaisti.com.br/2012/05/cuidado-nao-deixe-o-erp-perder-a-funcionalidade/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+profissionaisti+%28Profissionais+TI+-+Pra+quem+respira+informa%C3%A7%C3%A3o.%29


Desde que as empresas começaram a investir em tecnologia, tornou-se fundamental possuir um sistema computadorizado capaz de integrar todo o plano corporativo de uma organização. É muito comum encontrar sistemas para funções específicas, como gestão de contabilidade, recursos humanos, fiscalização, estoque e emissão de notas fiscais. Assim, até alguns anos atrás, uma empresa precisava instalar vários softwares para controlar todo o complexo interno operacional e administrativo. Essa dispersão de aplicativos foi solucionada com o desenvolvimento de um software capaz de integrar a maioria (ou todos) os departamentos da empresa em um único ambiente. Tal software, hoje muito importante para as empresas, recebeu o nome de ERP – Enterprise Resource Planning. No Brasil, esse software ficou conhecido como “Sistema Integrado de Gestão Empresarial”, embora muitas empresas ainda optem por utilizar o termo inglês “ERP”.
O surgimento do ERP incentivou a criação de um novo departamento dentro das empresas: a equipe de desenvolvimento de sistemas. Neste novo ambiente, as empresas contratam programadores para trabalhar internamente no desenvolvimento de um software para atender toda a demanda organizacional. Através do levantamento de requisitos e da análise de negócios, os profissionais dessa área provêm o desenvolvimento de um sistema totalmente modelado à estrutura da empresa. Existem também empresas que preferem implantar um sistema terceirizado, ou seja, desenvolvido por uma empresa de software especializada.
Por quê um sistema ERP deve ser mantido por uma equipe de desenvolvedores?
Como um ERP integra todos os setores de uma empresa, é muito frequente a necessidade de alteração ou atualização de alguns módulos relacionados aos processos operacionais e administrativos. Por exemplo, há alguns anos o governo iniciou a implantação da Nota Fiscal Eletrônica e determinou um prazo para que todas as empresas obrigatoriamente a implantassem em sua gestão. E aconteceu o que estava previsto: muitos ERPs tiveram que passar por consideráveis alterações para obter suporte para a emissão de Notas Fiscais Eletrônicas. Poucos anos depois, o governo implantou a versão 2.0 da Nota Fiscal Eletrônica, e mais uma vez os ERPs tiveram que sofrer alterações. São nestes casos que a equipe de desenvolvimento entra em atividade para atualizar o sistema de forma rápida e consistente.
Este foi só um exemplo. Na prática os sistemas ERP passam por várias alterações constantemente. Dependendo do escopo do sistema, podem surgir alterações relacionadas à setores tributários, relatórios, leis governamentais, parcerias e novas integrações, além de aspectos técnicos, como a utilização de novas tecnologias, dispositivos móveis e a integração com a web. No entanto, dentro deste contexto, é comum encontrar casos em que um ERP perde a funcionalidade.
Perdem a funcionalidade? Como assim?
Imagine que você possua um aparelho celular, daqueles antigos com tecnologia CDMA. Com o passar do tempo, surgem novas tecnologias como o 3G, Bluetooth, Player multimídia e acesso à Internet. Então você começa a notar que o seu antigo celular já não tem mais condições de operar nesse novo ambiente. O mesmo acontece com um sistema ERP: se ele deixar de ser atualizado, vai ser tornando cada vez menos funcional dentro da empresa. Um ERP deve estar pronto para oferecer informações com precisão e pontualidade acompanhado das condições variáveis do mercado externo, senão ele não oferecerá integridade. Em outras palavras, a partir do momento que um sistema não consegue mais atender os requisitos essenciais de uma empresa, pode-se dizer que ele se torna “inválido”.
E então ele não servirá pra mais nada?
Serve, claro, mas algumas funções não poderão mais ser processadas através dele. Dessa forma será preciso instalar outro sistema para cobrir essa parte em falta. Assim, aos poucos a empresa voltará ao tempo em que era preciso um software para cada função interna. Resultado: a empresa começa a gastar demais para manter vários sistemas instalados, além de ter que lidar com suportes técnicos.
Se um ERP perde a funcionalidade, ele é substituído – e essa substituição ocorre com muita frequência, principalmente por falta de recursos, suporte técnico ou atraso nas atualizações. Portanto, procure conscientizar a equipe de desenvolvimento para manter o sistema sempre atualizado.
Mesmo que o usuário (ou cliente) não tenha solicitado alterações, teste o sistema por algum tempo e procure meios para facilitar as funções, torná-las mais rápidas ou integrá-lo a algum outro dispositivo utilizado pelo usuário. Isso é muito importante para o reconhecimento do sistema, além de passar segurança aos usuários.
Publicado originalmente em Blog O Núcleo

26 de set de 2012

Melhorias de processos segundo o PDCA - Parte I

Por: José Luiz S. Messias 
Em: http://www.qualidadebrasil.com.br/artigo/qualidade/melhorias_de_processos_segundo_o_pdca_-_parte_i



Ao participar de grupos de discussão na rede social LinkedIn, deparei-me com asseguintes questões: “Como realizar melhorias com o PDCA? Por onde começar?”.Com o objetivo de compartilhar o conhecimento da utilização desta metodologiapoderosa, quando acreditada e bem utilizada, foi elaborado por mim um roteiro paraa utilização desta ferramenta, que pode gerar ganhos da ordem de R$ 50.000,00 atéR$1.000.000,00, dependendo do projeto em trabalho.
O que é PDCA? É uma Metodologia Avançada de Solução de Problemas (MASP), ou ainda, que poderia ser chamada de QC Story, traduzida informalmente por Estória de um Círculo da Qualidade, sendo esta definição bem utilizada no Japão.
Esta metodologia pode ser utilizada para a melhoria de processos, sejam estes para a produção de bens ou para empresas de prestação de serviços. Por ser dividido em 8 etapas, ou passos, pode ser encontrado na literatura sobre a forma de 8 D’s.
Por que esta ferramenta é aplicada de maneira comum em empresas? Por que os resultados trazidos nos projetos satisfazem colaboradores de diferentes níveis na empresa, desde os acionistas, média-gerência e colaboradores em nível operacional.
É fácil de ser aplicada, pois necessita de um conhecimento mínimo de Estatística, quando comparada à metodologia 6 Sigma. Um bom projeto pode ser realizado utilizando somente as 7 Ferramentas da Qualidade, que citarei ao longo deste artigo, que será escrito em três partes.
Além dos ganhos do projeto, definidos nas métricas adequadas, uma melhoria de processo com o PDCA trás também ganhos intangíveis, tais como:
  • a) Comprometimento dos colaboradores na Gestão do Negócio e de seus indicadores, os IC’s – Itens de Controle e os IV’s – Itens de Verificação;
  • b) Aproveitar o talento humano individual e natural do colaborador para contribuir com a resolução dos problemas de sua célula ou setor de trabalho;
  • c) Quebra de um paradigma de uma empresa: somente o líder ou o superior tem conhecimento e resolve problemas.
No item “c” supracitado, foi citada a palavra problema, como no início deste artigo, mas, como poderá ser conceituada a palavra problema?
Segundo Vicente Falconi, problema é um resultado indesejável de um trabalho(1). Pela definição do Prof. Falconi, em todas as vezes que o trabalho não alcançou o seu resultado esperado, houve um problema. Complementando, este problema foi ocorrido por uma ou mais causas.
A metodologia PDCA, então, pode ser sintetizada como uma metodologia para a definição das causas de um problema. Uma vez conhecidas a(s) causa(s), são executadas ações para a contenção, correção e prevenção de retorno da ocorrência desta(s) causa(s).
No entanto, esta investigação e análise de problemas somente terá efeito positivo se for realizada conforme os passos da metodologia. Ou seja, preferir o achômetro perante a análise dos dados, ou ainda, cumprir parcialmente os passos do método podem até ter efeitos positivos em curto prazo, mas como a mutação de um vírus, o problema voltará mais forte e resistente em uma próxima ocasião.
Por último, como em toda metodologia utilizada, deve-se haver maturidade e disciplina para alinhar o foco para a determinação e identificação de causas, e não de culpados.
A propósito, você leitor, pode estar perguntando – “O que significa a sigla PDCA?” PDCA é a abreviação para:
  • a) Plan – Planejar
  • b) Do – Fazer, Executar
  • c) Check – Checar
  • d) Action – Agir, Padronizar
que pode ser exemplificada pela figura abaixo(2):
Ciclo de Gerenciamento PDCA
ou ainda, seguindo a tabela abaixo, onde os 8 passos também são identificados na forma de um macrofluxograma (3):
Macrofluxograma
Na continuação do artigo, será abordada a etapa P, geralmente a mais trabalhosa e responsável pelo sucesso do projeto.
Bibliografia
  1. CAMPOS, Vicente Falconi. 8.10 – Como definir os seus problemas. In: Gerenciamento da rotina do trabalho do dia-a-dia. Nova Lima: INDG Tecnologia e Serviços Ltda., 2004, pg. 106;
  2. Figura 02 – http://www.indg.com.br/sobreoindg/metodopdca.aspacesso em 28.ago.2011.

25 de set de 2012

SOX como ferramenta de qualidade em TI

Por: 
Em: http://www.tiespecialistas.com.br/2011/01/sox-como-ferramenta-de-qualidade-em-ti/


Quem trabalha em multinacional conhece. A SOX, ou lei Sarbanes-Oxley tem sido desde 2002, assunto do café, quando chega a vez de reclamar de alguma coisa. Saem todos dizendo: “Nem me fale…” mas poucos realmente entendem as implicações.
A SOX foi criada na crise anterior, quando várias empresas confessaram que tinham feito uma “maquiagem” na contabilidade. Isso afetou negativamente a bolsa de Nova York, abalou a confiança das pessoas nas empresas e provocou escândalos em 2001, e no ano seguinte, os senadores americanos Paul Sarbanes e Michael Oxley foram relatores de um projeto de lei, conhecido hoje como SOX.
Na famigerada lei, consta de sua seção 404, o que a área de Tecnologia de uma empresa deveria fazer para melhorar a transparência das operações da empresa. Coisas básicas como fazer backup´s, manter acessos restritos por senha segura e comprar licenças dos softwares da empresa. O que talvez não seja tão básico é o conceito de conflito de interesses, que determina que haja segregação de tarefas nos sistemas corporativos. Assim, a pessoa que solicita a compra de um produto não pode ser a mesma que aprova a compra e nem a mesma que recebe e confere a mercadoria.
Para mostrar a todos que a área de Tecnologia fez a lição de casa e mantém todos os requisitos exigidos, são produzidos toneladas de relatórios com as evidências de que tudo foi feito de acordo. Desde controles de acesso, com data e hora de cada “login” no sistema, até evidências que os backups foram feitos e armazenados num cofre à prova de fogo.
Quando o auditor (palavrão para muita gente) chega, ele analisa as evidências e aprova ou não as atividades da área de Tecnologia, faz recomendações de melhorias e sugere novos métodos de controle e novas evidências. Ou seja, solicita mais trabalho das pessoas envolvidas.
Já que se vai ter todo este trabalho para apresentar evidências ao auditor, por que não usar esses mesmos controles para medir a qualidade do trabalho executado ??
Se é necessário fazer backup, produzir evidência que o backup foi feito e apresentar ao auditor,  o responsável pode aproveitar e revisar os procedimentos de backup para ver se aquela nova pasta de rede entrou no backup mensal. O mesmo se aplica para todas as evidências que são produzidas para auditoria. O trabalho é basicamente o mesmo. Basta que se encare a coisa não como uma “tortura”, mas como um procedimento de qualidade.
Nas fábricas existem diversos controles para assegurar qualidade dos produtos entregues. As entregas da tecnologia também podem ser medidas e ter sua qualidade assegurada. Sugiro aproveitar o mesmo trabalho feito para os auditores, melhorando a produtividade da própria área de Tecnologia.
Auditoria deve ser usada para beneficiar o negócio e ela não vai deixar de existir. Aliás, depois desta crise de 2008/2009 acho que aumentarão os controles sobre as operações das empresas, pelo menos em alguns setores. O auditor é encarado como “inimigo”, mas ele pode ser um poderoso aliado para que as falhas de operação sejam substituídas por aumento de eficiência e de produtividade.

24 de set de 2012

Comentários Críticos sobre Tecnologia da Informação

Por: Marco Mendes
Em: http://marcomendes.com/blog/2012/04/e-se-benjamim-franklin-fosse-um-arquiteto-de-software/


E se Benjamin Franklin fosse um arquiteto de software?


Benjamim Franklin foi um dos gênios da era moderna. Além de ser um cientista, ele também foi  jornalista, editor, autor, filantropo, abolicionista, funcionário público, diplomata, inventor e enxadrista. E se com todo este gênio, ele tivesse sido arquiteto de software?
Ele também teria nos ensinado diversas lições. A partir de um conjunto de pensamentos que resumem um pouco da filosofia de vida dele, coloco aqui lições dele projetadas no ramo da arquitetura de software.
01. Faça mais e fale menos.
“Well done is better than well said.”
Arquitetos devem fazer mais e falar menos. Isto é, arquitetos devem sair das famosas torres de marfim e dos documentos frios para a interação com as pessoas e a produção de protótipos, provas de conceitos e liberações frequentes de alfas e betas. Fazer em software significa: entregar valor. Entregar valor é código executável estável na mesa dos seus usuários.
02. Não adie riscos.
“Don’t Procrastinate.”
Arquitetos não devem adiar decisões. Isto é, eles devem identificar os fatores críticos que podem evitar o sucesso do projeto e atuar na mitigação destes riscos. Gerir riscos é uma habilidade fundamental a qualquer arquiteto.
03.  Esteja preparado.  
“By failing to prepare, you are preparing to fail.”
Arquitetos devem estar prontos para a ação. Conhecer métodos formais de arquitetura (tradicionais ou ágeis) e conhecer verdadeiramente os fundamentos da disciplina é fundamental para fazer um bom trabalho de arquitetura nos seus softwares. Acreditar que conhecer APIs Java EE ou .NET apenas é estar preparado é a primeira receita para fracassar como arquiteto.
04. Somente termina quando acaba.
“When you’re finished changing, you’re finished.”
Em média, um projeto tem 30% de seu escopo funcional mudado. Naturalmente, a arquitetura também irá mudar. Lutar contra o fato de existirem mudanças é perder tempo. Bons arquitetos entendem que  mudanças são naturais, replanejam o seu trabalho, atacam os novos riscos e renegociam os impactos desta mudança na arquitetura, seja no tempo, escopo ou financeiramente falando. Como já dizia Kent Beck: “Embrace Change”.
05. Seja um líder e movimente o seu time em direção às metas
“All mankind is divided into three classes: those that are immovable, those that are movable, and those that move.”
Arquitetos devem liderar times pragmaticamente em relação a objetivos bem estabelecidos. Bons arquitetos fogem da paralisia de análise e entregam resultados, custe o que custar. Arquitetos são seres pragmáticos.
06. Manter-se ocupado é fácil. Ser produtivo é diferente.
“Never confuse motion with action.”
Manter-se ocupado é fácil. Fazer da ocupação um trabalho produtivo é diferente. Bons arquitetos terminam o seu dia com pequenos produtos entregues. Eles se movimentam em relação aos seus alvos e não ficam ocupados em intermináveis reuniões infrutíferas ou documentos que não agregam valor tangível.
07. Errar é humano.
“Give Yourself Permission to Make Mistakes” 
Ficar na zona de conforto raramente levará um arquiteto a buscar soluções melhores para os seus software. Um excelente exemplo são as provas de conceito, que experimentam novas soluções em um projeto. Uma prova de conceito tem três resultados possíveis: sucesso, fracasso ou inconclusivo. Bons arquitetos não tem medo de fazer provas de conceito e experimentar novas soluções.
08. Seja persistente.
“Energy and persistence conquer all things.”
Arquitetar bons softwares não é trivial. Requer energia alta, trabalho duro e muita persistência. Significa negociar com gerentes e usuários. Significa liderar desenvolvedores. Significar enfrentar problemas complexos a cada dia. Significar aprender todo dia. Significa aprender a ouvir nãos e lidar (com frequência) com os seres mais arrogantes ou intransigentes que a genética do DNA humano permitiu conceber. Significa seguir em frente e não desistir.
09. Auto-conhecimento.
“There are three things extremely hard: steel, a diamond, and to know one’s self.”
Conhecer a si mesmo é fundamental para ser um arquiteto melhor e para compor o seu time. Arquitetos que reconhecem as suas forças e suas fraquezas tem a capacidade de saber o que podem fazer sozinhos, o que podem fazer em grupo e o que devem delegar.
10. Melhore sempre
“Be at war with your vices, at peace with your neighbors, and let every new year find you a better man.”
Arquitetos que acreditam que já sabem tudo estão se enganando. Como diria Benjamim Franklin, esteja em guerra com os seu vícios. Se você não consegue ouvir um estagiário, pratique a técnica de Escuta Ativa. Se o seu documento de arquitetura tem mais erros de regência verbal e uso de orações coordenadas e subordinadas do que o filho de 14 anos do seu vizinho, seja humilde para se matricular em um curso de português.  Se você não conhece a linguagem XPTO, faça um curso e frequente DOJOs aos sábados com seus amigos nerds. Se você não conhece sobre segurança ou acessibilidade Web e precisa disto em seu projeto, vá estudar sobre o assunto. Sempre haverá algo que você possa aprender na profissão de arquitetura de software.
Adaptado livremente a partir do blog de Thea Easterby – 14 Lessons From Benjamin Franklin About Getting What You Want In Life.

23 de set de 2012

Especialistas temem guerra cibernética no futuro

Por:MICHAEL GALLAGHER
Em: http://www1.folha.uol.com.br/bbc/1083557-especialistas-temem-guerra-cibernetica-no-futuro.shtml


Um exercício militar internacional, realizado em março em uma base militar na Estônia, tentou prever as consequências de um novo tipo de conflito, uma guerra cibernética.
A operação Locked Shields não envolveu explosões, tanques ou armas. Na operação, uma equipe de especialistas em TI atacou outras nove equipes, espalhadas em toda a Europa.
Nos terminais da equipe de ataque, localizados no Centro de Excelência da Otan em Defesa Cibernética Cooperativa, foram criados vírus ao estilo "cavalo de Tróia" e outros tipos de ataques pela internet que tentavam sequestrar e extrair dados das equipes inimigas.
O objetivo era aprender como evitar estes ataques em redes comerciais e militares e mostrou que a ameaça cibernética está sendo levada a sério pela aliança militar ocidental.
O fato de a Otan ter estabelecido seu centro de defesa na Estônia também não é por acaso. Em 2007 sites do sistema bancário, da imprensa e do governo do país foram atacados com os chamados DDoS (sigla em inglês para "distribuição de negação de serviço") durante um período de três semanas, o que agora é conhecido como 1ª Guerra da Web.
Os responsáveis seriam hackers ativistas, partidários da Rússia, insatisfeitos com a retirada de uma estátua da época da União Soviética do centro da capital do país, Tallinn.
Os ataques DDoS são diretos: redes de milhares de computadores infectados, conhecidas como botnets, acessam simultaneamente o site alvo, que é sobrecarregado pelo tráfego e fica temporariamente fora de serviço.
Os ataques DDoS são, no entanto, uma arma primitiva quando comparados com as últimas armas digitais. Atualmente, o temor é de que a 2ª Guerra da Web, se e quanto acontecer, possa gerar danos físicos, prejudicando a infraestrutura e até causando mortes.
TRENS DESCARRILADOS E BLECAUTES
Para Richard A. Clarke, assistente de combate ao terrorismo e segurança cibernética para os presidentes americanos Bill Clinton e George W. Bush, ataques mais sofisticados podem fazer coisas como descarrilar trens em todo o país, por exemplo.
"Eles podem causar blecautes, e não apenas cortando o fornecimento de energia, mas danificando de forma permanente geradores que levariam meses para serem substituídos. Eles podem fazer coisas como causar explosões em oleodutos ou gasodutos. Eles podem fazer com que aeronaves não decolem", disse.
No centro do problema estão interfaces entre os mundos físico e digital conhecidas como sistemas Scada, ou Controle de Supervisão e Aquisição de Dados, na sigla em inglês.
Estes controladores computadorizados assumiram uma série de tarefas que antes eram feitas manualmente. Eles fazem de tudo, desde abrir as válvulas de oleodutos a monitorar semáforos.
Em breve estes sistemas serão comuns em casas, controlando coisas como o aquecimento central.
O detalhe importante é que estes sistemas usam o ciberespaço para se comunicar com os controladores, receber a próxima tarefa e reportar problemas. Caso hackers consigam entrar nestas redes, em teoria, conseguiriam também o controle da rede elétrica de um país, do fornecimento de água, sistemas de distribuição para indústria ou supermercados e outros sistemas ligados à infraestrutura.
DISPOSITIVOS VULNERÁVEIS
Em 2007 o Departamento de Segurança Nacional dos Estados Unidos demonstrou a potencial vulnerabilidade dos sistemas Scada. Com um software, o departamento entrou com comandos errados e atacou um grande gerador a diesel.
Vídeos da experiência mostram o gerador chacoalhando violentamente e depois a fumaça preta toma toda a tela.
O temor é de que, um dia, um governo hostil, terroristas ou até hackers que apenas querem se divertir possam fazer o mesmo no mundo real.
"Nos últimos meses temos vistos várias coisas", disse Jenny Mena, do Departamento de Segurança Nacional. "Atualmente existem mecanismos de buscas que podem encontrar aqueles dispositivos que estão vulneráveis a um ataque pela internet. Além disso, vimos um aumento no interesse nesta área na comunidade de hackers e de hackers ativistas."
Uma razão de os sistemas Scada terem uma possibilidade maior de ataques de hackers é que, geralmente, engenheiros criam o software, ao invés de programadores especializados.
De acordo com o consultor de segurança alemão Ralph Langner, engenheiros são especialistas em suas áreas, mas não em defesa cibernética.
"Em algum momento eles aprenderam a desenvolver software, mas não se pode compará-los a desenvolvedores de software profissionais que, provavelmente, passaram uma década aprendendo", disse.
E, além disso, softwares de infraestrutura podem estar muito expostos. Uma usina de energia, por exemplo, pode ter menos antivírus do que um laptop comum.
Quando as vulnerabilidades são detectadas, pode ser impossível fazer reparos imediatos no software.
"Para isso, você precisa desligar e ligar novamente (o computador ou sistema). E uma usina de energia precisa funcionar constantemente, com apenas uma parada anual para manutenção", disse Langner. Portanto, até o desligamento anual da usina, não se pode instalar novo software.
STUXNET
Em 2010, Ralph Langner e outros dois funcionários de sua companhia começaram a investigar um vírus de computador chamado Stuxnet e o que ele descobriu foi de tirar o fôlego.
O Stuxnet parecia atacar um tipo específico de sistema Scada, fazendo um trabalho específico e, aparentemente, causava pouco dano a qualquer outro aplicativo que infectava.
Era inteligente o bastante para encontrar o caminho de computador em computador, procurando sua presa. E também conseguia explorar quatro erros de software, antes desconhecidos, no Windows, da Microsoft.
Estes erros são extremamente raros o que sugere que os criadores do Stuxnet eram muito especializados e tinham muitos recursos.
Langner precisou de seis meses para analisar apenas um quarto do vírus. Mesmo assim, os resultados que conseguiu foram espantosos.
O alvo do Stuxnet era o sistema que controlava as centrífugas de urânio na usina nuclear de Natanz, no Irã.
Atualmente se especula que o ataque foi trabalho de agentes americanos ou israelenses, ou ambos. Qualquer que seja a verdade, Langner estima que o ataque o Stuxnet atrasou em dois anos o programa nuclear iraniano e custou aos responsáveis pelo ataque cerca de US$ 10 milhões, um custo relativamente pequeno.
OTIMISTAS E PESSIMISTAS
O professor Peter Sommer, especialista internacional em crimes cibernéticos afirma que a quantidade de pesquisa e a programação sofisticada significam que armas do calibre do Stuxnet estariam fora do alcance da maioria, apenas disponíveis para governos de países avançados. E governos, segundo o especialista, costumam se comportar de forma racional, descartando ataques indiscriminados contra alvos civis.
"Você não quer causar, necessariamente, interrupção total. Pois os resultados podem ser imprevistos e incontroláveis. Ou seja, apesar de alguém poder planejar ataques que possam derrubar o sistema financeiro mundial ou a internet, por quê alguém faria isto? Você pode acabar com algo que não é tão diferente de um inverno nuclear."
No entanto, o consultor Ralph Langner afirma que, depois de infectar computadores no mundo todo, o código do Stuxnet está disponível para qualquer que consiga adaptá-lo, incluindo terroristas.
"Os vetores de ataque usados pelo Stuxnet podem ser copiados e usados novamente contra alvos completamente diferentes. Até há um ano, ninguém sabia de uma ameaça tão agressiva e sofisticada. Com o Stuxnet, isso mudou. (...). A tecnologia está lá, na internet."
Langner já fala em uma certeza: se as armas cibernéticas se espalharem, os alvos serão, na maioria, ocidentais, ao invés de alvos em países como o Irã, que tem pouca dependência da internet.
E isto significa que as velhas regras de defesa militar, que favoreciam países poderosos e tecnologicamente avançados como os Estados Unidos, já não se aplicam mais.