01-caderno-[6320 - 16041]caderno dida769tico fundamentos em business process management workflow

Fundamentos em Business Process Management (BPM)/Workflow

Sumário

3 Apresentação

5 Processos de Negócio e Modelagem de Processos

9 Gestão por Processos de Negócio

13 Workflow

19 Documentação dos Processos de Negócio

25 O Padrão XML

29 Arquitetura Orientada a Serviços

33 A Cultura Organizacional e a Gestão por Processos de Negócios

37 Tecnologia da Informação e Gestão por Processos de Negócios

39 A Tecnologia jBPM

43 As Linguagens de Execução e os Processos de Negócio

51 Das Funções de Negócio aos Processos de Negócio

55 Modelagem de Processos de Negócios

63 Sistemas para Gestão de Processos de Negócio

Copyright UnisulVirtual 2009

Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.

Edição – Caderno didático

Professor ConteudistaCarlos André de Sousa Rocha

Coordenação de CursoVera Rejane Niedersberg Schuhmacher

Design InstrucionalSilvana Souza da Cruz Clasen

Projeto Gráfico e CapaEquipe Design Visual

DiagramaçãoAlice Demaria Silva

RevisãoAmaline Mussi

Fundamentos em Business Process Management (BPM)/Workflow

Este caderno didático faz parte da disciplina Fundamentos em Business Process Management (BPM)/Workflow.

Nas unidades on-line da disciplina, você encontra o cronograma de estudos, assim como os demais textos, materiais e atividades de aprendizagem que se integram à leitura deste caderno didático.

Sugerimos que você imprima os textos indicados nas unidades on-line e os anexe a este caderno didático. Assim, você terá em um único local os materiais indicados para leitura, facilitando, inclusive, a realização da avaliação presencial da disciplina.

No decorrer deste caderno, você encontrará alguns espaços em branco. Aproveite-os para fazer anotações e questionamentos sobre os textos, assim como as sínteses necessárias. São exercícios extremamente importantes para a consolidação do seu aprendizado.

Aproveite ao máximo este e também os outros materiais didáticos do seu curso. O sucesso da sua aprendizagem depende, principalmente, de você.

Bom estudo e sucesso! Equipe UnisulVirtual

Apresentação

5

Toda organização, pequena, média, ou grande, executa uma série de atividades que são responsáveis por produzir algum produto ou algum serviço aos seus clientes. Partindo desta premissa, você pode entender uma Atividade como um termo genérico para o trabalho que uma companhia ou organização executa via processo de negócio.

Uma atividade pode ser atômica (pouca abrangência) ou não-atômica (grande abrangência). Por exemplo: imagine uma empresa que deseja desenvolver um novo sistema de software para o seu negócio de vendas através da Internet. Uma atividade não atômica (geral) seria a de “Processo de Desenvolvimento de Software”; já uma atividade atômica (específica) pode ser definida como a

“Descrição dos Requerimentos do Novo Sistema”.

Você verá a seguir que a primeira atividade é chamada de processo, já, a segunda, de tarefa. Assim, uma atividade pode ser tipificada como: processos, subprocessos ou tarefas (BALDAM et al., 2007, p. 19).

Ainda nas palavras de Baldam e outros (2007, p. 19), um processo é um encadeamento de atividades executadas dentro de uma companhia ou organização, que transforma entradas em saídas. Este conceito está em conformidade com o apresentado pelo Business Process Management Initiative (BPMI.org), que conceitua processo como uma atividade realizada dentro de uma companhia ou organização (BPMN, 2009, p. 32).

Em outras palavras, um processo representa o que uma organização faz, o seu trabalho, em uma determinada ordem, para realizar um propósito ou objetivo específico (WHITE; MIERS, 2008, p. 27). Um subprocesso é uma atividade contida dentro de um processo (BPMN, 2009, p. 21) ou, na definição de Baldam et al., (2007, p. 19), um subprocesso é um processo que está incluso em outro processo.

E, finalmente, uma tarefa para Baldam et al. (2007, p. 20)

Processos de Negócio e Modelagem de Processos

Carlos André de Sousa Rocha

6

Pós-graduação

[...] é uma atividade atômica que é incluída em um processo. Ela é usada quando a atividade no processo não será mais refinada em sub-processos dentro de um modelo de processos, sendo geralmente executada por um usuário final, equipamento ou sistema.

Destacando ainda o conceito de processos, no contexto de uma organização um processo pode ser tipificado em três grupos (SCHEER, 2006 apud BALDAM et al., 2007, p. 22):

• Processos de Governança: envolvem processos como gerenciamento de conformidades, gerenciamento de riscos, Business Intelligence, processos de BPM (negócio), desenvolvimento de estratégias, desenvolvimento de negócios e arquitetura empresarial.

• Processos de Gerenciamento (suporte e controle): abrangem as atividades diárias e mais comuns de gerenciamento da organização como: gerenciamento financeiro, controladoria, gerenciamento de informação, o BPM propriamente dito, gerenciamento de qualidade, gerenciamento de recursos humanos, gerenciamento de ativos, etc.

• Processos Operacionais: destinados a desenvolver a atividade fim da empresa: CRM (Customer Relationship Management), logística, desenvolvimento de produto, PCP (Planejamento e Controle de Produção), gestão empresarial, etc.

Você sabia?Organização (departamento de governo, serviço público, companhia comercial ou mercantil ou qualquer outra associação de pessoas unidas por um interesse comum) pode ser definida por sua estrutura, pela combinação de pessoas, máquinas e normas de atuação (DÁVALOS, 2006, p. 42). Ballestro-Alvarez (1997 apud DÁVALOS, 2006, p. 42) complementa o conceito, afirmando que ela é tida como um complexo entremeado de canais por meio dos quais produtos, serviços, recursos e fluxos de informação transitam de um ponto a outro dentro da organização e, também, entre esta e seu entorno.

Já o conceito de Negócio para Dávalos (2006, p. 47) é um empreendimento que pressupõe investimento e risco, pelo qual a organização busca atender suas necessidades econômicas, além da realização empresarial e social. Um negócio é constituído por pessoas, processos e tecnologia de informação.

7


Imagine uma organização com uma área de Recursos Humanos a qual precisa realizar o gerenciamento dos seus colaboradores. A Figura 1 mostra a relação entre processos, subprocessos e tarefas.

<<Processo>>Recrutar Empregado

<<Processo>>Avaliação do Empregado

<<Processo>>Afastamento do

Empregado

<<sub-processo>>Treinar Empregado

<<sub-processo>>Desempenho do

Empregado

Tarefas: 1) Imprimir teste; 2) Agendar treinamento; 3) Selecionar empregado

Figura 1 - Processos, subprocessos e tarefas para o negócio gerenciamento de RH. Fonte: Adaptado de Baldam (2007, p. 70).

Agora que você está pronto(a) para entender o conceito de Modelagem de Processos, vamos adiante?

Já vimos o que é processo e todos os conceitos envolvidos em sua definição, mas o que significa Modelagem? E Modelagem de Processos?

O OMG (2008) define modelagem como:

Desenho de aplicações de software antes da codificação. Modelagem é uma Parte Essencial de grandes projetos de software, e útil para médios e até mesmo pequenos projetos. Um modelo incorpora o papel análogo no desenvolvimento de software que anteprojetos e outras plantas (mapas de locais, elevações, modelos físicos) incorporam no projeto de um arranha-céu. Usando um modelo, aqueles responsáveis pelo sucesso de um projeto de desenvolvimento de software podem ter assegurado que a funcionalidade do negócio está completa e correta, as necessidades do usuário final são alcançadas, e desenho de programas suportam requerimentos escaláveis, robustos, seguros, extensíveis, e outras características, antes da implementação em código.

Pessoas geralmente utilizam modelos como base de discussões, como suporte a comunicações e compreensão de referência aos negócios com um detalhamento de como todas as atividades são organizadas umas com as outras, sendo que modelos de processos são normalmente criados a partir das regras (operações) de negócios dentro de uma organização (WHITE; MIERS, 2008).

Observando os fatos anteriormente apresentados sobre modelagem, nós nos permitimos assumir que ela tem a capacidade de capturar em seus modelos

objetivos, estratégias e regras de uma organização, assumindo que os maiores consumidores destes modelos serão pessoas que necessitam de comunicação entre si, ajudando-as a formar um conhecimento compartilhado interna e externamente à companhia (WHITE; MIERS, 2008).

A Figura 2 apresenta os modelos de processo que normalmente são criados observando as operações de negócio de uma companhia.

Captura de Processos

Operações de Negócio

Análise de Processos Redesenho a Processos Suporte a Processos

Figura 2- Importância dos modelos de processo em todas as fases de mudança de uma organização. Fonte: Adaptado de White e Miers (2008, p. 21).

A modelagem (desenho) permite que os processos identificados sejam representados de uma maneira gráfica, propiciando entendimento e visualização mais fáceis por parte de toda a organização. Ferramentas CASE (Computer-Aided Software Engineering – Engenharia de Software Auxiliada por Computador) permitem que os processos modelados sejam mapeados para uma posterior codificação.

Referências

BALDAM, Roquemar et al. Gerenciamento de Processos de Negócios–BPM. São Paulo: Érica, 2007.

BPMN. Business Process Modeling Notation: BPMN Specification Releases Version 1.2. 2009. Disponível em: <http://www.omg.org/spec/BPMN/1.2/PDF>. Acesso em: 14 abr. 2009.

DÁVALOS, Ricardo Villarroel. Modelagem de Processos. 2. ed. Palhoça: Unisulvirtual, 2006. 175 p.

OMG. Object Management Group: Introduction to OMG UML. Disponível em <http://www.omg.org/gettingstarted/what_is_uml.htm>. Acesso em: 31 jan. 2008.

SORDI, José Osvaldo de. Gestão por processos: uma abordagem da moderna administração. São Paulo: Saraiva, 2006.

WHITE, Stephen A; MIERS, Derek. BPMN Modeling Reference Guide. Lighthouse Point: Future Strategies, 2008.

9


Você sabia?O termo “Gerenciamento” remete às funções de monitoramento e controle do recurso gerenciado, enquanto “Gestão” é mais abrangente e compreende: planejamento, projeto, construção, implementação, utilização, monitoramento, identificação de melhorias e realização de ajustes melhor (SORDI, 2006, p. 23).

A BPM (Business Process Management – Gestão por Processo de Negócio) oferece suporte aos processos de negócio de uma organização na medida em que não só simplifica sua lógica para aprimorar sua eficiência, mas determina processos adaptáveis e extensíveis, que podem ser ampliados conforme mudanças de negócios (ERL, 2009).

A gestão por processos eleva uma organização de um nível meramente hierárquico/funcional para uma companhia que pode sofrer transformações de maneira precisa e com resultados previsíveis, gozando de uma disciplina administrativa e de engenharia, com indicadores pré-definidos, porém alteráveis (BALDAM et al., 2007).

Mas como nós poderíamos conceituar Gestão por Processos de Negócio (BPM)?

É importante entender que o conceito de BPM envolve todos os elementos presentes em uma organização, como pessoas, negócio e infraestrutura de TI (tecnologia de informação). Para Garimela, Lees e Williams (2008, p. 5),

