Get best of the week

Modelando processos de negócios como parte de um projeto de implementação de sistema ERP

Antes de iniciar outro projeto para implementar um sistema de informação que cubra a maioria das áreas de funcionamento da empresa, decidi escrever uma série de artigos com meus pensamentos sobre a justificativa para o fato de que grandes empresas industriais, especialmente aquelas que operam há décadas, possuem mais da metade dos projetos de ERP " eles não decolam. " Escreverei esses artigos mais para mim como uma "esclerose" para formar conversas com os principais gerentes da empresa e estruturar as considerações que fiz com base em minha experiência.

Esses artigos não se destinam a dizer ao mundo o quão legal eu sou ou o que eu sei melhor sobre como implementar esses projetos. Se você disser que este é “outro artigo de um perdedor que, bem, entende tudo incorretamente”, também será um valor para mim, pois espero que alguém compartilhe suas opiniões nos comentários.

Existem muitos problemas na implementação de tais sistemas. Se você criar corretamente uma lista de verificação dos riscos do projeto de implementação do sistema ERP, serão necessárias mais de cem linhas e provavelmente se transformará em uma boa justificativa para o motivo pelo qual a implementação do sistema ERP nunca pode ser iniciada na vida. No entanto, existem projetos bem-sucedidos, a necessidade da introdução de tais sistemas também é repetidamente confirmada, o que significa que a introdução de tais sistemas não é uma tarefa impossível.

Para mim, divido todos os problemas que impedem a implementação bem-sucedida do projeto em três categorias:

  1. Político, causado pela incompatibilidade das metas declaradas do projeto com as expectativas internas dos participantes do projeto
  2. Funcional, causado pela falta de competências dos participantes do projeto
  3. Tecnológico, causado pela subestimação dos recursos necessários, tempo

Isso é bastante amplo e condicional, mas me ajuda pessoalmente ao classificar os riscos para formar uma avaliação da probabilidade de uma implementação bem-sucedida do sistema.

Não tenho experiência na implementação de grandes sistemas de produção usando o Agile ou qualquer outra metodologia além da "cascata" padrão, que inclui as seguintes etapas principais:

  1. Uma pesquisa da empresa, uma descrição dos processos de negócios "como está", "como será".
  2. Criando um modelo de sistema de informação.
  3. Desenvolvimento e implementação de TK.
  4. Teste a operação.
  5. Operação piloto.

Portanto, a descrição das tarefas e riscos que quero estruturar em minha cabeça está relacionada à metodologia em cascata e pode não ser totalmente aplicável às tecnologias para obter resultados rápidos.

Provavelmente seria mais conveniente começar com uma descrição das tarefas que devem ser concluídas antes do lançamento do projeto, como identificar um cliente funcional, reunir equipes de projeto, formar e avaliar critérios de sucesso do projeto.

Mas até agora não estruturei essas considerações e as coloquei em uma caixa separada.
Portanto, para ler o artigo a seguir, tomaremos isso como garantido: a necessidade de implementação é fixa, um cliente funcional é encontrado e está pegando fogo com o projeto, o orçamento é encontrado, as equipes de projeto são montadas corretamente, os recursos para implementação são identificados.

No primeiro artigo, gostaria de corrigir as tarefas e os riscos do projeto de modelagem de processos de negócios. Isso está longe de ser o problema mais crítico disponível no estágio inicial do projeto, mas desde que o estágio de inspeção da empresa começa com a modelagem dos processos de negócios "como estão" e "como deveriam ser", decidi começar com ele.

Então, eu vou começar.

É difícil imaginar que um dos proprietários ou gerentes de uma grande empresa industrial tenha adquirido um sistema ERP em prol da moda. De uma forma ou de outra, se você começou a falar sobre a aquisição de um sistema, a alta gerência está insatisfeita com os analistas existentes para tomar decisões, processos de negócios existentes, a velocidade e a qualidade das mudanças neles (não levamos em consideração a aquisição de um sistema ERP para lavagem de dinheiro ou política, fins de imagem).

Os processos de negócios sempre existem em uma empresa e não importa se estão documentados ou não. Além disso, em uma grande empresa industrial, é provável que os processos de negócios reais em uma parte substancial ou não coincidam completamente com os processos de negócios documentados. De uma forma ou de outra, a solicitação de remessa ainda chega ao depósito, os economistas ainda calculam as necessidades de produção e o mestre ainda gera uma tarefa diária em turnos em algum sistema, usando um lápis em um cartão perfurado ou “edra da mãe” verbal.

Outra questão é que esses processos de negócios estabelecidos não são ótimos, redundantes e, às vezes, também não têm valor para os negócios e para os participantes no processo de negócios. Como exemplo, esta é a formação de algum tipo de relatório de gestão, cuja nomeação todos já esqueceram, ninguém está analisando o conteúdo e a necessidade de criar esse relatório é discutida no nível de “Maria Ivanovna sempre pede para fazer isso, mas por que, Deus sabe, pergunte a ela dela. "

Obviamente, ninguém deseja arrastar esses processos de negócios não ideais para um sistema ERP. Em teoria, na fase de design do sistema, a alta gerência declara metas para otimizar os processos de negócios e sua regulamentação. E até assina a tese de "maximizar o modelo dos processos de negócios existentes da empresa sob a funcionalidade típica do sistema implementado".

