Reduzindo a incerteza arquitetural

Por:  Marco Mendes
Em: http://marcomendes.com/blog/2012/05/reduzindo-a-incerteza-arquitetural/

Uma das grandes dificuldades no processo de criação de arquiteturas é capturar os requisitos que realmente importam para a arquitetura (Requisitos Arquiteturais).

Uma técnica para auxílio neste processo é fornecida por uma ferramenta da psicologiachamada de Janela de Johari que também usada em alguns círculos de engenharia de requisitos.

Adapto este conceito para o contexto de arquitetura de software, exibido na figura abaixo.

A figura mostra nem todo requisito é conhecido pelo nosso time e pelos nossos usuários e este desconhecimento (nosso, dos usuários ou de ambos) é fonte de muitos problemas.

Vamos contextualizar o conceito em um exemplo didático de um sistema de Internet Banking. É natural (para qualquer arquiteto e para os usuários chave de um Banco de Crédito) que aspectos de segurança devem afetar a arquitetura executável do produto sendo criado. Portanto, aspectos de autenticação, autorização e transporte seguro estariam no quadrante Q1, que é o dos requisitos arquiteturais óbvios. Até agora não temos nenhum problema.

Vamos considerar agora alguns requisitos de qualidade interna como a manutenibilidade ou a testabilidade, que são normalmente conhecidos pelo nosso time. Normalmente aspectos de qualidade interna não são percebidos diretamente pelos usuários chave, o que os coloca no quadrante Q4. Portanto, arquitetos devem tomar cautela extrema com estes requisitos pois eles não são normalmente percebidos pelos usuários e portanto não valorizados. A consequência é que eles podem causar aos usuários a sensação de baixa produtividade na execução de código pelo time de desenvolvimento. Ainda pior, eles podem encarecer o seu projeto sem percepção de valor similar para os seus usuários.

Vamos agora considerar alguma norma obscura do Banco Central que lide com algum aspecto regulatório. Se a maturidade dos usuários envolvidos no projeto e da equipe de arquitetura for baixa, este requisito regulatório, que pode afetar a arquitetura, estaria colocado no quadrante Q3. A lição aqui é óbvia. Os usuários normalmente não conhecem todos os requisitos e portanto devemos buscar requisitos que podem afetar a arquitetura em outras fontes de informação.

Finalmente, vamos lidar os requisitos mais perigosos, que são elementos óbvios para os usuários mas não óbvios para o time. Por exemplo, o usuário pode assumir que a portabilidade entre navegadores para dispositivos móveis é dada. O time, por sua vez, pode nem ter considerado esta possibilidade. Tipicamente estes requisitos do quadrante Q2 são fontes de desgaste durante o projeto e envolvem retrabalho para o time pois afinal eles são“óbvios” para os usuários.

Em cenários ideais gostaríamos de mover todos os requisitos para o quadrante 01, mas o fato é que sempre haverá requisitos nos quadrantes Q2, Q3 e Q4 também. Naturalmente a aplicação de métodos arquiteturais de coleta de requisitos reduzirá a probabilidade que isto aconteça. Algumas dicas rápidas para isso incluem:

• Realizar reuniões e oficinas de trabalho para mover os requisitos do quadrante Q2 para o quadrante Q1. Técnicas de leitura ambiental também são úteis neste contexto.
• Buscar outras fontes de informação além do ambiente e informações fornecidos pelos próprios usuários podem mover alguns requisitos do quadrante Q3 para o quadrante Q1.
• Educar usuários sobre os requisitos que eles não conhecem pode ajudar a levar requisitos do quadrante Q4 para Q1. Em outras situações, talvez devamos remover alguns requisitos de Q4 do escopo do nosso projeto.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Gerenciando Requisitos em Projetos

Por: Marcus Gregório Serrano
Em: http://www.tiespecialistas.com.br/2012/05/gerenciando-requisitos-em-projetos/

Para poder afirmar que um projeto obteve sucesso, é necessário definir e observar vários fatores, como entrega do escopo completo, dentro do prazo e custos planejados. Uma questão que certamente aumentará as chances de sucesso dos projetos é o gerenciamento de requisitos. Essa atividade se inicia nas primeiras fases do ciclo de vida de um projeto de qualquer natureza e assume grande importância, pois será a base para todo o restante do planejamento. Note que definir os requisitos é algo a ser feito no início de um projeto, mas seu gerenciamento se dará até o término do mesmo.

Requisito pode ser definido como qualquer capacidade ou característica mensurável do resultado final do projeto, seja ele um produto ou serviço. No nosso contexto (vamos focar em projetos de tecnologia – sistemas), estamos então falando de funcionalidades, capacidades e características de sistema entregue. Ou seja, de forma bem simples, os requisitos descrevem o que o sistema fará e como fará. Importante: o “como” é sob a ótica de quem usa, não de quem constrói.

A documentação de requisitos é a base para a definição do escopo do projeto, permitindo a conversão dos desejos e expectativas dos clientes em itens mensuráveis e rastreáveis. Apoiará também o controle de mudanças no projeto, o rastreamento do atendimento aos requisitos, além de ser a base para se obter uma aprovação formal do resultado final. Enfim, é um importante instrumento de planejamento, gerenciamento e de relacionamento com o cliente.

Assim, vamos a algumas dicas úteis para se definir e gerenciar os requisitos de um projeto:

• Identifique todos os envolvidos do projeto. Stakeholders são aquelas pessoas envolvidas ou afetadas pelo projeto. Identificá-los permitirá que você possa investigar suas necessidades, expectativas e desejos. Pessoas “esquecidas” em fases iniciais poderão surgir mais à frente e seus requisitos precisarão ser incorporados. Isso significa possíveis mudanças de escopo. E isso pode significar atraso no cronograma e aumento de custos.

• Documente todos os desejos e expectativas destes stakeholders. Aqui o trabalho é de detetive. Faça reuniões, entrevistas, aplique questionários, faça sessões JAD, brainstorms, etc. Use as mais variadas técnicas para colher todas as informações sobre as características desejadas.

• Associe os requisitos aos stakeholders. Quem é o dono de cada requisito? É importante que você consiga estabelecer essa relação, pois a gestão das mudanças no projeto começa aí. Qualquer pessoa pode solicitar qualquer alteração, em qualquer ponto? Não se esqueça de obter a aprovação dos requisitos antes de começar a construir.

• Transforme desejos em requisitos. “Quero um sistema mais veloz.” “Quero um software mais amigável.” “Desejo maior usabilidade.” “Espero maior integração.” Nenhuma dessas frases (e seus resultados) é mensurável. Um sistema com um desempenho 0,00005% melhor é “mais rápido”, não é mesmo? No entanto, é isso que o cliente espera? Ou seja, traduza os desejos em itens que possam ser medidos e avaliados, como capacidade de processamento, capacidade de armazenamento ou características específicas de interface, por exemplo.

• Atenção à descrição. Essa dica anda casada com a anterior. Alguns termos que você não deverá nunca usar: “veloz, rápido, amigável, fácil, suportar, etc, ou, mas não limitado a, minimizar, maximizar, suficiente, adequado, estado da arte”. Essas expressões não dizem nada!

• Classifique os requisitos. Reúna-os em grupos como, por exemplo, obrigatórios (sem eles o sistema não entra em funcionamento), importantes (o sistema entra em funcionamento sem eles, mas com capacidade limitada) e desejáveis (são interessantes, mas, num quadro geral, não comprometem a utilização do sistema).

• Associe os requisitos aos produtos gerados pelo projeto. Aqui, já estamos falando de gerenciamento de escopo. Se um requisito não está associado a algum produto, para que está sendo atendido?

• Reporte o atendimento aos requisitos durante o projeto. Ou seja, informe para aqueles donos sobre o atendimento aos seus requisitos. Obtenha a aprovação quando cada entrega parcial (se houver) for realizada e quando a entrega final do projeto for realizada também.

Seguindo essas dicas, muitos problemas comuns em projetos de tecnologia poderão ser evitados. Torne essa atividade sistemática em seus projetos. Mas isso não significa que deva ser burocrático! E lembre-se de que a forma da sua documentação não deve ser mais importante que seu teor. Post-its e anotações em quadros brancos, uma vez validados como métodos adequados para seu contexto, estão valendo.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Série Scrum: lidando com estimativa e escopo com o cliente

Por: Camilo Lopes
Em: http://feedproxy.google.com/~r/imasters/~3/zBMbc64hPF8/story01.htm

Olá, pessoal! E hoje vamos continuar firmes e fortes na série Scrum! Neste artigo, vamos aprender como lidar com estimativa e escopo com o cliente. Praticamente todo mundo já deve ter escutado essa solicitação do cliente: “será que não dá para diminuir um pouco a estimativa?”. O problema é que nem sempre dá, mesmo que o cliente continue insistindo. Então, como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? É o que veremos a seguir.

Lidando com estimativa e escopo com o cliente situação comum e esperada  

Estimar não é uma tarefa fácil e envolve vários fatores (o quanto o time conhece as tecnologias, o produto, a experiência profissional). Os novatos da equipe normalmente terão dificuldade em estimar no começo – pelos fatores citados anteriormente -, sendo assim, o ScrumMaster deve auxiliar os novatos, dando um coach na estimativa. 

Acredito que muitos de vocês já passaram pela situação que vou relatar a seguir – e não só com clientes, mas com gerente de projetos, arquitetos etc.

O cliente diz: eu sei que você tem uma equipe técnica qualificada e com os melhores profissionais. Será que não dá para diminuir um pouco a estimativa?

Nesse caso, o cliente está usando a qualidade interna (aquilo que ele não vê) como fator para reduzirmos a estimativa – mas ele não quer diminuir o escopo. Claro que não permitiremos isso. Sacrificar a qualidade interna, na maioria das vezes (para não dizer sempre) é uma péssima idéia. Lembre-se disto: uma vez que se permite a deteriorização de uma base de código, é muito difícil recuperar a qualidade mais tarde. Não conte com refactoring, pois fazê-lo depois de tudo demanda custos e nem sempre o cliente vai querer pagar por isso. Mas como responder ao cliente a pergunta acima? 

Uma das formas de responder é tentar convencê-lo a reduzir o escopo para algo mais especifico e remover aquela parte avançada – que normalmente vai virar uma nova história e que pode entrar no próximo Sprint. Um exemplo: se o cliente quer que todas as mensagens iterativas sejam exibidas, por que não implementar as mais importantes e deixar as outras para o futuro? Aquelas que não causam impacto no entendimento ou funcionalidade da aplicação podem ficar para os próximos Sprints. 

Outra situação é que ele quer um WebService para a aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo. A missão agora é convencer o cliente a diminuir o escopo – caso ele queira ver algo de WebService pelo menos iniciado no Sprint corrente. 

Sei que não é uma tarefa fácil convencer o cliente disso, mas se ele está envolvido com o time e o Scrum, ele sabe dos problemas que pode ter se tentar ir além da capacidade de entrega da equipe (é por isso que o PO não dita o que deve entrar no Sprint). É a equipe que vai pegando os itens até chegar ao limite. Então qual a solução? Negociar e validar o escopo com o PO. Essa é a forma mais adequada para não afetar a qualidade interna do produto. Alguém, uma vez, disse que a qualidade não é negociável. 

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Big Data pode ser uma bênção para a segurança

Por: Computerworld/EUA
Em: http://cio.uol.com.br/tecnologia/2012/05/15/big-data-pode-ser-uma-bencao-para-a-seguranca/

As ferramentas de BID Data podem distinguir os atacantes dos usuários normais ao detectarem anomalias na rede.

A avalanche de dados a que estão sujeitas as empresas traz riscos de segurança para as empresas, mas a análise maciça dos mesmos também traz novas esperanças. Entre os responsáveis de segurança e alguns analistas, fala-se da possibilidade de as abordagens ao Big Data levarem a cientistas de dados focados em segurança. Serão especialistas com ferramentas e conhecimento para detectarem ataques de intrusos.

Apanhar cibercrimnosos em flagrante delito nas redes tem sido muito difícil. Há quem diga que as abordagens de Bid Data trazem novas possibilidades. Mas com que solidez? Scott Crawford, analista da consultoria Enterprise Management Associates, acha que é possível. Durante um debate entre analistas na conferência da RSA, em San Francisco, Crawford previu que, eventualmente, poderá emergir “um mercado de algoritmos de segurança” no âmbito do Big Data.

Ele refere-se a empresas como a Red Lambda e a Palantir que estão lidando com isso empregando um pesado trabalho de matemática na detecção de anomalias.

Por exemplo: a atividade de um atacante para “se esconder” é uma anomalia face ao comportamento dos usuários, em geral, na rede. Frequentemente é “atrás” destes que os cibercriminosos se escondem, segundo alguns especialistas. Hoje, os atacantes estão ultrapassando as tradicionais defesas dos sistemas de informação, salientou o analista do Gartner, Neil MacDonald no mesmo debate. Hoje, diz, já não se sabe bem o que é  atividade mal intencionadas ou não em uma rede.

De fato, as abordagens ao Big Data podem obrigar as ferramentas de informação de segurança e gestão de eventos (SIEM – Security Information and Event Management) a terem que evoluir. Até certo ponto isso já começou a acontecer, diz MacDonald, apontando para os produtos de detecção de ameaças NetWitness, da RSA e ou ArcSight SIM, da HP, entre outros. A oferta da Crowdstrike é outro exemplo.

Mas será que as ferramentas de SIEM vão evoluir para conseguirem processar dados do tipo Big Data relacionados com o negócio? Será apenas uma agradável ilusão a ideia de que os dados de negócio possam ser adicionados a dados SIEM mais tradicionais para fornecer informações relevantes sobre um atacante? “Os responsáveis não conseguem obter as respostas pretendidas a partir das ferramentas de SIEM”, diz o analista da Forrester, John Kindervag. O mesmo defende a necessidade de novos desenvolvimentos, englobando as ferramentas de SIEM.