BPM é um conjunto de métodos, ferramentas e tecnologias usadas para desenhar, publicar, analisar e controlar processos de negócios operacionais. BPM é uma abordagem centrada em processos para melhoramentos de desempenho que combinam tecnologias da informação com processos e metodologias de governança (gestão). BPM é a colaboração entre pessoas do negócio, tecnologistas de informação para promover processos de negócios efetivos, ágeis e transparentes. BPM relaciona pessoas, sistemas, funções, negócios, clientes, fornecedores e parceiros.

Gestão por Processos de Negócio Carlos André de Sousa Rocha

10

Pós-graduação

Se você imaginar que toda organização está, nas palavras de White e Miers (2008), em uma grande jornada, onde o foco consiste em prover melhoramentos, e as atividades são realizadas para o benefício das pessoas envolvidas no negócio, inclusive os acionistas, e, ainda, em gerar lucros, você perceberá que esta jornada é o coração da BPM. Em outras palavras, BPM é uma maneira de pensar, uma filosofia de gestão centrada nos melhoramentos dos processos operacionais de uma organização.

O conceito apresentado por Sordi (2006) envolve também os elementos existentes em um ambiente organizacional: recursos humanos, papéis e responsabilidades, estrutura organizacional, políticas e regras, tecnologias da computação e da comunicação, facilidades e conhecimento.

Ainda para Sordi (2006), a BPM deve garantir a sincronia de todos estes elementos, permitindo a eficiência. Os processos de entrada, suas transformações e resultados de saídas devem estar em conformidade com os resultados esperados.

Você deve perceber que as tecnologias, as pessoas e as facilidades garantem aos processos a geração de resultados. Para a execução dos processos de maneira esperada, deve existir um direcionamento para as regras, papéis e estrutura organizacional. Já o conhecimento e o capital intelectual existem nos elementos físicos e tecnológicos do negócio, juntamente com as habilidades humanas. Você pode ver a relação entre os elementos apresentados, visualizando a Figura 1.

Ajustes

Conhecimento

Estruturaorganizacional

Papéis eresponsabilidades

Tecnologias

Políticas e regras

Recursos humanos

Facilidades

Processos denegócios

Conhecimento

Conh

ecim

ento

Conh

ecim

ento

Planejamento

Projeto

Construção

DisponibilizaçãoUtilização

Monitoramento

Oportunidades

Figura 1 - Processos de negócio e seus ativos a serem geridos. Fonte: Adaptado de Sordi (2006, p. 27).

11

A Gestão de Processos de Negócios deve estar em pauta de toda companhia que pensa em possuir mecanismos Humanos e Tecnológicos, capazes de responder, de maneira rápida e eficaz, aos anseios de um mercado (finanças, educação, bens de consumo, serviços, etc.) cada vez mais exigente e disputado, principalmente devido ao amadurecimento, a cada década, das transações comerciais através da Internet.

Referências


ERL, Thomas. SOA: Princípios de Design de Serviços. São Paulo: Pearson Prentice Hall, 2009.

GARIMELA, Kiran; LEES, Michael; WILLIAMS, Bruce. BPM Basics. Indianapolis: Wiley Publishing, 2008.




13


Workflow

A ideia de Workflow já data da década de 1980, quando este era conhecido como ferramentas de colaboração, com destaque para as soluções da Lotus Software, incorporada pela gigante IBM (REIS, 2008).

Nos anos 1990, workflow foi frequentemente usado como parte de um exercício de reengenharia de processo de negócio para automatizar processos de negócios

“reengenharizados”.

Nas palavras de Prior (2003), nessa época a ênfase era direcionada mais para tecnologia do que para aspectos humanos, com menos pensamentos conduzindo interações humanas dentro do processo; como resultado, workflow desenvolveu uma reputação pobre. O autor ressalta, entretanto, que o interesse na gestão de processos de negócios está novamente crescendo a partir do amadurecimento atual da abordagem de processos de negócios caracterizada pela habilidade dos processos serem modelados e monitorados em tempo real, e, ainda, por estes processos serem mais facilmente modificados em resposta às voláteis tendências de mercado e tecnologia,

O termo workflow aproveitou a popularização das ferramentas de colaboração que, aliada à necessidade de organizar a comunicação entre as pessoas e transferir responsabilidades ao longo de uma atividade organizacional, fez com que o conceito de workflow se firmasse e se mantivesse até hoje (REIS, 2008).

Palmer (2008) divide o workflow em três períodos distintos, aos quais chama de onda. O workflow surgiu na década de 1990, como parte das iniciativas de reengenharia seguidas após a recessão de 1991 nos Estados Unidos da América (USA); a segunda onda teve origem em 1999 como parte do “bug do milênio”; e, agora, em 2008, se apresenta a terceira onda do interesse e investimentos em Workflow e BPM como meios para combater as incertezas econômicas e o crescente custo das transações de negócios (PALMER, 2008).

A WfMC (Workflow Management Coalition – Coalizão para Gestão de Workflow) define Workflow como “A automação de processos de negócio, num todo ou

14

Pós-graduação

parte, no qual documentos, informação ou tarefas (atividades) são passadas de um participante (pessoa) para outro, de acordo com um conjunto de regras procedimentais” (ALLEN, 2001, p. 15).

Outra definição dada por Allen (2001) para workflow (fluxo de atividades) diz que ele compreende um número lógico de etapas conhecidas como atividades. Elas podem envolver interações manuais com os participantes do fluxo, ou podem ser executadas com a utilização de recursos tecnológicos.

A Figura 1 mostra a modelagem workflow para o exemplo de uma solicitação de empréstimos. O requerente visita a Home Page da financiadora e preenche o formulário de solicitação. A aplicação garante que todos os campos obrigatórios serão fornecidos. Em seguida, a companhia recebe os dados referentes à solicitação do requerente. A primeira atividade de workflow acontece na validação do formulário.

Na sequência, os dados da aplicação são clonados, para que outras atividades do workflow sejam executadas em paralelo. Após a atividade de consolidação, um supervisor é acionado, caso haja uma rejeição no pedido de empréstimo. Nesta hipótese, é gerada uma carta de rejeição. Caso contrário, uma carta de aprovação é distribuída ao requerente.

Requerente completaum formulário no

Web Site.Tecnologia da

Informação assegura que os campos

foram completados

Tarefa WorkflowAutomatizada

Clone

Verifica crédito

Fundos disponíveis?

Revisão do histórico do

cliente?

ConsolidarConcede

emprestimo?

Não Sim

Estação do SupervisorRevisão de exceções

e rejeições

Carta de aorovaçãodistribuída

Carta de rejeiçãodistribuída

Processos de Negócio

Atualizaarquivos

CIS

Tarefa WorkflowAutomatizada

Processos de Negócios Paralelos

Figura 1- Workflow para solicitação de empréstimos. Fonte: Adaptado de Allen (2001, p. 18).

15

Workflow

Você pode entender ainda Workflow como tradicionalmente definido em termos de escritório: movimento de papéis, processamento de pedidos, emitir uma fatura, etc. (PLESUMS, 2002). Este processo deve ser “gerenciado por um programa de computador que designa uma unidade de trabalho, passa-a adiante, e acompanha seu progresso” (PLESUMS, 2002, p.19).

Você sabia?Dentro do contexto de Workflow, uma atividade é a descrição de uma unidade de trabalho que forma um passo lógico dentro de um processo. Uma atividade é também chamada de tarefa.

As tecnologias de workflow permitem que uma unidade de trabalho ou um conjunto de dados sejam criados, processados e modificados, considerando um número de estágios de processamento, para que o objetivo de um negócio seja alcançado (ALLEN, 2001).

A automação do fluxo permite que unidades de trabalho sejam entregues aos participantes do processo, automatizando um fluxo que está sendo executado, provendo um grande incremento de eficiência. Esta automação permite ainda, a criação de uma Organização Virtual, que possibilita aos gerentes um controle efetivo do fluxo de atividades (ALLEN, 2001).

Ainda sobre a importância da automação de um processo, Plesums (2002) ressalta que a automação de um processo de negócio através de workflow permite não só que o negócio seja mais bem conduzido, mas também custos são diminuídos e serviços ao cliente são normalmente melhores. Você pode visualizar uma automação de workflow como a implementação de um algoritmo para o funcionamento efetivo de um negócio, ou parte dele. Um workflow deve ser capaz de distribuir todas as unidades de trabalho entre todos os recursos organizacionais.

Conceito-chaveEmbora a maioria das pessoas fale de sequência de trabalho entre pessoas, poderia também ser sequência de trabalho entre máquinas, entre departamentos, ou, até mesmo, entre empresas. Então os termos mais gerais “recurso” ou “participante” são, às vezes, usados para descrever a pessoa, grupo, ou máquina que está realizando o trabalho.

16

Pós-graduação

Você percebeu como o conceito de workflow está intimamente relacionado com a gestão de processos de negócio (BPM)? Que tal identificar este relacionamento?

A BPM exige um forte componente de workflow, porém estende este componente para incluir adaptadores de integração configuráveis que permitem a automação e a integração de processos, independente do modelo de processos utilizado, e uma flexível e configurável interface para interações humanas. (PRIOR, 2003, p. 17).

Prior (2003, p. 18) define em mais detalhes a relação entre Workflow e BPM, fazendo uma referência às palavras de Linus Chow:

A gestão de processos de negócios (BPM) colaborativa é a convergência de Workflow, EAI (Enterprise Application Integration – Integração de Aplicações Empresariais), e processos não-estruturados ou ad-hoc. BPM está atualmente revolucionando os negócios pelo fornecimento de infra-estrutura empresarial que gerencia e automatiza processos que têm ambas tarefas relacionadas a humanos e a sistemas. BPM é uma de algumas tecnologias em observado crescimento, pois pode mostrar valor real e ROI (Return On Investment – Retorno pelo Investimento) no ambiente altamente competitivo causado por uma queda na economia mundial.

Ainda na observação de Prior (2003), a WfMC sempre reconheceu workflow como sendo um elemento integrante para uma abordagem organizacional baseada em processos de negócios. Um workflow, além de descrever a execução de processos, permite o gerenciamento de tarefas automatizadas, ou manuais, e de regras de negócios. Sua recente cooperação com o BPMI fortaleceu este conceito.

É importante você entender que uma tecnologia BPM envolve vários tipos de ferramentas e tecnologias e, entre elas, o Workflow. O conjunto delas, associadas a uma abordagem de gestão por processos, permite que uma empresa sobreviva à turbulência causada, por exemplo, pela crise mundial deflagrada pelos Estados Unidos da América em outubro de 2008.

Foi citado no início deste texto que a relação entre WfMC e BPMI vem-se estreitando, isto também é observado através de um compartilhamento de uma base fornecedora comum e uma colaboração de ideias benéficas para a comunidade usuária e organizações. Mais uma vez, Prior (2003, p. 18) usa as palavras de Linus Chow para ressaltar a evolução da BPM:

Linus Chow

é Diretor Regional da Asia-Pacific e Six Sigma Champion, HandySoft Corporation.

