
Informatização Empresarial: Reengenharia e ERP
Cerca de uma década atrás, no caso de você ter esquecido, enfrentamos turbulências econômicas. Muitas pessoas foram demitidas e as empresas foram acometidas de um desejo ardente de cortar custos. Na ocasião, Michael Hammer e eu escrevemos nossos respectivos artigos sobre reengenharia. Meu erro foi procurar a respeitabilidade acadêmica, que tende a limitar a audiência. Não era minha intenção cunhar um nome mais respeitável para corte de cabeças e nem acredito que fosse a de Hammer. De qualquer forma, foi o que aconteceu.
A palavra reengenharia se tornou um código para demissões. Certamente houve empresas que fizeram reengenharia mais ou menos da maneira certa, com um foco em grandes processos multifunções e mudança radical. Mas até estas corporações tiveram problemas, e por algumas razões. Para começar, expectativas desproporcionais. As companhias acreditavam (ou foram levadas a acreditar) que era possível aplicar reengenharia com êxito a um processo importante em um ano. Elas acabaram descobrindo que, embora fosse possível projetar um novo processo revolucionário em pouco tempo, implementá-lo – gerar a mudança organizacional, as novas habilidades e assim por diante – levava alguns anos.
Os sistemas de informação eram outro problema. Programas multifunções abrangentes afastavam-se muito das arquiteturas de tecnologia da informação encontradas com mais freqüência nas organizações. Os sistemas de gestão empresariais (ERP) não estavam amadurecidos no início da reengenharia e as empresas tinham que desenvolver seus próprios programas ou juntar pacotes. Depois, quando se tornaram amplamente disponíveis, gerentes em corporações perceberam que tinham um importante papel a desempenhar em reengenharia. Ainda assim, como os software eram difíceis de modificar (e muitas empresas queriam prevenir problemas do ano 2000), processos que sofreram reengenharia customizada se tornaram rapidamente processos genéricos padrões da indústria.
Cerca de uma década atrás, no caso de você ter esquecido, enfrentamos turbulências econômicas. Muitas pessoas foram demitidas e as empresas foram acometidas de um desejo ardente de cortar custos. Na ocasião, Michael Hammer e eu escrevemos nossos respectivos artigos sobre reengenharia. Meu erro foi procurar a respeitabilidade acadêmica, que tende a limitar a audiência. Não era minha intenção cunhar um nome mais respeitável para corte de cabeças e nem acredito que fosse a de Hammer. De qualquer forma, foi o que aconteceu.
A palavra reengenharia se tornou um código para demissões. Certamente houve empresas que fizeram reengenharia mais ou menos da maneira certa, com um foco em grandes processos multifunções e mudança radical. Mas até estas corporações tiveram problemas, e por algumas razões. Para começar, expectativas desproporcionais. As companhias acreditavam (ou foram levadas a acreditar) que era possível aplicar reengenharia com êxito a um processo importante em um ano. Elas acabaram descobrindo que, embora fosse possível projetar um novo processo revolucionário em pouco tempo, implementá-lo – gerar a mudança organizacional, as novas habilidades e assim por diante – levava alguns anos.
Os sistemas de informação eram outro problema. Programas multifunções abrangentes afastavam-se muito das arquiteturas de tecnologia da informação encontradas com mais freqüência nas organizações. Os sistemas de gestão empresariais (ERP) não estavam amadurecidos no início da reengenharia e as empresas tinham que desenvolver seus próprios programas ou juntar pacotes. Depois, quando se tornaram amplamente disponíveis, gerentes em corporações perceberam que tinham um importante papel a desempenhar em reengenharia. Ainda assim, como os software eram difíceis de modificar (e muitas empresas queriam prevenir problemas do ano 2000), processos que sofreram reengenharia customizada se tornaram rapidamente processos genéricos padrões da indústria.