De todos os analistas no painel da conferência da RSA, Jon Oltsik, da Enterprise Strategy Group, foi o mais céptico. Diz que os CISO ainda não aderiram à ideia das abordagens Big Data serem de alguma forma uma bênção para a segurança. “Quando falo com CISOs e perguntar sobre Big Data, eles até riem”, comentou.

Há experiências encorajadoras

Mas existem projetos promissores. A Zions Ban Corporation criou um repositório enorme para analisar proativamente uma combinação de dados de segurança em tempo real e dados de negócios. Visa identificar ataques de phishing, evitar fraudes e repelir invasões de hackers. Anunciado em outubro passado, é baseado no Data Warehouse Zettaset, que faz uso da Hadoop para aplicações intensivas de dados distribuídos. Preston Wood, diretor de segurança da Zions, descreve a plataforma como uma forma de aumentar as capacidades das ferramentas de SIEM. Os fabricantes de tecnologia de SIEM, incluindo a NetIQ, dizem ter a certeza de que a onda em torno da abordagem Big Data e da segurança está apenas começando.

“O SIEM tem de evoluir por esse caminho,” defende Matt Ulmer, diretor de gestão de produto na NetIQ. O responsável diz que a indústria enveredou por um caminho de reinvenção do SIEM, incorporando tecnolgia de BI.

As ferramentas de Big Data podem detectar o que foge à norma, explica Ulmer. “Mas como se define a norma?” questiona Ulmer. E ele diz que as ações de ataque podem surgir apenas por alguns segundos todos os dias. Portanto, o objetivo principal é distinguir os atacantes dos usuários normais. E as ferramentas de Big Data podem ser muito úteis nisso.

Obstáculos práticos

No entanto, há alguns obstáculos de ordem prática para esta visão. A Cloud Computing está tornando mais difícil a implementação de estratégias tradicionais de SIEM. Uma estratégia de Big Data para segurança está na esfera da vanguarda. E os responsáveis de segurança já têm a agenda bem preenchida com a tendência “Bring Your Own Device” (BYOD) como tema de gestão.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Hierarquia de Maslow para desenvolvimento: do controle ao orgulho em 5 etapas

Por: Mário Henrique Trentim
Em: http://www.infoq.com/br/news/2012/04/hierarquia-maslow-no-software

Scott Hanselman, em seu blog Computer Zen, propõe uma hierarquia das necessidades de Maslow adaptada ao desenvolvimento de software, definindo os níveis de necessidades que devem ser satisfeitos para atingir a excelência nesta área.

Abraham Maslow é famoso pela criação da hierarquia das necessidades humanas, dividida em cinco níveis, sendo os inferiores as necessidades básicas, enquanto que os superiores representam aspectos sócio-psicológicos de satisfação e realização:

Segundo Maslow, a hierarquia das necessidades estabelece que as pessoas somente se preocupam com um determinado nível, quando o nível anterior está satisfeito; isto é, irão se preocupar, por exemplo, com necessidades de relacionamento somente quando as necessidades de segurança e as fisiológicas estiverem satisfeitas.

De forma análoga, os níveis propostos por Hanselman estão dispostos em forma de pirâmide, reforçando a ideia de não ser possível atender aos níveis superiores enquanto as necessidades da base ainda não tiverem sido totalmente satisfeitas. Veja a pirâmide proposta por Hanselman, também com cinco níveis:

 

Hanselman descreve, então, os cinco níveis de necessidades para o desenvolvimento de software, os quais apresentamos abaixo em tradução livre:

Revisable – Revisável (Controle de mudanças no desenvolvimento)

O nível mais básico: exige que o código possa ser desenvolvido e revisado de maneira controlável e consistente. Para isso é necessário ter um método e um fluxo de trabalho claros para o desenvolvimento e para os testes.

Buildable & Deployable – Implementável (Controle de mudanças na produção)

Quando o nível anterior de controle do código for dominado, pode-se pensar no nível Buildabe & Deployable. Neste nível, a preocupação repousa sobre a implementação do software, estabelecendo procedimentos específicos de contingências e mudanças.

Maintainable - Fácil manutenção (Controle Pós-implementação)

Considerando que os níveis anteriores estejam garantidos, a atenção se dirige agora para a manutenção do software implementado. Neste nível deve haver padronização para correção de bugs e para a verificação do software.

Refactorable - Refatoração facilitada (Oportunidades de Melhoria)

Os três níveis anteriores são básicos para o bom desenvolvimento de software, e uma vez satisfeitos pode-se dar um passo na direção de códigos mais fáceis de reutilizar, modificar e melhorar. A refatoração, com se sabe, mantém a capacidade de melhorar o software existente, além de deixá-lo mais claro e às vezes mais eficiente.

Bragging Rights - Direito ao orgulho (Excelência no desenvolvimento)

O nível mais alto da pirâmide de Maslow é a auto-realização. De maneira análoga, no desenvolvimento de software, um desenvolvedor busca criar códigos de qualidade com excelência em arquitetura, funcionalidades, e facilidade de manutenção e atualização – em busca de respeito, autoridade técnica e reconhecimento de suas habilidades.

---

Hanselman conclui ressaltando a importância de uma liderança forte e consciente. Criar arte é a parte divertida, diz, mas isso sozinho não assegura o progresso do projeto. O líder técnico precisa reconhecer o momento certo para ser um ‘artista’ e o momento certo para investir em processos fundamentais, e com isso viabilizar a escalada para níveis mais altos da pirâmide de necessidades.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Somente a certificação PMP garante a qualidade do Gerente de Projetos?

Por: Guilherme Rigolon
Em: http://www.tiespecialistas.com.br/2012/04/somente-a-certificacao-pmp-garante-a-qualidade-do-gerente-de-projetos/

Na atualidade a certificação PMP (Project Management Professional), emitida pelo PMI (Project Management Institute) é considerada a melhor qualificação em gerenciamento de projetos (existem outras certificações no PMI) no Brasil. Uma das diferenças desta certificação com as demais (ex.: SAP) é que o profissional certificado pelo PMI pode “perder” a certificação, caso não mantenha-se atualizado por meio de cursos que valem PDUs (Professional Development Units). Dessa forma, um profissional certificado pelo PMI deve acumular, no mínimo, 60 PDU’s a cada três anos, caso contrário, este profissional terá o seu certificado invalidado.

As empresas “começam” a exigir a certificação PMP ativa (semelhante ao que ocorre com a língua inglesa, com a fluência) como base de sustentação para o sucesso de um projeto.

Propagam-se pelo país, inúmeros cursos de capacitação para a obtenção da certificação PMP, porém o enfoque maior é com a memorização de termos e nomenclaturas das ferramentas e técnicas do que a apropriação dos seus usos e funções.

Esta situação, em geral, cria um contingente de profissionais “certificados”, mas sem as habilidades e competências necessárias para liderar uma equipe e fazer a gestão eficiente das atividades de um projeto. Este déficit de conhecimento torna-se notório sobretudo diante da complexidade de grandes projetos.

Passamos por ondas no gerenciamento de projetos no Brasil, a primeira onda diz respeito à certificação quantitativa de profissionais como PMPs. A segunda onda refere-se à qualificação destes profissionais certificados. Este processo é lento, pois para se transformar um profissional “apenas” certificado em Líder de projetos é necessário experiência construída com apoio de parceiros mais experientes.

Quando “ouvimos” na mídia que o Brasil não está preparado para as demandas atuais e futuras em relação à qualificação dos profissionais, em inúmeras áreas de trabalho, devemos incluir também os profissionais certificados como PMPs.

Sem habilidades e competências necessárias para fazer frente aos desafios de um projeto, estes profissionais, embora certificados seguirão despreparados para cumprir o papel que lhe cabe nos ambientes corporativos.

Este despreparo é um dos aspectos que afetam negativamente uma enorme quantidade de projetos que: não atendem o que o cliente “comprou”, o orçamento previsto não é respeitado e normalmente “estoura”, a rotatividade no time aumenta, o escopo não é administrado e tratado como vital, o planejamento é simplificado em atividades na ferramenta project e não é tratado de forma estratégica pelo líder etc.

As considerações acima ressaltam a importância de se conhecer, entender e aplicar as melhores práticas do PMBOK (Project. Management Body of Knowledge) no projetos. A maturidade aliada a experiência dos profissionais no conhecimento e aplicação das melhores práticas contribuem decisivamente para a diminuição do índice de insucesso dos projetos. Nesse sentido, temos que qualificar melhor os cursos preparatórios, associando teoria e prática.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Como evitar gastos desnecessários na estratégia de Big Data

Por: THOR OLAVSRUD
Em: http://computerworld.uol.com.br/tecnologia/2012/05/11/como-evitar-gastos-desnecessarios-na-estrategia-de-big-data/

É preciso prestar atenção nas armadilhas que podem ser criadas em projetos que envolvem grandes quantidades de dados.

Big Data está se mostrando cada vez mais uma ferramenta poderosa que promete transformar os volumes massivos de dados de uma organização com inteligência, fornecendo uma visão profunda dos negócios. No entanto, tantos atrativos podem levar a empresa a uma armadinha caso não seja criada uma estratégia adequada de adoção do modelo.

“Big Data pode resultar em gastos desnecessários. É preciso ficar atento”, diz Jeff Muscarella, consultor de gestão de gastos em TI da NPI Financial. Ele adverte que projetos de nessa área podem facilmente demandar investimentos de sete dígitos somando hardware, software e serviços. Além disso, os casos de sucesso apresentados pelos fornecedores perdem o brilho quando se tem contato com esses projetos. “Muitas vezes, eles não são tão perfeitos quanto parecem”, afirma.

Isso não quer dizer que Big Data é um erro, alerta Muscarella. O significado disso é que as organizações que procuram basear suas decisões em dados e precisam começar a reunir informações sobre como um projeto desse pode impulsionar os negócios.

“Big Data não é apenas uma nova tecnologia”, observa. “É uma nova tecnologia que busca solução para problemas que as empresas nunca resolveram. Isso é algo importante que os CIOs devem ter em mente”, completa. 

De acordo com ele, organizações que querem adotar uma estratégia de análise de grande quantidade de dados têm de realizar uma série de questionamentos: “Será que a tecnologia vai realmente gerar receita? Como e por quanto tempo?”. É preciso ter a certeza de que existe um foco nítido sobre a missão e o retorno do investimento do projeto.

Vá com calma

Ao pensar em um projeto de Big Data, não mergulhe de cabeça, adverte Muscarella. Dê o primeiro passo com ferramentas de código aberto como o Apache Hadoop e construa um caso de sucesso.

“Comece em pequena escala para provar o valor do investimento. Pergunte-se ‘se pudéssemos extrair esses dados de sensores ou cliques de web, como os resultados podem melhorar os negócios?’.”  

“Não fique preso em construir a infraestrutura ainda”, acrescenta. “Faça uma prova de conceito primeiro e depois parta para a construção da solução. Suponha que, no entanto, você resolva o problema, provavelmente vai jogá-lo fora e começar de novo. Tudo bem, porque pelo menos não jogou dinheiro fora”, brinca.

Depois de comprovada a necessidade dos negócios, é hora de olhar para a infraestrutura necessária para gerenciar Big Data. Grandes projetos de dados de escala de petabytes e exabytes, têm de ter uma tecnologia de armazenamento adequada. Muscarella diz que apesar dos argumentos em favor dos fornecedores de centralizar a solução em um único provedor, é melhor aproveitar a virtualização.“Não centralize em um único fornecedor”, aconselha. “Uma vez preso, sempre preso.”

Ele aponta que algumas empresas para as quais trabalhou decidiram centralizar a infraestrutura tecnológica em um único fornecedor. O acordo inicial parecia ideal, diz ele, mas quando o ciclo de atualização surgiu anos mais tarde, eles não tiveram escolha e as ofertas recebidas eram muito diferentes do que teriam escolhido.

Por isso, prossegue, use uma estratégia de múltiplos fornecedores. “Sobre o ciclo de atualização das plataformas, certifique-se de verificar todos os acordos para garantir que há a possibilidade de mudar”, aponta.

Além disso, tenha cuidado com o suporte de armazenamento. Verifique se o preço é justo e seja rigoroso sobre a identificação de hardware desativada no ambiente de armazenamento. Negocie também o custo de suporte do hardware nos acordos de nível de serviço.

Data mining + BI

Soluções e serviços de data mining e business intelligence (BI) são vendidos na maioria das vezes no contexto de um caso de negócio, o que significa que os vendedores certamente vão oferecer um business case gratuito, observa Muscarella. “Eles vão querer levar consultores para a instalação da empresa por vários dias, falar com o pessoal de negócios e ajudar a entender o que é possível conquistar com a estratégia de Big Data”, assinala.

“Eles vão fazer você se sentir muito bem sobre os gastos”, diz Muscarella. “Mas esses casos de negócios são muitas vezes cheio de buracos, ou há muitas hipóteses otimistas.”

É melhor, diz ele, pagá-los para efetuar a análise ou contratar um terceiro para realizar o estudo. Essa ação ajuda a conseguir uma avaliação mais completa e talvez até mais honesta.

Cuidado com o pacote Big Data

Se a companhia está comprando hardware, software ou serviços, evite acordos com diversas ofertas inclusas, adverte Muscarella. “Cuidado com os pacotes”, diz ele, observando que os fornecedores muitas vezes oferecem um acordo no qual os clientes podem utilizar qualquer uma das ferramentas da empresa de forma gratuita.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

O que é Análise de Negócios?

Por: Alaor Simão
Em: http://feedproxy.google.com/~r/GestoDeProcessosEProjetosgeis/~3/zzoSRdE_syQ/o-que-e-analise-de-negocios.html

Vídeo explica de forma simples e lúdica o que é a análise de negócios. 

http://reader.googleusercontent.com/reader/embediframe?src=http://www.youtube.com/v/qVPgOBbBE_k%26fs%3D1%26source%3Duds&width=320&height=266Popout

Publicado por Fabrício Laguna, da Gigante consultoria.  

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Um grande caso de sucesso em gestao de processos