17

Workflow

À medida que BPM amadurece, procura por novas capacidades de manipulação de processos inteligentes, não-estruturados, e em processo de amadurecimento e evolução. O desenvolvimento e a convergência de padrões tecnológicos em áreas como Web Services e Lógica de Processos tornará isso possível. Por enquanto, a crescente demanda por configuração mais rápida e mais fácil para os envolvidos nos negócios conduzirá fornecedores em direção à adição dessas novas capacidades.

O amadurecimento da dupla Workflow/BPM tende a beneficiar os negócios na medida em que, nas palavras de Prior (2002), este relacionamento de trabalho oferece uma oportunidade para uma nova abordagem de gerenciamento de processos e integração de aplicações, com um movimento em direção à capacitação de usuários para integrar e gerenciar aplicações empresariais desiguais dentro de seus processos de negócios.

Você deve compreender que o conduíte para a relação Workflow/BPM fornecido pela parceria entre a WfMC e a BPMI é um movimento em direção à capacitação dos usuários dos processos de negócios, e não apenas um time de especialistas em TI.

Referências

ALLEN, Rob. WfMC: Workflow Handbook 2001. In: FISCHER, Layna (Org). Workflow: An Introduction. Florida: Future Strategies, 2001. Disponível em: <http://www.futstrat.com/books/downloads/Workflow-An_Introduction.pdf>. Acesso em: 17 jul. 2008.

PALMER, Nataniel. WfMC: Workflow and BPM in 2008 A New Business Value Imperative. In: FISCHER, Layna (Org). BPM And Workflow Handbook: Spotlight On Human-Centric BPM. Florida: Future Strategies, 2008.

PLESUMS, Charles. WfMC: Workflow Handbook 2002. In: FISCHER, Layna (Org). Introduction to Workflow. Florida: Future Strategies, 2002. Disponível em: <http://www.futstrat.com/books/downloads/introduction_to_workflow02.pdf>. Acesso em: 17 jul. 2008.

PRIOR, Carol. WfMC: Workflow Handbook 2003. In: FISCHER, Layna (Org). Workflow and Process Management. Florida: Future Strategies, 2003. Disponível em: <http://www.futstrat.com/books/Workflow_and_Process_Management.pdf>. Acesso em: 17 jul. 2008.

REIS, Glauco S. Modelagem de Processos de Negócios com BPMN. São Paulo: PortalBPM, 2008.

19


Documentação dos Processos de Negócio

A utilização de uma documentação inicial que agrega importantes informações sobre estes processos constitui importante atividade, a qual pode ser considerada anterior à modelagem dos processos de negócios.

Dávalos (2006) aponta o levantamento detalhado dos processos como uma fase crítica. Este levantamento é vital, pois, através dele, conseguimos traçar um escopo da realidade que envolve os processos em estudo. O autor aponta, ainda, a Gestão por Processos de Negócio como um apoio tecnológico para realizar este levantamento.

Garimela, Lees e Williams (2008) apontam o Proprietário do Processo como o responsável por realizar a documentação do processo de negócio. Outro elemento da documentação de processos, nas palavras dos mesmos autores, são as regras de negócio.

A estes elementos podemos adicionar outros importantes para a documentação de um processo, a saber: tempos de execução, custos envolvidos, metas de sucesso, e se estão implementados através da tecnologia de informação, além de seu fluxo de informação (DÁVALOS, 2006).

Sordi (2006) adiciona a este conjunto de elementos os eventos de negócio, responsáveis por acionar os processos de negócio. O autor afirma que o estudo destes eventos é fundamental para entendermos quão complexos são os processos.

Podemos ainda adicionar como elementos importantes da documentação dos processos de negócio: relacionamento com outros processos, interfaces entre as áreas funcionais atingidas e os elementos apresentados por Eriksson e Penker.

20

Pós-graduação

Conceito-chaveO Proprietário do Processo “é o responsável pelo alinhamento dos processos às diretrizes estratégicas da organização, estabelecendo metas e resultados esperados e analisando riscos envolvidos” (BALDAM et al., 2007, p. 59).

Para a identificação de todos os elementos apresentados, Eriksson e Penker (2000, p. 87) ressaltam que devemos ter:

• O conhecimento do negócio, coletado a partir da experiência e informações de todos os que trabalham com o negócio;

• Modelos atuais do negócio;

• Modelos de referência para o domínio específico do negócio, isto é, estilos arquiteturais genéricos ou padrões para este domínio específico.

Processos de negócio são modelados através de entrevistas, discussões com os stakeholders e como resultado de sessões de brainstorming. Logo, para entendermos os mecanismos de um determinado negócio, devemos realizar o levantamento para a modelagem, que deve iniciar com encontros e entrevistas com os empregados e gerentes da organização (ERIKSSON; PENKER, 2000).

Neste sentido, Reis (2008) nos alerta que uma sessão de entrevistas muitas vezes não segue os caminhos organizados definidos por nós, uma vez que dois entrevistados diferentes conduzem as atividades de um processo de maneira diferente. Nestas situações, Reis (2008, p. 74) esclarece que:

Ao invés de conduzirmos uma discussão em termos já estruturados, as reuniões ficam mais leves se primeiro levantarmos todas as atividades a serem executadas, e, em um segundo momento, as colocarmos em um diagrama em ordem de execução. Desta forma, aliviamos a pressão imposta pela importância de um levantamento de fluxo e a tendência a erros é minimizada. É importante que não exista pressão para que as informações sejam apresentadas de maneira organizada, mas sim manter o foco nas atividades componentes.

Que tal agora organizarmos os elementos discutidos em um template para documentação de processos de negócio e em seguida o aplicarmos em um exemplo?

21


A Tabela 1 apresenta um template para a coleta de informações relevantes a um processo de negócio, considerando os elementos apresentados anteriormente.

Tabela 1 – Template para o Levantamento das Informações de um Processo de Negócios

Informações Gerais

Nome do Processo:

Proprietário do Processo:

Meta (Objetivo):

Tipo (processo, subprocesso):

AS-IS/TO-BE:

Informações Adicionais 1

Eventos:

Processos Relacionados:

Áreas Funcionais Atingidas:

Entradas:

Recursos Adicionais:

Saída:


Sequência de Fluxo:

Nome Arquivo:

Pasta Projeto:


Implementado (TI, manual):

Regra de Negócio:

Nome Arquivo:

Pasta Projeto:

Custo:

Tempo Execução:

Fonte: Elaborado pelo autor, 2009.

22

Pós-graduação

O exemplo da Tabela 2 mostra o levantamento para o processo de controle de repasses financeiros da rede de Supermercados SmallPrice para os bancos, através da utilização de uma empresa transportadora e seguradora de valores.

Tabela 2: Levantamento para o Processos de Negócio Repasses Financeiros da Rede SmallPriceSmallPrice

Informações Gerais

Nome do Processo: Repasse de Valores

Proprietário do Processo: Controlador de Finanças

Meta (Objetivo): Assegurar retirada de valores circulantes

Tipo (processo, subprocesso): Processo

AS-IS/TO-BE: AS-IS


Eventos: Saída de operador

Processos Relacionados: Vendas

Áreas Funcionais Atingidas: Frente de caixa, tesouraria, transportadora e banco

Entradas: Envelopes com cheques ou dinheiro

Recursos Adicionais: Informação da transportadora

Saída: Valores para o fluxo financeiro


Sequência de Fluxo: Vide diagrama modelado na CASE Enterprise Architect

Nome Arquivo: Diagrama de Processo 020-Atividades Processo Repasse Valores. EAP

Pasta Projeto: /./projeto/diagramas/


Implementado (TI, manual): Manual

Regra de Negócio: Vide documento de regras de negócio

Nome Arquivo: RN 020-Processo Repasse Valores.doc

Pasta Projeto: /./projeto/regras

Custo: Não calculado

Tempo Execução: 24 horas em média

Fonte: Elaborado pelo autor, 2009.

23


Você pôde perceber que, além de aspectos tecnológicos e metodológicos, a modelagem de processos envolve fatores humanos muito fortes e que escolher uma abordagem, UML, BPMN, ou uma combinação, é apenas um dos aspectos a serem considerados.

Muito do sucesso de uma abordagem baseada em processo, reside na participação efetiva dos stakeholders responsáveis pelos processos de negócios no levantamento das informações relativas a estes processos.

Referências



ERIKSSON, H. E.; PENKER, M. Business Modeling with UML. New York: John Wiley & Sons, 2000.




25


O Padrão XML

“O principal mérito da linguagem é a clareza” (Galen)

Muito provavelmente você já deve ter ouvido falar em XML (Extensible Markup Language). Mais do que uma linguagem de marcação (por definição), ou um termo chave da web, XML é uma tecnologia que, conforme Hunter et al. (2007), rapidamente se mostrou capaz de, através de seu desenvolvimento, oferecer suporte a aplicações “do mundo real”, muito especialmente àquelas relacionadas ao gerenciamento e organização de dados. A possibilidade de combinação com outras tecnologias lhe atribuiu o status de “essencial para qualquer um que trabalha com dados” (HUNTER et al., 2007, p. 2), seja na web, seja na intranet da própria organização.

Remexendo um pouco na história da XML, percebe-se que, quando se fala que esta linguagem amadureceu rapidamente, está-se realmente falando no sentido literal da palavra. Em um curtíssimo espaço de tempo, compreendido em praticamente uma década, pôde-se presenciar seu nascimento e estabelecimento como tecnologia forte.

Você sabia?Em 10 de Fevereiro de 1998, o W3C (World Wide Web Consortium) publicou a XML 1.0 como uma Recomendação W3C (W3C, 2008). Por essa razão, o ano de 2008 marcou as comemorações do décimo aniversário da XML através de registros de felicitações da comunidade XML no web site do W3C.

O surgimento da XML e de outras linguagens semelhantes e anteriores baseia-se em uma ideia que sempre esteve presente nas mentes dos programadores: a criação de um formato universal de dados, que tornasse a troca de informações entre diferentes plataformas mais simples (HUNTER et al., 2007).

Uma tentativa inicial de criar esse formato universal remete ao final da década de 1970, com a Standard Generalized Markup Language (SGML). Projetada para ser um formato padrão de marcação de dados para qualquer propósito, a SGML

26

Pós-graduação

combinava um modelo de dados intercambiável universal com capacidade de armazenamento. Mostrou-se promissora e, em 1986, alcançou o status de padrão internacional. Contudo, apesar de poderosa, a SGML mostrou-se uma linguagem complicada. Era necessário algo com suas características, mas que mantivesse a simplicidade (HUNTER et al., 2007; DEITEL et al., 2003).

A tentativa seguinte gerou uma linguagem muito popular, baseada em SGML: a HTML (HyperText Markup Language). Utilizando muitos conceitos da SGML, a ideia que cercava a HTML era a de que qualquer documento nesta linguagem seria apresentável em qualquer navegador web (HUNTER et al., 2007).

De fato, segundo o mesmo Hunter et al., (2007), HTML alcançou um incrível sucesso, mas, com o passar do tempo, percebeu-se a existência de um escopo limitado: seu uso estava restrito à apresentação de dados somente. Existia uma lacuna a ser preenchida, pois HTML não possui em seu conjunto de tags recursos capazes de descrever o conteúdo, mas somente formatá-lo para apresentação. A XML foi criada para se dedicar a estes aspectos.

Assim, o ano de 1996 marcou o início dos trabalhos empreendidos pelo W3C na realização do projeto de uma linguagem de marcação que combinasse atributos como flexibilidade e capacidade (características da SGML) e que fosse largamente aceita pela comunidade de desenvolvedores, como a HTML o foi (ANDERSON et al., 2001).

Uma linguagem de marcação extensível por definição, XML é considerada um subconjunto da SGML simplesmente porque realiza a marcação de qualquer tipo de dados, porém sem a complexidade de sua “mãe” (HUNTER et al., 2007).

Conceito-chave“É importante compreender que XML não é realmente uma ‘linguagem’, mas um padrão para a criação de linguagens que conhecem o critério XML [...]. Em outras palavras, XML descreve a sintaxe que você usa para criar suas próprias linguagens.” (HUNTER et al., 2007).

De lá para cá, a XML converteu-se na primeira linguagem de marcação capaz de tornar documentos compreensíveis por pessoas e manipuláveis por computadores. Isso é possível, devido à possibilidade de utilização de marcações (tags) mais poderosas, flexíveis e, especialmente, extensíveis (DEITEL et al., 2003). Por representar uma maneira simples e padrão de delimitar dados, é considerada a linguagem do documento inteligente (ANDERSON et al., 2001; DEITEL et al., 2003).

27

O Padrão XML

Percebe-se, então, que se trata de uma tecnologia preocupada com a descrição e estruturação de dados (HUNTER et al., 2007). Em outras palavras, XML gerencia dados, habilitando seu uso, por exemplo, para a realização de intercâmbio de dados, ou para a implementação da camada intermediária de aplicações cliente/servidor (DYKES; TITTEL, 2005; DEITEL et al., 2003).

Merecem, ainda, destaque outras características igualmente importantes, que contribuíram para a expansão da XML. Apesar de ser baseada em texto, XML não está limitada à descrição de dados textuais, podendo descrever imagens ou gráficos vetoriais com a mesma desenvoltura (DEITEL et al., 2003).

Além disso, documentos XML não são limitados a uma plataforma específica, ou seja, trata-se de uma tecnologia aberta e não proprietária. Entende-se por “aberta” o fato de ser muito bem documentada e amplamente disponível, e “não proprietária” por ser disponibilizada em uma forma que não é de propriedade exclusiva de nenhum indivíduo ou empresa (DYKES; TITTEL, 2005).

Não é de se surpreender que XML tenha se tornado a melhor escolha para troca de dados; uma escolha útil e consistente na manipulação de dados oriundos de múltiplas aplicações (e múltiplas plataformas), com o máximo de eficiência (DYKES; TITTEL, 2005).

Referências

ANDERSON, Richard et al. Professional XML. Rio de Janeiro: Ciência Moderna, 2001.

DEITEL, H. M et al. XML como programar. Porto Alegre: Bookman, 2003.

DYKES, Lucinda; TITTEL, Ed. XML for dummies. 4 ed. Indiana: Wiley Publishing, 2005.

HUNTER, David et al. Beginning XML. 4 ed. Indiana: Wrox Press, 2007.

W3C. World Wide Web Consortium. 2008. Disponível em: <http://www.w3.org/2008/xml10/>. Acesso em: 20 fev. 2008

29

Arquitetura Orientada a ServiçosCarlos André de Sousa Rocha

A camada Web Service expõe as funcionalidades da camada de aplicação como um serviço. Desta forma, múltiplos processos de negócios podem ser reusados com serviços, o que representa a promessa SOA (Service-Oriented Architecture – Arquitetura Orientada a Serviços). (BLANVALET, 2006, p. 65).

Na frase acima, você percebe a relação conjugada entre processos de negócios e a abordagem orientada a serviços? Vamos, então, a alguns conceitos sobre SOA.

Erl (2009, p. 24) define SOA como

[...] uma arquitetura que visa aprimorar a eficiência, a agilidade e a produtividade de uma empresa, posicionando os serviços como os principais meios para que uma solução lógica seja representada no suporte à realização dos objetivos estratégicos associados à computação orientada a serviços.

Conceito-chave“Serviços são programas de software fisicamente independentes, com características de design distintas que dão suporte à obtenção dos objetivos estratégicos associados à computação orientada a serviços.” (ERL, 2009, p. 25).

Um serviço pode conter uma coleção de capacidades que são executadas em determinado contexto funcional específico determinado pelo serviço (ERL, 2009).

O serviço atua baseado em duas premissas “objetivos estratégicos”, o que uma organização deseja com o seu negócio, e “contexto funcional específico”, atividade básica de um processo de negócio. Você percebeu que os serviços compõem processos de negócios e que desta forma podem viabilizar as estratégias de uma organização?

30

Pós-graduação

Para uma ideia mais clara de serviço, capacidades e processos de negócios, vejamos um exemplo.

Em uma atividade de delivery de uma cadeia fast-food, uma pessoa

pode para um serviço de entrega: separar os itens para entrega, dirigir o

automóvel para entrega e receber o pagamento. Temos aqui:

1 . O processo de negócio - realizar pedido;

2. Um serviço deste processo - entrega;

3. As capacidades deste serviço - separar os itens para entrega, dirigir o

automóvel para entrega e receber o pagamento.

Serviços são criados para suportar uma lógica de negócios existente em um determinado processo organizacional (ERL, 2009).

A relação entre processos de negócios e serviços de negócio são traçados por Jones (2006, p. 9):

• O que: define o escopo do serviço, o que o serviço quer representar;

• Quem: são os participantes que conduzem o serviço ou com quais serviços interagem;

• Porque: um serviço conversa com outro e que participantes externos interagem com estes serviços:

• Como: detalhes dos processos que coordenam os serviços e detalhes de como o serviço será implementado.

Um exemplo que reponde a estas perguntas pode ser visualizado através da Figura 1, a qual representa as interfaces participantes no processo de negócio

“ordem de compra”. Isto também justifica a implementação SOA utilizada pela tecnologia jBPM para execução de processos de negócios. A Figura 1 mostra um modelo de arquitetura para implementação de uma infraestrutura SOA.

31

Arquitetura Orientada a Serviços

Componentes do Projeto ou Organização

Sistemas Operacionais

Mainframe

Portlets WSRP

IBM AS/400

BusinessInteligence

CRM, ERP, ...

Orientação a Objetos

Componentes Organizacionais

Serviços Compostos

Serviços

Coreografia dos processos de

negócios

Apresentação

Arquitetura de Integração

QoS, Segurança, G

erenciamento e

Monitoram

ento

Figura 1 - Arquitetura para uma implementação SOA. Fonte: Arsanjani, 2004.

A Figura 2 apresenta um modelo com os elementos tecnológicos envolvidos em uma requisição/negociação SOA entre um consumidor e um provedor de serviços.

<<usa>> <<realiza>>

<<descrito em>><<contem>>

n

Consumidor obtém Descrição do Serviço do Negociador ou diretamente do Provedor

(o Negociador é opcional)

Consumidor do Serviço Descrição do Serviço

Negociador do Serviço

findService()

Provedor do Serviço

invokeService()bindtoService()

Figura 2 - Modelo Conceitual SOA. Fonte: Arsanjani, 2004.

32

Pós-graduação

O surgimento de modelos de negócios baseados em processos de negócios fez com que surgissem alternativas tecnológicas que viabilizassem sua implementação e a abordagem baseada em serviços oferecidos pelo SOA (RAISCH, 2007).

Processos organizados por serviços

[...] possibilitam que a empresa tenha maior facilidade em identificar quais os componentes que lhe proporcionam diferenciais competitivos e quais não. Com isso é possível definir as áreas que merecem investimentos, as que devem ser mantidas dentro da empresa, as que podem ser terceirizadas, as áreas a serem fechadas e os produtos que devem ser adquiridos no mercado (RAISCH, 2007, p. 1).

Pode-se pensar que a arquitetura orientada a serviços vem-se tornando uma interessante alternativa para implementação de uma arquitetura baseada na gestão de processos. SOA permite que soluções BPMS possam incorporar uma maior flexibilidade em seus componentes.

Referências

ARSANJANI, Ali. Service-Oriented Modeling and Architecture. 2004. Disponível em: <http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/>. Acesso em: 07 out. 2008.

BLANVALET, Stany et al. BPEL Cookbook: Best Practices for SOA-based integration and composite applications development. Birmingham: Packt Publishing, 2006.

ERL, Thomas. SOA: Princípios de Design de Serviços. São Paulo: Pearson Prentice Hall, 2009.

JONES, Steve. Enterprise SOA Adoption Strategies. XXX: C4Media, 2006.

RAISCH, Daniel. SOA Como Plataforma de Negócios. 2007. Disponível em: <http://www.portalbpm.com.br/servlet/leartigo?qual=/WEB-INF/artigos/arquivados/file15.pdf>. Acesso em: 04 ago. 2008.

33

A Cultura Organizacional e a Gestão por Processos de Negócios


A implementação da gestão por processos de negócios está intimamente relacionada a alguns aspectos essenciais a serem considerados em uma organização. Assim, devem ser considerados elementos relacionados à cultura organizacional, aqueles elementos que atribuem uma identidade única e individual a cada organização, bem como as questões relacionadas à infraestrutura de trabalho propriamente dita para a gestão por processos de negócios.

Avaliando-se primeiramente as questões relacionadas à infraestrutura de trabalho, de acordo com Baldam et al., (2007), para se executar o gerenciamento por processos faz-se necessária a existência de uma estrutura mínima, composta de pessoas, cujos papéis exercidos são bem definidos (aspecto primordial para o acompanhamento de metas), além de espaço físico adequado, dotado de recursos tecnológicos e ambiente para publicação de resultados.

Esta estrutura pode ser organizada, conforme Baldam et al., (2007), levando-se em conta as divisões de equipe, infraestrutura física, infraestrutura de software e manual do modelo de BPM.

A forma como a equipe para BPM será composta está diretamente relacionada às políticas da organização. No entanto, é desejável que a equipe demonstre competências para atuar segundo uma abordagem de organização matricial. Isso significa dizer que, no estudo de um processo, os indivíduos de diversos departamentos estarão envolvidos (BALDAM et al., 2007).

Baldam et al., (2007) sugere a determinação de três equipes:

(1) equipe de BPM (permanente): responsável pela coordenação das ações de BPM na empresa, esta equipe é basicamente formada por um gerente de BPM ou CPO (Chief of Process Office), pelos líderes de processo e por um auditor de processos;

(2) equipe do processo (temporária): sua função é atuar sobre um processo específico. Esta equipe, multidisciplinar, é formada pelo dono do processo, pelo gestor do processo, pelo líder do processo, pelos gerentes funcionais, por especialistas no tema e pela equipe de tecnologia da informação; e

34

Pós-graduação

