E agora, Angular ou React?

Post Original

Angular vs. React – the tie breaker

##1. Introduction A short while ago, our team had to choose a technology for Wix’s flagship product, the html wysiwyg website editor. It is a large single-page application, with complex flows, communication with other iframes and servers, and a lot of user experiences. This product is developed by more than 40 developers. The choices were ReactJS or AngularJS. We had experience with both, and were struggling between the ease-of-use of Angular declarative programming and the simplicity of React. We started a proof of concept that ultimately drove us to form a tie breaker. This article is about the comparison… and the tie breaker.

1.1 Packaging

Packaging is the ability to run and deploy your code in the way you want it. In order to achieve fast loading time, we want to load the bare minimum at first and continue on demand. This also gives us the ability to continue to develop new features without slowly degrading the load time.

Angular provides a very limited ability to do so (mostly html templates) and when we tweaked it to do what we wanted, it looked like assembly code.

In short, we found Angular to be too opinionated and too rigid. React doesn’t care, it’s plain JS and allows us to use requirejs to lazy load pieces of code. It also allows for working with other solutions like webpack.

Winner: React

1.2 Learning curve

Everybody knows about the bumpy road to mastering Angular: it’s quick to get started, then it improves and deteriorates as you go along, a lot like marriage…

We found that you can learn React to a high standard in just a week. It takes some time to get used to the one-way flow, especially for web developers, but once you do, it’s very lucid.

The lifecycle of Angular is complex, and to master it, you really need to read the code. Compile and link are not intuitive, and specific cases can be confusing (recursion in compile, collisions between directives). React, on the other hand, has only a few lifecycle methods, and they are self explanatory. The best feature we found with React is that never, even once, did we have to read its code.

Winner: React

1.3 Abstraction

Good abstraction is priceless. Abstraction provides fast development and hides details that are not necessary for the developer using a library.

We found Angular’s abstraction to be leaky. This means that in order to actually work with it, you need to understand the underlying model. This is why so many people need to debug the internals of Angular when debugging their code.

There are concepts that are exposed in order to treat the leaks, for example, directive priority. But how do I control priorities when using directives from different 3rd party vendors? Why should I care? Why is it that different directives sometimes don’t work nicely together on the same html node? Why do I need to know about digest cycles?

React’s abstraction results in it being less flexible in parts, like not being able to add attributes to html tags, or a single tag for a component. This is solved by React’s implementation of mixins (that allow overlap only on lifecycle methods, and have a predictable execution order) and the fact that it doesn’t leak (like I mentioned above, we never had to open it’s code).

Winner: React

1.4 Model complexity

By model complexity, I’m referring to how you structure the data model that is later represented by the view.

Angular’s performance is sensitive when dealing with scope because of copy-n-compare. This means that you cannot use large models. This has pros and cons. Pros, as it makes the code simpler and more testable; but cons, as it forces you to break down stuff that you’d normally use, and rebuild it back up (for server request for example).

React gives you the freedom to choose, without the performance penalty. The outcome really depends on whether you’re a good coder or a bad coder.

Winner: tie

1.5 Debugging

When something doesn’t work, we all start the tedious task of debugging. I’ll separate this into two main scenarios – figuring why your logic is not working, and understanding the outputted HTML along with what generated it.

Angular is an event driven system, which is always easier to write and harder to debug as the stack-traces end up longer and different than what you’d expect. However Angular does a good job of providing constructs that are logical, like services. If used correctly, they make the code easier to test and debug, but any good programmer will try to separate code and logic with or without them.

When something doesn’t work in Angular directives, one option is to re-write the code in a different way because there’s so much magic going on. Another option is to debug Angular’s code – not a trivial task.

React has two main scenarios – updating the model/doing other actions as a result of user events; and the one-way rendering flow which is always the same. This means that there are fewer places to look for your bugs and the stack traces have clear distinction between React’s code, and your own. They normally don’t mix. React also has less magic, and it’s all concentrated in one place – the vDom comparison. It is a closed black box but in our experience, it worked as expected.

When talking about understanding the HTML, and back-tracing to the code, the story is the opposite. In React, it is hard to compare your code to the resulting HTML. Even when using jsx, you can hardly compare them as “if” and “repeat” control flows break the HTML fragments into tiny chunks of templates. In Angular, however, the result closely resembles the HTML template.

Winner JS: React Winner HTML: Angular

