Função e processo de negócio
Dada a similaridade das suas composições, "Função de Negócio" e "Processo de Negócio" são conceitos que frequentemente suscitam dúvidas entre as pessoas interessadas em formar um melhor entendimento a respeito dos elementos de uma Arquitetura de Negócios.
Funções de Negócio são estruturas conceituais idealizadas que servem para descrever a missão de uma Organização. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantêm estáveis ao longo do tempo, mesmo diante de reorganizações da empresa. Como são perenes, as funções representam um ponto de referência (conceitos comuns) ao se descrever diferentes negócios, que de outra forma exibiriam variações significativas.
Esta definição é demonstrada, por exemplo, pelo fato de que a contabilidade define o contador, de que a função gerencial define o gerente, etc. Funções de negócio são também alocadas a unidades organizacionais específicas (que exercerão os diferentes papéis) e são envolvidas e invocadas no decorrer do "comportamento" do negócio.
Podemos dizer que uma função corresponde a uma série de atividades relacionadas, envolvendo uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da missão da empresa, gerando um determinado resultado financeiro, ou servindo às necessidades dos clientes da empresa, ou dando origem aos produtos e serviços a serem negociados, ou gerenciando, administrando, monitorando, registrando e relatando as atividades, estados e condições das "entidades" da organização.
As atividades que compõem uma função são relacionadas entre si por "afinidade", porque trabalham um grupo comum de entidades de dados ou porque são sequenciais ou paralelas na realização do trabalho associado a um resultado final comum.
O ponto de vista da Arquitetura busca uma visão conceitual e única de uma atividade (ou funcionalidade), de forma que se possa identificar quando e como ela se repete nos diversos processos de negócio, a fim de determinar a generalização dos conceitos de tarefas comuns, identificando atividades compartilhadas e administrando seu reúso através da distribuição dos componentes que as suportam. Da mesma forma, os sistemas de informação que suportam tais funções estarão focados em aspectos específicos do funcionamento do negócio, independentemente da forma como a empresa está organizada.
A decomposição funcional adequada deve levar em conta princípios e diretrizes estabelecidos, que podem ser, por exemplo:
- as funções devem ser identificáveis e definíveis em termos de atividades, responsabilidades e atribuições;
- as funções devem ser o mais independente possível das estruturas organizacionais existentes;
- as funções devem, como um grupo, constituir um conjunto que seja essencial ao ciclo de vida do "sistema";
- cada subgrupo resultante da decomposição funcional deve representar um "subsistema socio-tecnológico" por si só (referente a pessoas e tecnologia).
Atividades são direcionadas a dados e são "iniciadas" por transações ou solicitações de dados. Elas são a porção ativa das funções, e tendem a ser repetitivas e formalizadas. Uma maneira de se diferenciar o conceito de funções e atividades é que, geralmente, as funções são gerenciadas e atividades são realizadas.
Processo é definido como a sequência completa de um comportamento de negócio, provocado por algum evento e que produz um resultado significativo para o negócio e que, de preferência, tenha foco no cliente. No percurso do processo, desde o evento inicial até a produção de um determinado resultado, várias funções do negócio podem estar envolvidas. Assim, dizemos que os processos são elementos transfuncionais, já que perpassam diversas funções dentro da organização.
Se uma função é composta de atividades que representam um papel ou razão de existir da organização, os processos de negócio "executam" estas atividades de forma que, individualmente ou combinadas, realizem o trabalho de uma determinada função. A atividade representa, portanto, a unidade funcional (que servirá como componente de processos de negócio, numa visão transfuncional) que permite a identificação de "utilidades" comuns e, portanto, de oportunidades de reúso funcional.
Referências[editar | editar código-fonte]
- Engenharia da Informação – Metodologia, Técnicas e Ferramentas, A. F. Neto, Wilson Higa, J. D. Furlan – McGraw-Hill, 1988.
- Engenharia de Software, Roger S. Pressman, McGraw Hill, 5a. edição, 2002.
- Enterprise Architecture – The Business Issues and Drivers, Gartner Group, Alexander Drobik – Ago 2002.
- Unlocking the value of account opening with component business modeling - An IBM Institute for Business Value executive briefing.
- Enterprise Architecture – Building the Real-time Enterprise Requires a New Enterprise Architecture – J. Schulman, J. Comport – 13-ago-2002.
- Migrating to a service-oriented architecture – Kishore Channabasavaiah, Executive Architect, IBM Global Services; Kerrie Holley, Distinguished Engineer, Chief Architect - eBusiness Integration Solutions, IBM Global Services; Edward M. Tuggle, Jr., Senior Software Engineer, IBM Software Group – 2003.