• Nenhum resultado encontrado

Motivadores Clássicos:

No documento O Livro Do Analista de Processos (páginas 33-37)

1. O desejo de melhorar, mas falta o conhecimento.

Os Processos estão escondidos e camuflados nas atividades diárias dos colaboradores e da própria gestão. Praticamente todos os dias algum contorno é criado para que um pedido seja atendido, um relatório seja criado, um produto seja lançado etc. Este contorno, também conhecido popularmente como “jeitinho”, é feito em todos os níveis da organização, e para resolver praticamente todos os tipos de imprevistos. Além de tudo isso, a gerência luta contra a inconsistência nas informações recebidas.

Toda vez que é preciso gerar um relatório, uma correria é juntamente iniciada, culminando em algumas viradas de noite no trabalho, e um consequente sentimento de herói incompreendido por parte dos colaboradores. Afinal, se não fosse o esforço de um grupo ou recurso, o relatório não teria ficado pronto. Parece familiar?

E o que dizer sobre a qualidade desses dados?

Sempre que um colaborador desenvolve uma solução alternativa, e resolve um problema da organização, ele acaba por eliminar mais um possível ponto de controle, conhecimento, ou até mesmo de uma possível melhoria. Neste momento é criado um elemento externo, ou adicional ao processo, e que muito provavelmente, não será documentado, discutido, ou aprovado.

Esse contorno passará a residir nas atribuições veladas do colaborador, e no caso de sua saída, com ele será levado o conhecimento, ficando mais uma vez a organização sem a atualização da sua base de conhecimento corporativo.

Quanto ao conhecimento corporativo, podemos definir como um conjunto elementar e essencial de;

a) Processos (Primários, de Apoio, e de Gestão) b) Regras de negócio e condições

c) Bases de informação

d) Demais recursos – humanos e sistêmicos

2. Necessidade da área de TI fazer melhorias, mas como?

Essa é uma situação que não agrada nem um pouco às áreas de negócio da organização. É uma eterna luta entre áreas, e que acaba na constante demanda de desenvolvimento de melhorias de software, e que em sua grande parte, é entregue fora do prazo necessário para o negócio. É importante lembrar que tudo tem um tempo e uma forma de ser feito, e principalmente, é preciso ter a consciência de que o modelo atualmente utilizado não está funcionando. Normalmente, encontramos o seguinte cenário:

A área de tecnologia, após breve contato com a demanda, começa com a descrição técnica dos requisitos, faz o desenho da solução, entra em fase de desenvolvimento, realiza os testes isolados, realiza os testes integrados, e quando está pronta para entregar a solução para a área de negócio, e possivelmente entrar em homologação, ou está “faltando” alguma característica no projeto da solução, ou já não adianta mais. O tempo de entrega da solução não correspondeu ao time to market necessário, e o concorrente, mais uma vez, saiu na frente...

Qual a interação entre os sistemas, ou das suas constantes melhorias, com relação às outras áreas de negócio?

Sabemos que as organizações vêm desenvolvendo, mantendo, e modernizando suas soluções tecnológicas constantemente.

Quando realizamos uma mudança ou melhoria em determinado sistema, teria algum efeito não previsto no uso de outros sistemas?

Quais sistemas e dados que são realmente necessários ao bom andamento dos processos?

Uma visão dos processos de negócios é uma ótima forma de se evidenciar todos os sistemas envolvidos, os dados trafegados, e principalmente, em que ponto e de que forma eles se fazem realmente necessários.

Com essa visão poderemos decidir se devemos, e como podemos compor e reutilizar aplicações e sistemas, como manter a integridade e consistências dos dados, e quiçá, criar os tão desejados serviços a partir desta visão.

3. Quero automatizar, mas não sei por onde começar.

Esse é um fato importantíssimo e que deve ser tratado como tal.

Por inúmeras vezes fui solicitado para fazer “apenas algumas automatizações no processo”.

Como profissionais responsáveis que somos, não podemos permitir que esse tipo de leviandade continue acontecendo.

Em um projeto de BPM estamos falando e tratando dos processos de negócio da organização.

Estamos trabalhando preocupados em como, em que sequência, sob quais regras, e porque determinadas atividades serão realizadas. Não estamos vendendo ou desenvolvendo um produto que pode ser substituído a qualquer momento. Estamos lidando com o DNA da organização.

Sem fazer um levantamento da situação atual, sem realmente entender, sem mapear, sem modelar, propor melhorias, simular e então aprovar o novo processo junto a quem entende do negócio, como saberemos se não estamos automatizando algo ruim, pernicioso ao negócio, e talvez, dando maior velocidade ao problema?

Vamos realizar o pior processo de forma mais rápida?

Agindo dessa forma, qual o resultado que realmente podemos projetar?

Automatizar atividades do negócio sem uma boa analise, é o mesmo que praticar automedicação. É diagnosticar doenças sem, no mínimo, auscultar o paciente.

Qual o risco envolvido?

É preciso reconhecer que – nenhuma organização – conhece cem por cento os seus processos, e é imaturidade profissional assumir riscos desnecessários propondo pseudomelhorias, sem que se tenha uma base mínima de conhecimentos sobre o negócio, seus objetivos, processos, pessoas, dados, metas e tecnologias envolvidas.

Se você faz parte de pequenas e médias organizações, não imagine que somente a realidade destas organizações é permeada de dúvidas diárias quanto a que rumo tomar.

É importante salientar e evidenciar aqui o quão comum é encontrar em grandes organizações, muito mais avançadas na gestão de seus processos, e nos investimentos tecnológicos, certas questões que também são pertinentes ao gerenciamento de processos entre os seus fornecedores, clientes e concorrentes – independentemente do porte. São questões bastante comuns e presentes nas organizações dos mais variados portes e indústrias:

 Qual o impacto nos meus custos quando do aumento da produtividade?  Qual o impacto da ociosidade no custo do meu produto final?

 Quanto custará aumentar minha produção?

No documento O Livro Do Analista de Processos (páginas 33-37)