1.6 Binding

In Angular, you can only bind to scope. This means that in complex scenarios like binding to a server/async service, or when binding to a large model, you will need to have an intermediate model in the way, plus you will need to deal with digest cycles and with explicit watches.

In contrast, React only provides syntactic sugar for binding that is called valueLink (a single attribute for both “value” and “onChange” properties). This concept is so simple that it doesn’t sound like it will do the job, yet it does. And if you understand it well, you will be able to create your own linkState or similar functions that will answer all of your binding needs.

Winner: React

1.7 Performance tweaking

React makes it simple to control the performance. If you implement shouldComponentUpdate, you can choose which comparison you prefer – model or presentation. If your model is small, just let React do the comparison on the vDom. If your model is complex, or you create a lot of DOM, you can optimize it by a custom implementation of this function, where you can devise your own mechanisms for dirty-checking that can be very efficient.

In Angular, however, you need to start counting scopes (there are numerous utilities that do it for you), and in some cases, you just have to implement the internals of a component in pure js and wrap it in Angular for convenience. The evidence of this is the amount of articles you can find about Angular performance tweaking…

Winner: React

1.8 Code re-use

Angular gets points for having sooo much stuff ready for it out there, however it’s not trivial to use Angular libraries from more than one provider due to namespace and priority collisions. React lets you manage it the way you like. Saying that, Angular is still stronger in the market and has more ready-made stuff to offer.

Winner: tie

1.9 Templating

I saved the most important one for last… Even though most of the Angular or React articles discuss directives or data-flows, the reality is that when writing an online service, 80% of what you are doing is writing UI. I call them panels, the building blocks of application logic. They contain a lot of information and custom flows, and are built using ready-made building blocks, but they are not generally re-usable, and they are the bulk of what our users see and interact with. React does poor job with those. When writing a repeater it will look backwards:

To see full unobfuscated code samples

Whereas in Angular it will look like:

To see full unobfuscated code samples

How much better is that? (Answer: a lot). So Angular is a clear winner in this section.

Winner: Angular

##2. The tie-breaker – React-templates So, how do we resolve this debate? How can we get all of the benefits of React stated above, but not miss out on this great, super-important feature of Angular? We decided to give it a go and solve it for React.

The design consideration for the tool were:

  • Any valid HTML file is a valid reactTemplate, almost. We keep event notation camelCase like React, and also the notation for no-value attributes like disabled (true/false values will determine whether they appear in the actual DOM)
  • Switch from html context to js context with curly braces, and inside directives
  • Conversion should not be in runtime, so it doesn’t affect performance. No additional objects for scope or runtime code, use only js native constructs (closures, methods, native expressions) to achieve this functionality
  • Make the generated code as human parse-able as possible
  • Directives are inspired by Angularjs and should be obvious to people with prior Angular experience
  • Keep it small and simple. Directives need justification to be added (the entire converter is 350 lines of code)

And the result is the amazing React templates. We’ve got all of Angular templating values with the simplicity of React! We get complete separation between presentation and logic, declarative writing of panels, and to make it even more useful, we’ve added module loader support (either AMD or CommonJS) to allow reuse of other components within the templates themselves. Let’s see a few examples to show how simple this is.

###2.1 Collection iteration

<u{}{} <li="" rt{}{}ep{}{}t="{}{}tem" in="" it{}{}s"{}{}it{}{}}="" at="" in{}{}x="" {i{}{}mi{}{}ex{}{}="" l{}{}="" <="" {}{}="">

Note: itemIndex is derived from the name item, to allow using indices of nested repeaters

###2.2 If statement

<label rt-if="this.hasError()">{this.getError()}</label>

Note: this is a true if, meaning that will not render the node at all if the expression is false.

###2.3 Syntactic sugars – rt-class, rt-scope, expressions in attributes




AS IS. Como é que é?

Definição: É o trabalho de levantamento e documentação da situação atual do processo, comumente chamado de AS IS, a qual é representada em fluxo ou diagrama. Nesta mesma oportunidade levantam-se também os problemasou fragilidades, bem como as oportunidades de melhoria do processo.

Quem: Os participantes desse trabalho são principalmente as pessoas que realizam o processo no dia-a-dia, os executores. Recomenda-se também a participação de pessoas do processo fornecedor e do processo cliente e, alguém de TI. Não devem participar chefias em geral.