Por: Lecom
Em: http://www.bloglecom.com.br/2012/04/18/ferretti-group-e-lecom-%E2%80%93-um-grande-caso-de-sucesso-em-gestao-de-processos/

Na semana passada realizamos aqui no Blog Lecom e também para toda a nossa base de contatos o lançamento de nossa mais recente Newsletter externa, a Newscom 21!

Além de informações sobre os relacionamentos, lançamentos, produtos e projetos da Lecom, a Newscom 21 teve foco específico no case de sucesso do Ferrettigroup Brasil, corporação que está em pleno desenvolvimento contando com sua Gestão de Processos instrumentalizada pelo ATOS Lecom.

Importante salientar que o Ferrettigroup Brasil é cliente da Lecom há aproximadamente um ano, tendo alcançado expressivos resultados em produtividade em apenas alguns meses. Contrapor as expectativas com os resultados hoje constatados só traz uma palavra à mente, superação! Clique no link abaixo e leia a primeira matéria lançada no Blog sobre esse cliente e suas expectativas.

Ferrettigroup Brasil investe em tecnologia de processos para reforçar liderança de mercado

O Ferrettigroup nasceu em 1968 a partir da marca Ferretti Yachts, criada pelos irmãos italianos Norberto e Alessandro Ferretti, que uniram qualidade, tecnologia, alto desempenho e design ao segmento de iates de alto luxo. Até o ano de 2010 o Ferrettigroup Brasil era chamado Spirit Ferretti, atuando como licenciada, representante do Grupo no Brasil. Ao longo do ano, a empresa investiu pesado na ampliação do seu processo produtivo e passou a se chamar Ferrettigroup Brasil, e expandiu a gama de produtos ofertados no mercado brasileiro. O novo estaleiro do grupo, em território nacional, teve sua abertura oficial em junho de 2011.

A evolução da empresa demandou maior controle dos processos críticos e também o uso de uma plataforma tecnológica que viabilizasse as condições precisas para a melhor gestão e constante melhoria dos fluxos de trabalho. A necessidade era de uma solução de fácil compreensão, eficiente, e que permitisse autonomia em sua utilização. As demandas prioritárias eram de processos que envolviam clientes e que pela burocracia inerente a grandes empresas acabava tomando muitos dias para serem concluídos.

A meta do projeto, no primeiro momento, foi implantar três fluxos que partem de uma solicitação dos clientes: FAP (Formulário de Alteração de Pedidos), PAD (Pedido de Alteração Distinta) e Itens Especiais. Entenda melhor:

Utilizando o ATOS Lecom foi possível mapear e desenhar todo o caminho dos fluxos de trabalho, o quetornou os processos mais ágeis, além de ganhar total controle sobre as aprovações e o trânsito de informações. O ATOS Lecom, ao unir tecnologia a uma interface fácil e intuitiva, permitiu trabalhar com mais ênfase a cultura de processos na organização – e é justamente a união entre cultura e tecnologia que possibilitou grandes resultados ao Grupo.

“A solução nos permitiu independência para melhorias internas. Antes não conseguíamos atender com rapidez uma solicitação feita no atendimento ao cliente, por exemplo. Levávamos em média 25 dias para finalizar um processo, hoje, o processo é concluído em 1/3 deste tempo.” Ricardo Paulino, Gerente de Processos e Estratégia.

Hoje, os processos desenhados no ATOS Lecom do Ferrettigroup passam por cerca de 12 áreas da empresa, além de envolver, em alguns fluxos, os próprios clientes. A solução foi aprovada pelos colaboradores e clientes, que reconheceram o valor da ferramenta ao perceberem a otimização proporcionada na rotina corporativa.

Os aspectos-chave para o sucesso do sistema ATOS Lecom no Ferrettigroup podem ser listados em:sinergia, entre cliente e equipe Lecom; foco, em mapear os processos e detectar as demandas;assertividade, com o desenho dos fluxos e os resultados muito bem delineados; e, por fim, a cultura, trabalhada de forma que todas as áreas que utilizam a solução a enxerguem como suporte central da gestão dos processos.

Se você quer ter mais detalhes a respeito desse projeto e dos resultados alcançados pelo Ferrettigroup, acesse o PDF em nosso site, clicando aqui ou entre em contato conosco!

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

A perda de informações sensíveis e suas consequências

Por: Fernando Romero
Em: http://www.tiespecialistas.com.br/2012/05/a-perda-de-informacoes-sensiveis-e-suas-consequencias/

Você sabe onde estão suas informações sensíveis? Se sim, você dá a devida proteção a elas? O mais recente caso de tentativa de extorsão e vazamento de fotos íntimas da atriz Carolina Dieckmann, além de outros fatos corriqueiros que tenho observado nas empresas, me fez constatar que as pessoas ainda não dão a devida importância à guarda de informações. Um caso como o mencionado é exponencialmente maior quando falamos de um ambiente corporativo, no qual existem vários meios de manipular dados e mantê-los em dispositivos suscetíveis a perdas, roubos e ataques.

Imaginem o quanto valeriam os projetos de um novo tipo de motor, ou o planejamento publicitário anual de uma empresa para um concorrente? Essas informações, que devem ser protegidas e ter o seu uso monitorado, podem ser duplicadas e copiadas. Dados como esses podem cair nas mãos de um competidor, ou até mesmo um fraudador. A empresa pode ainda ser responsabilizada pelo vazamento de informações caso sejam dados financeiros de seus clientes, por exemplo.

Antes de começar a proteger as informações, necessitamos saber onde elas estão. Nessa fase entra o trabalho de classificação e descoberta, que começa pela identificação do que é realmente sensível. Após isso, investiga-se por onde são manipuladas, trafegam e são guardadas. É nessa fase que saberemos a visão real de exposição a qual uma empresa está sujeita e para onde devemos apontar os esforços.

Soluções como DLP (prevenção contra vazamento de informações) podem ajudar empresas, em primeiro lugar, a encontrar as informações sensíveis e relevantes ao negócio e posteriormente protegê-las. Desde nas estações de trabalho, em tablets, no tráfego que passa pela rede e até nos locais de armazenamento, como servidores de arquivos. Uma segurança adicional pode ser obtida com o uso de criptografia de dispositivos móveis como notebooks, tablets e smartphones. E finalmente, para validar esses controles, é interessante a execução de um teste de invasões, externo e interno, uma vez que grande parte das ameaças ocorre dentro do próprio ambiente de trabalho. Com esse tipo de teste é possível avaliar em quais pontos serão necessários controles maiores.

Normas e regulamentações como Sarbanes Oxley, PCI, HIPAA, Basiléia e GLBA exigem que informações sensíveis sejam protegidas. Claro que muitas dessas regras não são obrigatórias no Brasil ou conforme a atividade da empresa, porém seus controles podem ser adaptados à realidade da corporação. Na maior parte das vezes a tecnologia por si só não resolve o problema, devem ser feitas algumas mudanças nos processos de atividades. A impressão é um exemplo, frequentemente são encontrados documentos abandonados nas impressoras e muitos deles são restritos a um setor, ou nem deveriam ser impressos.

