Muitos dos projetos de Business Intelligence terminam em fracasso. Na maioria dos casos, dois fatores são apontados como os grande vilões. Um deles é a necessidade das empresas filtrarem um volume maior de informações de acordo com quesitos bastante específicos (relevantes para o negócio) o que faz aumentar a complexidade da pesquisa no sistema de BI. Ainda é necessário adequar o desenvolvimento de hardware e de software, que anda em passos mais lentos que essa demanda.
Além disso, vivemos em uma época na qual - acostumados a fazer pesquisas no Google, por exemplo – os usuários desejam obter respostas rápidas. Tal velocidade, imprime nos sistemas internos a pressão de responder na hora, pois poucos usuários ainda toleram sistemas lentos. O retardo nas repostas leva a um só comportamento por parte do usuário final: o abandono da plataforma de informações. Prejuízo certo para a corporação que desembolsou uma quantia razoável pela solução.
O resultado do desastre é uma opulência de tabelas do Excel transitando pela corporação em silos desorganizados.
Baseando-se nos anos de experiência e em diversos debates com profissionais de TI e de unidades de negócio de centenas de empresas, a Information Builders identificou 10 razões mais frequentes do fracasso das implementações de BI.
1. Requisitos pouco claros
Depois que as unidades de negócio e o departamento de TI concordam que a sua empresa necessita de um sistema de reporting e de análise dos dados de negócio, o próximo grande passo é definir os indicadores-chave do desempenho (KPIs) para uma gestão empresarial eficaz. Contudo, em vez da definição destes indicadores, muitas empresas usam as aplicações de BI meramente para confirmar o que faziam anteriormente no Excel e, depois, questionam-se porque os seus relatórios são apenas um pouco melhor do que os anteriores.
Depois que as unidades de negócio e o departamento de TI concordam que a sua empresa necessita de um sistema de reporting e de análise dos dados de negócio, o próximo grande passo é definir os indicadores-chave do desempenho (KPIs) para uma gestão empresarial eficaz. Contudo, em vez da definição destes indicadores, muitas empresas usam as aplicações de BI meramente para confirmar o que faziam anteriormente no Excel e, depois, questionam-se porque os seus relatórios são apenas um pouco melhor do que os anteriores.
2. Dados incorretos ou incompletos
Por mais persuasivo que o design da aplicação de BI possa ser, as pesquisas iniciais sobre a informação requerida em vastas fontes de dados durante um teste podem revelar que os dados estão desatualizados, têm erros ou (ainda) estão inacessíveis. Dados com pouca qualidade são uma causa frequente de grandes problemas nos projetos de BI. As lacunas, por vezes, também se revelam na utilização diária, quando se trabalha com dados que mudam frequentemente.
Por mais persuasivo que o design da aplicação de BI possa ser, as pesquisas iniciais sobre a informação requerida em vastas fontes de dados durante um teste podem revelar que os dados estão desatualizados, têm erros ou (ainda) estão inacessíveis. Dados com pouca qualidade são uma causa frequente de grandes problemas nos projetos de BI. As lacunas, por vezes, também se revelam na utilização diária, quando se trabalha com dados que mudam frequentemente.
3. Usuários finais envolvidos tardiamente
Quando se implementa um projeto de BI, é essencial que se inclua colaboradores das unidades de negócio que irão trabalhar com a aplicação final já nas fases iniciais do projeto. Se a aplicação não está em sintonia com os seus inputs, o projeto provavelmente encontrará considerável resistência. Se, no mínimo, poucos utilizadores tiverem a oportunidade de trabalhar com o primeiro produto acabado, então o próximo trabalho de projeto poderá incluir as suas experiências.
Quando se implementa um projeto de BI, é essencial que se inclua colaboradores das unidades de negócio que irão trabalhar com a aplicação final já nas fases iniciais do projeto. Se a aplicação não está em sintonia com os seus inputs, o projeto provavelmente encontrará considerável resistência. Se, no mínimo, poucos utilizadores tiverem a oportunidade de trabalhar com o primeiro produto acabado, então o próximo trabalho de projeto poderá incluir as suas experiências.
4. Resultados apresentáveis apenas após dois anos
Muitas vezes, as empresas tentam abordar todos os requisitos concebíveis de BI em um projeto a longo prazo. Enquanto uma abordagem estratégica é sempre correta, os problemas podem surgir se a equipe do projeto insistir em, inicialmente, manter o seu trabalho “em segredo”. Quando a equipe apresenta os seus primeiros resultados após dois anos, é altamente provável que estes se desviem significativamente das suas expectativas iniciais. É muito mais promissor se levarem dois ou três meses para apresentar módulos acabados que possam provar a sua adequação às operações diárias.
Muitas vezes, as empresas tentam abordar todos os requisitos concebíveis de BI em um projeto a longo prazo. Enquanto uma abordagem estratégica é sempre correta, os problemas podem surgir se a equipe do projeto insistir em, inicialmente, manter o seu trabalho “em segredo”. Quando a equipe apresenta os seus primeiros resultados após dois anos, é altamente provável que estes se desviem significativamente das suas expectativas iniciais. É muito mais promissor se levarem dois ou três meses para apresentar módulos acabados que possam provar a sua adequação às operações diárias.
5. Falta de gestão da mudança
Mudanças e ajustes às especificações e objectivos originais existirão em qualquer projeto de BI. Contudo, em muitos casos, inexistem uma equipe de gestão formal das mudanças que definam como os novos requisitos serão incorporados ao projeto existente e um responsável pela sua aprovação. A falta de uma gestão de mudanças resulta rapidamente em custos adicionais e em atrasos na conclusão do projeto.
Mudanças e ajustes às especificações e objectivos originais existirão em qualquer projeto de BI. Contudo, em muitos casos, inexistem uma equipe de gestão formal das mudanças que definam como os novos requisitos serão incorporados ao projeto existente e um responsável pela sua aprovação. A falta de uma gestão de mudanças resulta rapidamente em custos adicionais e em atrasos na conclusão do projeto.
6. Cumprimento e segurança negligenciados
O número de disposições e regulamentações legais têm aumentado continuamente nos últimos anos, e as disposições de privacidade tornaram-se mais rigorosas. As equipes de projeto raramente têm em conta as normas, as regras e os conceitos de segurança, desde o início, ao fazerem disposições para integrar futuras mudanças o mais facilmente possível. Por exemplo, deverá ser necessário dar acesso aos usuários às aplicações e aos dados no futuro.
O número de disposições e regulamentações legais têm aumentado continuamente nos últimos anos, e as disposições de privacidade tornaram-se mais rigorosas. As equipes de projeto raramente têm em conta as normas, as regras e os conceitos de segurança, desde o início, ao fazerem disposições para integrar futuras mudanças o mais facilmente possível. Por exemplo, deverá ser necessário dar acesso aos usuários às aplicações e aos dados no futuro.
7. Documentação pobre sobre o ambiente da aplicação
Não é raro que os projetos mais abrangentes de BI revelem que a documentação existente sobre a aplicação está incorreta ou desatualizada. Este é o maior obstáculo da coordenação do sistema e da integração de todos os sistemas afetados. Um simples exemplo disto é o campo de nomes que varia de uma aplicação para outra, precisando ser consolidado através de uma tabela de correspondência. Como resultado, temos custos adicionais e, normalmente, um atraso significativo do projeto.
Não é raro que os projetos mais abrangentes de BI revelem que a documentação existente sobre a aplicação está incorreta ou desatualizada. Este é o maior obstáculo da coordenação do sistema e da integração de todos os sistemas afetados. Um simples exemplo disto é o campo de nomes que varia de uma aplicação para outra, precisando ser consolidado através de uma tabela de correspondência. Como resultado, temos custos adicionais e, normalmente, um atraso significativo do projeto.
8. Recursos de hardware cotados de forma incorreta
Podemos distinguir dois tipos diferentes de erros aqui. Em um primeiro caso, as empresas são demasiado generosas na determinação das suas necessidades de hardware, o que deixa os recursos inativos e leva a custos contínuos consideráveis (e desnecessários). Em um segundo caso, os requisitos de hardware são subestimados, resultando em um desempenho pobre e usuários finais insatisfeitos.
Podemos distinguir dois tipos diferentes de erros aqui. Em um primeiro caso, as empresas são demasiado generosas na determinação das suas necessidades de hardware, o que deixa os recursos inativos e leva a custos contínuos consideráveis (e desnecessários). Em um segundo caso, os requisitos de hardware são subestimados, resultando em um desempenho pobre e usuários finais insatisfeitos.
9. Funcionários centrados no Excel
Durante anos, muitas unidades de negócio de empresas de todas as dimensões apoiaram-se exclusivamente no Excel para criar e analisar relatórios. “Mas sempre foi assim que fizemos” é a resposta mais comum dos funcionários que ainda não estão preparados para perder os velhos hábitos. No que diz respeito a isto, muitos subestimam a prática que será necessária para tornar a aplicação um sucesso, nas operações diárias.
Durante anos, muitas unidades de negócio de empresas de todas as dimensões apoiaram-se exclusivamente no Excel para criar e analisar relatórios. “Mas sempre foi assim que fizemos” é a resposta mais comum dos funcionários que ainda não estão preparados para perder os velhos hábitos. No que diz respeito a isto, muitos subestimam a prática que será necessária para tornar a aplicação um sucesso, nas operações diárias.
10. Um orçamento inadequado
O custo de um projeto de BI, que irá proporcionar transparência aos processos de negócio e fornecer dados para uma gestão eficaz, não pode ser coberto por fundo. Um sentido equivocado de economia leva, muitas vezes, a que as empresas decidam implementar capacidades-chave, como a integração de fontes adicionais de dados, o fornecimento de capacidades “core” de BI aos dispositivos móveis ou levar em conta os utilizadores móveis e os seus dispositivos.
O custo de um projeto de BI, que irá proporcionar transparência aos processos de negócio e fornecer dados para uma gestão eficaz, não pode ser coberto por fundo. Um sentido equivocado de economia leva, muitas vezes, a que as empresas decidam implementar capacidades-chave, como a integração de fontes adicionais de dados, o fornecimento de capacidades “core” de BI aos dispositivos móveis ou levar em conta os utilizadores móveis e os seus dispositivos.
Aqueles que aprendem a partir dos erros dos outros são os que o melhor planejam suas aplicações de BI. Se os problemas são identificados a tempo, as hipóteses de se ser bem sucedido nos projetos de BI são boas. Esta é uma importante condição para assegurar que os negócios atinjam as suas metas operacionais com as aplicações de BI.
(*) Manuel del Pino é diretor de Pré-venda da Information Builders Ibéria
0 comentários:
Postar um comentário