Profundidade: o nível de profundidade ou a granularidade da documentação do processo depende dos propósitos do projeto. Normalmente, solicita-se às pessoas que estão dando seu depoimento na reunião de mapeamento, que relatem o processo, como se estivessem ensinando alguém novo na função, a executá-lo – o que e como seria ensinado à pessoa que esta sendo treinada. Deve se tomar cuidado para se levantar toda a informação necessária em uma única vez – em uma única reunião.

É indispensavel descrever, para cada atividade – ou cada passo – do processo,  um nível de detalhamento que melhore o seu entendimento e torne possível a um eventual aprendiz, entender com o mínimo de detalhe, como se faz essa atividade. A estrutura desse texto de detalhamento é (sugestão):

– Input:

– Função de Sistema que suporta a atividade:

– Cargo ou Papel responsável pela execução:

– Descrição detalhada de como se faz a atividade – regra de como se executa:

– Output:

Nota Importante: Com esse nível de detalhamento, torna-se possível a emissão do Manual de Procedimentos, que corresponde ao conjunto de instruções de como se executa o processo. Consulte como realizar isso na sua ferramanta de modelagam.

Estrutura da documentação: É fundamental que o fluxo do processo documentado  tenha o correspondente elemento na estrutura macro de processos da organização, representada pela Cadeia de Valor.

Cuidados e preparativos para a documentação AS IS:

  • Objetivos do projeto, entender por que e para que a modelagem será feita. O que se espera ao final dos trabalhos. Este é o motivador do estudo do processo.
  • Documentar junto aos gestores, quais as melhorias (ligadas aos problemas) e ganhos esperados e exprimir essa informação de forma quantitativa  (e não qualitativa). O que se espera como visão de futuro para o processo.
  • Definir Padrão de Notação e de Trabalho para Modelagem de Processos.
  • Definir ferramenta para modelagem de processos. Use ferramenta na medida certa para a sua organização, ou seja, nao compre ferramenta com recursos além do necessário.
  • Técnicas de levantamento definidas e possíveis para o mapeamento.
  • Definição da equipe do projeto e responsabilidades dos membros.
  • Plano de trabalho, especificando as etapas, os responsáveis, os recursos necessários, o cronograma e agenda com os participantes – a partir da priorização dos processos para projetos de documentação e melhoria.
  • Garantir os recursos necessários para o projeto – Infra-estrutura

Técnicas: O mapeamento pode ser feito de algumas formas, dependendo do cenário e contexto da organização. As mais usuais são:

  • Entrevista: que, embora seja a mais usual é desaconselhável, por considerar a visão de uma única pessoa.
  • Observação: quando o documentador se coloca ao lado de quem executa as atividades.
  • Questionário: o qual é enviado ao entrevistado que o devolve preenchido, sendo este o argumento para o mapeamento.
  • Reunião JAD: na qual representantes dos envolvidos com o processo se reúnem em um mesmo local, para a documentação do processo. Esta é, de longe, a mais adequada, pela rapidez e qualidade do produto gerado. É importante observar que, nesta técnica, o processo vai sendo documentado em tempo real, na ferramenta de modelagem definida, à medida que a realidade do processo vai sendo apresentada pelos participantes da reunião. A validação ocorre também em tempo real, na mesma reunião. Para essa tecnica é preciso dispor de sala e datashow.
    Não há sentido em se anotar o que está sendo discutido e em seguida transpor para a ferramenta e então, validado.

Levantamento dos Problemas ou Pontos Fracos: Na própria reunião de mapeamento do processo, após a conclusão do fluxo detalhado, devem-se documentar, em planilha própria, os problemas e oportunidades de melhoria do mesmo, aproveitando as pessoas presentes. A informação mais importante e mais difícil de se obter é a quantificação do problema – sem isso os problemas perdem a importância e o pior: não será possível fazer o calculo de ROI das melhorias que estão sendo propostas. A seguir alguns elementos causadores de problemas, que afetam negativamente o processo – sugestões:

  • Burocracia
  • Planejamento (falta / Insuficiência)
  • Atividades que não agregam valor
  • Prazo de execução do processo
  • Retrabalho  / conferência
  • Risco
  • Comunicação interna / externa na execução do processo
  • Desempenho do processo – Gargalo
  • Competências para execução do processo
  • Ameaças externas (lei, concorrência, legislação)
  • O Tempo de execução
  • O Custo do processo
  • Os sistemas – obsoletos ou inexistentes
  • Controles em sistema não oficial (Excel, Access, etc.) – cuidado: Planilha em processo é sinal de problema.

