Pat Phelan, do Gartner
Segunda-feira, 21 de dezembro de 2009 - 11h49
O controle de investimento é fundamental para o suporte de aplicações corporativas/ERP.
Esta pesquisa descreve o objetivo do controle de investimento e oferece indicadores de desempenho (KPIs) para avaliar sua eficácia. Líderes corporativos e de TI podem utilizá-la para se orientarem conforme planejam uma estrutura organizacional de suporte e mecanismos de govenança.
Considerações básicas
• Pesquisa informal com 100 clientes do Gartner que estão obtendo sucesso na entrega de suporte de aplicações revelou que cerca de 49% dos recursos de suporte foram direcionados a funções corporativas.
• Como incluir representantes corporativos é uma das principais decisões organizacionais que devem ser tomadas durante o planejamento da etapa seguinte à implementação do suporte de aplicações corporativas/ERP.
• Empresas com organizações bem-sucedidas de suporte de aplicações corporativas/ERP tem um conselho de controle de investimento (embora ele possa ser definido com outro nome) cuja função é orientar a evolução da aplicação para mantê-la alinhada às necessidades do negócio.
Recomendações
• Direcione a função de controle de investimento a líderes corporativos envolvidos com o uso da aplicação e com como ela evolui durante seu ciclo de vida. Dê suporte a esta função com consultoria de TI.
• Formalize a função criando um conselho de controle de investimento e mudança para gerenciar os investimentos em aplicações corporativas/ERP.
• Use métricas para avaliar o desempenho da função. Garanta que a pessoa responsável pela análise do desempenho dispõe dessas métricas e as incluirá nos seus objetivos durante o período de análise do desempenho.
ANÁLISE
A implementação da aplicação corporativa/ERP representa um importante investimento para uma empresa. A implementação é normalmente executada por uma equipe de projeto formada por representantes corporativos e de TI. Entretanto, quando a aplicação corporativa está ativa, a equipe de projeto se separa e os usuários corporativos que estiveram envolvidos com o projeto retornam aos seus cargos habituais ou então dão início a um novo projeto. Consequentemente, costuma haver pouco comprometimento com o gerenciamento da evolução da aplicação durante o seu ciclo de vida. Sem o comprometimento do usuário, há um atraso nas respostas a mudanças ou a questões que exigem maior investimento na aplicação. A aplicação corporativa também corre o risco de ficar estática ou até regredir, e não evolui adequadamente para atingir os objetivos do negócio.
Algumas empresas erroneamente acreditam que o suporte pós-implementação das aplicações corporativas/ERP pode ser satisfatoriamente entregue por meio da estrutura interna de TI; porém, essa estrutura interna omite a necessidade do alto nível de envolvimento do usuário final para a obtenção de sucesso. Em uma pesquisa informal com 100 clientes do Gartner, pedimos uma lista dos recursos destinados ao suporte operacional, ao suporte de aplicação e ao suporte de processos corporativos. Os resultados revelaram que cerca de 49% dos recursos destinados às funções de suporte eram corporativos.
As melhores práticas para o sucesso da etapa seguinte à implementação de aplicações corporativas/ERP incluem estabelecer um centro de competência de aplicação corporativa (BACC) que integre os serviços de suporte de aplicação básicos do departamento de TI com serviços orientados aos negócios que mantenham os usuários finais produtivos; melhorar continuamente o processo corporativo e controlar o investimento e mudanças na aplicação. Um serviço fundamental é o gerenciamento da evolução da aplicação durante seu ciclo de vida, incluindo o direcionamento de futuros investimentos. Essa função de gerenciar e controlar investimentos em ERP é desempenhada por líderes corporativos envolvidos com a utilização e com a evolução da aplicação. Essa função normalmente é exterior ao BACC, mas está estreitamente vinculada a ele, orientando os serviços de suporte.
Objetivo da função de controle de investimento
O objetivo da função de controle de investimento é fornecer uma orientação estratégica para aplicações ERP ou outras aplicações corporativas. Em muitas empresas, os termos “controle de mudança” e “controle de configuração” também são usados para definir esta mesma função. Quando esses termos são relacionados com a função de controle de investimento, eles implicam o gerenciamento e o controle de quaisquer mudanças que devam ser feitas na aplicação ou no padrão de configuração global, em vez de terem um sentido mais tático, que envolveria a manutenção e líderes de projeto gerenciando as mudanças na aplicação e na configuração conforme elas se desenvolvem, sendo testadas e aplicadas no ambiente de produção.
A função de controle de investimento evoluiu conforme áreas mais funcionais foram incorporadas na solução de ERP. Com o aumento do número de stakeholders compartilhando a aplicação, houve também o aumento da necessidade de coordenar os investimentos e as mudanças na aplicação. Tornou-se fundamental que usuários finais se comuniquem entre si quando resolverem fazer qualquer mudança na aplicação, para diminuir os problemas que devem surgir quando novas funcionalidades forem inseridas. O próprio processo de introdução da mudança também precisa ser adaptado aos usuários finais que compartilham a solução. Conforme mais stakeholders compartilharam a responsabilidade de gerenciar as mudanças nas aplicações corporativas/ERP, surgiu uma abordagem comunitária para gerenciar e controlar os investimentos em aplicações. Foi assim que se originou a função do controle de investimento em aplicação corporativa/ERP.
Os serviços típicos incluídos nessa função são:
• Determinar as estratégias para a aplicação corporativa/ERP e criar uma trajetória para a aplicação.
• Gerenciar investimentos na aplicação durante seu ciclo de vída.
• Garantir que as mudanças na aplicação são realizadas para o bem da companhia como um todo.
O artigo “Conjunto de ferramentas: ERP e Ferramenta de Planejamento Estratégico de Suporte de Aplicação Corporativa” fornece um exemplo de serviços de suporte entregues pela função de controle de investimento.
A função normalmente depende do conselho de controle de investimento e mudança. Essa função de nível sênior, frequentemente compartilhada por vários líderes corporativos, deve estabelecer a direção dos investimentos nas aplicações que auxiliam o negócio. Além disso, ela deve encontrar um ponto de equilíbrio entre as demandas do usuário por singularidade e o custo de manter as aplicações. Com base nas diretrizes de governança de aplicação do Gartner, a função de controle de investimento inclui as seguintes questões:
• Quais investimentos adicionais em aplicação devem ser feitos?
• Quais novos investimentos devem ser feitos em primeiro lugar?
• Quem pagará pelo desenvolvimento e pela manutenção da solução?
• Quem é o proprietário da solução?
Um componente fundamental da função de controle de investimento é a avaliação e a aprovação das exigências da mudança, assim como atividades de planejamento da mudança, como priorizar e agendar projetos de mudança de aplicação. A função também implica alocar fundos e recursos para os projetos. Líderes de TI servem como consultores de suporte para a função de controle de investimento e como auxiliares na tarefa de priorizar, porque outros esforços independentes da aplicação corporativa/ERP devem ser adaptados ao programa da mudança. A função de controle de investimento é responsável pelo planejamento do ciclo de vida da aplicação, incluindo o monitoramento ativo das necessidades dos usuários finais e o planejamento da retirada da aplicação obsoleta. Essa função fornece uma direção para os gerentes da aplicação e para os gerentes de portfolio de aplicações responsáveis por executar as estratégias de aplicação. Finalmente, a função inclui o estabelecimento e o gerenciamento de políticas relacionadas com a aplicação.
Principais atributos
Quando utilizar a função de controle de investimento, é essencial definir o grupo de líderes corporativos. Para esta função ser eficaz, as pessoas envolvidas precisam:
• Conhecer profunda e amplamente o negócio e seus processos
• Ter autoridade para tomar as decisões mais apropriadas para o negócio
• Ser responsabilizada pelos resultados
• Ter tempo e prioridades orientados para os seus objetivos
As pessoas responsáveis por esta função também precisam ser capazes de trabalhar em grupo para gerenciar a configuração de aplicação global ou corporativa e os padrões de processos. A colaboração entre as pessoas envolvidas com a função de controle de investimento é fundamental para o sucesso do controle do suporte à aplicação.
Métricas de desempenho
No suporte de aplicação corporativa/ERP, garantir que são utilizadas as métricas de desempenho corretas é importante. Devido ao fato de a função de controle de investimento ser um tarefa de pessoas que normalmente tem inúmeras responsabilidades, o comprometimento é uma métrica de desempenho. Ele não é apenas essencial para assegurar que o esforço individual está alinhado às decisões do grupo, mas também é essencial para dar credibilidade e propriedade às decisões da função de controle de investimento tomadas pelo grupo. Embora a avaliação do desempenho da função de controle de investimento seja subjetiva, as seguintes métricas podem ser úteis para identificar se um participante está realmente cumprindo suas tarefas:
• Nível de participação no conselho de controle de investimento
• Estratégia de aplicação e plano de investimento elaborados e executados
• Métricas de retorno do investimento associadas com os projetos aplicadas, registradas e gerenciadas.
• Quantidade de pedidos de mudança de aplicação abertos
• Projetos aprovados e com capital disponível
• Aplicações obsoletas retiradas em 12 meses após a implementação do novo sistema
• Políticas da aplicação alinhadas com as necessidades do negócio
Utilize as métricas corretas para avaliar esses fatores. Garanta que a pessoa responsável por analisar o desempenho desta função conhece profundamente essas métricas. Inclua métricas nos objetivos individuais dos envolvidos com o projeto durante o período de análise do desempenho
segunda-feira, 28 de dezembro de 2009
Versão beta do novo MySQL está disponível na internet
Versão Milestone traz atualizações solicitadas pelos usuários, como códigos padrão de retorno para programas armazenados e recursos de replicação.
Por Joab Jackson, do IDG News Service
21 de dezembro de 2009 - 10h21
A comunidade de desenvolvedores do MySQL liberou a primeira versão preliminar pública do que será o próximo MySQL. Administradores de bancos de dados são convidados pela comunidade a baixar e testar o MySQL Server 5.5.0-m2, de codinome Betony, embora ainda não seja aconselhável usá-lo em ambientes de produção.
“Os novos recursos desta versão estão com qualidade de beta. Como em qualquer versão de pré-produção, recomenda-se cautela na instalação em sistemas de produção ou com dados críticos”, escreveu o engenheiro sênior da Sun Microsystems que participa da equipe de desenvolvimento do MySQL, Jörg Brühe, em e-mail enviado a algumas listas de discussão.
Entre os novos recursos da MySQL estão uma opção para replicação semissíncrona, que assegura que uma transação do banco de dados não será considerada completa até que uma cópia de segurança da confirmação da operação seja feita.
O MySQL 5.5 também adere ao método padrão SQL ANSI/ISO de retorno de códigos de erro por procedimentos armazenados (stored procedures), chamado Signal/Resignal, que havia sido uma solicitação dos usuários. A sintaxe de particionamento também foi melhorada, e a aderência ao padrão XML foi ampliada. A versão traz várias correções de bugs e outras modificações menores.
Novo modelo
Esta é a primeira edição a ser liberada sobre um novo modelo de versão que, segundo seus idealizadores, vai levar a versões mais estáveis e a atualizações mais frequentes. O sufixo “-m” informa que se trata de uma versão Milestone, com novos recursos sendo testados.
As versões Milestone são liberadas antes das versões geralmente disponíveis – GA (de Generally Available), no jargão do modelo de versões do MySQL.
“Acredito que tivemos algum espaço para avançar em qualidade com os recursos incluídos nas novas versões do MySQL, e que o modelo Milestone é um passo na direção certa para resolver algumas dessas questões”, escreveu o vice-presidente de relações com a comunidade MySQL Kaj Arnö, em seu blog.
Apesar de identificada como Milestone 2, esta versão é na verdade a primeira a ser liberada para teste público, ressaltou o porta-voz da Sun, Steve Curry, em entrevista por e-mail.
O MySQL 5.5 foi construído a partir do MySQL 5.4, que por sua vez foi uma atualização relativamente menor do MySQL 5.1, a versão de produção do MySQL mais utilizada atualmente. A MySQL 5.4 não será mais atualizada, e os usuários de MySQL 5.1 serão encorajados a atualizar para a versão 5.5, que está pronta para ambientes de produção.
Alvo de disputa
O banco de dados relacional MySQL tem sido alvo de discussões na disputa entre a Oracle, que quer comprar a Sun, e a União Europeia, que demonstrou sua preocupação sobre questões antitruste ligadas ao acordo.
O criador do MySQL, Michael “Monty” Widenius, também expressou sua preocupação sobre a Oracle ser dona do MySQL – que, para muitos usuários, tem sido uma alternativa de baixo custo ao próprio sistema de banco de dados da Oracle. A Sun Microsystems mantém uma versão comercial do MySQL, embora o programa tenha código aberto e muitos desenvolvedores independentes tenham contribuído para sua construção.
Curry não estimou um prazo para que o software entre em modo de produção, mas disse que o novo sistema de versões deverá acelerar o processo de desenvolvimento. O MySQL 5.1 foi liberado na forma GA em dezembro de 2008, e 11 atualizações foram aplicadas ao software desde então.
Por Joab Jackson, do IDG News Service
21 de dezembro de 2009 - 10h21
A comunidade de desenvolvedores do MySQL liberou a primeira versão preliminar pública do que será o próximo MySQL. Administradores de bancos de dados são convidados pela comunidade a baixar e testar o MySQL Server 5.5.0-m2, de codinome Betony, embora ainda não seja aconselhável usá-lo em ambientes de produção.
“Os novos recursos desta versão estão com qualidade de beta. Como em qualquer versão de pré-produção, recomenda-se cautela na instalação em sistemas de produção ou com dados críticos”, escreveu o engenheiro sênior da Sun Microsystems que participa da equipe de desenvolvimento do MySQL, Jörg Brühe, em e-mail enviado a algumas listas de discussão.
Entre os novos recursos da MySQL estão uma opção para replicação semissíncrona, que assegura que uma transação do banco de dados não será considerada completa até que uma cópia de segurança da confirmação da operação seja feita.
O MySQL 5.5 também adere ao método padrão SQL ANSI/ISO de retorno de códigos de erro por procedimentos armazenados (stored procedures), chamado Signal/Resignal, que havia sido uma solicitação dos usuários. A sintaxe de particionamento também foi melhorada, e a aderência ao padrão XML foi ampliada. A versão traz várias correções de bugs e outras modificações menores.
Novo modelo
Esta é a primeira edição a ser liberada sobre um novo modelo de versão que, segundo seus idealizadores, vai levar a versões mais estáveis e a atualizações mais frequentes. O sufixo “-m” informa que se trata de uma versão Milestone, com novos recursos sendo testados.
As versões Milestone são liberadas antes das versões geralmente disponíveis – GA (de Generally Available), no jargão do modelo de versões do MySQL.
“Acredito que tivemos algum espaço para avançar em qualidade com os recursos incluídos nas novas versões do MySQL, e que o modelo Milestone é um passo na direção certa para resolver algumas dessas questões”, escreveu o vice-presidente de relações com a comunidade MySQL Kaj Arnö, em seu blog.
Apesar de identificada como Milestone 2, esta versão é na verdade a primeira a ser liberada para teste público, ressaltou o porta-voz da Sun, Steve Curry, em entrevista por e-mail.
O MySQL 5.5 foi construído a partir do MySQL 5.4, que por sua vez foi uma atualização relativamente menor do MySQL 5.1, a versão de produção do MySQL mais utilizada atualmente. A MySQL 5.4 não será mais atualizada, e os usuários de MySQL 5.1 serão encorajados a atualizar para a versão 5.5, que está pronta para ambientes de produção.
Alvo de disputa
O banco de dados relacional MySQL tem sido alvo de discussões na disputa entre a Oracle, que quer comprar a Sun, e a União Europeia, que demonstrou sua preocupação sobre questões antitruste ligadas ao acordo.
O criador do MySQL, Michael “Monty” Widenius, também expressou sua preocupação sobre a Oracle ser dona do MySQL – que, para muitos usuários, tem sido uma alternativa de baixo custo ao próprio sistema de banco de dados da Oracle. A Sun Microsystems mantém uma versão comercial do MySQL, embora o programa tenha código aberto e muitos desenvolvedores independentes tenham contribuído para sua construção.
Curry não estimou um prazo para que o software entre em modo de produção, mas disse que o novo sistema de versões deverá acelerar o processo de desenvolvimento. O MySQL 5.1 foi liberado na forma GA em dezembro de 2008, e 11 atualizações foram aplicadas ao software desde então.
domingo, 27 de dezembro de 2009
DDA tem 2,4 milhões de clientes cadastrados
Sistema de débito direto autorizado está em operação há dois meses e conta com 24,2 milhões de boletos de cobrança inseridos no sistema, segundo Federação Brasileira dos Bancos.
Por Agência Brasil
23 de dezembro de 2009 - 16h01
Depois de dois meses em operação, o Débito Direto Autorizado (DDA) tem 2,4 milhões de clientes cadastrados e 24,2 milhões de boletos de cobrança de todo o mercado inseridos no sistema. Os dados foram divulgados nesta quarta-feira (22/12) pela Federação Brasileira dos Bancos (Febraban).
O novo sistema permite a visualização eletrônica dos boletos de cobrança que antes eram enviados pelo correio ao pagador. Segundo o assessor técnico da Febraban, Walter Tadeu, o sistema facilita a vida do cidadão porque permite que todos os boletos de cobrança possam ser visualizados em uma mesma pasta de arquivos.
“Se o pagador não está no DDA, ele recebe um monte de papel, que pode se extraviar ou ser adulterado, enquanto com o DDA ele tem as informações no meio que o banco disponibiliza para ele”, observa.
Para utilizar o DDA, o cliente, seja pessoa física ou jurídica, cadastra-se no banco em que tiver conta. A empresa que receberá o pagamento também se cadastra no banco para que as cobranças sejam registradas e emitidas. Se o pagador for cadastrado e o recebedor tiver listado suas cobranças, o pagador poderá ver o boleto bancário pela via eletrônica.
Tadeu salientou que o DDA não traz custo algum para o cliente, porque, para ter acesso ao sistema, basta utilizar os meios eletrônicos disponibilizados pelo banco. O único custo bancário possível é cobrado pela própria empresa, que contrata um banco para fazer a cobrança dos boletos. “E esse serviço é pago. A empresa deveria assumir esse custo, mas muitas delas repassam para o devedor. Isso não é o banco, é a empresa. No DDA, continua da mesma forma.”
A previsão da Febraban era a de que esses números fossem alcançados apenas depois de sete meses da implantação. “Não tivemos a oportunidade de mensurar como estarão esses números daqui a cinco meses, mas acredito que será um volume muito grande, porque o DDA foi um sistema que, por seus aspectos de segurança e facilidade, chamou muito a atenção das pessoas”.
Por Agência Brasil
23 de dezembro de 2009 - 16h01
Depois de dois meses em operação, o Débito Direto Autorizado (DDA) tem 2,4 milhões de clientes cadastrados e 24,2 milhões de boletos de cobrança de todo o mercado inseridos no sistema. Os dados foram divulgados nesta quarta-feira (22/12) pela Federação Brasileira dos Bancos (Febraban).
O novo sistema permite a visualização eletrônica dos boletos de cobrança que antes eram enviados pelo correio ao pagador. Segundo o assessor técnico da Febraban, Walter Tadeu, o sistema facilita a vida do cidadão porque permite que todos os boletos de cobrança possam ser visualizados em uma mesma pasta de arquivos.
“Se o pagador não está no DDA, ele recebe um monte de papel, que pode se extraviar ou ser adulterado, enquanto com o DDA ele tem as informações no meio que o banco disponibiliza para ele”, observa.
Para utilizar o DDA, o cliente, seja pessoa física ou jurídica, cadastra-se no banco em que tiver conta. A empresa que receberá o pagamento também se cadastra no banco para que as cobranças sejam registradas e emitidas. Se o pagador for cadastrado e o recebedor tiver listado suas cobranças, o pagador poderá ver o boleto bancário pela via eletrônica.
Tadeu salientou que o DDA não traz custo algum para o cliente, porque, para ter acesso ao sistema, basta utilizar os meios eletrônicos disponibilizados pelo banco. O único custo bancário possível é cobrado pela própria empresa, que contrata um banco para fazer a cobrança dos boletos. “E esse serviço é pago. A empresa deveria assumir esse custo, mas muitas delas repassam para o devedor. Isso não é o banco, é a empresa. No DDA, continua da mesma forma.”
A previsão da Febraban era a de que esses números fossem alcançados apenas depois de sete meses da implantação. “Não tivemos a oportunidade de mensurar como estarão esses números daqui a cinco meses, mas acredito que será um volume muito grande, porque o DDA foi um sistema que, por seus aspectos de segurança e facilidade, chamou muito a atenção das pessoas”.
Usiminas adota solução de TI para otimizar cadeia de produção
Projeto apresenta informações em video wall de 12 metros que mostra dados de sistemas legados, ERP e câmeras com imagens em tempo real da planta de Ipatinga da siderúrgica.
Por Redação da Computerworld
23 de dezembro de 2009 - 15h00
A empresa siderúrgica Usiminas precisava otimizar as etapas de produção de sua fábrica em Ipatinga (MG). A solução escolhida foi criar um centro integrado de operação que reúne profissionais de cada etapa do processo de produção e conta com um video wall onde são apresentadas, em tempo real, informações da cadeia produtiva.
O projeto, realizado pela consultoria de tecnologia Neoris, levou dois anos para ser concluído e sua implantação foi finalizada em outubro. Com a solução, os 23 profissionais que trabalham no centro de operação em cada um dos três turnos podem modificar procedimentos em cada etapa para garantir melhores resultados à produção como um todo.
"Ipatinga é uma planta siderúrgica integrada. Somos uma usina em série, temos interdependência de processos, por isso necessidade de sincronismo entre eles", explica o gerente de programação e controle de produção da planta, Leonardo Zenóbio.
O video wall com 12 metros de largura e 2,5 metros de extensão é formado por 14 cubos que formam uma imagem completa. O conceito do projeto é apresentar as informações visualmente, por meio do uso de diferentes cores, de forma que elas sejam facilmente identificadas pelos profissionais que monitoram os processos.
Os dados mostrados no video wall são obtidos graças à integração com sistemas legados da Usiminas (chamados Manufacture Execution Systems - MES -, ou sistemas de execução de manufatura), com o ERP da SAP usado pela empresa siderúrgica, com imagens de 32 câmeras de vídeo instaladas em toda a fábrica e com o sistema de mapa georeferenciado do pátio da fábrica.
A aplicação baseia-se na ferramenta SAP MII (Manufacturing Integration and Intelligence), que permite extrair e agregar informações de diferentes sistemas. "As informações são apresentadas simultaneamente ou de forma combinada, gerando um terceiro dado que é mostrado no video wall", completa o diretor da área de manufatura da Neoris, Jorge Mottecy.
A cadeia produtiva da Usiminas tem 55 processos, controlados por 180 pontos mostrados no videowall, que são locais onde ocorrem eventos de produção ou transporte, por exemplo. Cada ponto pode ser visto com até quatro níveis de detalhe, garantindo que a análise da informação chegue até o nível da planta. A atualização das informações ocorre, em média, a cada minuto, segundo Mottecy.
"Nossa proposição foi juntar funções e pessoas em lugar único, tendo o video wall como um site de informações e alertas onde cada profissional pode olhar não só um processo específico, mas a cadeia produtiva como um todo. Às vezes a decisão sobre um processo pode ser boa isoladamente, mas pode prejudicar o processo da frente", observa Zenóbio.
O gerente da Usiminas diz que a solução ainda está na fase de adatapção cultural dos profissionais, devido à mudança de processos que trouxe para a empresa. Mas Zenóbio avalia que já é possível notar que a informação entre as áreas de estratégia, produção e operação está muito mais convergente, o que faz com que todos os envolvidos entendam porque determinada ação foi tomada e qual efeito ela teve sobre toda a cadeia produtiva. "Estamos falando muito mais a mesma língua", ressalta.
O executivo não quis revelar o valor investido no projeto e tampouco os resultados quantitativos que a Usiminas espera alcançar com a adoção do video wall. Mas um dos objetivos da empresa á maximizar o tempo de entrega do produto para os clientes, além de reduzir a variabilidade do prazo de entrega de cada etapa do processo produtivo. Zenóbio espera alcançar essas metas em seis meses e prevê que o retorno sobre o investimento será atingido em um ano e meio.
Por Redação da Computerworld
23 de dezembro de 2009 - 15h00
A empresa siderúrgica Usiminas precisava otimizar as etapas de produção de sua fábrica em Ipatinga (MG). A solução escolhida foi criar um centro integrado de operação que reúne profissionais de cada etapa do processo de produção e conta com um video wall onde são apresentadas, em tempo real, informações da cadeia produtiva.
O projeto, realizado pela consultoria de tecnologia Neoris, levou dois anos para ser concluído e sua implantação foi finalizada em outubro. Com a solução, os 23 profissionais que trabalham no centro de operação em cada um dos três turnos podem modificar procedimentos em cada etapa para garantir melhores resultados à produção como um todo.
"Ipatinga é uma planta siderúrgica integrada. Somos uma usina em série, temos interdependência de processos, por isso necessidade de sincronismo entre eles", explica o gerente de programação e controle de produção da planta, Leonardo Zenóbio.
O video wall com 12 metros de largura e 2,5 metros de extensão é formado por 14 cubos que formam uma imagem completa. O conceito do projeto é apresentar as informações visualmente, por meio do uso de diferentes cores, de forma que elas sejam facilmente identificadas pelos profissionais que monitoram os processos.
Os dados mostrados no video wall são obtidos graças à integração com sistemas legados da Usiminas (chamados Manufacture Execution Systems - MES -, ou sistemas de execução de manufatura), com o ERP da SAP usado pela empresa siderúrgica, com imagens de 32 câmeras de vídeo instaladas em toda a fábrica e com o sistema de mapa georeferenciado do pátio da fábrica.
A aplicação baseia-se na ferramenta SAP MII (Manufacturing Integration and Intelligence), que permite extrair e agregar informações de diferentes sistemas. "As informações são apresentadas simultaneamente ou de forma combinada, gerando um terceiro dado que é mostrado no video wall", completa o diretor da área de manufatura da Neoris, Jorge Mottecy.
A cadeia produtiva da Usiminas tem 55 processos, controlados por 180 pontos mostrados no videowall, que são locais onde ocorrem eventos de produção ou transporte, por exemplo. Cada ponto pode ser visto com até quatro níveis de detalhe, garantindo que a análise da informação chegue até o nível da planta. A atualização das informações ocorre, em média, a cada minuto, segundo Mottecy.
"Nossa proposição foi juntar funções e pessoas em lugar único, tendo o video wall como um site de informações e alertas onde cada profissional pode olhar não só um processo específico, mas a cadeia produtiva como um todo. Às vezes a decisão sobre um processo pode ser boa isoladamente, mas pode prejudicar o processo da frente", observa Zenóbio.
O gerente da Usiminas diz que a solução ainda está na fase de adatapção cultural dos profissionais, devido à mudança de processos que trouxe para a empresa. Mas Zenóbio avalia que já é possível notar que a informação entre as áreas de estratégia, produção e operação está muito mais convergente, o que faz com que todos os envolvidos entendam porque determinada ação foi tomada e qual efeito ela teve sobre toda a cadeia produtiva. "Estamos falando muito mais a mesma língua", ressalta.
O executivo não quis revelar o valor investido no projeto e tampouco os resultados quantitativos que a Usiminas espera alcançar com a adoção do video wall. Mas um dos objetivos da empresa á maximizar o tempo de entrega do produto para os clientes, além de reduzir a variabilidade do prazo de entrega de cada etapa do processo produtivo. Zenóbio espera alcançar essas metas em seis meses e prevê que o retorno sobre o investimento será atingido em um ano e meio.
Por que os projetos de ERP fracassam
Especialistas apontam os principais erros cometidos pelas empresas em implantações de sistemas de gestão
Por Rodrigo Caetano, da Computerworld
19 de agosto de 2009 - 07h00
Grandes projetos, grandes problemas. Não importa a metodologia utilizada, a ferramenta escolhida e o tamanho da equipe. É comum, até demais, que implementações de sistemas de gestão (ERP) fracassem. Prazos são estourados, orçamentos vão muito além do limite e os resultados não correspondem às expectativas das áreas de negócios.
Mesmo projetos bem sucedidos enfrentam problemas no seu decorrer. Sejam eles motivados pela cultura da empresa, por mau planejamento ou briga de egos, os percalços acabam custando caro para as companhias. Afinal, no mundo dos negócios, tempo é dinheiro e sistema que não funciona é igual a processos que não funcionam.
Segundo a consultoria Gartner, a segunda maior prioridade dos executivos de tecnologias para este ano é implementar ou atualizar o sistema de gestão. A vice-presidente de pesquisas da empresa, Ione Coco, afirma que o cenário não deve mudar, pelo menos, até 2012. O que leva a uma reflexão: apesar de tão importantes, por que os projetos de ERP fracassam?
Apontar uma razão principal é difícil, mas, segundo especialistas, existem alguns fatores comuns encontrados nas empresas que, fatalmente, levam ao mau resultado. O primeiro não tem nada a ver com questões técnicas, mas sim com a cultura das organizações. Segundo Ione, as empresas, e principalmente os departamentos de TI, precisam saber o que esperar de um projeto. Estimativas altas demais, ou mesmo com foco errado, comprometem todo o trabalho, não importa se foi bem feito.
Para o sócio da consultoria Mondo Strategies, especializada em gestão integrada de software, Ernani Ferrari, o problema das estimativas ainda vai além do resultado. As empresas têm dificuldades para prever a quantidade de tempo e recursos necessários para a conclusão do projeto. Como conseqüência, tendem a acelerar uma das pontas do processo, pulando etapas e cortando custos, prejudicando as demais.
Em apresentação feita durante evento promovido pela Associação de Usuários SAP do Brasil (Asug), entidade que reúne clientes da fornecedora alemã de sistemas de gestão, o diretor do capítulo São Paulo do Project Management Institute (PMI), Paulo Moraes, apontou alguns pontos que fazem a diferença na hora de iniciar um projeto. O PMI é uma associação sem fins lucrativos que desenvolve estudos sobre o gerenciamento de projetos. Área onde, geralmente, começam os problemas.
Confira as dicas do executivo:
- Falta de uma camada de gerenciamento de projetos: no mínimo, a empresas precisa conhecer as melhores práticas de gerenciamento descritas no PMBOK, principal publicação feita pelo PMI. Mas, qualquer metodologia serve, desde que esteja presente.
- Falha no planejamento do projeto: essa talvez seja a fase mais crítica de um projeto. Segundo Moraes, as empresas não pode ter preguiça de escrever, fazer diagramas, relatórios, etc.
- Processos críticos de negócios mal definidos: quase uma conseqüência do mau planejamento. Fatalmente, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto.
- Falha em detalhar os processos nas pontas: caso a empresa não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente fará algo inútil ou complicado demais.
- Falta de envolvimento do pessoal das pontas: Moraes conta uma história curiosa. Determinada empresa, após implementar um novo ERP, começou a ter problemas com a qualidade dos dados. Após meses de investigação, descobriu que os operadores de empilhadeira, responsáveis pela coleta dos dados nos armazéns da companhia, não conseguiam digitar corretamente nos computadores de mão por usarem luvas. Este pequeno detalhe acabava comprometendo todo o processo.
- Falha em preparar o sistema para agüentar os picos de utilização: nenhum sistema é utilizado com a mesma freqüência o tempo inteiro. É preciso saber o quanto ele agüenta e quanto terá de agüentar, quando for exigido em carga máxima.
- Evangelizar os patrocinadores do projeto: tudo tem de estar escrito. “Se não está explicitamente indicado, está implicitamente excluído”, afirma Moraes. Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais.
- Iniciar a implantação antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados.
- Estouro do escopo: estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado. Por isso é fundamental ter um sistema bem definido de gerenciamento de mudanças.
- Grandes modificações de software padrão: um sistema SAP, segundo Moraes, faz muita coisa. Antes de modificar o software, certifique-se, realmente, que isso é necessário.
- Falhas de testes: de 20% a 40% do tempo total de projeto deve estar reservado para os testes. E eles só são válidos se forem devidamente documentados.
- Falta de treinamento: é um erro reduzir o custo do projeto cortando o treinamento. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários.
- Falhas ao carregar os dados no sistema: um sistema ERP gera mudanças culturais na empresa. Muitas vezes, os funcionários estão acostumados a usar diversos sistemas legados, cada um referente a uma determinada época. Por isso é preciso definir o alcance do novo sistema. Falta de dados também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, não significa, necessariamente, que ela exista.
- Falha no “cut over”: a data de inauguração do novo sistema, e desligamento de antigo, deve estar definida e o processo planejado. É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto.
- Falhas após o “go live”: depois de estar tudo funcionando, não é difícil se deparar com um time de suporte mal dimensionado. Outros problemas são a falta de documentação e falhas no entendimento das responsabilidades dos envolvidos.
- Deixar os testes para depois do “go live”: testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta dará dor de cabeça, com absoluta certeza.
Por Rodrigo Caetano, da Computerworld
19 de agosto de 2009 - 07h00
Grandes projetos, grandes problemas. Não importa a metodologia utilizada, a ferramenta escolhida e o tamanho da equipe. É comum, até demais, que implementações de sistemas de gestão (ERP) fracassem. Prazos são estourados, orçamentos vão muito além do limite e os resultados não correspondem às expectativas das áreas de negócios.
Mesmo projetos bem sucedidos enfrentam problemas no seu decorrer. Sejam eles motivados pela cultura da empresa, por mau planejamento ou briga de egos, os percalços acabam custando caro para as companhias. Afinal, no mundo dos negócios, tempo é dinheiro e sistema que não funciona é igual a processos que não funcionam.
Segundo a consultoria Gartner, a segunda maior prioridade dos executivos de tecnologias para este ano é implementar ou atualizar o sistema de gestão. A vice-presidente de pesquisas da empresa, Ione Coco, afirma que o cenário não deve mudar, pelo menos, até 2012. O que leva a uma reflexão: apesar de tão importantes, por que os projetos de ERP fracassam?
Apontar uma razão principal é difícil, mas, segundo especialistas, existem alguns fatores comuns encontrados nas empresas que, fatalmente, levam ao mau resultado. O primeiro não tem nada a ver com questões técnicas, mas sim com a cultura das organizações. Segundo Ione, as empresas, e principalmente os departamentos de TI, precisam saber o que esperar de um projeto. Estimativas altas demais, ou mesmo com foco errado, comprometem todo o trabalho, não importa se foi bem feito.
Para o sócio da consultoria Mondo Strategies, especializada em gestão integrada de software, Ernani Ferrari, o problema das estimativas ainda vai além do resultado. As empresas têm dificuldades para prever a quantidade de tempo e recursos necessários para a conclusão do projeto. Como conseqüência, tendem a acelerar uma das pontas do processo, pulando etapas e cortando custos, prejudicando as demais.
Em apresentação feita durante evento promovido pela Associação de Usuários SAP do Brasil (Asug), entidade que reúne clientes da fornecedora alemã de sistemas de gestão, o diretor do capítulo São Paulo do Project Management Institute (PMI), Paulo Moraes, apontou alguns pontos que fazem a diferença na hora de iniciar um projeto. O PMI é uma associação sem fins lucrativos que desenvolve estudos sobre o gerenciamento de projetos. Área onde, geralmente, começam os problemas.
Confira as dicas do executivo:
- Falta de uma camada de gerenciamento de projetos: no mínimo, a empresas precisa conhecer as melhores práticas de gerenciamento descritas no PMBOK, principal publicação feita pelo PMI. Mas, qualquer metodologia serve, desde que esteja presente.
- Falha no planejamento do projeto: essa talvez seja a fase mais crítica de um projeto. Segundo Moraes, as empresas não pode ter preguiça de escrever, fazer diagramas, relatórios, etc.
- Processos críticos de negócios mal definidos: quase uma conseqüência do mau planejamento. Fatalmente, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto.
- Falha em detalhar os processos nas pontas: caso a empresa não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente fará algo inútil ou complicado demais.
- Falta de envolvimento do pessoal das pontas: Moraes conta uma história curiosa. Determinada empresa, após implementar um novo ERP, começou a ter problemas com a qualidade dos dados. Após meses de investigação, descobriu que os operadores de empilhadeira, responsáveis pela coleta dos dados nos armazéns da companhia, não conseguiam digitar corretamente nos computadores de mão por usarem luvas. Este pequeno detalhe acabava comprometendo todo o processo.
- Falha em preparar o sistema para agüentar os picos de utilização: nenhum sistema é utilizado com a mesma freqüência o tempo inteiro. É preciso saber o quanto ele agüenta e quanto terá de agüentar, quando for exigido em carga máxima.
- Evangelizar os patrocinadores do projeto: tudo tem de estar escrito. “Se não está explicitamente indicado, está implicitamente excluído”, afirma Moraes. Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais.
- Iniciar a implantação antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados.
- Estouro do escopo: estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado. Por isso é fundamental ter um sistema bem definido de gerenciamento de mudanças.
- Grandes modificações de software padrão: um sistema SAP, segundo Moraes, faz muita coisa. Antes de modificar o software, certifique-se, realmente, que isso é necessário.
- Falhas de testes: de 20% a 40% do tempo total de projeto deve estar reservado para os testes. E eles só são válidos se forem devidamente documentados.
- Falta de treinamento: é um erro reduzir o custo do projeto cortando o treinamento. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários.
- Falhas ao carregar os dados no sistema: um sistema ERP gera mudanças culturais na empresa. Muitas vezes, os funcionários estão acostumados a usar diversos sistemas legados, cada um referente a uma determinada época. Por isso é preciso definir o alcance do novo sistema. Falta de dados também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, não significa, necessariamente, que ela exista.
- Falha no “cut over”: a data de inauguração do novo sistema, e desligamento de antigo, deve estar definida e o processo planejado. É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto.
- Falhas após o “go live”: depois de estar tudo funcionando, não é difícil se deparar com um time de suporte mal dimensionado. Outros problemas são a falta de documentação e falhas no entendimento das responsabilidades dos envolvidos.
- Deixar os testes para depois do “go live”: testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta dará dor de cabeça, com absoluta certeza.
quinta-feira, 17 de dezembro de 2009
Sped entra em nova fase em 2010
A partir do próximo ano, todas empresas tributadas pelo lucro real terão de entregar ao fisco livros fiscais no formato digital para cruzamento das informações.
Por Edileuza Soares, da Computerword
17 de dezembro de 2009 - 07h15
O Sistema Público de Escrituração Digital (Sped), criado pelo governo brasileiro para combater a sonegação fiscal e tornar o relacionamento com o fisco mais eficiente, entra em nova fase no próximo ano. A previsão é que até o final de 2010, todas as empresas sujeitas à tributação do Imposto de Renda com base no lucro real deverão substituir os livros fiscais em papel pelo modelo eletrônico.
As estimativas de especialistas são de que aproximadamente 120 mil companhias de diversos segmentos tenham que se adaptar ao sistema digital. Elas precisarão enviar mensalmente para o fisco apurações fiscais e as informações contábeis do ano. Os cronogramas estão sendo liberados pelos Estados com enquadramento de empresas que recolhem ICMS e IPI.
Criado pelo decreto 6.022 de janeiro de 2007, o Sped faz parte do Programa de Aceleração do Crescimento (PAC 2007-2010) para informatização da relação entre o fisco e os contribuintes. Pelo sistema, a fiscalização das obrigações acessórias passa a ser feita de forma eletrônica e em tempo real.
O sistema é composto por três grandes subprojetos: Escrituração Contábil Digital (Sped Contábil), Escrituração Fiscal Digital Fiscal (Sped Fiscal) que substituem os livros Diário e Razão; e Nota Fiscal Eletrônica (NF-e). Com o acompanhamento desses três em tempo real, o Fisco tem como consolidar dados e cruzar informações sobre a arrecadação tributária.
Para que as empresas tenham tempo de se enquadrar no novo modelo, o governo estabeleceu um cronograma. A primeira fase começou este ano com um número restrito de 8 mil companhias de grande porte acompanhadas pela Receita Federal. Primeiro elas entregaram em 30 de junho o SPED Contábil com arquivos referentes ao exercício de 2008. Em 30 de setembro, apresentaram o Sped Fiscal com informações da apuração dos impostos do período de janeiro a agosto de 2009.
“As estimativas são de que 120 mil empresas sejam obrigadas a aderir ao SPED em 2010”, afirma o diretor-geral da empresa NFe do Brasil, Marco Antonio Zanini. A companhia é especializada em soluções para esta área. Entre este número, o especialista afirma que há pequenos e médios negócios. Pelo menos outras 500 mil de diversos setores também terão de emitir a NF-e.
Integração
Esse grande contingente vai exigir um esforço maior dos contadores e das áreas de TI, que precisarão preparar suas bases de dados para a emissão dos livros digitais que terão de ser apurados a partir de janeiro de 2010. Haverá a necessidade de integração e interligação de todos os setores dentro da empresa, de ajustes dos processos internos para implantar o novo modelo de gestão.
Os que usam sistemas de gestão empresarial (ERPs) precisarão recorrer aos fornecedores para adequá-los às novas exigências ou pedir ajuda para uma consultoria. Todos precisarão investir em certificados digitais, que é uma exigência do Fisco tanto para envio NF-e quanto do Sped.
Na Totvs, o vice-presidente da área de gestão de desenvolvimento de software, Wilson de Godoy, afirma que a empresa reforçou o time para dar suporte aos clientes que vão aderir ao Sped. Sua estimativa é que dos 24 mil clientes da companhia, pelo menos 8 mil terão de apresentar os livros digitais até o final de 2010.
Segundo o executivo, os pacotes de ERP do grupo já estão preparados com os componentes para atender ao novo modelo, desde que os usuários façam a atualização sem custos. A empresa montou uma equipe com 40 pessoas para atender tanto aos que precisarão entregar livros fiscais digitais quanto os que vão emitir pela primeira vez a NF-e.
Além de oferecer soluções para os dois casos integradas ao ERP da marca, Godoy informa que a Totvs tem um modelo terceirização. Entretanto, o executivo recomenda que as empresas comecem a se preparar para as mudanças com antecedência. Segundo ele, a primeira vez vai doer por causa do trabalho que as companhias terão para preparar as bases de dados.
Zanini da NFe Brasil, destaca que as informações que serão enviadas ao Fisco são muito abrangentes e que precisam ser consistentes. Ele explica que é preciso ter NF-e para depois ir para o Sped. "É incoerente ter nota em papel com livros fiscais digitais".
Por Edileuza Soares, da Computerword
17 de dezembro de 2009 - 07h15
O Sistema Público de Escrituração Digital (Sped), criado pelo governo brasileiro para combater a sonegação fiscal e tornar o relacionamento com o fisco mais eficiente, entra em nova fase no próximo ano. A previsão é que até o final de 2010, todas as empresas sujeitas à tributação do Imposto de Renda com base no lucro real deverão substituir os livros fiscais em papel pelo modelo eletrônico.
As estimativas de especialistas são de que aproximadamente 120 mil companhias de diversos segmentos tenham que se adaptar ao sistema digital. Elas precisarão enviar mensalmente para o fisco apurações fiscais e as informações contábeis do ano. Os cronogramas estão sendo liberados pelos Estados com enquadramento de empresas que recolhem ICMS e IPI.
Criado pelo decreto 6.022 de janeiro de 2007, o Sped faz parte do Programa de Aceleração do Crescimento (PAC 2007-2010) para informatização da relação entre o fisco e os contribuintes. Pelo sistema, a fiscalização das obrigações acessórias passa a ser feita de forma eletrônica e em tempo real.
O sistema é composto por três grandes subprojetos: Escrituração Contábil Digital (Sped Contábil), Escrituração Fiscal Digital Fiscal (Sped Fiscal) que substituem os livros Diário e Razão; e Nota Fiscal Eletrônica (NF-e). Com o acompanhamento desses três em tempo real, o Fisco tem como consolidar dados e cruzar informações sobre a arrecadação tributária.
Para que as empresas tenham tempo de se enquadrar no novo modelo, o governo estabeleceu um cronograma. A primeira fase começou este ano com um número restrito de 8 mil companhias de grande porte acompanhadas pela Receita Federal. Primeiro elas entregaram em 30 de junho o SPED Contábil com arquivos referentes ao exercício de 2008. Em 30 de setembro, apresentaram o Sped Fiscal com informações da apuração dos impostos do período de janeiro a agosto de 2009.
“As estimativas são de que 120 mil empresas sejam obrigadas a aderir ao SPED em 2010”, afirma o diretor-geral da empresa NFe do Brasil, Marco Antonio Zanini. A companhia é especializada em soluções para esta área. Entre este número, o especialista afirma que há pequenos e médios negócios. Pelo menos outras 500 mil de diversos setores também terão de emitir a NF-e.
Integração
Esse grande contingente vai exigir um esforço maior dos contadores e das áreas de TI, que precisarão preparar suas bases de dados para a emissão dos livros digitais que terão de ser apurados a partir de janeiro de 2010. Haverá a necessidade de integração e interligação de todos os setores dentro da empresa, de ajustes dos processos internos para implantar o novo modelo de gestão.
Os que usam sistemas de gestão empresarial (ERPs) precisarão recorrer aos fornecedores para adequá-los às novas exigências ou pedir ajuda para uma consultoria. Todos precisarão investir em certificados digitais, que é uma exigência do Fisco tanto para envio NF-e quanto do Sped.
Na Totvs, o vice-presidente da área de gestão de desenvolvimento de software, Wilson de Godoy, afirma que a empresa reforçou o time para dar suporte aos clientes que vão aderir ao Sped. Sua estimativa é que dos 24 mil clientes da companhia, pelo menos 8 mil terão de apresentar os livros digitais até o final de 2010.
Segundo o executivo, os pacotes de ERP do grupo já estão preparados com os componentes para atender ao novo modelo, desde que os usuários façam a atualização sem custos. A empresa montou uma equipe com 40 pessoas para atender tanto aos que precisarão entregar livros fiscais digitais quanto os que vão emitir pela primeira vez a NF-e.
Além de oferecer soluções para os dois casos integradas ao ERP da marca, Godoy informa que a Totvs tem um modelo terceirização. Entretanto, o executivo recomenda que as empresas comecem a se preparar para as mudanças com antecedência. Segundo ele, a primeira vez vai doer por causa do trabalho que as companhias terão para preparar as bases de dados.
Zanini da NFe Brasil, destaca que as informações que serão enviadas ao Fisco são muito abrangentes e que precisam ser consistentes. Ele explica que é preciso ter NF-e para depois ir para o Sped. "É incoerente ter nota em papel com livros fiscais digitais".
terça-feira, 15 de dezembro de 2009
Café com ERP: Navegar é preciso, viver não é preciso
Certamente
quando Fernando Pessoa escreveu o poema Navegar é Preciso, ele não imaginava
que alguém em algum dia iria usá-lo para falar sobre ERP.
Navegabilidade
é uma característica que está a cada dia sendo melhor explorada no
desenvolvimento e na seleção de ERP... ninguém aceita mais ter que trafegar
obrigatoriamente por incontáveis telas para fazer uma determinada ação, não ter
como captar informações de referência (você se lembra daqueles momentos em que
se tinha que anotar num papel um código para usá-lo depois... argh!!!), não ter
como procurar em detalhes informações a partir de outras, e assim por diante.
Telas
simples, botões configuráveis de atalho, menus
configuráveis e captação de informações, são obrigações de todos os sistemas
atuais... e se tiver meios de imersão nos dados (drill-down) em todos os
pontos, vinculação direta com aplicações externas e navegação por workflow você
terá conseguido um plus considerável.
Lembre-se de
uma coisa: no Brasil temos quase 400 fornecedores de ERP nos mais variados
níveis de solução.... ainda existe muito a evoluir.
Boa
navegabilidade significa produtividade do seu pessoal, redução de riscos e
facilidade no processo de aprendizagem.
Todos esses fatores são importantes na implantação do sistema e na
evolução a longo prazo das operações.
Como avaliar
a navegabilidade do ERP?
a) Verifique
quais recursos ele tem: teclas de atalho (personalizadas ou não), menus configuráveis, etc.
b) Teste
operações complexas e verifique o grau de dificuldade.
c) Teste as
operações de maiores repetições (vendas, faturamento, contas a pagar/receber,
etc.) e veja a velocidade obtida.
d) Solicite
apresentações de processos e no meio do caminho peça outras informações e
verifique como é o processo para retornar ao ponto de mudança.
e) Teste como
se aprofunda a busca por uma informação.
Ex.: na tela de tesouraria apresenta uma conta bancária negativa, no
detalhe você acessa a todas as movimentações da conta, no detalhamento verifica
uma movimentação específica de pagamento, no detalhe verifique que aquele
pagamento está vinculado a uma ordem de compra.... e depois consegue voltar
facilmente ao ponto de origem.
Navegabilidade
= Produtividade de Uso.... e navegar tem que ser preciso!
Abraços;
Mauro Cesar
Análise: SAP não encontrará uma solução rápida para a saga KPI
Grupos de usuários da empresa querem mais provas de que o serviço Enterprise Support, que implica custos adicionais, tem benefícios reais.
Por IDG News Service
04 de dezembro de 2009 - 13h31
As tentativas da SAP de convencer os usuários de que a elevação dos preços no suporte corporativo (Enterprise Support) justifica-se podem se arrastar mais do que a companhia esperava.
A iniciativa de criar conjunto de indicadores (KPIs) surgiu após protestos dos usuários, que resistiram ao aumento de custos imposto pelo serviço lançado em 2008.
O projeto KPI, no entanto, sofreu uma instabilidade pública recentemente com a desistência do líder do projeto e membro do grupo alemão de usuários (DSAG), Andreas Oczko. O projeto também perdeu o importante apoio do membro do DSAG Otto Schell.
Apesar disso, a SAP declarou que tem resultados positivos para anunciar sobre o projeto KPI e o resultado do suporte para os usuários.Mas a questão principal é se todos os usuários vão se beneficiar com a mudança.
Em entrevista nesta quinta-feira (4/12) Oczko e Schell disseram que não estão convencidos de que os resultados iniciais do KPI eram concretos e compreensivos o suficiente para provar que o Enterprise Support é útil para a base geral de consumidores da Base, contra as 100 companhias que participam do projeto.
Esforços de testes sempre apresentam “um grande desafio”, e tentar completar a tarefa desde a estaca zero em tão pouco tempo requer um grande compromisso, afirmou Oczko.
A Rede Executiva de Grupos de Usuários da SAP (SUGEN) pretende realizar uma reunião em Boston na próxima semana para discutir as “lições aprendidas” no processo inicial e determinar quem continuará a liderança do projeto, afirmou Schell.
O DSAG continua “muito interessado”, apoia o programa KPI em geral, mas quer “resultados a prova de balas”, completou Schell.
Dos 100 clientes partipantes do projeto KPI, 45 estão na Europa, Oriente Médio e África, 32 estão nas Américas e 23 estão na Ásia.
Os grupos de usuários podem se convencer dos benefícios do Enterprise Support se tiverem resultados da posição da SAP durante um ano, segundo o parceiro da empresa de análises Altimeter Group, Ray Wang. “O programa KPI é uma grande ideia, mas difícil de implementar”.
Por IDG News Service
04 de dezembro de 2009 - 13h31
As tentativas da SAP de convencer os usuários de que a elevação dos preços no suporte corporativo (Enterprise Support) justifica-se podem se arrastar mais do que a companhia esperava.
A iniciativa de criar conjunto de indicadores (KPIs) surgiu após protestos dos usuários, que resistiram ao aumento de custos imposto pelo serviço lançado em 2008.
O projeto KPI, no entanto, sofreu uma instabilidade pública recentemente com a desistência do líder do projeto e membro do grupo alemão de usuários (DSAG), Andreas Oczko. O projeto também perdeu o importante apoio do membro do DSAG Otto Schell.
Apesar disso, a SAP declarou que tem resultados positivos para anunciar sobre o projeto KPI e o resultado do suporte para os usuários.Mas a questão principal é se todos os usuários vão se beneficiar com a mudança.
Em entrevista nesta quinta-feira (4/12) Oczko e Schell disseram que não estão convencidos de que os resultados iniciais do KPI eram concretos e compreensivos o suficiente para provar que o Enterprise Support é útil para a base geral de consumidores da Base, contra as 100 companhias que participam do projeto.
Esforços de testes sempre apresentam “um grande desafio”, e tentar completar a tarefa desde a estaca zero em tão pouco tempo requer um grande compromisso, afirmou Oczko.
A Rede Executiva de Grupos de Usuários da SAP (SUGEN) pretende realizar uma reunião em Boston na próxima semana para discutir as “lições aprendidas” no processo inicial e determinar quem continuará a liderança do projeto, afirmou Schell.
O DSAG continua “muito interessado”, apoia o programa KPI em geral, mas quer “resultados a prova de balas”, completou Schell.
Dos 100 clientes partipantes do projeto KPI, 45 estão na Europa, Oriente Médio e África, 32 estão nas Américas e 23 estão na Ásia.
Os grupos de usuários podem se convencer dos benefícios do Enterprise Support se tiverem resultados da posição da SAP durante um ano, segundo o parceiro da empresa de análises Altimeter Group, Ray Wang. “O programa KPI é uma grande ideia, mas difícil de implementar”.
ENQUETE: A sua empresa tem um ERP?
RESULTADO:
Não, e não estamos procurando: 5
Não, e estamos procurando: 1
Sim, mas queremos trocar: 1
Sim, estamos começando a implantação: 0
Sim, estamos no meio da implantação: 1
Sim, terminamos a implantação: 1
COMENTÁRIOS:
Apesar do pequeno número de participantes, achei interessante a distribuição do resultado onde a maioria se posicionou como não tendo um ERP e não estão procurando.
Isso demosntra apenas que as pessoas não sabem o quanto de benefício um ERP trás para uma empresa e/ou imaginam que não tem condições financeiras para promover tal investimento...sem saber que isso, hoje em dia, está muito viável.
Abraços;
Mauro Cesar
mauro.oliveira@vilelaleite.com.br
segunda-feira, 7 de dezembro de 2009
Café com ERP: Seu ERP Não Precisa Sofrer de Solidão
ERP tem
sentimentos? Não, ainda não chegamos a esse ponto. O que quero passar nessa
nota é que estamos numa época onde a complexidade e os graus de interação
exigem que os nossos sistemas “conversem” constantemente e de forma natural.
Bancos,
Receita Federal, órgãos de fiscalização, clientes, parceiros, fornecedores e
associações estão muito presentes no nosso cotidiano e o que vemos no mercado é
um desnível grande nesse processo de comunicação.... isso não ocorre por causas
técnicas e sim gerenciais.
Falta de
atitude, falta de conhecimento quanto às possibilidades, falta de meios para
buscar as melhorias e evoluções necessárias, falta de visão... falta de
entendimento da verdadeira importância do ERP nos negócios.
Seja o motivo
que for que o fez até esse momento não providenciar as integrações externas do
seu ERP que possam promover verdadeiras ações de redução de riscos e aumento da
produtividade, ele passou a não existir... Diga NÂO a Solidão do Seu ERP e tome
uma ação agora!!!
Bons exemplos
de integrações são: franquias de lojas (master
e franqueados), CNAB bancário, EDI mercantil/logístico, coleta instantânea de
informações jurídicas com os tribunais/D.O.U., rede de concessionárias e de
assistência técnica, redes de representações comerciais, portais de serviços de
turismo, etc.
Levante a sua
situação atual de integração com agentes externos, defina quais são as
integrações que vão te trazer benefícios, converse com a sua área de TI para
ver como pode ser feito isso... detalhe, não aceite nada complexo e nem
mirabolante. O simples é a regra... e tire do caminho tudo que possa atrapalhar
essas ações.
ERP sem solidão
é um ERP mais produtivo....passe a mensagem.
Abraços;Mauro Cesar
Mauro.oliveira@vilelaleite.com.br
quinta-feira, 3 de dezembro de 2009
Café com ERP: Erosão de Uso: Doença Fatal dos ERP
A história é
mais ou menos essa... a empresa se esforça e tenta contratar um pacote de
produtos e serviços de ERP compatível com as suas necessidades e orçamento,
todos (cliente, colaboradores e fornecedores) se unem pra implantar o sistema
da melhor forma possível, pouco a pouco a implantação vai ocorrendo, uma parte
melhor que a outra, mas sempre em frente e depois de um determinado tempo
(quase sempre posterior ao que foi planejado, diga-se de passagem) o ERP é
considerado implantado... ufa! Conseguimos... e todos relaxam.
Justamente
nesse ponto é que começa um grande problema!!!
As pessoas
começam a dar “jeitinhos” para burlar as regras do sistema, pessoas mudam e não
são treinadas, o sistema muda e as pessoas não se adaptam, as pressões do
dia-a-dia conduzem as pessoas a trabalharem de outras formas... formas essas
que não são do interesse maior da empresa, e num dado momento, vemos muito mais
atividades sendo feitas em planilhas eletrônicas e em formulários de papel do
que no ERP em si.... nesse caso dizemos que o ERP sofreu uma erosão.
Como quase
todos os problemas da vida as suas causas são várias e os seus impactos também.
Como causas
podemos destacar a cultura do “jeitinho”, que muitas das vezes é até
incentivada de forma direta ou indireta pela Direção da empresa; o não
entendimento dos impactos dos processos, a falta de conhecimento das
funcionalidades do ERP e a vulnerabilidade dos ERP para a realização de
“jeitinhos não autorizados”, que é uma classe diferente dos ”jeitinhos”, cuja
autorização existe.
Já as suas
consequências as vemos de forma confusa e não associativa a erosão, mas as
percebemos no dia-a-dia.... As informações não rotineiras ficam mais difíceis
de serem encontradas, muitos problemas de qualidade nas informações, aumento
nas falhas dos processos, perda de produtividade global dos colaboradores e
redução na capacidade de uso do ERP nas análises e nas tomadas de decisões.
A erosão,
como o próprio nome sugere, corrói aos poucos a estrutura social de utilização
do ERP, e devido ao seu movimento lento fica difícil perceber que estamos
passando por isso.... é como a história do sapo fervido lentamente.
Se você
conseguiu perceber que a erosão do ERP está tomando conta das suas operações,
ótimo.... você é um dos poucos que conseguiu enxergar isso, e posso te dizer
que a cura dessa “doença” é muito simples. Diga NÃO ao “Jeitinho”. Diga NÂO a
tudo que for feito fora do ERP e que ele tem condições de te atender.
Esse problema
se resolve com atitude, esse problema se resolve com vontade e se o remédio for
bem aplicado o paciente vai sair dessa sem sequelas.
Bem, a
receita já foi passada.... passar bem e nos voltamos a falar na próxima
consulta.... quero dizer, na próxima postagem.
Abraços;
Mauro Cesar
Mauro.oliveira@vilelaleite.com.br
Assinar:
Postagens (Atom)
