terça-feira, 22 de setembro de 2009

Vantagens da POC no processo comercial

Praticamente todos os esforços de venda de software hoje em dia envolvem a realização de uma POC. Se por um lado, como veremos mais adiante, uma POC bem realizada pode ser um excelente instrumento de avaliação de uma solução, por outro lado, uma POC má conduzida pode trazer mais malefícios do que benefícios, prejudicando o processo de compra e se transformando apenas em custo tanto para o comprador quanto para o fornecedor.

Na área de tecnologia da informação, o termo POC (Proof of Concept) significa o desenvolvimento de um protótipo que tem como objetivo avaliar se os principais requisitos técnicos e funcionais de um projeto serão atendidos pela tecnologia oferecida.

O grande benefício de uma POC é o de permitir que o comprador, com um mínimo de investimento (tempo), possa ter garantias do sucesso do seu projeto. Em outras palavras, a POC visa minimizar os riscos associados à futura implementação.

A POC também traz benefícios ao fornecedor, pois durante o seu desenvolvimento, há um conhecimento mais detalhado do projeto futuro, minimizando assim erros de dimensionamento do esforço. Além disso, a POC aumenta a visibilidade da tecnologia oferecida dentro da empresa compradora.

O escopo da POC deve ser definido em comum acordo pelas áreas técnica e usuária. A área usuária deve avaliar se as regras de negócio (rateios, alocações, cálculos diversos) são atendidas. Já área técnica deve avaliar os tradicionais "gargalos" tecnológicos típicos de projetos de BI, como o acesso às fontes de dados, tempos de carga, cálculo e consolidação e tempo de recuperação dos dados pelo usuário final. O ambiente de construção da POC deve ser compatível com o futuro ambiente de desenvolvimento / produção da aplicação, caso contrário, os resultados poderão apresentar distorções.

O tempo ideal de desenvolvimento de uma POC gira em torno de três dias. POCs muito pequenas correm o risco de sub-avaliarem a solução proposta. Já as POCs muito grandes geram um custo alto para os fornecedores, pois na maioria das vezes a POC não é cobrada. Além disso, uma POC longa tende a perder o foco sobre o que realmente precisa ser avaliado.

Uma das dificuldades no processo de avaliação de uma POC, é quando existem diversos fornecedores participando de um mesmo processo. Normalmente cada fornecedor tenta salientar na POC as funcionalidades da sua tecnologia que são reconhecidamente melhores do que as da concorrentes. Por isso é muito importante o comprador estar consciente do que é realmente importante para o seu projeto, e focar na análise destes pontos. O resto é "nice to have".

Outro ponto importante, este para o fornecedor, é definir qual é o momento correto para iniciar a construção da POC. Neste caso, é importante entender bem em que etapa do processo de compra está o comprador. Existem diversas formas de classificar uma oportunidade comercial. Em todas elas, existe um status para classificar o estágio no qual o cliente confirma a existência de orçamento para o projeto. É a partir deste momento que haverá uma seleção das soluções de mercado e é neste estágio que a POC deve ser realizada.

Resumidamente, a POC é uma excelente forma de avaliação das alternativas de solução do mercado. Se usada corretamente, tanto o comprador como o fornecedor serão beneficiados e o risco de sucesso do projeto futuro aumentará consideravelmente.

Até mais,

quarta-feira, 16 de setembro de 2009

Os doze vendedores mais influentes em TI

A Intelligent Enterprise divulgou a lista dos doze vendedores mais influentes de TI em 2009. São, em ordem alfabética:

- Adobe
- Amazon
- IBM
- Microsoft
- Microstrategy
- Netezza
- Oracle
- Salesforce.com
- SAP
- SAS
- TIBCO e
- Teradata

Dentro da área de BI, foram listadas as seguintes empresas que merecem atenção:

- Actuate (open source reporting and BI)
- Attensity (SaaS based data and semantic analytics)
- Clarabridge (customer experience management - CEM)
- Information Builders (integrated enterprise business intelligence platform)
- Inforsense (predictive analytics and visual-analysis)
- Pentaho (open-source BI)
- SPSS (analytics and data mining products) . Detalhe: antes da aquisição pela IBM

Já na categoria de Performance Management, as empresas que merecem atenção são as seguintes:

- Kinaxis (SaaS-based performance management application)
- Quantrix (in-memory planning and modeling)
- Riverlogic (integrated business planning)
- Varicent (sales performance management)

até mais,

terça-feira, 15 de setembro de 2009

10 Cuidados Para Transformar a Implantação de BI em um Caso de Sucesso

1. Patrocínio

Antes de iniciar um projeto de BI, certifique-se de que este projeto está "comprado" por um dos gestores da Empresa. Geralmente os projetos de BI são gerenciados pela área de TI, mas esta iniciativa deve ser patrocinada por alguém que tenha força para fazer com que todos da empresa envolvidos no projeto tenham a dedicação e o envolvimento necessários. Sem este apoio, muitas vezes TI não consegue que os usuários participem ativamente do projeto, seja nas etapas de desenho, construção e/ou validação, e ainda pior, não conseguem fazer os usuários trocarem as planilhas em uso pelo novo sistema de informações.

O ideal é que o próprio CEO esteja envolvido no projeto, pois somente ele poderá garantir uma abrangência corporativa à iniciativa, mesmo que iniciado em um departamento específico.

A prática mostra que sem este apoio, na grande maioria dos casos de conflito, os usuários acabam sempre priorizando as atividades do dia-a-dia em detrimento àquelas do novo projeto.

2. Escolha do Software

Atualmente a quantidade de softwares/soluções de BI existentes no mercado é muito grande e especializada. Ferramentas de dashboards, query, reports, simulações, input de dados e etl, são apenas alguns exemplos que compõe este vasto universo. Esta diversidade faz com que exista uma grande disparidade de preços e funcionalidades entres os produtos, que pode gerar percepções equivocadas se comparadas indiscriminadamente pelo comprador.

Antes de escolher o pacote, é importante entender claramente quais são os requisitos técnicos e de negócio da Empresa, e verificar dentro das ofertas, aquelas que se adequam melhor ao desejado.

Exemplificando, se a empresa possui uma base de dados operacional (fontes de dados do BI) fragmentada, é importante adquirir uma ferramenta de etl que seja capaz de fazer esta integração. Se existem disparidades de conceitos entre os departamentos da Empresa, talvez seja importante adquirir uma ferramenta de gestão de meta-dados.

Uma outra boa questão é a escolha entre uma solução completa de um único fabricante (Oracle, SAP e IBM por exemplo), e a aquisição soluções específicas chamadas "best-of-breed" (Panorama, Informatica, etc). Além disso, já existem no mercado aplicações de BI "prontas", que trazem indicadores, modelos de dados e mapas de extração de dados já desenvolvidos, e prometem uma redução significativa no tempo de desenvolvimento do projeto.

3. Parceiro Experiente

A escolha de um bom parceiro (fornecedor) para a implantação do projeto traz vantagens, não apenas pelo aporte de conhecimento técnico e funcional aplicáveis ao projeto, mas também por mitigar riscos comuns, cujo pré-conhecimento garantirá uma significativa redução de custos e horas gastas no projeto.

Geralmente no mercado as empresas de consultoria especializadas estão vinculadas à uma bandeira, ou seja, representam, revendem ou distribuem softwares de uma determinada Empresa. Nestes casos, a escolha do parceiro estará diretamente ligada à escolha do pacote de software.

A utilização do parceiro em projetos de BI vai desde a terceirização total dos serviços para o parceiro (outsourcing), até a contratação tipo "turn-key" com a capacitação da equipe interna. Dessa forma, é muito importante que a Empresa defina a estratégia de utilização do parceiro desde o início do projeto.

4. Definição do Piloto

O ditado diz: "Pensar grande, começar pequeno". Escolha uma área da Empresa como piloto para o projeto. Para a escolha vários fatores podem ser levados em conta: Aquela que detém os indicadores mais importantes (vendas, por ex.), aquela cujos usuários são mais integrados a TI, aquela cuja extração dos dados é mais simples, etc.

O piloto tem dois principais objetivos: Ajudar a conhecer, em proporções controláveis, quais são os pontos de risco do projeto e ajudar a vender o projeto internamente para os usuários.

5. Aderência ao Modelo de Gestão

Um sistema de informações gerenciais será utilizado na medida em que reflita o modelo de gestão da Empresa. É muito comum chegar ao final de um projeto de BI e para a surpresa de todos, o conjunto de informações apresentadas não atender às demandas dos principais gestores. Neste caso, o sentimento de frustração é muito grande por parte de todos os envolvidos.

Para evitar este tipo desagradável de surpresa, é fundamental iniciar o projeto com um desenho conceitual que enderece com clareza o detalhamento dos Fatores Críticos de Sucesso (FCS) e seus respectivos Indicadores-Chave de Desempenho (ICD). Dimensões, atributos e fontes de dados, entre outros, devem ser documentadas e apresentadas aos usuários finais para validação.

Uma dica para esta etapa é solicitar os relatórios atualmente utilizados pelos gestores para a tomada de decisão. Embora na maioria das vezes estejam em formato desestruturado, um olho treinado poderá extrair deles informações valiosas para o desenho.

6. Arquitetura Técnica Adequada

Antes de iniciar o projeto é importante ter uma visão das necessidades de hardware e software envolvidos. Esta visão deve contemplar o projeto completo, e deve-se levar em conta que o crescimento do modelos de dados gerenciais é geralmente exponencial, ou seja, embora em um primeiro momento (piloto) possamos ter uma boa performance, na medida em que o modelo de dados cresce e/ou dados históricos são acrescentados, este quadro pode mudar rapidamente para um cenário de (sobretudo nos modelos diários) gargalo.

É muito importante criar ambientes similares de desenvolvimento e produção (e eventualmente homologação), pois geralmente um dos fatores mais críticos dos projetos de BI é o tempo de carga e cálculo dos modelos de dados.

É comum encontrar nas empresas um ambiente de desenvolvimento significativamente menor do que o de produção. Neste caso, jamais teremos como avaliar o desempenho dos modelos antes de migrá-los para produção, o que representa um grande risco para o projeto.

7. Fonte de Dados Confiável e Acessível

A fase de extração dos dados operacionais para o BI é aquela que concentra a maior parte dos riscos para o projeto, pois normalmente o esforço e complexidade são subdimensionados. O risco desta etapa aumenta proporcionalmente à quantidade de fontes de dados diferentes.
O BI é uma grande janela que mostra os dados da Empresa, desde o valor consolidado chegando em alguns casos a informações bem detalhadas (ex: sku de produtos, nota fiscal). Por isso é muito comum que o processo de validação dos dados no BI acabe mostrando várias inconsistências existentes nas bases operacionais. Em alguns casos são tantos os problemas de qualidade dos dados que inviabilizam a continuação do projeto.

8. Envolvimento dos Usuários

Um sistema de informações jamais pode ser imposto, ou pelo menos, jamais pode parecer ter sido imposto. Por isso, o usuário final, ou seja, o principal beneficiário, deve ser envolvido no projeto desde a sua concepção, tornando-o co-responsável pelo produto final a ser gerado.

Nos casos onde não há uma co-participação do usuário, é muito comum haver uma maior resistência em abrir mão das ferramentas de gestão atuais, pois o mesmo não se sentirá nem comprometido com o que foi gerado, nem suficientemente seguro para confiar nos números do novo sistema.

A participação do usuário é crítica durante todo o projeto, mas é sobretudo nas etapas de desenho conceitual e de validação dos dados que se torna indispensável.

9. Plano de Implantação Detalhado

O momento de colocar a aplicação em produção é muito crítico. Há muita ansiedade dos usuários pelo novo sistema, e qualquer atraso na implantação gerará frustração. Por isso, é muito importante detalhar um plano de implantação que contemple aspectos como "fall-back" (em caso de problemas), produção assistida e treinamento dos usuários, entre outros.

É importante que a área da empresa responsável pelo gerenciamento de mudança seja envolvida no processo, para preparar o plano de mudança junto aos usuários. Um bom plano de marketing interno focando nos benefícios do novo projeto também é recomendado.

10. Melhoria Contínua

Como dito anteriormente, uma aplicação de BI deve refletir o modelo de gestão da empresa. Como as empresas estão em constante transformação, o modelo de gestão está sempre mudando. A chegada de novos gestores, mudanças no cenário mundial, alterações na legislação, são todos exemplos de mudanças que certamente terão reflexos no BI.

O projeto de BI não termina após a sua implantação. Esta é apenas o marco inicial de um processo contínuo de geração de informações para a tomada de decisão. Na medida em que houver o amadurecimento do sistema, com a adesão de mais e novos usuários, a inclusão de novos indicadores, e a construção de novos módulos (planejamento, consolidação, scorecard) a Empresa caminhará para um cenário onde poderá efetivamente utilizar a informação como diferencial competitivo.