Planilha para registro dos Problemas de cada processo

Diagnóstico da situação atual –

Pela análise da realidade levantada durante a documentação AS IS (diagrama + planilha de pontos fracos), elabora-se um relatório diagnóstico da situação atual, que serve de base para que todos que tenham interesse no processo e possam dar contribuição, no sentido de determinar ou sugerir melhorias, o façam. Este relatório tem fundamento nos levantamentos e discussões, visando gerar uma primeira proposta de melhoria do processo e também tem, portanto, sugestões de mudança para o processo:

Amostra relativa à parte relativa aos problemas identificados:


Amostra relativa à parte relativa às sugestões de mudança:


Algumas lembranças relativas à documentação de Processos AS IS:

  • Trabalhe blocos pequenos de processos, com resultados rápidos – segundo o critério de priorização. Grandes projetos se desgastam com o tempo e demoram a dar resultados, gerando descrédito.
  • Cuidado para não mapear processos da área – oriente-se pela Cadeia de Valor.
  • Chamar para as reuniões de mapeamento as pessoas que mais conhecem os processos é chave de sucesso.
  • Leve em conta se a expectativa dos gestores, com relação aos ganhos está sendo alcançada – Calcule o ROI(retorno do investimento), para cada processo tratado. A fonte fundamental para isso é a planilha de Problemas ou Pontos Fracos, mencionada acima.

Aplicação (algumas) para documentação da situação AS IS do processo:

  • Base de conhecimento sobre o processo, para servir de fonte para o repensar do mesmo, também chamado de Redesenho ou TO BE.
  • Estudos do processo, relativos a Custeio, Competências, Riscos e Controles, etc.
  • Validação dos motivadores indicados pela alta gestão, em relação aos ganhos esperados.
  • Registrar diferentes práticas para o mesmo processo na mesma organização – visão de padrão.
  • Treinamento interno.
  • Ponto de partida para a implementação do BPM.

Post original https://bpmquotes.wordpress.com/2012/01/21/04-mapeamento-as-is-com-roi/

Chame o ROI para a sua turma!

Este é um post que achei sobre como definir uma métrica na hora de se mapear o processo ou propor uma nova alternativa a ele.

São os possíveis benefícios monetários resultantes de um valor aplicado no desenvolvimento ou revisão de alguma iniciativa que consumiu esse valor. No nosso caso de Gestão de Processos, é o valor do ganho obtido com asmelhorias obtidas com as mudanças feitas nos processos.

É uma medida de desempenho utilizada para avaliar a eficiência de um investimento.

Para calcular o ROI, o benefício ou o ganho (retorno) com o investimento é dividido pelo custo do investimento, o resultado é expresso como uma porcentagem ou uma taxa.

Retorno sobre o investimento fórmula:

Ganho – Investimento

ROI =  ___________________


700 – 500

ROI =  _________ ==> 40%


É uma métrica popular devido à sua versatilidade e simplicidade, ou seja, se um investimento não tem um ROIpositivo, ou se há outras oportunidades, com um ROI mais elevado, então o investimento (a melhoria do processo) não deve ser realizado.

Se a taxa de ROI for superior a 0,00 significa que o investimento retorna mais do que o seu custo.

É preciso ter em mente que o cálculo de retorno sobre o investimento pode ser modificado para se adequar à situação, tudo depende do que se considera como retorno e custo. A definição do termo no sentido mais amplo apenas tenta medir a rentabilidade de um investimento e, como tal, não há um cálculo absolutamente correto.

O retorno é a quantidade total de ganho de seu investimento. O investimento diz respeito à quantidade de recursos alocados com a intenção de gerar o retorno. Alguns retornos não são obtidos de uma só vez e neste caso é preciso acompanhar a efetiva ocorrência da mudança prevista, ao longo do tempo, para se fazer a apuração do ROI.

O cálculo de ROI deve ser usado sempre que alguma mudança de processo, visando a sua melhoria, requerer algum investimento.

– Nos projetos de melhoria de processo:

A decisão de se fazer a melhoria de um processo deve ser antecedida por uma análise previa da viabilidade dessa iniciativa, com o uso do recurso de ROI – isto antes de qualquer mapeamento. Os gestores envolvidos devem ser consultados e, com as informações obtidas junto a eles, realiza-se um primeiro cálculo do ROI. Sendo favorável o projeto segue.

Etapas semelhantes devem ser realizadas após o levantamento da situação atual – AS IS e confirmadas após o TO BE. Uma certeza maior será obtida com o cálculo de ROI após a implementação e enraizamento da melhoria.

–  Nas iniciativas cotidianas de melhoria – prática do PDCA

Medidas semelhantes devem ser tomadas visando analisar a viabilidade da melhoria.

O cálculo de ROI presume que se tenham os ganhos e os investimentos expressos em números. É importante observar que um ganho nem sempre se manifesta em valor ou quantia. Nos casos nos quais não se disponibilize valores, a decisão de realizar ou não a melhoria deve ser tomada com base em consulta e exposição de motivos aos gestores que tenham alçada para essa decisão.

Os motivadores de projetos de melhoria de processo nem sempre se resumem a ganhos financeiro$. Há outros propósitos que justificam mudanças em processos, que pela sua natureza estratégica pode não se traduzir em ganho quantitativo identificável. Sugere-se consultar os motivadores do projeto, para essa confirmação. A seguir alguns ganhos, comuns em projetos dessa natureza, segundo a sua classificação:

Melhorias => Ocorrências em: Ganhos:
Controles Tempo
Interfaces Qualidade
Pessoas Confiabilidade
Sistemas Custo
Rotinas Satisfação do cliente
Regras e políticas Riscos (diminuição/eliminação)
Infra-estrutura Ameaças (diminuição/eliminação)
Eliminação de desperdício Eliminação de Fila ou gargalo
Competências Taxa de erros
Rastreabilidade Produtividade – Eficiência / Eficácia
Monitoramento Segurança
Variabilidade Flexibilidade/Previsibilidade

Vide o tópico: “Benefícios/Ganhos decorrentes da adoção da Gestão de Processos na organização”, em Gestão de Processos

Sempre que houver mudança/melhoria em processos, é razoável que se tenha a medida do ganho resultante, o qual deve ser documentado e divulgado, para que aumente e fortaleça a visibilidade da iniciativa de BPM na organização.

O ROI elimina suposições e assegura confiabilidade na informação, para mensuração dos efeitos da adoção de BPM na organização.

Considerações sobre ROI em iniciativas de BPM:

BPM não é uma pílula, para curar uma dor localizada, mas sim um exercício, que requer constância.

Estamos tratando da gestão da organização, aprimorada continuamente através da melhoria de seus processos. Alguns resultados podem vir no curto prazo, mas a maioria e mais significativa, ocorre no médio e longo prazos. O grande resultado da Gestão de Processos é obtido pela somatória de pequenas melhorias realizadas no dia-a-dia da operação da organização, ao longo do tempo. Veja, a respeito, o caso da Toyota, que persegue pequenas e constantes melhorias, nos últimos 50 anos:

“Na Toyota , acreditamos que a chave para fazer produtos de qualidade é desenvolver pessoas de qualidade. Cada funcionário pensa sobre o que ele ou ela deve fazer, fazendo melhorias de forma contínua, e ao fazê-lo, torna ainda melhores nossos carros. Nós temos estado ativamente envolvidos no desenvolvimento de pessoas que compartilham e podem executar este valor fundamental”.
“Faz 50 anos desde que o primeiro Toyota foi apresentado à América. Os primeiros esforços da Toyota não foram um sucesso espetacular, mas persistimos, e  houve melhorias – constantemente. Esse é o segredo do sucesso. Todos os dias as pessoas da Toyota querem se tornar melhores. Todos os dias, eles querem melhorar os seus produtos ou os seus processos ou a sua equipe. E, a cada dia, algo ficou melhor na Toyota – por 50 anos.”
Akio Toyoda – presidente da Toyota

Post original https://bpmquotes.wordpress.com/2012/01/21/07-calculo-do-roi-em-iniciativas-de-processos-retorno-sobre-investimento/

BPM – As 7 fases do projeto.

Para que uma empresa atinja o sucesso, primeiro deve-se garantir que ela tenha eficácia para depois assegurar acerca de sua eficiência. Este é o objetivo de um mapeamento de processos BPM: implementar efetividade em planos gerais complexos.

Mas para entendermos com profundidade o que é um mapeamento de processos BPM é de fundamental importância conhecermos a definição de processo: um processo é uma sequência de tarefas, ou atividades, que ao serem executadas transformam insumos em algo (resultado) com valor agregado. A execução de um processo de negócio consome recursos materiais e/ou humanos para agregar valor ao seu resultado. Insumos são matérias-primas, produtos ou serviços vindos de fornecedores internos ou externos que alimentam o processo. Os resultados são produtos ou serviços que vão ao encontro das necessidades de clientes internos ou externos.

Um mapeamento de processos BPM tem como objetivo determinar a forma como os insumos recebidos são tratados e transformados, para promover este processo com total efetividade, (eficiência + eficácia).

Para fazer um mapeamento de processos BPM todos os detalhes de todos os processos devem ser analisados para que depois seja montado um mapa, demonstrando o fluxo operacional e a interrelação entre as diferentes área e processos.

O mapeamento dos processos BPM possibilita e facilita a construção de sistemas de medições e indicadores de desempenho, avaliando em tempo real a execução das tarefas, medições dos resultados, custos, produção, produtividade, riscos, etc., tornando mais fácil o seu gerenciamento.

Através deste mapeamento é possível calcular os custos totais do processo, o tempo de execução, os responsáveis, o pessoal alocado, o tempo de dedicação de cada recurso e o estabelecimento de melhorias ou otimizações.

Fases de um projeto de mapeamento de processos BPM

Fase 1 – Definir equipes que possam apresentar a rotina de processos. Os participantes desse trabalho são principalmente as pessoas que realizam o processo no dia a dia. Recomenda-se também a participação de pessoas do processo fornecedor e do processo cliente.

Fase 2 – Identificar processos. Obter amplo conhecimento acerca da organização levantando as seguintes informações:

  • Estrutura organizacional, as atribuições de cada área e os principais gestores.
  • Estratégia de crescimento de cada setor.
  • Principais processos de negócio.
  • Principais indicadores de desempenho.
  • Sistemas de informações utilizados na organização.
  • Prioridades estratégicas de implantação de processos.
  • Estratégias de terceirização de processos.

Fase 3 – Identificar processos atuais. Levantar dados sobre as políticas que regem os processos, as tarefas executadas, tempos gastos nas atividades, quantidade de pessoas envolvidas em cada atividade, quem são os fornecedores e respectivos clientes internos e quais as suas interações. Nesta fase não é obrigatória a diagramação dos fluxos, um simples texto em português estruturado é suficiente para formalizar a fase.

Fase 4 – Analisar processo atual e propor melhorias. Análise crítica dos processos para detectar as causas dos problemas e as oportunidades de melhoria no processo. Fontes de problemas e oportunidades:

  • Método de trabalho.
  • Pessoas.
  • Máquinas e equipamentos.
  • Matéria prima.
  • Ambiente físico.

Ferramentas disponíveis:

  • Brainstorming.
  • Diagrama de Pareto.
  • Diagrama de Ishikawa ou Diagrama de Causa – Efeito.

Fase 5 – Mapear fluxos To Be. Desenvolver alternativas de solução para os problemas do processo. Avaliar cada alternativa em função dos seus impactos sobre:

  • Custo-benefício.
  • Prazo de implantação.
  • Quadro de pessoa.
  • Outros.

Também nesta fase:

  • Decidir pela melhor alternativa de melhoria.
  • Diagramar a nova versão do processo.

Fase 6 – Priorizar e Automatizar. Identificar os processos prioritários para implantação e automatização.

Definir estratégia de automatização:

  • Que fluxos serão automatizados no ERP?
  • Que fluxos demandam o uso de um sistema de apoio/controle?

Ainda nesta fase:

  • Adquirir software e hardware.
  • Definir controles para geração de evidências.
  • Divulgar e treinar pessoas.
  • Implantação efetiva e suporte assistido.

Fase 7 – Monitorar, melhorar e expandir automatização. Realizar reuniões periódicas para acompanhamento de indicadores e sugestões de melhoria.

  • Criar processos para registro e tratamento de mudanças em processos.
  • Estabelecer um comitê de mudanças de processos.
  • Manter controle de versão de processos.
  • Identificar novos processos para automatização e repetir o passo anterior.

Postado originalmente em http://www.venki.com.br/blog/mapeamento-de-processos-bpm/