(3) equipes de contato e avaliação (podem ser externas à organização): muito úteis na oferta de consultorias, fornecendo os subsídios necessários para avaliar resultados dos processos em execução.

Em relação à infraestrutura física, é desejável que ofereça quadros com pincéis coloridos (necessários para a representação de esquemas e apresentação de resultados das reuniões), paredes/painéis amplos onde os esquemas dos processos possam ser afixados, mesa de reunião, recursos de projeção de alta resolução, computadores (BALDAM et al., 2007).

No tocante à infraestrutura de software, sua disponibilização está diretamente relacionada a dois aspectos primordiais: à metodologia adotada pela organização e ao nível de especialização do BPM. Não obstante, normalmente conta-se com os seguintes itens: ferramenta de modelagem, simulador, editor de textos, planilha eletrônica, ambiente de publicação (internet ou rede interna, por exemplo) (BALDAM et al., 2007).

Finalmente, Baldam et al. (2007, p. 63) salientam a utilidade em se adotar um manual do modelo de gerenciamento por processos; em outras palavras, um documento que apresente as informações básicas sobre como “o BPM é conduzido na organização, como os processos são escolhidos, como é modelado e otimizado, como é implantado um novo processo e como processos em andamento passarão a ser monitorados”. É importante que o manual esteja completamente alinhado à estratégia da organização e sirva como um modelo esclarecedor dos propósitos que conduziram à implantação da gestão por processos.

No tocante à cultura organizacional, é importante que a empresa passe a compreender melhor os princípios relacionados à implementação da gestão por processos de negócio, às técnicas utilizadas e aos fundamentos necessários “para iniciativas de orientação por processos de negócios” (SORDI, 2006, p. 159).

Além disso, deve-se considerar a necessidade da revisão da importância exercida pelos recursos tecnológicos que compõem uma estrutura mínima desejável (conforme afirmado por Baldam (2007) e apresentado anteriormente neste texto).

Sordi (2006) baseia-se nas obras de Hammer e Champy, Process inovation, e de Davenport, Reengineering the corporation, para apresentar um resumo sobre a postura a ser assumida por uma organização que passará por esse tipo de reestruturação, ou seja, que deseja implantar a gestão por processos de negócios. Cabe mencionar que, como em qualquer outro processo de mudança, além dos benefícios alcançados, potenciais restrições devem ser superadas para que se alcance o sucesso definitivo.

35

A Cultura Organizacional e a Gestão por Processos de Negócios

Por essa razão, dar-se-á aqui ênfase ao conjunto de elementos que constituem desvantagens e dificuldades para o negócio da organização, dada sua postura intra e interorganizacional.

Assim, conforme Sordi (2006), a empresa que possui barreiras internas entre as áreas funcionais prejudica seu negócio, dada a identificação de indicadores, tais como:

• comunicação ineficaz entre as áreas funcionais, acarretando falta de visão do negócio como um todo;

• falta de responsabilidade sobre o produto final: desta forma, os problemas serão percebidos somente quando o produto é acabado ;

• alienação por parte dos colaboradores;

• atrasos e demoras; retrabalho;

• falta de sinergia.

Considerando este cenário intraorganizacional, podem ser identificados os seguintes fatores como principais dificuldades para a remoção destas barreiras (SORDI, 2006):

• competitividade e dificuldade de comunicação entre as áreas funcionais, dadas diferenças culturais e de métodos de trabalho;

• desconhecimento do trabalho realizado em outras áreas funcionais;

• disputas pelo poder;

• falta de consciência no tocante às responsabilidades que cercam o trabalho final;

• cultura de informações não compartilhadas;

• necessidade de integração entre os sistemas de informação.

Convém mencionar que, da mesma forma, a empresa que possui barreiras com as demais empresas com as quais se relaciona, possui uma relação de desvantagens a se considerarem (SORDI, 2006):

• perda de flexibilidade, tempo e competitividade;

• dificuldades para negociação;

• acúmulo de estoques e aumento de custos;

• maior necessidade de investimento em qualidade e inovações;

• minimização das margens;

• ineficiência como um todo.

36

Pós-graduação

Para que as barreiras interorganizacionais supracitadas sejam removidas, Sordi (2006) cita como algumas das principais dificuldades: perceber que o processo tem seu início e fim fora da empresa; os padrões de comportamento entre as organizações assumem o perfil “ganha-perde”; dificuldades em manter o espírito de parceria, fazendo com que informações não sejam compartilhadas entre as empresas; visão focada nos próprios ganhos; dificuldades de compreender culturas diferentes.

Finalmente, deve-se compreender que há uma série de formas disponíveis para se desenvolver o aprendizado organizacional e que estas devem envolver todos os indivíduos relacionados à organização (internos e externos). Esta combinação de elementos conduzirá então ao sucesso desta etapa (SORDI, 2006).

Referências



Conforme Baldam (2007), o avanço e popularização massivos do uso de microcomputadores e demais recursos de tecnologia da informação (TI) contribuíram de forma decisiva para o BPM nas organizações, considerado a terceira onda do uso dos processos nas organizações.

Tido como recurso restrito e não totalmente disseminado até a década de 1990, o uso dos computadores não permitia o apoio da TI nos processos de negócios de uma organização, de forma que fossem implantados em sua totalidade (BALDAM, 2007). Ainda assim, o final do século XX foi marcado por vultosos desenvolvimentos de TI (mencione-se telefonia móvel, transferências eletrônicas e a internet como alguns dos mais importantes), os quais contribuíram sobremaneira para as mudanças organizacionais que se seguiriam, relacionadas especialmente às possibilidades de uso de processos nas empresas (BALDAM et al., 2007).

37


Tecnologia da Informação e Gestão por Processos de Negócios

Conforme Baldam (2007), o avanço e popularização massivos do uso de microcomputadores e demais recursos de tecnologia da informação (TI) contribuíram de forma decisiva para o BPM nas organizações, considerado a terceira onda do uso dos processos nas organizações.

Tido como recurso restrito e não totalmente disseminado até a década de 1990, o uso dos computadores não permitia o apoio da TI nos processos de negócios de uma organização, de forma que fossem implantados em sua totalidade (BALDAM, 2007). Ainda assim, o final do século XX foi marcado por vultosos desenvolvimentos de TI (mencione-se telefonia móvel, transferências eletrônicas e a internet como alguns dos mais importantes), os quais contribuíram sobremaneira para as mudanças organizacionais que se seguiriam, relacionadas especialmente às possibilidades de uso de processos nas empresas (BALDAM et al., 2007).

Conforme Baldam et al., (2007, p. 135), “Atualmente, o ambiente de negócios é muito mais complexo e regulamentado do que no passado e a tendência é de assim permanecer”. Em termos gerais, o emprego da TI que tem por finalidade apoiar o uso do BPM proporciona várias oportunidades as quais, a princípio, possuem objetivos de redução de custos, de tempo e assim por diante.

Não é difícil, então, perceber que a TI tem especial importância para a abordagem de processos de negócio em uma organização, pois, além da sua utilização na automatização de tarefas e na própria execução dos processos, conforme Gonçalves (2000), as diversas tecnologias atualmente disponíveis podem ser largamente utilizadas como forma de apoio em diversas atividades de gestão desses processos.

Os investimentos cada vez mais recorrentes por parte das organizações em aplicações de TI como apoio aos seus processos (de negócio, ou não) mais importantes são justificados pela possibilidade de aperfeiçoamento de seu desempenho (GONÇALVES, 2000).

É importante compreender que a TI exerce um papel fundamental no tocante ao estudo e uso dos processos de negócio nas organizações, principalmente pelo fato de influenciar o trabalho de uma organização sob dois aspectos: na forma de realizar o trabalho e na forma de gerenciar o trabalho (GONÇALVES, 2000).

A TI influencia na “forma de realizar o trabalho”, porque envolve alterações que vão desde o trabalho individual até o trabalho interorganizacional (quando empresas

38

Pós-graduação

trabalham juntas). Isso implica uma redefinição “da maneira pela qual os grupos de pessoas realizam suas tarefas grupais” (GONÇALVES, 1993 apud GONÇALVES, 2000, p. 17).

É importante mencionar a influência da TI no trabalho interorganizacional exatamente porque os processos de negócios atuais envolvem cada vez mais empresas parceiras colaborativamente. Consequentemente, uma diversidade maior de tecnologias é envolvida nos processos. Logo, não se pode também ignorar que esta variedade de sistemas de informação, plataformas de softwares e demais recursos de TI conduzem a problemas, gerados exatamente pelas dificuldades em se gerenciar (ou mesmo modificar) este “emaranhado” tecnológico envolvido nas atividades de gestão dos processos de negócio (SORDI, 2006).

Imprime-se a partir deste contexto uma necessidade vital de aprendizado e modificação na forma de se gerenciar o trabalho. O uso da TI induz algumas modificações e facilita a ocorrência de outras. Segundo Gonçalves (2000), os sistemas integrados de gestão empresarial tão empregados atualmente exigem que os indivíduos de uma organização passem a realizar suas tarefas conforme rotinas e procedimentos instituídos pela tecnologia (por maior que seja a diferença com relação aos padrões anteriores). Exatamente por causa disso é que se considera a TI como “a ferramenta do redesenho de processos por excelência” (GONÇALVES, 1995a apud GONÇALVES, 2000, p. 18).

Impõe salientar, por fim, que o uso de TI exige necessariamente que prioridades de tratamento de processos sejam definidas: deve-se imprimir maior dedicação e esforço àqueles processos mais importantes, de modo a se garantirem resultados realmente relevantes para o negócio da empresa (GONÇALVES, 2000).

Caso não haja uma seleção adequada dos processos de negócio a serem tratados, fatalmente continuará a ser trilhado um caminho onde maciços investimentos em TI resultam em efeitos inexpressivos (causa de decepções), dado o fato de que se dedicou atenção (e automatização) a processos que geram pouco ou nenhum valor para a empresa, tais como, funções administrativas. (GONÇALVES, 2000).

Referências


GONÇALVES, José Ernesto Lima. As empresas são grandes coleções de processos. Revista de Administração de Empresas, São Paulo, v. 40, n.1, Jan./Mar. 2000. Disponível em: <http://www.fgvsp.br/rae/artigos/006-019.pdf>. Acesso em: 02 fev. 2009.


39

A Tecnologia jBPMCarlos André de Sousa Rocha *

O jBPM é uma solução tecnológica para o gerenciamento e orquestração de processos de negócios oferecido pela JBoss (REDHAT, 2007).

Esta solução permite que organizações implementem e automatizem processos de negócios conduzidos por pessoas, aplicações e serviços. A execução e integração dos processos de negócios é alcançada através de serviços implementados em uma infraestrutura SOA (Service Oriented Architecture – Arquitetura Orientada a Serviços) (REDHAT, 2007).

REDHAT (2007) afirma ainda que a arquitetura de implementação jBPM lida com as mais variadas tecnologias padrões de mercado, como integração em J2EE, como Web Services, Java Messaging, J2EE, Connectors, JDBC e EJBs. Isto permite que os processos sejam gerenciados e auditados de maneira automatizada.