Na prática, tudo parece muito mais deplorável. Executores comuns não estão prontos para alterar os processos de negócios, mesmo os mais elementares. Talvez essa seja minha prática malsucedida de trabalhar no baile. empresas, talvez essa seja uma tendência real, mas não espere que a frase "agora você não precise realizar uma ordem de despesa para aprovação em pés por 3 quilômetros, mas possa ser feita automaticamente no sistema em 3 segundos", você ficará satisfeito em responder. Um artista comum, cujo trabalho consistia em 60% do tempo que corre com documentos, decide imediatamente que ele será cortado, ele receberá trabalhos nos quais ele não pensa ou reduz seu salário. A lógica em suas considerações nem sempre está presente, mas o funcionário comum pode oferecer resistência às mudanças com bastante clareza. Além disso, como no estágio de coleta de requisitos para o sistema,quando ele provar o valor de apenas andar por aí com papéis (“E MikhalKuzmich, do departamento de orçamento da organização principal, disse que eles só aceitam uma digitalização de um documento com todas as assinaturas nossas”) e no estágio de operação do sistema, quando ele simplesmente imprime ordens do antigo sistema e use-os com os pés ("mas ninguém me disse que o novo sistema já está funcionando", "ah, sim, é mais rápido com os pés", "mas eu os enviei para esse sistema e ninguém respondeu lá")“Enviei para este seu sistema e ninguém respondeu lá”, etc.).“Enviei para este seu sistema e ninguém respondeu lá”, etc.).

Longe de estar sempre pronto para mudanças nos processos de negócios, nos gerentes de nível intermediário e até nos gerentes de topo. A alteração dos processos de negócios leva a uma alteração nas funções do pessoal subordinado e é capaz de identificar a falta de pessoal qualificado e a liberação de pessoal devido a uma redução nos custos de mão-de-obra para a execução de determinadas funções. Esse é um fator político oculto que pode influenciar bastante a tomada de decisões na mudança dos processos de negócios. No estágio inicial do design do sistema, ele pode ser percebido como insignificante e resolvido organizacionalmente no nível do proprietário do processo. Porém, na fase de teste ou operação industrial piloto com falta de potencial gerencial, a implementação de um processo de negócios pode até levar à sabotagem do trabalho do projeto pelos gerentes intermediários.A falta de recursos já pode ser detectada durante o OPE e afeta diretamente o curso da operação, e a indisponibilidade de subcarga ou qualificação do pessoal será ocultada pelo gerente sob o pretexto da complexidade de operar "este seu sistema" e levará a requisitos para alterar o novo sistema para processos de negócios existentes anteriormente.

Mesmo os proprietários de processos e a alta gerência podem não estar prontos para mudanças nos processos de negócios. As saídas principais de um processo de negócios são entradas para outro processo de negócios. E essa regra banal de modelagem de processos de negócios se encaixa bem no papel, mas encontra forte resistência na prática. As razões para a inconsistência dos processos de negócios nesse caso são de natureza política e a solução para essas inconsistências é bastante dolorosa.

Uma situação do livro quando um plano de vendas é aprovado na empresa isoladamente do plano de produção. E ao formar um plano de compras, nem um plano de vendas nem um plano de produção são levados em consideração. No estágio do fluxo de trabalho em papel, essas lacunas nos processos de negócios não são visíveis tão claramente, ou melhor, são visíveis, mas os proprietários do processo aprenderam a lidar com eles no nível operacional. Cada um dos líderes vai ao diretor para assinar seu plano sozinho. E ele faz uma análise dos fatos do plano exclusivamente de acordo com seu plano. Ao mesmo tempo, a integridade do quadro de vida da empresa é perdida, as quebras de analistas são reconhecidas como praticamente inevitáveis; o gerenciamento dos principais gerentes é realizado manualmente com base em dados irrelevantes e incompletos.

É necessário identificar essas contradições e lacunas nos processos de negócios o mais cedo possível e tomar sua decisão ao mais alto nível. O mapa estratégico ampliado dos processos de negócios “como será” deve ser percebido e apoiado pelos proprietários do processo como uma constituição. O sistema ERP introduzido não resolverá automaticamente essas contradições e inconsistências dos processos de negócios, não os enterrará, mas será muito mais caro trazê-los à superfície e resolver esses problemas durante a operação. E a fixação tardia das lacunas do processo de negócios muitas vezes leva à suspensão do projeto com todas as conseqüências ou à automação e desvio por partes dos objetivos do projeto.

O que pode ser feito para a mudança mais produtiva nos processos de negócios?


  1. - « » -, -. , , . , 8 , . - , . 10 .

    , - . , - - . - -. ( « , , »), , .
  2. - . - . , , . , , .
  3. - . -, . , -, . , . , -, , , « » . . , . , 10 - , , , .
  4. . ERP-, -. . - - . - , , .
  5. , ERP-, « ». , .
  6. KPI -. KPI , ..

Resumo: Eu acho que um projeto para implementar um sistema ERP terá uma chance muito maior de sucesso se todos os participantes do projeto compartilharem a tese de que o sistema de informação serve para automatizar os processos de negócios EXISTENTES, está pronto para estruturá-los, colocar informações nas prateleiras, prepare análises, mas, ao mesmo tempo, não substitui os cérebros dos executores e não será um salva-vidas se a própria gerência da empresa não estiver pronta para lidar com o caos existente.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles