processos de negócio

Prévia do material em texto

· Modelagem de negócios é uma abordagem para toda a empresa. É estruturada para fornecer produtos e serviços que dão valor ao cliente. Baseia-se na premissa de que você deve ter uma visão de processo em toda a empresa a fim de entender que produtos e serviços gerados durante a produção do bem ou execução do serviço gerarão maior satisfação e entrega de valor.
Modelagem de processos de negócios é uma maneira em que as organizações estudam seus processos de negócios atuais e desenvolvem novos métodos para melhorar a produtividade, eficiência e custos operacionais no futuro.
O modelo nos permite examinar a forma como uma organização funciona, suas metas de desempenho a longo prazo, e quando analisamos esse modelo, que representa uma fração do mundo real, podemos, a partir de sua análise de resultados, recomendar melhores e mais transparentes maneiras de trabalho para alcançar a melhoria geral.
Concentra-se em novos processos de negócios e também nos já existentes, em como diagnosticar problemas com a metodologia atual de uma organização, como redesenhar, reconstruir e monitorar esses processos para garantir que sejam eficazes.
Uma vez que os novos modelos de processos, bem como as mudanças implementadas, são testados quanto à futura eficácia, os profissionais de modelagem trabalham constantemente para atualizar e melhorar ainda mais as soluções.
Antes de desenvolver estratégias de trabalho e uso de ferramentas de modelagem, você pode ter que realizar a investigação sobre a empresa e determinar os problemas que enfrentará. Como profissional que trabalhará com modelagem, você terá que implementar novas tecnologias no local de trabalho para criar processos automatizados e eficientes.
Processos que são ineficientes ou ineficazes em entregar o que os clientes exigem, precisam ser claramente identificados e direcionados a melhorias.
Um processo eficiente é aquele em que os recursos consumidos no processo estão nos níveis mínimos possíveis. Ou seja, um processo efetivo é capaz de entregar produtos ou serviços de acordo com as especificações dadas.
Como toda organização começa o trabalho de medição de desempenho em termos de requisitos críticos, os quais orientados para o cliente, os funcionários não pensam em si como gerentes funcionais responsáveis pelas saídas também funcionais dos processos sob suas responsabilidades. Em vez disso, veem seus papéis no contexto de um objetivo maior, mais importante, que é o de satisfazer e criar clientes fiéis. Dessa maneira, como pensadores do processo, consideram o impacto potencial de suas ações e decisões nas entradas e saídas dos processos e, por fim, sobre a capacidade da empresa em entregar o que promete aos seus clientes.
Modelar processos inclui o uso do processo de descoberta, mapeamento, métricas, Indicadores-Chave de Desempenho (KPI), colaboração, tomada de decisões e monitoramento do processo,pois quanto mais sofisticado o modelo, mais fiéis serão as condições reais.
Quando mencionamos modelagem de negócios, trata-se de Business Process Management (BPM), disciplina que a contém em seu corpo de conhecimentos.
Veja as nove áreas de conhecimento que se interpolam:
1 Alinhar os processos às estratégias de negócios;
2 Descobrir e modelar esses processos;
3 Construir os processos de medição;
4 Realizar a análise e avaliação comparativa de processos;
5 Definir as políticas de construção e captura de regras;
6 Melhorar os processos;
7 Gerir a mudança de cultura;
8 Governar e tomar decisões;
9 Prover tecnologia para a implantação.
A esta altura talvez você esteja se perguntando o que é um modelo de negócio, já que acabou de ler que a modelagem do negócio é, em si, importante nos dias atuais. Aqui vai uma definição bastante básica e de fácil compreensão sobre o que é um modelo de negócio: em sua forma mais simples, é uma especificação que descreve como uma organização cumpre seu propósito.
Todos processos e políticas de negócios fazem parte desse modelo. De acordo com Peter Drucker (1996), um modelo de negócio responde às seguintes questões:
· Quem é seu cliente?
· Como construir valor para o cliente?
· Como entregar esse valor a um custo adequado?
Fonte: DRUCKER. P. F. O Líder do Futuro: Visões, Estratégias e Práticas para uma Nova Era, 9a. ed, Futura, 1996.
Vimos muitas coisas nesta Unidade, de modo que segue um “resumão” focado:
Quando você modela um negócio, os benefícios vão um pouco além da obviedade da redução de custos e economias estruturais. Assim, devemos levar em conta que, uma vez documentado o modelo de negócio, você tem em suas mãos um guia para manter o foco nos objetivos da empresa, revendo práticas operacionais e garantindo que os dois sejam congruentes.
Uma representação do modelo de negócio de uma empresa pode ser incorporado em material de desenvolvimento de sistemas de informação, bem como é útil para compartilhar com clientes e parceiros. Uma declaração de missão ou a declaração de visão pode ser incluída em um modelo de negócio; de modo que o foco aqui não é administrativo; na verdade, dá o Norte de porquê você precisa otimizar os processos e os modelos para incrementar a eficiência e eficácia, ou seja, fazer com que todos os insumos e processos se comportem com o propósito de cumprir a razão de ser da organização, condições essas descritas na sua missão e visão, bem como entregar valor ao cliente.
Se você prestar atenção, perceberá que a equação é simples: a velocidade com que uma empresa atinge seus objetivos é proporcional à qualidade da modelagem de seus processos, além da consistência da técnica aplicada e a eficácia medida durante a simulação, colocação de indicadores importantes e que suportam a decisão quando esses processos forem para a execução no mundo real.
Os benefícios mais importantes da modelagem de negócios são:
· Aceleração do time to market de produtos e serviços;
· Melhorias no custo, produtividade, pontualidade e qualidade;
· Melhorias nos níveis de serviço ao cliente e aumento da satisfação do mesmo;
· Transferência de conhecimentos para assegurar e manter o desenvolvimento de capacidades futuras;
· Simplificação dos processos de negócio para impulsionar a eficácia, eficiência e agilidade;
· Gestão de riscos focada no cumprimento do estabelecido a fim de evitar não conformidades;
· Oferecimento de maior visibilidade do desempenho organizacional;
· Introdução de novos e mais rápidos modelos de processo;
· Redução dos custos e melhora dos fluxos de receita.
A modelagem do negócio permite ao analista dispor de materiais importantes, como a lista das partes requeridas do negócio, como essas partes são estruturadas e como interagem entre si, de forma que uma vez colocadas em um modelador, torna-se natural que sejam percebidas as formas de como o processo evoluirá, o que permite correções de rumo antes do dispêndio de recursos financeiros, tecnológicos e humanos.
Quando modelamos, devemos levar em conta as quatro grandes forças que constituem essa ação: processos, recursos, metas e regras. Então, como todos esses atores interagem e impactam uns aos outros, chegamos à conclusão de que o objetivo de modelagem de negócios nada mais é do que a definição desses conceitos, além de mostrar seus relacionamentos e as interações entre os quais.
Às vezes, devido à complexidade do que modelaremos, surge a necessidade de abstrairmos uma meta modelo. Ou seja, uma descrição gráfica em muitos casos onde os conceitos primordiais são apresentados visualmente e os recursos necessários – como verbos que permitem a interação entre os objetos dessa proto modelagem. Em linhas gerais, com a utilização de meta, buscamos modelos como os processos procuram atingir seus objetivos. Nesse sentido, veja o seguinte exemplo:
Figura 1.
Fonte: <http://www.pfvasconcellos.eti.br>.
Como toda a informação ainda é pouca e aqui tratamos de algo muito grande – como a prática em indústrias de qualquer tipo e porte, utilizando ou não tecnologia e/ou sistemas de informação –, não se acanhe, procure mais informação onde der, mas procure!
Apenas recordando, um padrão denegócios descreve uma abordagem reutilizável para a solução de um problema de negócio em particular, dessa maneira, um modelo de negócio pode ser descrito como um modelo de arquitetura para uma solução de negócios.
Você percebeu as implicações disso?
Levemos em consideração uma definição da Microsoft, do MSDN, que separa em partes as possibilidades de uso de padrões:
Um padrão descreve uma solução genérica a um problema recorrente, dentro de um contexto definido. As três partes principais da definição do padrão são:
· Solução genérica: Isto significa que um padrão não pode ser definido para uma solução específica. Em vez disso, ele identifica a "classe" do problema e como esse problema pode ser resolvido com uma abordagem particular, com base em evidências demonstráveis. Seu poder é derivado do fato de que é uma abstração que pode ser aproveitada através de um grande número de situações;
· Problema recorrente: Isto significa que os padrões são úteis quando o problema não é único, e são mais úteis quando o problema ocorre muitas vezes;
· Contexto definido: Isso significa que você tem que colocar limites na solução genérica porque não existem soluções universalmente verdadeiras. Então, você tem que entender as circunstâncias em que esta solução genérica é válida e, portanto, como criar seu próprio projeto específico.
Para podermos utilizar um padrão de negócio, temos que entender os problemas mandatários; além disso, devemos saber os requisitos e, para você ter uma ideia, grande parte dos requisitos de negócio não está documentada em lugar algum, reside na mente dos interessados, no feedback que ainda deve ser obtido a partir de usuários finais e de um estudo de fluxogramas e pesquisas que ainda deve ser criado.
É, como você deve ter percebido, não é nada fácil.
O objetivo do levantamento de requisitos, portanto, é identificar completamente as necessidades dos negócios, riscos e pressupostos associados em um determinado projeto.
Dessa forma, elicitação de requisitos ou levantamento de requisitos, nada mais é do fazer as perguntas e obter as respostas. Para isso, requeremos das partes interessadas para que respondam as suas partes do que será feito e o porquê de um sistema de informação ou de um processo necessitar ser construído ou melhorado. Ademais, a elicitação é um processo contínuo durante o desenvolvimento do projeto, de modo que não se trata de uma atividade estagnada, compartimentada, mas sim da descoberta de necessidades latentes ou potenciais dos clientes e do sistema ou processo.
Dessa maneira, quando mencionamos análise de requisitos, levamos em consideração a solução ideal, as vantagens e desvantagens de várias implementações possíveis. Ou seja, trata-se de constatar a solução que pode ser melhor implementada sob várias restrições existentes, por exemplo, quanto ao jeito mais rápido e/ou mais barato.
Quando tratamos de requisitos de sistemas da informação, o que normalmente ocorre quando modelamos um negócio, embarcamos esses requisitos em suas funcionalidades.
Logo, podemos definir que requisitos funcionais definem as capacidades que um sistema deve ter, ou propriedades desse sistema, ao que chamamos de requisitos não funcionais, que atendam às necessidades dos usuários para executar um conjunto específico de tarefas, tudo isso dentro de um escopo definido.
A regra de negócio, por outro lado, é um preceito que define ou restringe algum aspecto de negócios e sempre é testado como verdadeiro ou falso.
As regras de negócios são destinadas para confirmar uma estrutura de negócios, controlar ou até mesmo influenciar o seu comportamento. Descrevem as operações, definições e restrições que se aplicam a uma empresa.
Essas regras podem se aplicar a pessoas, processos, comportamentos e sistemas em uma empresa, são usadas como forma de fazer com que, uma vez colocadas em prática, alcancem seus objetivos na organização.
Conforme definido no Rational Unified Process (RUP), disponível em: <http://www.funpar.ufpr.br>, existem quatro categorias de regras de negócio centradas em dois grupos:
· Regras de restrição especificam políticas e condições que restringem o comportamento e a estrutura de objetos:
· Regras de estímulo e resposta restringem o comportamento, especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado;
· Regras de restrição de operação especificam as condições que devem ser verdadeiras antes e após uma operação para garantir que esta seja executada corretamente;
· Regras de restrição de estrutura especificam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados.
· Regras de derivação especificam políticas ou condições para deduzir ou calcular fatos de outros fatos:
· Regras de dedução especificam que se determinados fatos são verdadeiros, uma conclusão pode ser deduzida;
· Regras de cálculo derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução.
· Business Process Modeling Notation (BPMN) é um método que modela as etapas de um processo de negócio planejado de ponta a ponta. A chave para a gestão de processos de negócios, que visualmente representa uma sequência pormenorizada das atividades de negócio e fluxos de informação necessários para concluir um processo.
A intenção original do BPMN era ajudar a construir uma ponte nas falhas de comunicação que muitas vezes existem entre os vários departamentos dentro de uma organização ou empresa.
Foi desenvolvido pelo Business Process Management Initiative (BPMI) e passou por uma série de revisões. Em 2005, esse grupo se fundiu com o Object Management Group (OMG), que assumiu a iniciativa. Em 2011, foi lançado o BPMN 2.0 e mudou o nome do método para BPMN. Foi desenvolvido então um padrão mais detalhado para modelagem de processos de negócio, usando um conjunto mais rico de símbolos e indicações para o desenvolvimento dos diagramas de negócio. Ao contrário de UML, BPMN foi concebido para modelagem de negócios – e não de sistemas –; por sua vez, UML foi desenvolvida para modelar sistemas a partir de negócios; para modelar negócios que sofreram adaptações foram criadas extensões como a Perkins.
Desde 2014, BPMN é complementado por um método de decisão em fluxograma denominado modelo de decisão e notação padrão, uma vez que não se presta a fluxos de decisão, mas a gateways.
Tal iniciativa é destinada a participantes e outras partes interessadas em um processo de negócio para ganhar a compreensão através de uma representação visual cujas etapas são fáceis de entender.
Preenche a lacuna entre intenção e implementação de processos, fornecendo detalhes e clareza suficiente na sequência das atividades empresariais representadas nesses diagramas.
Quando mencionamos UML, este também lhe ajuda a especificar, visualizar e documentar modelos de sistemas de software, incluindo a sua estrutura e design, de forma que atenda a todos esses requisitos. Sim, você pode usar UML para modelagem de negócios e de outros sistemas não orientados ao desenvolvimento de software. Você pode analisar os requisitos de seu futuro processo ou aplicativo e projetar uma solução que os atenda, representando os resultados do seu modelo.
Mas há extensões específicas para modelagem de negócios, como na notação estendida melhor adaptada. Por exemplo, Eriksson e Penker (2001), fornecendo um quadro para processamento de modelos de negócios, em que um arquiteto corporativo pode adicionar estereótipos e propriedades adequadas para o seu negócio.
Vamos dar uma olhada nisso?!
Nesta Unidade vimos duas ferramentas extremamente úteis para modelagem de negócios. Uma se tornará, a longo prazo, o padrão mundial para modelagem de negócios, trata-se do Business Process Modeling Notation (BPMN); a outra oferece uma possibilidade para as empresas que utilizam já a longa data Unified Modeling Language (UML), uma possibilidade de estender sua linguagem para a modelagem de negócios através de Eriksson e Penker (2001).
Utilizando as palavras desses autores, pode-sedizer que a modelagem de negócios serve para manter as empresas competitivas.
A fim de manter-se e ser competitivo, todas as empresas devem avaliar a qualidade de seus produtos e a eficiência dos seus serviços. Ao fazer isso, eles devem considerar o que está acontecendo no mundo em torno deles, e eles também devem levar um olhar introspectivo em seus produtos ou serviços (ERIKSSON; PENKER, 2001).
Devemos ter respostas às perguntas cruciais para a sobrevivência das empresas e isso pode ser feito na linguagem do modelamento de processos de negócio como, por exemplo:
· O funcionamento empresarial está sem problemas?
· Podemos melhorar seus produtos ou serviços? 
· Sua produção é executada da forma mais eficiente possível? 
· Podemos expandir seus portfólios de produto ou serviço para atingir novos mercados e clientes?
Você percebe que não estamos tratando de sistemas de informação, mas de maneiras de perenizar o negócio no mercado? Lógico que isso pode significar que teremos que utilizar automação via sistemas de informação, por exemplo,mas isso não é uma regra.
Tal modelo é o centro para conduzir negócios ou melhorar como tal negócio é operado. Modelar um negócio envolve responder a algumas perguntas-chave, de modo que é melhor você ter sempre em mente estas questões:
· Como os diferentes atores interagem?
· Quais atividades fazem parte de seu trabalho?
· Quais são os objetivos finais de seu trabalho?
· Quais são as regras que regem as suas atividades e estruturas?
· Existem maneiras as quais os atores poderiam executar mais eficientemente seus papéis e atividades?
Todavia, modelar negócios não é um “mar de rosas”, dado que especialistas e analistas de sistema e de negócio que enveredam por esse trabalho podem encontrar/gerar problemas em suas documentações e correrem riscos que impactam o produto final a ser visualizado pelos stakeholders e outros participantes do design de processo de negócio ou do próprio negócio. Veja alguns riscos:
· Os modelos que criamos são mais difíceis de se entender, principalmente para as partes interessadas, levando potencialmente a processos de negócios que incluem informações incorretas, baixo desempenho ou até mesmo não funcionalidade;
· Em alguns casos é mais complexo para nós criar modelos, o que significa que precisamos de mais tempo de análise para entregar a mesma quantidade de valor ou, se preferir, de trabalho. É preciso verificar se isso é realmente necessário e a demora pode agregar valor e atuar como coadjuvante no atingimento dos objetivos de negócios;
· Quando o que estamos modelando nos deixa mais propensos a cometer erros de modelagem, que diminuem – em vez de aumentar – a clareza de nossos fluxos de processo.
Por fim, lembre-se que os princípios que guiam a modelagem de processos de negócio são a clara descoberta e desenho das peças-chave desse quebra-cabeça, a saber:
· Processo – o conjunto de ações que transformam objetos de entrada em saídas que têm um valor acrescentado para o cliente. Os processos têm um objetivo que se cumpre mediante a execução de  eventos;
· Eventos – mudanças de estado que são causadas por um processo e são, então, recebidas por um ou mais processos;
· Recursos – são todos os tipos de coisas usadas na empresa, de maneira física ou abstrata, por exemplo, informações;
· Metas – definidas para a organização e cada um de seus processos, representando o estado desejado de cada recurso da empresa;
· Regras de negócio – definem as condições em que a atividade empresarial é realizada, de modo que o conhecimento da empresa deve estar representado.
Bem, como percebeu, agora você precisa praticar, desenhar processos de negócio e treinar até atingir a perfeição.
Regras de Negócio
· Assertiva Estrutural : inclui regras que definem conceitos ou declarações de fatos que expressam aspectos da estrutura de uma organização. ( por ex.: não posso te entregar x pois meu limite de produção não comporta )
· Assertiva de ação: inclui regras que especificam declarações de restrições ou condições que limitam ou controlam as ações de uma organização
· Derivação: inclui regras que especificam declarações de um conhecimento que é derivado de outro conhecimento do negócio.
Requisito funcional e Regra de negócio
· Requisito funcional refere-se a o que o sistema deverá fazer
· Regra de negócio refere-se a como o sistema deverá fazer
· Do ponto de vista do negócio, ambos são necessidades ( requisito funcional e Regra de Negócio ), mas cada uma com um foco diferente.
O requisito funcional é um objetivo que o sistema deverá alcançar.
Uma função que o sistema deverá realizar.
Misturar isso faz com que um requisito assuma a responsabilidade de uma regra e vice-versa.
Em suma:
Requisito funcional = o que o sistema fará
Regra de Negócio = como o sistema fará
Modulo 3
Nesta Unidade vimos a importância dos padrões de negócios, pois a partir destes podemos inserir modelagem e realizar testes para sabermos se se aproximam da realidade, ou se nossa abstração do processo modelado não teve acurácia e representatividade suficientes para ser o mais completo possível, enquanto permitem importantes nuances para atimização e mudança, se for o caso.
Você viu no exemplo da Microsoft que um modelo de negócio descreverá:
· As funções de negócio a ser suportado;
· Os dados que são necessários para suportar as funções descritas;
· Os componentes de negócios que são as representações de Tecnologia da Informação (TI) dos dados e funções para atender às necessidades do negócio;
· Opcionalmente, a infraestrutura necessária para suportar funções, dados e componentes.
No entanto, devemos nos concentrar em certos relacionamentos essenciais que moldam fundamentalmente o padrão de negócios:
· As relações entre entidades/relacionamentos devem ser estáveis;
· As funções de negócio estão incluídas nos componentes de negócios;
· Ademais, os dados devem estar incluídos nos componentes de negócios.
Por fim, processos de negócios são suportados por aplicações e estas, por sua vez, funcionam utilizando tecnologia.
Figura 1.
Fonte: Adaptado de https://goo.gl/scJma8.
A Figura acima demonstra um padrão de negócio, elaborada por Nei Grando a partir do livro Business model generation – Inovação em modelos de negócios –, cujo objetivo é demonstrar como uma organização cria, entrega e captura valor.
Uma das possibilidades é utilizar o business model canvas, veja o exemplo abaixo:
Quadro 1.
Fonte: <http://businessmodelgeneration.com>.
Agora preencheremos a base e, a partir daí, buscaremos os requisitos:
Quadro 2.
Fonte: <http://www.slideshare.net/neigrando>.
É importante você perceber que elicitar requisitos tem problemas sérios de entendimento e seus GAP, segundo Christel e Kang, são os problemas que indicam os desafios para elicitação de requisitos:
· Problemas de alcance – a fronteira do sistema é mal definida ou os clientes/usuários especificam detalhes técnicos desnecessários que podem confundir, ao invés de esclarecer, os objetivos gerais do sistema;
· Problemas de compreensão – os clientes/usuários não estão completamente certos do que é necessário, possuem má compreensão das capacidades e limitações de seu ambiente de computação, não têm compreensão completa do domínio do problema, têm problemas para comunicar as necessidades e/ou omitem informações por acreditarem ser óbvias, e também especificam requisitos que estão em conflito com as necessidades de outros clientes/usuários, ou pior, especificam requisitos que são ambíguos ou não testáveis;
· Problemas de volatilidade – os requisitos mudam ao longo do tempo. A taxa de variação é, por vezes, referida como nível de exigência, ou seja, volátil.
Como sugestão, treine a utilização tanto do desenvolvimento de padrões utilizando o canvas, como tente elicitar os requisitos para cada “caixinha” –sim, no começo você terá uma dificuldade imensa.
Persevere, porque tirando os prodígios, ninguém nasce sabendo tocar um instrumento, de modo que normalmenteé necessária grande dedicação, às vezes mais de oito horas diárias, fora o tempo investido em conservatórios, professores particulares, leitura de livros, ensaios com pessoal mais experiente etc. Enfim, trata-se muitas vezes de serviço voluntário para que você possa ter o básico e ir desenvolvendo a maestria com o tempo – e sim novamente, com sistemas e análise, bem como modelagem de negócios, acontece o mesmo
UNIDADE III
Business Process Modeling Notation (BPMN) é um método que modela as etapas de um processo de negócio planejado de ponta a ponta. A chave para a gestão de processos de negócios, que visualmente representa uma sequência pormenorizada das atividades de negócio e fluxos de informação necessários para concluir um processo.
A intenção original do BPMN era ajudar a construir uma ponte nas falhas de comunicação que muitas vezes existem entre os vários departamentos dentro de uma organização ou empresa.
Foi desenvolvido pelo Business Process Management Initiative (BPMI) e passou por uma série de revisões. Em 2005, esse grupo se fundiu com o Object Management Group (OMG), que assumiu a iniciativa. Em 2011, foi lançado o BPMN 2.0 e mudou o nome do método para BPMN. Foi desenvolvido então um padrão mais detalhado para modelagem de processos de negócio, usando um conjunto mais rico de símbolos e indicações para o desenvolvimento dos diagramas de negócio. Ao contrário de UML, BPMN foi concebido para modelagem de negócios – e não de sistemas –; por sua vez, UML foi desenvolvida para modelar sistemas a partir de negócios; para modelar negócios que sofreram adaptações foram criadas extensões como a Perkins.
Desde 2014, BPMN é complementado por um método de decisão em fluxograma denominado modelo de decisão e notação padrão, uma vez que não se presta a fluxos de decisão, mas a gateways.
Tal iniciativa é destinada a participantes e outras partes interessadas em um processo de negócio para ganhar a compreensão através de uma representação visual cujas etapas são fáceis de entender.
Preenche a lacuna entre intenção e implementação de processos, fornecendo detalhes e clareza suficiente na sequência das atividades empresariais representadas nesses diagramas.
Quando mencionamos UML, este também lhe ajuda a especificar, visualizar e documentar modelos de sistemas de software, incluindo a sua estrutura e design, de forma que atenda a todos esses requisitos. Sim, você pode usar UML para modelagem de negócios e de outros sistemas não orientados ao desenvolvimento de software. Você pode analisar os requisitos de seu futuro processo ou aplicativo e projetar uma solução que os atenda, representando os resultados do seu modelo.
Mas há extensões específicas para modelagem de negócios, como na notação estendida melhor adaptada. Por exemplo, Eriksson e Penker (2001), fornecendo um quadro para processamento de modelos de negócios, em que um arquiteto corporativo pode adicionar estereótipos e propriedades adequadas para o seu negócio.
Quais diagramas e extensões são usadas para modelagem de negócios: ( os diagramas de atividades e caso de uso )
Business Process Modeling Notation (BPMN) é um método que modela as etapas de um processo de negócio planejado de ponta a ponta. A chave para a gestão de processos de negócios, que visualmente representa uma sequência pormenorizada das atividades de negócio e fluxos de informação necessários para concluir um processo.
A intenção original do BPMN era ajudar a construir uma ponte nas falhas de comunicação que muitas vezes existem entre os vários departamentos dentro de uma organização ou empresa.
Foi desenvolvido pelo Business Process Management Initiative (BPMI) e passou por uma série de revisões. Em 2005, esse grupo se fundiu com o Object Management Group (OMG), que assumiu a iniciativa. Em 2011, foi lançado o BPMN 2.0 e mudou o nome do método para BPMN. Foi desenvolvido então um padrão mais detalhado para modelagem de processos de negócio, usando um conjunto mais rico de símbolos e indicações para o desenvolvimento dos diagramas de negócio. Ao contrário de UML, BPMN foi concebido para modelagem de negócios – e não de sistemas –; por sua vez, UML foi desenvolvida para modelar sistemas a partir de negócios; para modelar negócios que sofreram adaptações foram criadas extensões como a Perkins.
Desde 2014, BPMN é complementado por um método de decisão em fluxograma denominado modelo de decisão e notação padrão, uma vez que não se presta a fluxos de decisão, mas a gateways.
Tal iniciativa é destinada a participantes e outras partes interessadas em um processo de negócio para ganhar a compreensão através de uma representação visual cujas etapas são fáceis de entender.
Preenche a lacuna entre intenção e implementação de processos, fornecendo detalhes e clareza suficiente na sequência das atividades empresariais representadas nesses diagramas.
Quando mencionamos UML, este também lhe ajuda a especificar, visualizar e documentar modelos de sistemas de software, incluindo a sua estrutura e design, de forma que atenda a todos esses requisitos. Sim, você pode usar UML para modelagem de negócios e de outros sistemas não orientados ao desenvolvimento de software. Você pode analisar os requisitos de seu futuro processo ou aplicativo e projetar uma solução que os atenda, representando os resultados do seu modelo.
Mas há extensões específicas para modelagem de negócios, como na notação estendida melhor adaptada. Por exemplo, Eriksson e Penker (2001), fornecendo um quadro para processamento de modelos de negócios, em que um arquiteto corporativo pode adicionar estereótipos e propriedades adequadas para o seu negócio.