Como uma solução BPMS prevê a utilização de uma linguagem de execução, a JBoss jBPM suporta uma linguagem de execução chamada jPDL (Process Defnition Language – Linguagem de Definição de Serviços), além de suportar o modelo BPEL para orquestração de Web Services. Características de Workflow também são integradas à solução no sentido de permitir gerenciamento de fluxo de trabalho e gerenciamento de tarefas humanas (REDHAT, 2007).

A Figura 1 apresenta o desenho da arquitetura jBPM, mostrando um detalhamento desta arquitetura através de seus elementos. Aí podemos perceber a conformidade com a arquitetura BPMS, uma vez que suporta definições de serviços (processos) através do desenvolvedor do processo, sua administração, sua execução e definição de fluxos de trabalhos pelos usuários, além da integração com várias soluções como ERP, CRM (Customer Relationship Management – Gestão do Relacionamento com o Cliente) e SCM (Supply Chain Management – Gestão da Cadeia de Suprimentos) (KOENIG, 2004).

* ROCHA, Carlos André de Sousa. A Tecnologia jBPM. Curso de Especialização em Gerência de Projetos de Tecnologia da Informação: material didático on-line da disciplina Fundamentos em Business Process Management (BPM) / Workflow. Palhoça: UnisulVirtual, 2009.

40

Pós-graduação

JBPM

JPDL

GPD IdentidadeGerenciamento

de tarefas Organização

BPEL Page�ow ...

Process Virtual Machine (PVM)

Figura 1 - Elementos da Arquitetura jBPM. Fonte: JBoss, 2008a.

Todos os elementos apresentados na arquitetura jBPM têm uma correspondência com as camadas do ecossistema BPMS apresentado na Figura 2. Nela você pode observar que as camadas de processos e aplicações estão relacionadas ao desenvolvedor do processo, a integração organizacional está relacionada com a integração com soluções ERP, CRM e SCM, enquanto que o monitoramento do processo é realizado pela figura de um administrador na arquitetura jBPM.

Desenvolvedor de processos Administrador

Serviços de administração

Serviço de definição

Serviço de execução

SistemasUsuários

JB oss jBPM

ERP SCM CRM

Figura 2 - Elementos da Arquitetura jBPM e seus Participantes. Fonte: JBoss, 2008b

A Tecnologia jBPM

41

As características a seguir são apresentadas por Koenig (2004, p. 5) como existentes na tecnologia JBoss jBPM:

• Fornece componentes de aplicação em uma aplicação corporativa;

• Oferta de aplicações baseadas em processos;

• Participa como componente de uma arquitetura corporativa.

Conforme lhe foi apresentado, a tecnologia jBPM possui ainda um componente de linguagem de execução, chamada jPDL, além de oferecer implementações utilizando o padrão BPEL. A Figura 3 mostra a relação entre estas duas linguagens de execução.

Designer Gráfico Aplicação Organizacional

bpel.jar jpdl.jar

hibernate.jar

Qualquer banco de dados

Web Service

jBPM BPEL

<process><vars/><flow/></process>

Figura 3 - Relação entre jBPM e jPDL. Fonte: JBoss, 2008b.

Embora haja a necessidade de a tecnologia jBPM evoluir um pouco mais na automatização de fluxos de atividades (workflow) e amadurecer a utilização do padrão BPEL, ela se mostra uma solução robusta e acessível para pequenas, médias e grandes organizações.

42

Pós-graduação

Referências

JBOSS. Welcome to jBPM: Multiple Process Languages Embeddable In Your Java Application. Disponível em: <http://www.jboss.org/jbossjbpm/downloads/>. Acesso em: 04 ago. 2008a.

_________. Welcome to jBPM: Service Orchestration. Disponível em: <http://www.jboss.org/jbossjbpm/bpel/>. Acesso em: 04 ago. 2008b.

KOENIG, John. JBoss jBPM White Paper. 2004. Disponível em: <http://www.br.redhat.com/pdf/jboss/jBPM_white_paper_portugues.pdf >. Acesso em: 04 ago. 2008.

REDHAT. JBoss jBPM. 2007. Disponível em: <http://www.br.redhat.com/pdf/jboss/jBPM.pdf>. Acesso em: 04 ago. 2008.

43

As Linguagens de Execução e os Processos de Negócio

Carlos André de Sousa Rocha *

Linguagens de Execução são linguagens que definem o comportamento, implementação e interoperabilidade de um processo de negócio, permitindo orquestração, coreografia e colaboração entre processos de negócio. BPEL (Business Process Execution Language – Linguagem para Execução de Processos de Negócio) especifica o comportamento de um processo de negócio baseado em Web Services, sendo conhecida como WS-BPEL (OASIS, 2007).

Processos descritos usando a WS-BPEL têm a capacidade de exportar e importar funcionalidades com o uso de interfaces Web Services (OASIS, 2007).

Conceito-chaveWeb Service é um padrão usado como ponto de integração em aplicações de negócio tradicionais na Internet, e fornece uma interface comum que, independentemente da origem, unifica o modelo de integração para todos os serviços. (MACEDO, 2006, p. 37).

Em meados de 2002, IBM, Microsoft e BEA criaram a BPEL, utilizando as características dos Web Services implementados pela Web Service Flow Language da IBM e da XLAN da Microsoft. Em 2003, BPEL foi submetida ao OASIS (Organisation for the Advancement of Structured Information Standards – Organização para o Avanço do Padrão de Informação Estruturada) para torná-la um padrão aberto para a orquestração de processos com Web Services (MACEDO, 2006).

Para Blanvalet (2006), BPEL não constitui apenas mais um produto ou padrão lançado pela indústria de software, mas sim uma maneira de garantir que as organizações tenham a habilidade de modificar suas aplicações conforme possíveis mudanças em seu horizonte de negócio. Com BPEL, uma organização automatiza seus processos de negócio através da orquestração entre eles.

* ROCHA, Carlos André de Sousa. As Linguagens de Execução e os Processos de Negócio. Curso de Especialização em Gerência de Projetos de Tecnologia da Informação: material didático on-line da disciplina Fundamentos em Business Process Management (BPM) / Workflow. Palhoça: UnisulVirtual, 2009.

44

Pós-graduação

Conceito-chaveOrquestração entre processos representa a visão da organização de seus processos, seu negócio específico. Coreografia entre processos é o comportamento esperado entre a interação de participantes do negócio, onde estes participantes podem ser regras de negócio ou uma entidade de negócio específica, como por exemplo, os Correios ou uma transportadora. Já a colaboração entre processos é uma espécie de coreografia que define um conjunto de interações ordenadas entre os participantes de um processo (WHITE; MIERS, 2008, p. 29).

Ainda nas palavras de Blanvalet (2006), BPEL permite a orquestração de processos interorganizacionais baseados na integração de processos, para que companhias construam uma rede colaborativa e on-line de negócios.

Mas, como os processos de negócios podem ser transformados em uma linguagem de execução?

Como você aprendeu sobre a tecnologia XML, ela permite uma integração e interoperabilidade entre plataformas diferentes, fato que está em total conformidade com as características apresentadas da BPEL.

Um processo BPEL é um documento XML que atende a um trabalho de mais alto nível realizado por analistas de negócio e atividades mais específicas de implementação realizada pelos desenvolvedores (MACEDO, 2006). Esta linguagem de execução utiliza a tecnologia XML para acessar dado, enquanto que os Web Services são utilizados para serialização de dado (BLANVALET, 2006). A serialização é uma técnica de persistência de dados através de uma sequencialização destes para posterior armazenamento em um arquivo XML, um arquivo texto e até um banco de dados.

Quanto ao uso do BPEL, podemos esperar aumento de produtividade, redução de custos e melhoria do nível de serviços automatizados, utilizando-se tecnologias de padrões abertos. Um dado importante é o fato de o uso de Web Service prever o uso de padrões de mercado. Se uma empresa usa softwares proprietários, o método tradicional para se fazer a integração de processos consiste em modificações no código das aplicações, pela equipe de TI. O desenvolvimento, os testes e o esforço de implantação são muito caros e complexos (MACEDO, 2006, p. 37).


45

A materialização das características da BPEL propiciadas pela tecnologia XML permite um conjugado entre o dual negócio e TI, uma vez que negócios são executados através de seus processos e a TI fornece a infraestrutura necessária para executar e automatizar estes processos.

Vejamos, então, como se relacionam as camadas de processos de negócio (processos BPEL), de Web Services e das regras de negócio destes processos.

A Figura 1 mostra como uma lógica de negócio está inserida em uma arquitetura de níveis através de três diferentes camadas de uma infraestrutura de TI. A camada de processos de negócio é responsável por gerenciar toda a execução dos processos de negócio implementados usando BPEL. A camada de Web Services expõe as funcionalidades da camada de aplicação como serviços, já que múltiplos processos de negócios podem acessar um mesmo serviço. E, finalmente, a camada de regras de negócio que trata da complexidade das lógicas existentes no negócio (a inteligência do negócio) entre as várias entidades participantes do negócio (BLANVALET, 2006).

Camada de Processos de Negócios

Servidor de Aplicação

Processo BMP

Camada de Serviços Web (Web Services)

Camada de Regras

RegrasServiços Web

Execução das Regras

Banco de Dados

Java, Net, Phyton,

Delphi, etc.

Aplicações Legais

Aplicações Backend

Serviços Web Serviços Web

Figura 1 - Camadas de execução para a arquitetura de um processo de negócio utilizando BPEL. Fonte: Adaptado de Blanvalet (2006, p. 64).

46

Pós-graduação

Veja agora como um processo de negócio é mapeado para um arquivo XML A Figura 2 apresenta o exemplo de uma ordem de compra: este processo será mapeado através de um arquivo XML para a BPEL. Sua lógica de execução é descrita como segue.

Ao receber a ordem de compra de um cliente, o processo inicia três caminhos concorrentemente: cálculo do preço final da ordem, seleção de uma transportadora e agendamento da produção e carregamento da ordem solicitada. Observe que algum processamento ocorre concorrentemente, existindo dependências de controle e dados entre os três caminhos. Em particular, o preço do carregamento é requerido para finalizar o cálculo do preço, e a data do carregamento é requerida para o cumprimento da agenda. Quando os três caminhos concorrentes são completados, o processamento da fatura pode prosseguir e a fatura é enviada para o cliente.


47

Recebimento da Ordem da Compra

Processamento da Fatura

Cálculo Inicial do Preço

Cálculo Completo do Preço

Organizar Logística

Agendamento Completo da

Produção

Decidir Transportador

Agendamento Inicial da Produção

Figura 2- Processo de Negócio Ordem de Compra. Fonte: Adaptado de Oasis (2006, p. 15).

As interfaces existentes para os participantes do processo são mostradas na Figura 3.

ProcessoprocessoOrdemCompra

OrdemCompraPT

Interface do Particiapante carregamento

Interface do Particiapante pedido

calcularPreçoPT

retornarFaturaPT

carregarPT

retornarCarregamentoPT

agendarPT

Interface do Particiapante fatura

Interface do Particiapante agendamento

Figura 3 - Interfaces para os Participantes do Processo Ordem de Compra. Fonte: Adaptado de Oasis (2006, p. 16).

48

Pós-graduação

As descrições das interfaces da Figura 3, juntamente com a implementação BPEL do processo apresentado, são mostradas no Quadro 1.

Quadro 1 - Mapeamento entre BPEL e XML para o Processo de Negócio Pedido de Compra. Fonte: Oasis (2006, p. 16).


49

Você observou que as Linguagens de Execução são um componente essencial para que processos de negócios possam ser implementados e orquestrados em um ambiente organizacional. Esta orquestração é viabilizada pela tecnologia XML, já que prevê uma integração e interoperabilidade entre padrões e plataformas distintas, o que faz com que um processo de negócio seja reutilizável.

Referências

BLANVALET, Stany et al. BPEL Cookbook: Best Practices for SOA-based integration and composite applications development. Birmingham: Packt Publishing, 2006.

MACEDO, Sifredo. Introdução ao BPEL e à Orquestração de Serviços. Revista PortalBPM. Ano 1, n. 2, São Paulo, PortalBPM, 2006, p 37. Disponível em: <http://www.portalbpm.com.br/servlet/leartigo?qual=/WEB-INF/artigos/digital/PortalBPM2.pdf>. Acesso em: 10 ago. 2008.

OASIS. Web Services Business Process Execution Language Version 2.0. 2007. Disponível em: <http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf>. Acesso em: 21 abr. 2009.


51

Das Funções de Negócio aos Processos de Negócio


Para uma compreensão mais adequada de como e por que algumas Organizações atualmente vêm buscando estruturar suas atividades através de Processos de Negócios, você precisa entender como este conceito evoluiu das tradicionais Funções Empresariais.

Então, que tal saber como as Funções Empresariais estão caminhando para os Processos de Negócio?

Sordi (2006) afirma que um aspecto bem característico de diversas organizações é a utilização de uma estrutura organizacional baseada na concepção de “silos funcionais”. Nas palavras do autor, estes “‘silos’ executam e gerenciam um conjunto de atividades bastante específicas e especializadas” (SORDI, 2006, p. XIII).

As décadas de 1980 e 1990 implantaram e impulsionaram o movimento pela qualidade total, que propagou para as décadas seguintes um grande movimento pela especialização das áreas funcionais, visando suas competências básicas (SORDI, 2006).

Propostas como BPR (Business Process Reengineering - Reengenharia de Processos de Negócio) e BPD (Business Process Design - Desenho de Processos de Negócio) na década de 1990 direcionaram as organizações aos processos de negócio. Este tipo de organização difere dos tradicionais “silos funcionais”, uma vez que preza pela redução de interferências e perdas consequentes das comunicações entre organizações, áreas funcionais e níveis hierárquicos (SORDI, 2006).

O conceito de Função Empresarial data da década de 1920, inserido por Frederick Taylor, e está diretamente ligado à especialização de atividades e profissionais em torno de áreas ou departamentos de uma organização especializada por sua vez na execução de determinadas funcionalidades do negócio, isto é, centradas nos

“silos funcionais”.

* ROCHA, Carlos André de Sousa. Das Funções de Negócio aos Processos de Negócio. Curso de Especialização em Gerência de Projetos de Tecnologia da Informação: material didático on-line da disciplina Fundamentos em Business Process Management (BPM) / Workflow. Palhoça: UnisulVirtual, 2009.

52

Pós-graduação

Baldam et al. (2007) afirmam que uma organização com uma gestão unicamente baseada em processos corresponde a uma idealização e que a visão funcional continua coexistindo com a visão baseada em processos.

Mas e os Processos de Negócio? O que são? Como eles são criados e executados dentro de uma organização? Como a Modelagem de Processos é utilizada para a identificação dos processos?

Para obter estas respostas, veja este conceito, mostrado de forma mais detalhada na sequência do texto.

As organizações operacionalizadas e geridas utilizando processos de negócio são intituladas de organizações “Orientadas a Processos”. As tradicionais, que operam por meio de áreas funcionais hierárquicas, são denominadas “Orientadas, baseadas, a Funções” (SORDI, 2006).

Dávalos (2006) mostra que a visão organizacional tradicional é baseada em organogramas funcionais e conduz a uma forma de operacionalização e gestão baseadas em um modelo vertical de negócios.

Desta forma, para Brache e Rummler (1994 apud DÁVALOS, 2006, p. 52), a administração organizacional

[...] passa a ser sustentada por silos (estrutura fechada) que impede a resolução de assuntos nos escalões inferiores, sendo necessário que o gerente daquele nível discuta a solução do problema com o gerente do outro silo para, posteriormente, comunicar a solução para a área onde o trabalho será executado.

A visão baseada em processos de negócios prevê um fluxo de atividades que atinge diferentes áreas funcionais e até mesmo diferentes organizações, gerando um determinado resultado para os seus clientes (SORDI, 2006). Dávalos (2006) complementa que este modelo, dito horizontal, permite observar que uma atividade transpõe fronteiras funcionais, produzindo relacionamentos internos entre um fornecedor e um cliente interessados em produtos e serviços.

A Figura 1 mostra o cruzamento entre a visão operacional e a visão estratégica de áreas funcionais de uma organização manufatureira e seus processos de negócio, além de seus elementos externos na figura de fornecedores e clientes.

Das Funções de Negócio aos Processos de Negócio

53

Figura 1- Participação das áreas funcionais nos processos de negócio. Fonte: Adaptado de Lambert et al. (2001 apud SORDI, 2006, p. 6).

Como você percebeu, as organizações orientadas a processos não podem ter a sua estrutura organizacional baseada em apenas um modelo hierárquico, já que, neste modelo, a visão de execução de atividades segue uma orientação localizada em áreas funcionais com pouca interação entre si.

Os processos de negócio atravessam, por definição, várias áreas funcionais, sendo necessária a interação entre elas para que um processo seja executado da melhor maneira possível e alcance seu resultado esperado.

54

Pós-graduação

Referências




55

Modelagem de Processos de NegóciosCarlos André de Sousa Rocha *

Você já estudou que um Workflow é utilizado para modelar e automatizar processos de negócio. Além de técnicas de workflow, um processo de negócio pode ser modelado através da UML (Unified Modeling Language – Linguagem de Modelagem Unificada) ou através da notação BPMN (Business Process Modeling Notation – Notação para Modelagem de Processos de Negócio).

Vamos então conhecer as duas abordagens?

Para Eriksson e Penker (2000, p. 6), algumas perguntas devem ser respondidas quando se realiza uma modelagem de negócios:

• Qual o objetivo de um determinado processo?

• Como os participantes do processo interagem?

• Quais atividades correspondem a partes de seus trabalhos?

• Como elementos externos (pessoas, sistemas, recursos), não participantes diretos, influenciam um determinado processo?

• Quais as regras que governam as atividades de um processo?

• Existem maneiras mais eficientes dos participantes executarem seus trabalhos?

Conceito-chaveOs participantes, pessoas envolvidas, usuários (gerentes, funcionários, clientes, fornecedores, parceiros) que executam um processo ou uma determinada atividade de um processo são denominados de stakeholders (ERIKSSON; PENKER, 2000).

Para responder às perguntas acima, os autores desenvolveram um conjunto de extensões baseadas em elementos de modelos da UML. Vejamos como Eriksson e

* ROCHA, Carlos André de Sousa. Modelagem de Processos de Negócios. Curso de Especialização em Gerência de Projetos de Tecnologia da Informação: material didático on-line da disciplina Fundamentos em Business Process Management (BPM) / Workflow. Palhoça: UnisulVirtual, 2009.

56

Pós-graduação

Penker (2000, p. 108) representam um processo de negócio e os seus elementos. A Figura 1 mostra esta representação genérica.

Analysis

Entrada A

<<people>>ObjetoPessoa

<<goal>>Meta ProcessoQuatitativa ou Qualitativa

<<output>>ObjetoSaída

<<supply>>ObjetoInformação<<physical>>

ObjetoIFísico

<<physical>>Entrada B

Process

<<supply>>

<<supply>>

<<achieve>><<control>>

Figura 1 - Diagrama de Processos baseado em uma extensão do Diagrama de Atividades da UML. Fonte: Adaptado de Eriksson e Penker (2000, p. 108).

Você observou que um processo de negócio possui uma meta (objetivo), contém entradas e saídas específicas e utiliza recursos? Além disto, um processo contém um número de atividades realizadas em uma dada ordem, que ocorrem durante a execução do processo. Um processo de negócio ainda cria um valor para um

determinado stakeholder e afeta mais de uma área funcional.

Que tal detalharmos agora os elementos envolvidos em um processo de negócio?

Eriksson e Penker (2000) definem estes elementos da seguinte forma:

• Meta (objetivo): Descreve o estado desejado de um ou mais recursos. Uma meta precisa ser mensurável de maneira qualitativa ou quantitativa. Ela é a razão de existência do processo de negócio;

• Recursos: Objetos que atuam ou são usados no negócio. Eles são conceitos consumidos, produzidos, transformados ou usados pelos processos de negócio. Entradas são recursos que são transformados ou consumidos como parte dos processos. Saídas são recursos que representam a realização da meta do processo de negócio. O resultado de uma saída pode ser um novo objeto criado pelo processo ou uma transformação dos recursos de entrada.

Modelagem de Processos de Negócios

57

class Unidade 2Recurso

Algo Informação

Físico Abstrato

Figura 2 - Hierarquia de recursos em um ambiente de negócios. Fonte: Adaptado de Eriksson e Penker (2000, p. 77).

A Figura 2 apresenta uma ordem de hierarquia de recursos definidos por Eriksson e Penker (2000, p. 77). Foi desenvolvida, tomando como base o diagrama de classes da UML.

Desta hierarquia você pode concluir que um recurso pode ser uma informação, ou algo abstrato ou físico, sendo que, se for físico, será um participante do processo.

Muitos conceitos? Que tal associarmos agora estes conceitos a um exemplo prático?

Na Figura 3, você pode observar um processo de produção de dispositivos móveis.

analysis: Exemplo de um modelo de prcesso de negócio

PedidoPodução de celular

<<physical>>celular produzido

Feedback do teste do aparelho

<<physical>>celular testado

Avaliação daprodução

Figura 3 - Exemplo de um modelo de negócio para o processo de produção de celulares. Fonte: Adaptado de Eriksson e Penker (2000, p. 308).

Neste exemplo, podemos identificar todos os elementos de um processo. Vamos conhecê-los.

• Meta qualitativa: melhorar a qualidade dos celulares produzidos. Uma meta quantitativa seria “diminuir em 25% o tempo de produção de um celular”;

• Recursos de entrada: pedido (informação), telefone celular produzido (físico);

58

Pós-graduação

• Recursos de saída: telefone celular produzido (físico), telefone celular testado (físico), feedback para área de produção (informação);

• Atividades: subprocesso de produção e subprocesso de avaliação (teste);

• Valor agregado: melhor qualidade do produto final;

• Áreas funcionais afetadas: produção e avaliação (testes).

Agora que você aprendeu como modelar processos de negócio utilizando a extensão de negócio de Eriksson-Penker, que tal aventurar-se em praias da notação BPMN?