Para finalizar, segue uma dica para pessoas que continuam mantendo fotos e arquivos importantes em dispositivos móveis, ou armazenando-os no seu computador pessoal: assim que possível, mova esses arquivos para um local mais seguro como um volume criptografado. Para usuários domésticos recomendo o software open-source True Crypt (www.truecrypt.org), que pode realizar muito bem essa tarefa. Já para os usuários corporativos, por conta da complexidade no gerenciamento e dos recursos envolvidos, serão necessárias soluções de mercado que demandem investimentos.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

O objetivo essencial de um Escritório de Gerenciamento de Projetos (PMO)

Por: Willy Vollger
Em:http://www.tiespecialistas.com.br/2012/05/o-objetivo-essencial-de-um-escritorio-de-gerenciamento-de-projetos-pmo/

Introdução

A necessidade de alinhar objetivos e estratégias da organização à execução de portfólios, programas e projetos não é uma tarefa trivial. Comunicar esta estratégia de forma eficiente e torná-la eficaz é um desafio constante para as organizações.

Alinhada a esta demanda organizacional, a implantação de Escritórios de Gerenciamento de Projetos (PMO – Project Management Office) cria mecanismos que irão permitir acompanhar e monitorar se os projetos executados estão alinhados às estratégias das organizações, por exemplo.

Mas seria só este o papel do PMO na organização?

 Definindo um Escritório de Gerenciamento de Projetos (PMO)

Existem várias definições para o Escritório de Gerenciamento de Projetos, que de certa forma se convergem /complementam, tais como:

• Rad & Raghavan (2000) uma entidade organizacional que provê o foco institucional nos procedimentos de gerenciamento de projetos;
• Crawford (2000), como um provedor de serviços e processos completos para gerenciamento de projetos e que o mesmo também atua como centro de excelência em gestão de projetos dentro da organização;
• Cleland & Ireland (2000) como grupo de suporte que provê serviços para os gerentes de projetos, gestores seniores e gerentes funcionais trabalhando em projetos;
• Kate (2000) define o Escritório de Gerenciamento de Projetos como uma unidade do negócio focada na eficiência do gerenciamento de projetos e programas dentro da organização;
• Kerzner  (1992) diz que o time do projeto é uma combinação do Escritório de Gerenciamento de Projetos e os empregados funcionais.

Responsabilidades do PMO

A seguir relaciono algumas responsabilidades que normalmente são atribuídas ao Escritório de Gerenciamento de Projetos:

• Definir, uniformizar e defender padrões, processos, métricas e ferramentas de gerenciamento de projetos;
• Oferecer serviços de gerenciamento, treinamento e documentação de projetos;
• Garantir o alinhamento das iniciativas à estratégia organizacional;
• Apoiar a alta gestão com relatórios e informações executivas;
• Monitorar e acompanhar a resolução/solução de Issues (Problemas);
• Prover ações de melhoria contínua nas práticas de gestão de projetos.
• Fornecer apoio ao planejamento e controle de projetos e, em alguns casos, assumir ou recuperar o gerenciamento de determinados projetos considerados estratégicos.

Alguns fatores motivam a implantação do Escritório de Gerenciamento de Projetos, como por exemplo, cita Bridges & Crawford (2001):

• Gerentes de Projetos não conscientes das diretrizes estratégicas da organização ou que não conseguem guiar seus projetos de acordo com estas diretrizes;
• Os projetos não são ativamente monitorados e gerenciados durante sua execução, fazendo com que as decisões de interromper o projeto ou então de recuperação de projetos mal conduzidos sejam tomadas tarde demais, quando boa parte dos recursos e imagem da organização foi consumida;
• Falha no treinamento adequado dos gestores de projetos;
• Falta de comprometimento e entendimento da importância dos projetos por parte da alta administração;
• Ausência de procedimentos, processos e ferramentas definidos e divulgados.

Estes fatores relacionados não parecem velhos conhecidos nossos?

Classificação dos Escritórios de Gerenciamentos de Projetos

Os tipos possíveis de Escritório de Gerenciamento de Projetos são variados, de empresa para empresa, e também é possível que se tenha mais de um Escritório de Gerenciamento de Projetos numa mesma organização.

Dinsmore & Cabanis-Brewin (2009), os tipos ou níveis de escritórios de projetos são três: escritório de projetos corporativo, escritório de projetos divisional, escritório de controle de projetos.

Segundo Crawford (2001):

• Um escritório de projetos divisional pode prover apoio a projetos isolados ou integrar múltiplos projetos de tamanhos variados dentro da divisão.
• O escritório de projetos corporativo é o que poderá trazer maiores benefícios às organizações, uma vez que além de ser um centro de excelência (disseminando o conhecimento de gerenciamento de projetos em toda a organização e, assessorando no uso deste conhecimento), serve para mitigar os conflitos gerados pela competição de recursos e para identificar áreas nas quais pode haver recursos comuns que podem ser usados por toda a corporação.
• O escritório de controle de projetos é o tipo mais simples de escritório de projetos e serve apenas para controlar projetos, direcionando seu foco para cronogramas e relatórios. Trata-se de um escritório de projetos dedicado a um único projeto (projeto isolado).

Por outro lado, uma visão mais detalhada sobre a estruturação do Escritório de Gerenciamento de Projetos é a de Hill (2004), que define o Escritório de Gerenciamento de Projetos numa organização como uma estrutura com competências evolutivas e funcionalidades a serem assumidas ao longo do tempo, em cinco estágios:

O “PMO Competency Continuum”, adaptado de Hill (2004).

Nesse modelo, cada nível subentende um escopo particular de capacidade funcional; os estágios superiores implicam em haver-se previamente conquistados as competências dos estágios anteriores; porém, mesmo devendo esses estágios ser obrigatoriamente escalados um por um, a organização pode executar atividades em mais de um nível, num dado instante. Assim, podemos ter vários Escritórios de Gerenciamento de Projetos e um Centro de Excelência corporativo simultaneamente.

Conclusão

 Nos últimos anos vem surgindo modelos com o objetivo de atestar a maturidade dos Escritórios de Gerenciamento de Projetos (PMOs). São exemplos destas iniciativas:

• Organizational Project Management Maturity Model,(OPM3) do PMI;
• PMO Maturity Cube, Américo Pinto, Marcelo Foresti Cota e Dra. Ginger Levin;
• Gartner PPM Maturity Model, Gartner, Inc.

Como as estratégias organizacionais podem mudar com o tempo, a percepção de que o PMO agrega valor para a organização é algo latente e crítico. Caso ocorram estas oscilações, é possível que organização não seja capaz de perceber a capacidade de gerar valor e benefícios tangíveis. Neste cenário o PMO perderá o seu apoio, pois não haverá como justificar a manutenção do investimento realizado, sendo muitas vezes visto como um overhead da operação.

Uma alternativa para mitigar este risco é enxergar o PMO como um prestador/provedor de serviços: produzir, entregar serviços que claramente façam sentido para a organização, que sejam adaptáveis, flexíveis. Que estes serviços produzam valores reais, benefícios e apoiem com eficiência o alinhamento das estratégias da organização à execução de projetos.

Uma afirmação relevante é a que propõe Pinto, & Cota & Levin (2010): o grau de maturidade de um PMO é resultado do quanto ele é capaz de gerar valor para seus clientes e para a organização como um todo.

Não seria este o objetivo essencial de um Escritório de Gerenciamento de Projetos (PMO)?

Fontes

• BRIDGES, Dianne N., CRAWFORD, J. Kent. A Project Office – Where and What Type. In: Proceedings of the Project Management Institute Annual Seminars & Symposium, Nashville, November de 2001.
• CLELAND, David L. & IRELAND, LEWIS R. Project Manager´s Portabler Handbook, New York: McGraw-Hill, 2000.
• CRAWFORD, J. Kent. Making a Place for Success, Project Management Best Practices Report, 2000.
• CRAWFORD, J. Kent. The Strategic Project Office: a guide to improving organizational performance. New York: Marcel Dekker, 2001.
• DINSMORE, Paul C. Winning in business with enterprise project management. New York: Amacom, 1999.
• DINSMORE, Paul C., CABANIS-BREWIN, Jeannette, Manual de Gerenciamento de Projetos. Brasport, Rio de Janeiro, 2009.
• HILL, G. M. Evolving the Project Management Office: A Competency Continuum. Information Systems Management, 2004.
• IT Score Overview for Program and Portfolio Management – http://www.gartner.com/id=1422722
• KATE. J, Program Office: An Enterprise View, 2000.
• KERZNER, Harold. Project Management: A systems approach to planning, scheduling and controlling. 4. ed., New York: Van Hostrand Reinhhold, 1992.
• PATAH, Leandro A. Alinhamento Estratégico de Estrutura Organizacional de Projetos: Uma análise de múltiplos casos. Dissertação de mestrado. Escola Politécnica da Universidade de São Paulo, São Paulo, 2004.
• PINTO, A., COTA, M.F. E LEVIN, G.   The PMO Maturity Cube, a Project Management Office Maturity Model. In: PMI Research and Education Congress 2010, Washington D.C., USA 2010.
• PROJECT MANAGEMENT INSTITUTE – Organizational Project Management Maturity Model, (OPM3) Knowledge Foundation: Knowledge Foundation.
• RAD, Parviz F. e RAGHAVAN, Asok Establishing an Organizational Project Office. In: AACE International Transactions, 2000.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

O valor do Big Data para as empresas

Por: Cezar Taurion
Em: http://feedproxy.google.com/~r/imasters/~3/P_xbha0B0I0/story01.htm

O Big Data ainda está no canto da tela do radar dos executivos, mas tem o potencial de ser um disruptor de competitividade entre empresas. Afinal, se uma empresa puder obter insights aprofundados sobre seus clientes, o que eles desejam e opinam sobre a empresa e seus produtos, ela tem condições de mudar o jogo. O Big Data e Analytics permitem encontrar padrões e sentido em uma imensa e variada massa amorfa de dados gerados por sistemas transacionais, mídias sociais, sensores, etc.

Portanto, o Big Data cria valor para as empresas descobrindo padrões e relacionamentos entre dados que antes estavam perdidos não apenas em data warehouses internos, mas na própria web (em tuites, comentários no Facebook e mesmo em videos no YouTube). Isto foi reconhecido pela McKinsey em seu relatório “Big Data: The Next Frontier for Innovation, Competition and Productivity”. Recomendo também clicar aqui para maiores informações e exemplos práticos de uso.

Mas colocar Big Data em prática não é uma simples questão de instalar alguma nova tecnologia. As tecnologias impulsionadoras são fundamentais, mas é necessário também que a empresa adapte seus processos de negócio, de modo a explorar os insights gerados. Um exemplo de uso do Big Data de forma inovadora é a Pistoia Alliance, associação de empresas da industria de “life sciences” que permite, em modo de coopetição, compartilhar dados para acelerar os seus processos de P&D. A ideia básica é criar um pool de Data Warehouses e através de processos inovadores e novas tecnologias, compartilhar informações entre diversas empresas. Utilizando-se de modelos computacionais, como o cloud computing (aqui podemos falar em nuvens híbridas), ganha-se em economia de escala, permitindo que grupos de empresas possam implementar estratégias de Big Data que sozinhas não teriam condições financeiras e tecnológicas. Para isso, é necessário criar padrões de acesso, regras e politicas bem definidas de privacidade e segurança de acesso. 

 Outro pré-requisito essencial é dispor de expertise com novas funções, como data scientist e CDO (Chief Data Officer). O data scientist é um profssional multidisciplinar, com skills em ciência da computação, matemática, estatística e, claro, conhecimentos do negócio onde está inserido. Quem exatamente é esta figura ainda não está claro, mas uma boa discussão pode ser vista aqui. Também vale a pena dar uma olhada nesta comunidade. Quanto ao CDO, veja uma descrição do cargo e função na Wikipedia e o que Mário Faria, primeiro CDO do Brasil, da Boa Vista Serviços, me disse em um artigo anterior: “Minha função é bastante nova, apesar das empresas se preocuparem com o assunto “dados” há décadas. O papel de um CDO é ser o responsável por gerir os dados da empresa, através de uma estratégia baseada em valor para o negócio. Mesmo nos Estados Unidos, esta posição é nova, e o primeiro CDO foi o Professor Richard Wang do MIT, que em 2010, se licenciou para ser o CDO do Exército Americano.

O meu papel é conseguir olhar para as necessidades que a empresa tem em desenvolver novos produtos, serviços e ofertas, e quais são os insumos (no caso os dados) que precisam estar disponíveis para que isto ocorra. Se eu trabalhasse em uma indústria, meu cargo seria o de Diretor de Materiais”.

Na área de formação de profissionais para Big Data, a IBM implementou uma nova iniciativa nos EUA, denominada Big Data University, que visa a formação de estudantes de graduação e pós-graduação na área, expondo-os ao Hadoop e aos conceitos de Big Data. Inaugurada em outubro passado, a Big Data University já atraiu mais de 18 mil estudantes para seus cursos online gratuitos, em inglês. Dêem uma olhada em Big Data University.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

13 ótimos livros sobre open innovation e crowdsourcing

Por: Crowdoque
Em: http://crowdoque.typepad.com/blog/2012/03/13-%C3%B3timos-livros-sobre-open-innovation-e-crowdsourcing.html

 

Apesar de ser fã de blogs, revistas e artigos, acredito que os livros ainda proporcionam uma síntese interessante das tendências globais e perspectivas. Em se tratando de inovação aberta e crowdsourcing, talvez os livros ofereçam um conteúdo muito mais completo, já que são poucos os blogs que tratam exclusivamente disso no mundo. Uma meia dúzia talvez.

Dessa forma, e para incentivar que vocês se aprofundem um pouco mais no assunto, listo os 13 livros que acho mais interessantes sobre inovação aberta e crowdsourcing:

1. Outside Innovation: How Your Customer Will Co-Design Your Company’s Future – Patricia Seybold argumenta que as empresas devem buscar a inovação envolvendo ativamente e trazendo seus clientes para o processo de desenvolvimento de produto.
2. Motivation in Open Innovation – Robert Motzek investiga os perfis motivacionais dos usuários inovadores a partir do ponto de vista do fabricante, utilizando o usuário como parte de um “kit de ferramentas”. A análise é baseada em dois estudos de caso, Spreadshirt e Threadless.
3. Open Innovation: The New Imperative for Creating and Profiting from Technology – O mestre Henry Chesbrough sugere que as empresas se tornem mais permeáveis ao fluxo de conhecimento através de estratégias tais como a contratação  de professores e alunos de pós-graduação como consultores, patrocinando a pesquisa em universidades e investindo em parceria em startups de alta tecnologia.
4. Open Innovation: Researching a New Paradigm – Oferecendo explicações teóricas e práticas para o uso (e limites) da inovação aberta, o livro examina a aplicabilidade do conceito, as implicações para os limites das empresas, o potencial da inovação aberta para ser bem sucedida, e as implicações para as políticas de propriedade intelectual e práticas.
5. Open Business Models: How to Thrive in the New Innovation Landscape – Chesbrough não é o primeiro pesquisador a compreender o valor econômico superior de “bens intelectuais” na economia de hoje. Mas ele, certamente, é o pesquisador que pensou mais profundamente sobre as conseqüências disso para as empresas.
6. Democratizing Innovation – Von Hippel apresenta um caso convincente para os benefícios de incentivar os usuários para inovar e um olhar verdadeiramente intrigante sobre a contribuição deles para o mundo até agora. Download grátis aqui.
7. Wikinomics: How Mass Colaboration Changes Everything – Como defensor do peering, compartilhamento e open-source, Don Tapscott apresenta uma pré-visualização de como a inovação aberta irá mudar tudo.
8. Innovation Happens Elsewhere: Open Source as Business Strategy – É um fato simples: independente de quão inteligente, criativa e inovadora sua organização seja, há pessoas mais inteligentes, criativas e inovadoras fora dela.
9. The Wealth of Networks: How Social Production Transforms Markets and Freedom – Yonchai Benkler nos mostra como a internet permite novos métodos para a produção de bens baseados na participação pública.
10. Group Genius: The Creative Power of Collaboration – Um especialista pioneiro na criatividade e inovação mostra o poder da colaboração para a criatividade organizacional individual.
11. The Wisdom of Crowds – Enquanto nossa cultura confia em especialistas e desconfia da sabedoria das massas, o colunista do New Yorker, James Surowiecki, argumenta que “sob circunstâncias corretas, grupos são impressionantemente inteligentes, e muitas vezes são mais inteligentes do que as pessoas mais inteligentes neles.
12. We Are Smarter Than Me: How to Unleash the Power of Crowds in Your Business – Em We Are Smarter Than Me, você vai descobrir exatamente como usar as redes sociais e a comunidade em seu negócio, levando a melhor tomada de decisão. As ações, ideias e estudos de novos casos no desenvolvimento de produto, fabricação, marketing, atendimento ao cliente, finanças, gestão e muito mais.
13. The Global Brain: Your RoadMap for Innovation Faster and Smarter in a Networked World – Nambisan e Sawhney escreveram um livro que constrói uma ponte entre a inovação aplicada a uma rede orientada e sua aplicação. Um olhar refrescante sobre inovação e sua prática.

—

Update: Como bem lembrado pelo mestre Stefan Lindegaard, o décimo quarto livro da lista é “A Revolução da Inovação Aberta”, do próprio Stefan. Para comprá-lo, clique aqui.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Analista de Negócios em projetos BPM

Por: Marco Gandra

Em: marcogandra@blogspot.com

Sei que os puristas dirão que essa é a área dos Analistas de Processos e que o corpo de conhecimento deverá ser o CBOK em detrimento do BABOK dos Analistas de Negócios. Assim esclareço: vamos discorrer sobre esses papéis no contexto de uma implantação BPMS.

Se aceitarmos, erroneamente, que os sistemas transacionais, diga-se: ERP, são uma classe de sistemas diferente dos sistemas orientados a processos como as soluções BPMS, incorreremos, igualmente, no erro de classificar os Analistas de Processos como uma classe bem distinta dos profissionais de Análise de Negócios, porque, na verdade, as fronteiras não são tão tangíveis assim.

A cada dia, gestores estão despertando para a unificação completa do negócio à TI. Esse movimento tem mão dupla: ora motivada e patrocinada pela área da tecnologia, ora pela área de negócios. O fato é que esse movimento não é uma onda passageira e, sim, uma nova forma de ver os liames entre a TI os negócios.

Os processos que são horizontais, em contraposição aos departamentos funcionais, que são dispostos hierarquicamente de forma vertical, exigem dos Analistas de Negócios uma visão por processos, onde as atividades quase sempre iniciam em um determinado departamento e percorrem vários outros até que o fluxo operacional se extinga.

Nessa visão, o Analista de Processo e o Analista de Negócios se fundem em uma nova abordagem que exige maior responsabilidade e perspicácia. Sua temática é uma evolução, inclusive porque esse novo profissional poderá ser nomeado Arquiteto Corporativo, já que estará preocupado não só em modelar as sequências “AS-IS” e “TO-BE” com BPMN, nem apenas em usar, nas fases subsequentes, diagramas UML para modelar a automação de atividades em serviços distribuídos, usando a arquitetura SOA, ou descrever os requisitos elicitados em regras de negócios nos BRE/BRM´s, mas, também, em assumir atributos de outros profissionais, como os antigos Analistas de O&M, ou, em versão mais atualizada, o Analista da Qualidade, que, por sua vez, se preocupa em determinar pontos de monitoramento e melhoria em todas as fases do processo.

Com essas novas atribuições, os Analistas de Negócios deverão se preocupar em criar meios para monitorar indicadores de desempenho usando ferramentas computacionais – destaque para o BAM ou BI – para criar efetivos painéis de gestão à vista – vivos – tais como os painéis de bordo apregoados pela abordagem BSC, porém renovados em monitores LCD´s de 60 polegadas, permitindo que gestores possam ser, finalmente, proativos, já que terão meios de contemplar os KPI´s gerados em tempo real e, assim, agir antes que as metas atribuídas para o negócio se tornem críticas.

Não há retorno; não podemos criar feudos em torno de títulos profissionais; temos de agir imediatamente e é nesse ambiente florescente, gerado pela abordagem BPM, que observamos um profissional em condição de se destacar e assumir, de forma mais ampla, as responsabilidades e desafios que as novas escolas de gestão propõem. Estamos falando do Analista de Negócios, profissional multiespecialista, grande integrador que promoverá melhoria contínua nos processos e, finalmente, efetivar a ponte entre a informática e o negócio.

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra

Curso gratuito de BABOK e Análise de Negócios – Introdução – Parte 2

Por: Marcelo Neves
Em: http://an202.com/2012/04/24/curso-gratuito-de-babok-e-analise-de-negocios-introducao-parte-2/

Pessoal,

Segue parte 2 do curso.

Grande abraço!

Marco Gandra

www.twitter.com.br/marcogandra

http://marcogandra.blogspot.com/

http://br.linkedin.com/in/marcogandra