Com o desenvolvimento da BPML (Business Process Modeling Language – Linguagem de Execução de Processos Baseada em XML) por parte da BPMI.org, surgiu a necessidade de criar uma notação gráfica que pudesse traduzir processos de negócio para esta linguagem. Com a criação de uma linguagem de execução de processos, nasceu a necessidade de uma tradução de uma notação orientada a negócios para uma linguagem de execução técnica (WHITE; MIERS, 2008).

Conceito-chave“BPMI é um órgão internacional gestor da evolução do BPMN que produziu um formato binário para execução dos fluxos criados em BPMN, conhecido como BPML.” (REIS, 2006, p. 49).

Reis (2006, p. 49) define BPMN como:

Uma notação visual para representação de fluxos de processos que pode ser mapeado para diversos formatos de execução, como BPML e BPEL (Business Process Execution Language – Linguagem para Execução de Processos de Negócio). Em uma analogia com a orientação para objetos, o BPMN seria como a UML, que define elementos gráficos para representar objetos e classes, como também sua interação.

Esta notação deve permitir o entendimento dos processos modelados por todos os stakeholders e, ainda, a tradução destes modelos para uma linguagem de execução (codificação do processo).

White e Miers (2008, p. 24) apresentam os objetivos da BPMN como:

Prover uma notação para modelagem de processos fácil de usar, acessível aos usuários do negócio, e prover facilidades para traduzir modelos em uma forma executável como a BPEL.


59

Como você pode observar, o primeiro objetivo está em conformidade com os objetivos da WfMC e BPMI no sentido de capacitar os usuários de negócios no gerenciamento de aplicações empresariais mostradas no texto sobre Workflow.

A BPMN é uma notação direcionada para a modelagem de processos. Isto significa que outros tipos de modelagem realizados no escopo de um negócio não são suportados pela BPMN. Ela, por exemplo, não suporta: estruturas organizacionais e recursos, decomposição funcional, modelos de dados e de informações, estratégias e regras de negócio (BPMN, 2009).

Que tal você visualizar alguns modelos de processos de negócios com a notação BPMN?

Os textos em maiúsculo que acompanham os elementos dos modelos representam a definição BPMN destes elementos.

Você pode observar outro exemplo na Figura 4, que mostra o recebimento de uma transação de cartão de crédito por uma administradora de cartão.

ATIVIDADE

EVENTO INCIAL

EVENTO FINAL

Receber Solicitação de Crédito

Aprovar

Pagamento ok?

GATEWAY (DESVIO) EXCLUSIVO

Incluir Histórico de Transação

Responder com Mensagem Padrão

UM FLUXO DE SEQUÊNCIA

NÃO

SIM

Figura 4 - Modelo de Processos para uma Transação de um Cartão de Crédito. Fonte: Adaptado de White e Miers (2008, p. 28).

O modelo da Figura 5 mostra a proposta para criação de uma nova conta em uma companhia de marketing. Um evento de documentos recebidos dispara a elaboração da proposta e seu ponto de decisão.

60

Pós-graduação

Elaborar uma proposta

+Enviar oferta e criar conta

Preparar orçamento

+

Enviar rejeição

SUB-ATIVIDADES EVENTOS MÚLTIPLOS FINAIS

sim

não

orçar?

Figura 5 - Modelo de Processos para proposta de uma nova conta em uma Agência de Marketing. Fonte: Adaptado de White e Miers (2008, capa).

Já a Figura 6 apresenta o modelo de processos para o recebimento de um pedido em um site de e-commerce. Ao despachar o pedido para transportadora, é enviada uma mensagem de confirmação à área funcional responsável por este processo.

Receber Pedido

Enviar confirmação

Confirmar EnvioTransportadora

EVENTO DE MENSAGEM

Despachar para Transportadora

+

Receber Pagamento

Figura 6 - Modelo de Processos para Realização de Pedidos em um site de E-commerce. Fonte: Adaptado de White e Miers (2008, p. 31).


61

Você pôde observar que existe uma complementação entre estas duas abordagens de modelagem (UML e BPMN). Enquanto a UML oferece mais recursos que permitem a modelagem de um negócio como um todo, a BPMN oferece uma rica notação para representação da maioria dos elementos necessários à representação de um modelo de processo de negócio.

Referências

BPMN. Business Process Modeling Notation: BPMN Specification Releases Version 1.2. 2009. Disponível em: <http://www.omg.org/spec/BPMN/1.2/PDF>. Acesso em: 14 abr. 2009.

ERIKSSON, H. E.; PENKER, M. Business Modeling with UML. New York: John Wiley & Sons, 2000.

REIS, Glauco. A tão sonhada compatibilidade de padrões existe? Revista PortalBPM. Ano 1, n. 1, São Paulo, PortalBPM, 2006, p. 49. Disponível em: <http://www.portalbpm.com.br/servlet/leartigo?qual=/WEB-INF/artigos/digital/PortalBPM1.pdf>. Acesso em: 10 ago. 2008.


63

Sistemas para Gestão de Processos de Negócio


A modelagem de processos de negócios passou por uma evolução desde seus primeiros passos nas décadas de 1980 e 1990, quando eram estudados apenas pelos envolvidos com a área de conhecimento da Administração de Empresas. Atualmente, os processos de negócios são suportados pelas mais variadas tecnologias da informação, como workflows, modelagem UML e BPMN, sendo que todas estas tecnologias convergem para o que a indústria de software chama de soluções BPMS (Business Process Management Systems – Sistemas para Gestão de Processos de Negócio).

Uma solução BPMS permite a geração e controle dos processos de negócio da empresa, proporcionando rápida tomada de decisão e realinhamento dos processos de negócio de forma agilizada. (REIS, 2008, p. 11).

Reis (2008, p. 12) resume algumas características de uma solução BPMS:

• Deve permitir a modelagem visual dos processos de negócio;

• É desejável suporte a WS-BPEL ou a outra abordagem da BPEL;

• Deve ser suportada por um servidor de aplicações;

• Deve permitir o controle e simulação dos processos desenhados e implementados;

• Deve ser executada com um custo mínimo de recursos a alteração de um processo, seu realinhamento ou melhoria;

• Deve possuir um componente de Workflow;

• É desejável a incorporação de recursos de EAI (Enterprise Application Integration – Integração de Aplicações Empresariais);

• É desejável a integração do desenho organizacional da empresa com os recursos tecnológicos existentes.

* ROCHA, Carlos André de Sousa. Sistemas para Gestão de Processos de Negócio. Curso de Especialização em Gerência de Projetos de Tecnologia da Informação: material didático on-line da disciplina Fundamentos em Business Process Management (BPM) / Workflow. Palhoça: UnisulVirtual, 2009.

64

Pós-graduação

A Figura 1 apresenta uma visão mais pontual das características de uma solução BPMS.

Desenho(BPMS)

Orquestração(WS-BPEL)

Componentização (SOA)

Monitoramento(DashBoards)

RealinhamentoBPMN + SOA

Figura 1 - Características de uma Solução BPMS. Fonte: Adaptado de Reis (2006, p. 27).

Já a Figura 2 mostra a arquitetura de componentes de uma solução BPMS.

Process Modelers

Ferramentas que ajudam a modelar e avaliar designs de processos de negócios alternativos

EIA

Aplicações que integram fontes de dados dispersas

através de um barramento de

mensagens de aplicação

App Services

Plataformas para o gerenciamento e

execução de aplicações

WorkFlow

Aplicações que automaticamente roteiam documentos e manipulam pessoas baseado em passos de processos

Business Pocess Management System

Figura 2 - Elementos de uma Arquitetura BPMS. Fonte: Adaptado de Reis (2005, p. 15).

Você percebeu o quanto complexa e completa deve ser uma solução BPMS? Percebeu sua estreita relação com o conceito de BPM?

Garimela, Lees e Williams (2008, p. 10) denominam “Suíte” o “S” do BPM e o definem como:

Um suíte de tecnologias BPM que incluem todos os módulos funcionais, capacidades técnicas, infra-estrutura de suporte, integrados em um único ambiente que executa toda a tecnologia BPM de maneira contínua.

Sistemas para Gestão de Processos de Negócio

65

A Figura 3 mostra a arquitetura de um ambiente BPM suportado por um ecossistema tecnológico BPMS.

Figura 3 - A Tecnologia BPMS como um Ecossistema Organizacional. Fonte: Adaptado de Garimela, Lees e Williams, 2008.

A arquitetura da Figura 3 define, na visão de Garimela, Lees e Williams (2008):

• Arquitetura de negócios: a estrutura completa das metas e objetivos dos clientes e stakeholders da organização, e as estratégias, regras e responsabilidades necessárias para executá-las;

• Arquitetura de processos: os métodos, práticas e procedimentos através dos quais as pessoas na organização transformam recursos disponíveis e capital para agregar valor para os clientes e stakeholders e alcançar as metas e objetivos de negócios;

• Arquitetura de gerenciamento: como as ações e comportamentos das pessoas e sistemas, bem como o fluxo de informação ao longo do tempo, são direcionados na execução dos processos para alcançar as metas do negócio.

Você pode fazer uma relação entre a arquitetura do ambiente BPM com a arquitetura de seus elementos tecnológicos, por exemplo, na arquitetura do ambiente temos uma camada de integração organizacional suportada pelos EAI. Para a camada de processos de aplicações temos os Process Modelers e o componente de Workflow.

Dutra (2006) salienta que no Brasil existem mais de vinte soluções BPMS competindo pelo mercado e que, apesar de estas soluções terem desenvolvido processos complexos de avaliação, um ponto a não ser desconsiderado é a relação que uma solução BPMS deve possuir com a metodologia de gestão dos processos organizacionais. Logo, além de soluções tecnológicas, temos de ficar atentos à cultura metodológica da organização para gestão de seus processos.

66

Pós-graduação

As soluções BPMS são componentes imprescindíveis para implementação de modelos de negócios organizacionais, na medida em que eles propiciam todos os recursos de infraestrutura tecnológica necessária para a execução, integração, monitoramento e melhoria dos processos de negócios.

Referências

DUTRA, Antonio. Metodologias de BPM e sua influência no desenvolvimento de soluções. Revista PortalBPM, São Paulo, Ano 1, n. 2, PortalBPM, p 12, 2006. Disponível em: <http://www.portalbpm.com.br/servlet/leartigo?qual=/WEB-INF/artigos/digital/PortalBPM2.pdf>. Acesso em: 10 ago. 2008.



REIS, Glauco. Introdução ao BPM, BPMS e SOA. Revista PortalBPM, São Paulo, Ano 1, n. 1, PortalBPM, p 27, 2006. Disponível em: <http://www.portalbpm.com.br/servlet/leartigo?qual=/WEB-INF/artigos/digital/PortalBPM1.pdf>. Acesso em: 10 ago. 2008.

REIS, Glauco. Modelagem de Processos, Casos de Uso e Ferramentas BPM. Revista MundoJava, Curitiba, Ano 3, n. 15, p.15, 2005.

01-caderno-[6320 - 16041]caderno dida769tico fundamentos em business process management workflow

Documents