Processo de negócio é um processo, porque transforma input em output, conforme a definição anterior. Mas ele possui características adicionais. Segundo o nosso glossário, processo de negócio é um “trabalho de ponta a ponta (end-to-end) que agrega valor aos clientes ou apoia/gerencia outros processos para além das fronteiras funcionais” (ABPMP, 2013)

Essa definição agrega os três tipos de processo de negócio:

• processo ponta a ponta (também conhecido como processo de negócio primário, processo end-to-end, processo essencial – core)
• de apoio
• e gerencial

Baldam et al. (2014) definem de uma forma mais simplificada o processo de negócio, como sendo um “conjunto de atividades que cria valor para stakeholders específicos” (ilustrado na próxima figura).

Figura 450: ilustração da definição de um processo de negócio, que cria valor para stakeholders específicos

Conhecido também como:

O processo de negócio primário também é conhecido como processo essencial (core) e processo ponta a ponta (end-to-end). Ele é interfuncional, parte das necessidades, desejos, problemas e dores dos clientes ou de oportunidades (novidades) que os clientes nem reconhecem e entregam resultados, nos quais os clientes percebem valor. 

É chamado de ponta-a-ponta  (end-to-end) porque 

• parte dos clientes (uma ponta final) 
• considera desde o início (outra ponta inicial) as necessidades dos clientes e 
• entrega valor para os clientes (a ponta final), como ilustra a próxima figura.

 Os processos ponta a ponta representam a essência de uma organização para cumprir sua missão.

Figura 451: ilustração de um processo ponta a ponta

Os clientes dos processos ponta a ponta podem ser “internos” e não necessariamente externos. Na verdade, podemos dizer que esses processos partem dos stakeholders e criam e entregam valor para os stakeholders, com foco nos clientes. Os clientes são stakeholders também e, normalmente, são eles que possibilitam que a empresa exista, pois “pagam” pelos produtos e serviços (em empresas comerciais).

Se considerarmos somente os clientes, os processos criam, entregam e capturam valor (por meio das receitas, por exemplo). Ao capturar valor dos clientes, os processos entregam valor para os acionistas, que por sua vez entregam valor para os funcionários, parceiros, fornecedores, ecossistema e, em última análise, para a sociedade.

Em empresas sociais, há uma separação entre quem recebe os benefícios e quem paga pelos produtos e serviços.

Exemplos de processo ponta a ponta

• planejamento estratégico (*1) 
• desenvolvimento de produtos e serviços
• desenvolvimento de tecnologia
• intraempreendedorismo
• inovação de modelo de negócio
• marketing (*2) e vendas de produtos e serviços
• suprimentos
• produção e logística
• entrega de produto e serviços (inclui assistência técnica e manutenção)

Notas:
(*1): o planejamento estratégico cria valor, pois a inovação “começa” por esse processo. As atividades de monitoramento, controle e eventual correção de rumo fazem parte do processo de governança, que é um processo gerencial. Algumas empresas incluem essas atividades no planejamento estratégico. Nesses casos, pode-se considerá-lo um processo primário e gerencial.
(*2): marketing é mais amplo que um processo, consideramos como sendo uma  disciplina. O marketing  pode estar associado a uma função empresarial bem ampla, pois envolve vários processos. Os processos de marketing que criam valor, com relação direta com os clientes, são considerados ponta a ponta (veja o capítulo “marketing e inovação”).

Muitos processos “gerenciais” servem de apoio aos processos primários e ao mesmo tempo “gerenciam” ativos ou atividades. Por isso vamos apresentá-los de forma unificada.

O APQC (american productivity & quality center) publica um framework de classificação de processos (PCF – process classification framework), que divide os processos de negócio em duas categorias:

• processos operacionais (são os processos primários)
• serviços de apoio e gerenciais. 

Apesar do PFC do APQC apresentar os processos de apoio e gerenciais  de forma unificada, vamos diferenciar suas definições.

Processo de apoio ou suporte: apoia a realização dos processos primários. Não geram valor direto para os clientes. Processos de apoio entregam valor para os processos primários. Eles são importantes e fundamentais para os negócios porque aumentam a capabilidade da empresa em realizar os processos primários (ilustração abaixo).

Figura 452: Processos de apoio criam as condições para se realizar os processos de negócio primários ponta a ponta

Exemplos de processos de apoio

• gestão dos processos – BPM (*1)
• gestão de marketing
• gestão dos projeto, programas e portfólio (*2)
• gestão da mudança
• gestão da tecnologia de informação
• gestão de pessoas
• gestão dos recursos financeiros
• gestão dos ativos
• gestão de conhecimentos
• inteligência competitiva
• gestão da propriedade intelectual (subprocesso da gestão de tecnologia)
• gestão das relações externas (investidores, governo, setor, conselho, relações públicas)

(*1) A gestão de processos também é um processo gerencial, conhecido pela sigla em inglês BPM (business process management). Muitas vezes adota-se o termo “gestão por processos” para indicar que BPM é uma disciplina gerencial.
(*2) A gestão dos projeto, programas e portfólio contém processos gerenciais

Processos gerenciais: São utilizados para medir, monitorar e controlar um negócio visando atingir as estratégias e objetivos (ilustração abaixo). “Não agregam valor diretamente para os clientes, mas são necessários para assegurar que a organização opere de acordo com seus objetivos e metas de desempenho. Podem estar associados a áreas funcionais ou serem interfuncionais” (ABPMP, 2013).

Figura 453: ilustração dos processos gerenciais, que medem, monitoram e controlam um negócio por meio da supervisão dos processos e gestão das estratégias, objetivos e metas.

Exemplos de processos gerenciais

• planejamento estratégico (*3)
• governança (*4)
• gestão dos processos – BPM (*5)
• gestão dos projeto, programas e portfólio (*6)

(*3) o planejamento estratégico também pode ser considerado um processo primário (ponta a ponta), porque cria a direção que orienta a criação de valor
(*4) a governança corporativa, claramente, está acima de todos os processos e do negócio. Fica aparente que é um processo “puramente” gerencial. A governança de processos é utilizada para criar as regras e padrões sobre como os gestores de áreas funcionais interagem com donos e/ou gerentes de processos (ABPMP, 2013). Explore as definições de governança acessando os links acima.
(*5) gestão de processos também é conhecida pela sigla em inglês BPM (business process management). Muitas vezes adota-se o termo “gestão por processos” para indicar que BPM é uma disciplina gerencial.
(*6) A gestão dos projeto, programas e portfólio contém processos gerenciais e de apoio.

Voltamos à discussão inicial da definição básica de processo, que transforma entradas em saídas.

Na figura abaixo sintetizamos em um mapa conceitual as relações entre os processos apresentados. A relação entre processo e os que estão abaixo é uma relação de generalização e especialização (consulte pelos links o significado desses dois termos). Os processos de negócio herdam a característica do processo de transformar entradas em saídas.

Figura 503: mapa conceitual para ilustrar a relação de generalização e especialização entre a definição básica de processos e processos de negócio, que herdam a característica de transformar entradas em saídas

No próximo tópico discutiremos o uso de um processo de negócio como referência para projetos e operações. Mas para isso, precisamos antes comparar projetos (project) de operações.

De acordo com o nosso glossário:

• Projeto é um esforço temporário realizado para criar um produto, serviço ou resultado exclusivo
• Operação é função organizacional que realiza a execução contínua de atividades que produzem o mesmo produto ou fornecem um serviço repetitivo

A figura abaixo ilustra a comparação desses termos.

Figura 445: ilustração da comparação entre projetos e operações.

Projeto

• tem começo, meio e fim (é temporário);
• é único, apesar de poder ter atividades semelhantes com outros projetos, porque o resultado é único, diferenciado;
• portanto, os objetivos também são únicos, normalmente definidos no início do projeto

Exemplos de projetos:

• desenvolvimento de produtos, serviços etc.
• mudança organizacional
• construção de uma infraestrutura
• programa de treinamento específico
• implantação de um sistema de informação

Operação

• é contínua e repetitiva, como indicado na definição
• seus objetivos são atualizados periodicamente, por exemplo, no planejamento estratégico

Exemplos de operação:

• produção
• atendimento de clientes
• vendas
• compras
• assistência técnica 

Conforme alguns fatores contextuais, pode existir uma superposição entre projetos e operações, como ilustra a próxima figura.

Figura 446: ilustração da sobreposição entre projetos e operações e os fatores determinantes para diferenciá-los (variedade e volume dos resultados e frequência de realização / execução)

Se um mesmo tipo de projeto para o desenvolvimento de um mesmo tipo de produto ocorre em grande volume com alta frequência, podemos operacionalizar esses projetos. Modularizamos as opções e um novo desenvolvimento é praticamente uma configuração nova (combinação de módulos) com pouca variabilidade.

Exemplos; 

A Tecban desenvolve caixas eletrônicos. Cada desenvolvimento é praticamente uma operação, pois o volume e frequência são altos e a instalação de um novo caixa só passa pela adaptação da solução às condições locais.

Na construção civil, existem empresas, como a Tenda, que graças à aplicação de técnicas de lean production, transformaram o projeto de construção de prédios populares em uma operação.

Projetos de elevadores padronizados, como os da Atlas Schindler, nos quais todas as opções de design já estão disponíveis em um sistema de configuração, tornam-se operações.

Se uma operação de venda inclui o desenvolvimento de especificações técnicas únicas para um cliente específico, essa venda se torna um projeto. É o caso típico de vendas técnicas sob encomenda, quando o fornecedor tem de desenvolver um projeto para poder precificar e criar uma proposta.

O mesmo ocorre para a produção. A produção de uma solução sob encomenda pode ser considerada um projeto.

Por exemplo, imagine o desenvolvimento e implantação de plantas turnkey (o fornecedor é responsável por entregar a solução pronta para o cliente – é só entregar a “chave” para operação). O projeto envolve o desenvolvimento, produção dos equipamentos, a construção da infraestrutura e instalação de todos os equipamentos). Esse é o caso típico da construção civil e de fornecedores de: 

• hidrelétricas,
• frigoríficos, 
• plantas de fabricação de celulose,
• fábricas de alimentos,
• indústrias petroquímicas,
• plantas de geração de energia e outras

Com base nos conceitos do tópico anterior, projetos (project) versus operações, podemos afirmar que um processo de negócio pode servir de referência para (veja a próxima figura):

• a realização de projetos, tal como o processo de desenvolvimento de produtos e serviços (processos primários que são realizados por meio de projetos) ou
• a condução de uma operação, como o processo de produção, compras etc. (processos primários operacionais repetitivos)

Figura 456: ilustração do processo de negócio usado como referência para a realização de projetos ou para a condução de operações

Então, podemos diferenciar os processos de negócio primários end-to-end (ponta a ponta), de acordo com o seu papel como referência para projetos ou para operações:

• no caso de referência para projetos, chamamos de “processos primários realizados por meio de projetos” (A) 
• no caso de referência para operações, chamamos de “processos primários operacionais repetitivos” (B)

No caso de “processos primários realizados por meio de projetos” (A): 

• algumas atividades do processo são selecionadas e podem ser adaptadas para se tornarem atividades de um projeto;
• novas atividades, não previstas no processo, podem ser definidas para um projeto específico;
• nas fases iniciais da inovação, as atividades de um processo devem ser referências bem amplas e não detalhadas para não engessar a inovação;
• projetos disruptivos não seguem processos, pois surgem da criatividade das pessoas. Após a definição de um conceito, nas fases subsequentes de detalhamento, deve-se seguir a disciplina de um processo.

A maior parte das inovações ocorrem por meio de projetos ou iniciativas que se assemelham a projetos. Nesses casos, como ilustra a próxima figura, um processo de negócio pode servir de referência para distintos projetos de uma mesma categoria.

Figura 457: ilustração de um processo de negócio servindo de referência para a especificação de diferentes projetos da mesma categoria

No caso de “processos primários operacionais repetitivos” (B):

• as atividades da operação seguem estritamente o que está definido no processo. Normalmente são processos repetitivos, cuja qualidade e produtividades dependem da disciplina de se seguir o processo; 
• são incorporadas regras de negócio no processo para definir possíveis rotas alternativas. Por exemplo, em um processo de compras, conforme o valor, a atividade de aprovação da compra vai para um cargo específico, que possui a atribuição de aprovar esse valor;
• pode ser automatizado por meio de workflows, o que otimiza ainda mais a sua realização.

Vamos repetir os exemplos de processos de negócio primários já apresentada para diferenciá-los segundo esses dois casos, usando as duas “A” e “B” letras entre parênteses,que indicam os tipos de processos primários apresentados anteriormente::

• planejamento estratégico (A) – (*7) 
• desenvolvimento de produtos e serviços (A)
• desenvolvimento de tecnologia (A)
• intraempreendedorismo (A)
• inovação de modelo de negócio (A)
• marketing (*8) e vendas de produtos e serviços (B)
• suprimentos (B)
• produção e logística (B)
• entrega de produto e serviços (inclui assistência técnica e manutenção) (B)

Notas:

(*7) Há controvérsias se o planejamento estratégico pode ser realizado por meio de um projeto, usando um processo como referência. Além disso, como mostramos na seção “Execução das estratégias”, grande parte do planejamento falha na execução, que envolve vários outros processos. Isso exige uma gestão estratégica, que atualiza constantemente o que foi planejado, alinhando as decisões top-down (de cima para baixo), com as propostas bottom-up (de baixo para cima); principalmente na inovação corporativa integrada com o intraempreendedorismo. Porém, podemos considerar somente o planejamento estratégico anual  como um projeto, pois ele tem começo, meio e fim. O desdobramento das estratégias (caminho top-down) ou o alinhamento de iniciativas bottom-up e conexão das estratégias com os objetivos dessas iniciativas fazem parte das atividades de outros processos.
(*8) Como já dissemos, consideramos o marketing uma disciplina (veja a seção “marketing e inovação”). Porém, o processo de vendas de produtos e serviços, em geral, é um processo primário operacional repetitivo. Só seria um processo realizado por meio de projetos no caso de vendas sob encomenda ETO (engineering to order), como mostramos na seção  “inovação sob encomenda”.

Um subprocesso é um conjunto de atividades embutido em um processo maior (Baldam et al., 2014).

A figura a seguir ilustra exemplos de subprocessos. 

Figura 455: Exemplos de subprocessos

Os processos primários, de apoio e gerenciais, assim como os de fabricação transformam inputs em outputs e por isso são considerados processos. Como já mencionado, processo é uma generalização desses outros tipos de processos.

Os processos primários, de apoio e gerenciais podem ser constituídos de subprocessos, que também podemos chamar de processos, já que a definição de processos é genérica (transforma inputs em outputs).

No entanto, as especializações dos processos primários devem se ater à definição. Se um processo não tiver a característica de ser ponta a ponta (end-to-end), ele deixa de ser um processo primário.

Por exemplo, a inovação é considerada por muitos autores como sendo um processo. Sim, de acordo com a definição genérica de processo, ela seria um processo. Porém, consideramos melhor lidar com os subprocessos da inovação, pois ela é muito ampla. Vamos chamar os subprocessos da inovação de processos (está de acordo com a generalização). Trabalhar com os processos de inovação permite estruturar alternativas de gestão da inovação. Seus processos constituintes possuem as características de um processo ponta a ponta, tais como, desenvolvimento de produtos, de serviços e outros (veja alguns exemplos na figura acima).

No entanto, se descermos mais um nível da especialização deste processo, temos os processos de entendimento dos clientes e levantamento de requisitos, ou ideação e outros. Podemos ainda chamar de processos (segundo a generalização), mas não de processos primários ponta a ponta.

Subprocessos que formam um fluxo de trabalho

A articulação entre esses processos mais especializados forma um fluxo de trabalho (não necessariamente linear). O cliente interno, nesses exemplos, são os próprios membros do time de desenvolvimento de produtos e esses processos só fazem sentido se encadeados com outros processos (subprocessos) do desenvolvimento de produtos. Observe que ainda não estamos falando do nível de atividade (consultar a definição de atividade no glossário). Atividade é um nível abaixo.

Por exemplo, os resultados dos processos de entendimento dos clientes e levantamento de requisitos são as entradas para os processos de ideação; que por sua vez fornecem os conceitos das ofertas para os processos de detalhamento e lançamento. Se forem instanciados em um projeto de inovação, as atividades desses processos podem ser estruturadas em fases do projeto. O conceito de fase é da gestão de projetos, ou seja, da gestão de uma instância dos processos listados. Veja que todos esses processos podem fazer parte de um processo de desenvolvimento de produtos (por exemplo). Neste caso, esses processos podem ser chamados de subprocessos. Veja a próxima figura.

Figura 605: ilustração que representa a diferença dos conceitos de processo e fases de projeto , citando a possibilidade de se extrair atividades de processos de referência, que são alocadas em diferentes fases de projetos distintos

Processo de apoio com subprocessos “estanques” 

No caso de um processo de apoio, que gerencia um ativo, como o de gestão de pessoas destacado na figura abaixo, os processos (subprocessos) são “estanques” entre si. Ou seja, não formam um fluxo de trabalho ponta a ponta entre si. Esses subprocessos, que podem ser chamados de processos, pois transformam entradas em saídas,  existem para apoiar os processos primários, como apresentado anteriormente.

Figura 496: exemplo de um processo de apoio “estanque”, no qual seus subprocessos não formam um fluxo de trabalho (ponta a ponta) entre si

Na figura abaixo sintetizamos em uma mapa conceitual o conteúdo deste tópico, acrescido do conteúdo de tópicos anteriores.

Figura 504: mapa conceitual para ilustrar os tipos de processos e subprocessos

De acordo com o nosso glossário, uma função de negócio .. 

“refere-se a grupos de atividades e competências especializadas relacionadas a objetivos ou tarefas particulares”. Normalmente, são de responsabilidade de uma área (departamento, diretoria etc.) da empresa com uma orientação vertical de comando e controle baseada na especialização para gerenciamento de um determinado recurso (ABPMP, 2013)”

Exemplos de funções e recursos gerenciados (ABPMP, 2013):

• marketing: mercado (consumidores, concorrentes)
• suprimentos: materiais e insumos
• distribuição: logística
• recursos humanos: profissionais
• finanças: dinheiro
• patrimônio: bens
• qualidade: normas e padrões
• jurídico: leis

Esses recursos gerenciados pelas funções de negócio possuem um “ciclo de vida”, que inclui as fases de (ABPMP, 2013):

• planejamento do recurso
• aquisição do recurso
• incorporação do recurso 
• administração do recurso 
• desincorporação do recurso 

Consideramos esses exemplos simplificados demais, mas que servem para ilustrar o que são funções do negócio. Por exemplo, não enxergamos esse ciclo de vida com relação aos concorrentes na função marketing, nem a logística ou as leis. Mesmo porque o jurídico não cuida somente das leis, que nem podem ser consideradas um recurso de uma empresa. 

Existem ainda processos associados a funções de negócio, que normalmente são de responsabilidade de uma área organizacional, como a gestão de marketing.

 A função marketing possui processos, que são integrados aos processos de inovação, por exemplo: os processos de desenvolvimento de clientes, pesquisa e entendimento de mercado, teste de MVPs etc. Outros processos da função marketing não estão diretamente envolvidos com um processo de inovação, como o desenvolvimento de marca. Porém, esses dois processos são sinérgicos, ou seja, uma inovação de sucesso pode alavancar a marca, que por sua vez pode alavancar a difusão de uma inovação (veja a seção “marketing e inovação”).

Na flexm4i, consideramos o marketing uma disciplina e em algumas empresas é uma função de negócio, como você pode consultar no capítulo “marketing e inovação”.

A estrutura funcional é importante porque leva a especialização, que aumenta a produtividade. Se por acaso um processo atravessar mais de uma área funcional, as transferências (handoffs) de informações e responsabilidades causam ineficiências e rupturas por falta de um gerenciamento integrado, como ilustra a figura abaixo.

Figura 462: ilustração para representar atividades integradas em um único fluxo (processo), mas que sofrem transferências cada vez que saem de uma função de negócio, o que pode causar um desperdício  

Mesmo que um sistema de informação seja implantado para minimizar as ineficiências das transferências entre as áreas, a falta de integração entre as pessoas dessas áreas causa outros tipos de problemas. Essas limitações são mitigadas pela visão de processos.

Gerenciar por processos supera as barreiras e interfaces da estrutura funcional. A geração de valor pode ser por processos usando a visão ponta a ponta (end to end) dos processos primários. As funções podem ser tratadas como centros de serviços, que teoricamente poderiam ser administrados pelo nível de serviço que prestam, ou seja, uma espécie de SLA (service level agreement) interno.

Precisamos diferenciar essa prática por tipo de processo (veja as definições no tópico “Processo de negócio serve de referência para projetos e operações”) :

• processos primários operacionais repetitivos
• processos primários que são realizados por meio de projetos

Os processos primários operacionais podem ser estruturados dentro de uma área funcional para eliminar interfaces entre áreas organizacionais, o que torna o processo mais enxuto. É quando estruturamos a empresa por processo.

Como exemplo, temos as funções de vendas, processo de contratação de um colaborador, processo de produção, processo de compras etc. Em empresas de serviços é mais comum conseguir integrar as atividades de áreas distintas em uma nova área orientada por processo, como o processo de abertura de uma conta em um banco ou o tratamento de sinistros em uma seguradora.

A figura abaixo ilustra uma área funcional responsável por um único processo primário. As diferentes cores dos quadrados representam atividades que antes eram realizadas em outras áreas funcionais, que foram integradas.

Figura 460: ilustração de um conjunto de atividades distintas (diferentes cores) pertencentes a um processo de negócio primário e alocadas dentro de uma área funcional da empresa

No entanto, nem sempre é possível integrar todas as atividades de um processo em uma área. Principalmente para processos multidisciplinares, como o processos primários de inovação, que são realizados por meio de projetos.

Podemos criar áreas funcionais responsáveis pelos diferentes processos de inovação, tais como desenvolvimento de produtos e serviços, desenvolvimento de tecnologia, mas a natureza  desses processos continua multidisciplinar. Este é um dos diferenciais dos processos de inovação. Tradicionalmente, esses processos estão sob a responsabilidade de áreas como engenharia ou P&D, que hoje chamamos de P&D&I (pesquisa, desenvolvimento e inovação).

O exemplo a seguir foi extraído do capítulo “marketing e inovação” (próxima figura). 

Figura 461: ilustração da comparação entre a visão tradicional de desenvolvimento de produtos, na qual áreas funcionais cuidam de subprocessos criando handoffs e perda de eficiência, com a visão por processo, na qual pessoas de diferentes áreas funcionais fazem parte de um time integrado

Visão tradicional

A figura ilustra, na parte superior, a visão tradicional e limitada de uma área ser responsável por um processo multidisciplinar, exemplificado no caso de desenvolvimento de produtos. Em muitas empresas é ainda assim que funciona. Na visão tradicional, ninguém é responsável por todo o desenvolvimento do produto, que é um processo de negócio primário, transversal e multidisciplinar. 

O marketing conhece o mercado e faz um “briefing” com a engenharia passando todos os requisitos levantados. Um documento semelhante ao briefing é a especificação de design. Colocamos o termo “briefing” entre aspas porque consideramos que os designers e outros profissionais do time de desenvolvimento de produtos e serviços devem ser envolvidos no processo de desenvolvimento de clientes. Isso é ainda mais necessário se estivermos falando de inovações mais radicais. Vários insights obtidos pelas pessoas de marketing tornam-se conhecimentos tácitos, que não se conseguem explicitar (documentar) em um briefing, mesmo que se realizem reuniões para se passar essas informações. Ou seja, deve-se trabalhar em time, composto pelo pessoal de marketing e os designers, entre outros profissionais.

 Outra característica da visão tradicional é que a área “responsável” pelo desenvolvimento de produtos e serviços, a engenharia, “passa o bastão” para outras áreas, após realizar o detalhamento das especificações técnicas.

Na transferência (handoff) de informação entre áreas, muito conhecimento é desperdiçado.

Na visão tradicional perde-se o olhar multidisciplinar na criação dos artefatos.

Visão por processo 

A parte inferior da figura ilustra que a visão de processos pode integrar pessoas de diversas áreas. Observe que não estamos falando em criar uma área de desenvolvimento de produtos e sim gerenciar o desenvolvimento de produtos por processo. A figura também ilustra o compartilhamento de atividades entre processos.

Há relatos de empresas, que no passado criaram áreas funcionais para desenvolvimento de produtos, trazendo profissionais de outras áreas para formarem a nova área, tais como: assistência técnica, qualidade, atendimento de clientes, produção, marketing etc. Depois de um tempo, esses profissionais não tinham mais contato com a área original. Eles, portanto, não conheciam mais a dinâmica atual das áreas e as novas lições aprendidas, assim como as novas tecnologias que estavam surgindo e sendo aplicadas.

Essas empresas retornaram a trabalhar com a estrutura matricial e realizavam projetos para sempre contar com profissionais qualificados e atualizados nas suas diversas disciplinas.

Esse foi um exemplo didático para ilustrar a necessidade de se trabalhar por processos.

Os projetos que cruzam as áreas funcionais são abrangentes e necessitam da multidisciplinaridade de áreas diferentes, como mostramos no tópico anterior.

No entanto, projetos de menor escopo e bem focados (não necessitam da multidisciplinaridade) podem ser realizados dentro de uma área funcional.

Exemplos:

• Uma pesquisa de mercado realizada pela área de inteligência de mercado.

• Um teste de um conceito tecnológico realizado por um laboratório.

• Uma pesquisa de satisfação realizada pela área de gestão de pessoas.

O’Connor publicou um ensaio, no qual ela propôs que a inovação fosse considerada uma função de negócio (O’Connor, 2012). Sua justificativa parte de um paralelo com a evolução do marketing, que se estabeleceu como uma função de negócio. Raoni Bagno, na sua tese de doutorado, explorou com maior profundidade essa questão e chamou a inovação de função organizacional (Bagno, 2014).

Consideramos a visão de função de negócio limitante para o futuro das empresas, como discutimos no tópico “como articular a gestão da inovação com as demais abordagens?” no capítulo sobre gestão da inovação.

Separar função e áreas organizacionais por processos

Ponderamos que deveríamos separar a função de uma área organizacional específica. Julgamos importante tratar a relação entre esses três elementos organizacionais, ou seja, separar uma área organizacional de uma função de negócio

• processos de negócio
• função de negócio
• organização

Primeiramente, as funções deveriam mapear os seus processos.

Se os processos da função forem limitados a processos de apoio ad hoc, ou seja, processos que administram recursos e servem a outros processos, essas funções deveriam ser associadas a áreas organizacionais específicas.

Por exemplo, a área de contabilidade pode alocar especialistas em análise de investimento para apoiar como “consultor interno” no time de um projeto de inovação.

Se uma função possuir processos a serem integrados com processos primários ponta a ponta, as pessoas que participam desses processos poderiam ser transferidas para uma outra área, ou participarem de times de desenvolvimento por meio de squads.

Por exemplo, especialistas de hardware podem ser alocados na área de desenvolvimento provisoriamente, durante o tempo de realização de um projeto estratégico.

Se uma função for muito ampla e tiver a responsabilidade por processos primários operacionais repetitivos, as pessoas que participam desses processos poderiam fazer parte de uma nova área, juntamente com pessoas de outras funções, que eventualmente participem desses processos.

Por exemplo, o processo de armazenamento, distribuição e logística integrada pode ser unificada em uma função e em uma área organizacional.

Alguns processos de apoio, servem aos processos de negócio indiretamente, quando eles gerenciam recursos que são utilizados pelos processos de primários, tais como, gestão de TIC e de pessoas. Algumas atividades de outros processos de apoio e mesmo gerenciais fazem parte do “fluxo” de um processo primário.

Por exemplo, uma análise de investimento para inovações de sustentação são normalmente realizadas para se montar o business case e forma uma base para a decisão de se aprovar a proposta de inovação, dentro do planejamento do portfólio. Essa atividade é derivada dos processos de apoio das disciplinas contabilidade e/ou finanças (veja que existem superposições entre as disciplinas relacionadas com a inovação) e faz parte do processo de planejamento da inovação. As informações que definem as premissas para a realização da análise de investimento resultam de processos de marketing, tais como: previsão de demanda e precificação, entre outros. Já imaginou se essas atividades fizessem parte de processos separados.

Outro exemplo são as atividades de gestão de projetos e gestão de mudança, que definem atividades, que são incorporadas aos processos de inovação, que servem de referência para projetos de inovação (veja a seguir o tópico correspondente). São atividades tais como, planejar o escopo (ou o sprint na gestão ágil), motivar e empoderar as pessoas etc.  

A próxima figura ilustra conceitualmente a integração de alguns processos de apoio ou gerenciais a um processo primário.

Figura 458: ilustração de atividades dos processos gerenciais e de apoio serem integradas em um processo de negócio primário 

As atividades oriundas dos processos de apoio, quando integradas a um processo primário, tornam-se parte do processo primário. É diferente daqueles processos de apoio que gerenciam recursos, que servem de apoio à realização dos processos primários, como gestão de TIC e de pessoas.

Figura 459: ilustração da integração de atividades de processos gerenciais e de apoio em um processo de negócio primário de forma matricial

Neste tipo de representação não se coloca explicitamente as dependências entre as atividades, como mostra a figura abaixo.

Figura 460:  ilustração da integração de atividades de processos gerenciais e de apoio em um processo de negócio primário de forma matricial sem as flechas de dependência entre as atividades

Observe que as atividades core do processo de negócio primário foram denominadas nesta representação de atividades “técnicas”. Na verdade, utilizamos o termo associado à natureza principal do processo.

Na prática, quando se usa representação de forma matricial, as linhas representam áreas funcionais ou disciplinas que agregam atividades de mesma natureza e na vertical são representadas as fases, os processos, atividades e marcos do processo primário, que servem de referência para se planejar um projeto de inovação. A figura a seguir ilustra este tipo de representação. Ela vem de um caso real e por isso não é legível por questões de confidencialidade.

Figura 464: exemplo real de representação (modelo) de um processo primário com a divisão das suas atividades por área funcional / processos de apoio

A figura a seguir ilustra, de forma conceitual, a distribuição de atividades (retângulos pretos) sob responsabilidade de diferentes:

• processos de apoio e/ou
• funções de negócio e/ou
• áreas organizacionais

pela fases de um processo de desenvolvimento de produtos, que serve de referência para a especificação de um projeto de desenvolvimento de produtos..

Figura 465: ilustração das atividades de um processo primário (no caso de desenvolvimento de produtos) divididas por processos de apoio e/ou funções de negócio e/ou áreas organizacionais

Já dissemos que a inovação é multidisciplinar e multifacetada. Os processos de inovação são compostos por atividades de processos de apoio e de gestão derivados de várias abordagens e práticas, como ilustra a próxima figura.

Figura 482: ilustração das atividades dos processos de inovação derivadas de várias abordagens e práticas

Nessa ilustração da figura, cada abordagem e/ou prática (metodologia, processo, métodos e ferramentas) é representada por uma cor, e as atividades “encadeadas” nos processos possuem cores correspondentes para mostrar que elas derivam de várias abordagens e práticas.

Por exemplo, abordagens de design (representadas pela cor preta), possuem atividades e métodos, tais como, observação e entendimento do cliente, documentação da jornada do cliente, confecção de um mapa de empatia, que podem fazer parte das fases iniciais de um processo de desenvolvimento de produtos.

Podemos considerar que os processos discutidos até aqui podem ser considerados “fenômenos” que ocorrem nas empresas, que procuramos sistematizar para aumentar a sua eficiência e eficácia. O “documento” que representa um processo pode ser denominado de “modelo de processo” ou simplesmente “processo”, ou seja, o termo processo pode designar tanto o fenômeno como o “documento” que representa o processo. Isso torna o termo polissêmico o que traz ambiguidades no seu uso 

Entre outras definições do nosso glossário, selecionamos a que diz que um modelo é uma representação simplificada ou uma abstração da realidade.

Modelos estão sempre errados ao representarem a realidade. Se os erros e simplificações não interferirem no nosso objetivo de uso do modelo, podemos utilizá-los.

Modelo de processo é uma representação de um processo, que é obtida por meio da modelagem de processos. “Um modelo de processos inclui ícones que representam atividades, eventos, decisões, condições e outros elementos do processo. Um modelo de processos pode conter ilustrações e informações sobre” (ABPMP, 2013):

• Os ícones (representando elementos do processo)
• Os relacionamentos entre os ícones
• Os relacionamentos dos ícones com o ambiente
• Como os ícones se comportam ou o que executam

“Os termos diagrama de processo, mapa de processo e modelo de processo são muitas vezes utilizados de forma intercambiável ou como sinônimos. Contudo, diagramas, mapas e modelos têm diferentes propósitos e aplicações. Na prática, diagrama, mapa e modelo são diferentes estágios do desenvolvimento, cada qual agregando mais informação e utilidade para entendimento, análise e desenho de processos” (ABPMP, 2013).

Apesar dessa diferenciação formal, na flexM4i, vamos denominar essas representações de “modelo de processo” com diversos níveis de detalhamento / abstração.

Definição a partir dos termos “modelo” e “processo”

Consulte o significado de “modelo” e de “processo”, do qual derivamos o significado de modelo de processo, que associa os dois termos.

“Modelo de processo é uma representação simplificada de um conjunto de atividades inter-relacionadas ou interativas que transformam entradas em um resultado pretendido” .

Tipos de modelos de processo

Os tipos de modelos de processo dependem dos tipos dos processos de negócio, da linguagem de modelagem de processos e seu objetivo de uso, que depende dos usuários do modelo e muda dentro de cada realidade.

Podemos usar um modelo de processo para estabelecer um padrão mínimo de repetibilidade do trabalho (cuidado para não exagerar e engessar o trabalho); para definir práticas de governança; como referência para se planejar projetos; para documentar práticas e procedimentos; etc.

O modelo representa o processo real. Ou melhor, o modelo de processo de uma empresa deveria representar o processo real. Porém, é comum encontrar uma disparidade entre o que está documentado em um modelo de processo e o que as pessoas realizam no processo real. Essa é uma disfunção a ser analisada para se identificar a causa raiz. As possíveis causas podem ser:

• modelo de processo detalhado demais de forma desnecessária
• modelo de processo não atualizado e não alinhado com a evolução da prática
• falta de disciplina em “seguir” o modelo (lógico que partindo do pressuposto que deva ser seguido)
• desafios muito novos que não eram previstos no modelo
• falta de cultura em se trabalhar sistematicamente (quando necessário)
• documentar em processos um conjunto de atividades de criatividade, ou seja, que não deveriam ser documentadas

Os modelos de processo são “desenhados” de uma forma livre ou com base em uma linguagem de modelagem. É o que denominamos de modelagem do processo.

Linguagens de modelagem de processo também são denominadas de metodologias ou métodos de modelagem. Elas servem para se explicitar um modelo tanto em forma gráfica, textual e/ou lógica.

Qual formalismo utilizar para modelar os processos de inovação?

Essa é uma pergunta difícil de responder, pois depende de muitos fatores. Segundo Costa et al. (2017), “os modelos de processo de design atendem a diferentes objetivos, que inclui a gestão de projetos e a realização de das atividades diarias”.

O formalismo de modelagem deve atender às necessidades dos usuários nos seus diferentes contextos (Costa et al., 2017).

Seguem alguns exemplos de formalismos de modelos:

• para representar os processos de inovação para uma audiência interessada em uma visão geral, você pode utilizar figuras sem formalismo;
• para treinar pessoas sobre as atividades e responsabilidades do processo, você pode utilizar qualquer linguagem de modelagem de alto nível, com a qual os usuários estejam familiarizados, com a indicação de templates de uso, tais como BPMN (business process management notation), IDEF0, fluxogramas, EPC;
• para automatizar parte do processo (sequência de aprovação de artefatos, compra de material para construção de protótipos, contratação de parceiros etc.), você pode utilizar uma linguagem que permita ser facilmente implementada em um workflow, tais como BPMN, IDEF3.

Por exemplo, frequentemente, as atividades dos processos de compra podem ser automatizadas por meio de um workflow. Outras atividades, recorrentes e padrão em processos de design, como as de aprovação de um desenho / modelo, também podem fazer parte de um workflow. Essas atividades são de apoio à inovação e ficam distribuídas e integradas aos processos primários de inovação (como mostramos em “Integração dos processos de apoio aos processos de negócio primários” ).

• para simular o processo, você pode utilizar as linguagens utilizadas para automatizar ou as linguagens proprietárias das ferramentas de simulação;

• para otimizar o fluxo de criação de valor durante a realização das atividades dos processos de inovação, você pode utilizar a VSM (value stream mapping)

• para apoiar a gestão de projetos tradicional, você pode criar checklists das atividades, que se tornaram tarefas (tasks) de um sistema de gerenciamento de projetos;
• para apoiar a gestão ágil de projetos, você pode criar uma lista de artefatos (entregas) e atividades, que farão parte de um backlog de planejamento das iterações (sprints);
• para apoiar a realização das atividades dos processos de inovação (que se tornam tarefas dos projetos), você pode utilizar qualquer mídia, como vídeos, áudios, storyboards, ou mesmo soluções de realidade aumentada.

Como o próprio nome diz, um modelo de referência de processo é uma representação de um processo, que pode servir de referência para diversos usos.

Não existe um consenso do significado do termo “modelo de referência”.  Alguns autores dizem que “este termo é usado para denominar modelos de processo genéricos de um domínio específico, ou seja, um modelo de processo que poderia ser utilizado como referência ou benchmark para uma empresa (Costa et al., 2015). Fettke et al. (2005) afirmam que “modelos de referência também são chamados de modelos universais, modelos genéricos ou padrões de modelos. Para se criar um modelo de referência particular (de uma empresa), os modelos de referência devem ser adaptados a uma empresa específica”. 

Um modelo de referência pode estar associado a uma empresa em particular ou pode ser genérico. Devido a ambiguidades resultantes dos diversos significados de um modelo de referência, adotamos como sinônimos os termos “modelo de referência” ou “metodologia”, quando se tratar de uma referência genérica, e o termo “modelo de processo” ou simplesmente “processo”, quando se tratar da referência de uma empresa particular.

No entanto, recomendamos que você adote o termo que está mais acostumado e que faça parte do seu repertório ou da cultura da sua empresa.

Um ou mais modelos de referência ou metodologias podem servir de inspiração (referência) para você definir o modelo de processo da sua empresa, que por sua vez se torna uma referência para a especificação de projetos. Na próxima figura ilustramos essas definições e os sinônimos comumente utilizados.

Figura 242: ilustração do modelo de referência ou metodologia (e outros termos equivalentes) como uma referência genérica que serve de inspiração para a definição de modelos de processo ou processos (e outros termos equivalentes) de uma empresa específica 

Um modelo de referência (ou metodologia) instanciado e formalizado em uma empresa torna-se um (modelo de) processo específico dessa empresa.

e

Um modelo de um processo de inovação (específico de uma empresa), também denominado simplesmente de processos, pode servir de referência para a definição de projetos de inovação, como ilustra a figura anterior.

Na figura abaixo sintetizamos em uma mapa conceitual dos termos que adotamos na flexM4I, que representa o que apresentamos neste tópico.

Figura 505: mapa conceitual que representa os termos relacionados com metodologia (de um processo) e processos de negócio.

A flexM4I apresenta vários modelos de processo que podem ser usados como referência para você desenvolver um projeto de inovação, ou estabelecer processos de inovação para desafios recorrentes de sua empresa. Ou seja, esses modelos de processo são considerados modelos de referência (*)

Modelos de referência (*) não são específicos para uma empresa. 

Um processo de uma categoria (por exemplo, de desenvolvimento de produtos) pode ainda dar origem a diferentes projetos da mesma categoria. No momento da especificação do projeto (com base no modelo de referência), as adaptações do processo resultam em projetos distintos.

Um exemplo de processo deste tipo é o processo de criação de startups do Steve Blank e Bob Dorf, o “Startup: manual do empreendedor – um guia passo a passo para construir uma grande empresa” (Blank & Dorf, 2012).
Outro famoso é o “stage-gate” do Robert Cooper, Winning at new products: Creating value through innovation (Cooper, 2017), descrito na seção “metodologias e modelos de processo”.

Mas a especificação de um projeto pode ser realizada “do zero” sem usar um processo como referência…

… principalmente em empresas iniciantes, a prática de usar um modelo de referência criaria muita burocracia. Só vale a pena ter processos de referência, quando desafios semelhantes e recorrentes existirem.

Processos amplos e pouco detalhados, não prescritivos e baseados em princípios podem ser utilizados como referência para se definir projetos de inovação.

Um exemplo é o livro de lean design intitulado, The Toyota product development system: integrating people, process, and technology (Morgan & Liker, 2020). 

A 7a edição do PMBOK (padrão para gestão de projetos) também está baseada em princípios e não mais em processos.

Na verdade, você pode criar um processo não só baseado em modelos de referência, metodologias mas adicionando também outras fontes de informação, tais como abordagem, métodos e ferramentas, como ilustra a próxima figura.

Figura 238: ilustração para representar que modelos de processos de uma empresa específica podem ser criados com base em diversas fontes de informação e não somente em metodologias

Dessas fontes extraímos princípios e práticas, que podem complementar as metodologias que adotamos como referência.

Repare no texto “outras perspectivas??” da figura. Foi colocado para destacar que a discussão realizada aqui é focada na perspectiva procedural (de processos). A empresa possui outras perspectivas (organizacional, pessoal, estratégica, recursos), cujas práticas podem vir de abordagens e não somente de metodologias. A consideração dessas outras perspectivas é essencial para o sucesso da gestão da inovação.

Nem sempre conseguimos derivar um processo a partir das fontes apresentadas no tópico anterior. Isso porque o processo real já existe, ou seja, as pessoas já praticam as atividades daquele processo. O processo “foi se formando organicamente a partir da prática”. Pode ser que o processo real tenha falhas que podem ser otimizadas. Porém, muitas vezes existem práticas no processo atual que foram sendo aprimoradas com o passar do tempo e que devem ser incorporadas em um novo modelo de processo (ou simplesmente processo) da sua empresa. 

Você sempre deve partir de um diagnóstico para conhecer os pontos fortes, que devem ser mantidos, e os fracos que precisam ser melhorados.

Assim, uma empresa pode ter dois modelos de um mesmo processo: um que representa a situação atual (as-is) e outro que representa a situação desejada futura (to-be). Só que essas representações não existem concomitantemente. Elas surgem em momentos distintos de acordo com um projeto de transformação dos processos. Como ilustra a figura abaixo, cujos passos são descritos a seguir.

.

Figura 241: passos para se criar um modelo de processo futuro (to-be)

Os passos para se obter um modelo de processo futuro (to-be) são:

1. Modelagem e análise: o processo atual (real) é modelado e se cria o modelo de processo atual (as-is). Esse modelo pode usar um formalismo de representação bem simples. O objetivo neste passo é entender e analisar o processo atual.  Em geral, realiza-se um diagnóstico para levantar os pontos fortes e fracos. 
2. Comparação: uma metodologia/ abordagem ou uma combinação de abordagens e metodologias (e/ou práticas avulsas) servem de referência para compararmos com a situação atual. Neste passo, podem ser usados também BOKs, padrões, normas e framework (como mostra o próximo tópico). O intuito aqui é complementar a análise anterior para se levantar possíveis princípios e práticas a serem incorporadas ao novo modelo de processo. 
3. Modelagem (instanciação): define-se uma situação ideal, instanciando uma metodologia (ou mais de uma) em um modelo de processo futuro (to-be). Como já dissemos, podem ser utilizadas outras fontes. O conhecimento da equipe com relação a novos princípios e práticas que podem ser utilizados é muito importante.
4. Implementação: a situação futura (to-be) desenhada é implementada no processo real. Este passo é muito importante, pois aqui podem surgir muitas barreiras a serem vencidas. É quando se especificam sistemas de informação para apoiar a execução do processo etc. 
5. Este não é um passo propriamente dito. É quando o modelo de processo futuro torna-se atual, ou seja, um único modelo (e não mais dois modelos distintos). Volta então a existir um único modelo de processo que representa o processo atual, como ilustrado na figura do tópico anterior.

Depois de um tempo, o processo real se consolida, as pessoas aperfeiçoam suas práticas, novos conhecimentos, tecnologias e práticas são criadas. O ciclo de melhoria contínua do processo se repete.

Os passos apresentados representam uma simplificação de um ciclo de BPM. Mais a frente vamos citar um ciclo mais completo, que você pode consultar.

Algumas organizações, tais como associações de profissionais, compilam melhores práticas para serem usadas como referência por profissionais da área de conhecimento que elas representam.

Devido a sua relevância, a flexM4i possui uma seção específica sobre o tema deste tópico.

Vamos repetir a seguir a figura central da seção citada, que mostra a relação dessas referências no contexto da gestão de processos.

Figura 243: ilustração de duas alternativas para se definir um modelo de processo específico para uma empresa a partir BOKs, padrões e normas: 1) estudando os documentos; 2) instanciando (derivando) o processo a partir de um modelo de referência (genérico) – clique na figura para aumentá-la.

Essa figura integra os aspectos que tratamos nos tópicos anteriores sobre referências para “inspirar” a criação de um modelo de processo específico para uma empresa.

Uma explicação detalhada desta figura, assim como outros conceitos sobre “Corpo de conhecimentos (BOK: body of knowledge), norma, modelo e framework de processos”, você pode ler na seção”Corpo de conhecimentos (BOK: body of knowledge), norma, modelo e framework de processos”, cujo sumário e links apresentamos a seguir.

• 1 Introdução
• 2 Corpo de conhecimentos (BOK)
  • 2.1 Definição
  • 2.2 Exemplos
• 3 Normas
  • 3.1 Definição 
  • 3.2 Exemplos
  • 3.3 Normas delimitam a gestão da inovação
• 4 Modelo de processo e modelo de referência de processos
  • 4.1 Definição
  • 4.2 Exemplos
• 5 Framework de processos
• 6 Definição
  • 6.1 Exemplo
• 7 Como utilizar os BOKs, padrões e normas?
  • 7.1 Exemplos de objetivos de aplicação
  • 7.2 São importantes para as fases de detalhamento
  • 7.3 Certificação de profissionais
  • 7.4 Como definir um modelo de processo da sua empresa a partir dessas publicações?

Um ponto central do BPM, na fase de análise, modelagem e otimização é definir uma arquitetura de processos de negócio (BPA: business process architecture).

Antes da definição da BPA, apresentamos os conceitos de:

• arquitetura empresarial, também conhecida como arquitetura dos sistemas empresariais ou corporativos (do inglês ESA – enterprise systems architecture), que inclui a arquitetura de negócios e a arquitetura da tecnologia de informação e comunicação (TIC);
• arquitetura de negócios, componente de nível superior de uma arquitetura empresarial e
• arquitetura de processos de negócio (BPA). como parte principal da arquitetura de negócios 

A próxima figura ilustra essa relação entre essas três arquiteturas.

Figura 906: arquiteturas que compõem uma arquitetura empresarial

A arquitetura empresarial também é conhecida como arquitetura dos sistemas empresariais ou corporativos (do inglês ESA – enterprise systems architecture).

Uma arquitetura empresarial é um modelo que representa a estrutura da organização e como ela atende aos requisitos atuais e objetivos futuros (to-be) do negócio (ABPMP, 2013).

O conceito de arquitetura empresarial surgiu na comunidade de tecnologia da informação e comunicação (TIC). Até hoje e também devido à difusão da abordagem de transformação digital, o conceito de arquitetura empresarial direciona a implementação de tecnologias de informação e comunicação (TIC). Na verdade, neste contexto é utilizado um termo em inglês, que representa este viés “enterprise systems architecture (ESA)”, cuja tradução literal seria “arquitetura dos sistemas empresarias” ou “arquitetura de sistemas corporativos”.

O termo arquitetura de sistemas corporativos (ESA) introduz intencionalmente um viés de TIC para o papel da arquitetura empresarial, que fornece uma direção estratégica e estruturação dos recursos de TI dentro organização, assim como os mecanismos de controle, para garantir que o cenário tecnológico e modelos operacionais de negócios estão alinhados. O objetivo de uma função empresarial, que gerencie a arquitetura empresarial, é fornecer o suporte e a orientação necessários para qualquer projeto, sistema ou processo que possa impactar o ecossistema de tecnologia (da informação) da organização para apoiar suas operações enquanto aborda os capacitadores de tecnologia para os modelos operacionais de negócios (Banger, 2022). 

Tradicionalmente, a arquitetura empresarial foca no alinhamento entre as tecnologias de software, aplicativos e elementos da infraestrutura de TI. Hoje em dia, a arquitetura empresarial mostra como a TIC apoia os processos de negócio (vom Brocke & Rosemann,  2015)

A missão crítica de uma arquitetura empresarial é vincular as arquiteturas de negócios, de sistemas e de tecnologia de informação e comunicação  (Rummler & Ramias, 2010), como ilustra a próxima figura.

Figura 510: as arquiteturas que compõem a arquitetura empresarial, também conhecida como arquitetura dos sistemas empresariais ou corporativos (do inglês ESA – enterprise systems architecture).
Fonte: adaptado de Rummler & Ramias (2010)

“Apesar da arquitetura empresarial ser um tema estudado desde os anos 1980, a sua missão crítica de definir e conectar negócios, sistemas e a arquitetura de TIC raramente foi atingida. Os projetos de arquitetura empresarial são muitas vezes reduzidos a nada mais do que exercícios elaborados para inventariar sistemas e tecnologias, com pouco ou nenhum esforço para documentar e analisar a direção estratégica e os processos de negócios das empresas, que deveriam orientar as iniciativas de TI” (Rummler & Ramias, 2010).

Na proposta de Banger (2022), a arquitetura empresarial é composta dos seguintes níveis:

• Modelo de operação do negócio: forças externas, motivadores / condições / recursos (drivers) para mudança, estrutura empresarial, modelos de negócios, informações, gestão financeira;
• Processos de negócio;
• Capabilidades;
• Aplicações (software);
• Serviços de dados e informações (software);
• Serviços de tecnologia (hardware);
• Serviços tecnológicos (lógico)
• Serviços adicionais de valor agregado: segurança, recuperação de desastres, governança e capabilidades não funcionais (usabilidade, documentação, integridade, robustez, auditoria e outros)  

A arquitetura de negócios, que alguns confundem com arquitetura de processos, é discutida no próximo tópico.

“A arquitetura de negócios representa as visões holísticas e multidimensionais de negócios de: recursos, entrega de valor de ponta a ponta, informações e estrutura organizacional; e as relações entre essas visões e estratégias de negócios, produtos, políticas, iniciativas e partes interessadas” (Guild, 2021).

Uma arquitetura de negócios representa uma empresa e seu ecossistema de negócios. Assim, ela agrega valor ao permitir que ocorra uma comunicação eficaz sobre o negócio. A estrutura da arquitetura de negócios (Guild, 2021):

• possibilita uma comunicação eficaz sobre o negócio;
• permite traduzir as estratégias em ações;
• aumenta a capacidade da empresa de implementar mudanças transformacionais;
• facilita navegar pela complexidade do negócio;
• reduz os riscos, pois possibilita uma avaliação das estratégias a luz da visão holística antes de implementá-las;
• apoia a tomada de decisões, pois são baseadas em informações mais abrangentes do negócio; 
• alinha os stakeholders, com base em uma visão compartilhada do futuro;
• orienta a implementação mais eficiente e eficaz da tecnologia de informação e comunicação (TIC).

A próxima figura representa os aspectos da arquitetura de negócios, segundo o Guild (2021).

Figura 902: Aspectos de uma arquitetura de negócios
Fonte: adaptado de Guild (2021)

Na verdade, uma arquitetura de negócios representa o ecossistema de negócios (que inclui a própria empresa) e deve destacar que os negócios não estão confinados aos limites da empresa. Eles ocorrem por meio de interações com atores do ecossistema.

Uma arquitetura de processos (BPA – business process architecture) descreve as relações entre os processos. A BPA determina “como o negócio é organizado para atingir os seus objetivos” (Harmon, 2015).

Segundo vom Brocke & Rosemann (2015), a arquitetura de processos de negócio (BPA) também é conhecida como arquitetura de negócios. Eles consideram, na mesma publicação, que a arquitetura de negócios define como que o negócio está organizado para atingir seus objetivos.

No entanto, consideramos que a arquitetura de processos de negócio (BPA) é uma das perspectivas da arquitetura de negócios.

A camada de arquitetura de negócios (tópico anterior) trata da estratégia de negócio, de políticas, de modelos conceituais, dos processos organizacionais, sua governança e suas relações. Portanto, os processos estão inseridos na arquitetura de negócios, ou seja, elas não são equivalentes. A BPA está localizada na parte superior de uma arquitetura empresarial, articulada com a arquitetura de negócios, como ilustra a próxima figura.

Figura 903: as arquiteturas que compõem a arquitetura empresarial com destaque para o posicionamento da arquitetura de processos (BPA) na arquitetura de negócios
Fonte: adaptado de Rummler & Ramias (2010)

Burlton (2015) propôs um método para alinhar a arquitetura de processos (BPA) com a orientação estratégica da empresa, composto pelas seguintes atividades:

• entender o contexto da empresa
• determinar as relações dos stakeholders e os fatores críticos de sucesso;
• consolidar os critérios estratégicos;
• modelar os processos empresariais;
• definir indicadores de desempenho;
• estabelecer a governança dos processos;
• alinhar as capabilidades dos processos;
• gerenciar os processos

Selecionamos duas das definições do nosso glossário.

“Modelo de negócio descreve a lógica de como uma organização cria, entrega e captura valor” (Osterwalder & Pigneur, 2010).

“Em essência, um modelo de negócios incorpora nada menos que a “arquitetura” organizacional e financeira de um negócio. Não é uma planilha ou um modelo computacional, embora um modelo de negócio possa estar inserido em um plano de negócio e nos pressupostos de receitas e nas projeções de receitas. Mas, claramente, a noção de modelo de negócio refere-se em primeira instância a um modelo conceitual, e não financeiro, de um negócio.” (Chesbrough  & Rosenbloom, 2002)

O conceito de modelo de negócio, que veio da comunidade de administração, tem uma superposição com a arquitetura de negócios, que surgiu da comunidade de TIC, como citamos anteriormente. Porém, o modelo de negócios é mais superficial e mais abrangente que uma arquitetura de negócios e não é voltado para vincular a arquitetura de TIC, como ilustra a próxima figura.

Figura 904: ilustração da posição do modelo de negócio no topo da arquitetura empresarial (ESA – enterprise systems architecture – possui um viés de TIC) e superposto à arquitetura de negócios (o ícone da figura representa a figura 902 dos aspectos da arquitetura de negócios). Mostra ainda que o detalhamento da arquitetura de negócios é por meio de diversos modelos das outras perspectivas (recursos, organização etc.). TIC: tecnologia de informação e comunicação.

Um dos componentes de um modelo de negócio são os processos chave, como mostra a próxima figura.

Figura 905: framework do modelo de negócio CANVAS, com destaque para o componente “processos principais”.
Fonte: adaptado de  Osterwalder & Pigneur (2010)

Veja que em um modelo de negócio listamos somente o título dos processos principais, que trazem um diferencial para obter uma proposição de valor diferenciada. Não é uma arquitetura de processos. Esses processos principais precisam estar representados com um maior nível de detalhe na arquitetura de processos, juntamente com outros processos, que não são principais para obter a proposição de valor.

ABPMP (2013). CBOK v3.0 – Guide to the Business Process Management Common Body of Knowledge. 3. ed. Indiana: Association of Business Process Management Professionals. Disponível em: www.abpmp.org..

Baldam, Roquemar; Valle, Rogerio; Rozenfeld, Henrique (2014). Gerenciamento de processos de negócios – BPM: uma referência para implantação prática. 1. ed. Rio de Janeiro: Elsevier.

Banger, D. R. (2022). The Stack. In Enterprise Systems Architecture: Aligning Business Operating Models to Technology Landscapes (pp. 25-32). Berkeley, CA: Apress.

Burlton, R. (2015). Delivering Business Strategy Through Process Management. In: Vom Brocke, J.; Rosemann, M. (Eds.). . Handbook on Business Process Management 2, 2nd Edition. Berlin, Heidelberg: Springer Berlin Heidelberg. p. 45–78.

Cheng, L. C., & de Melo Filho, L. D. R. (2007). QFD: desdobramento da função qualidade na gestão de desenvolvimento de produtos. Editora Blucher.

Chesbrough, H., & Rosenbloom, R. S. (2002). The role of the business model in capturing value from innovation: evidence from Xerox Corporation’s technology spin‐off companies. Industrial and corporate change, 11(3), 529-555.

Costa, D. G., Macul, V. C., Costa, J. M. H., Exner, K., Pförtner, A., Stark, R., & Rozenfeld, H. (2015). Towards the next generation of design process models: A gap analysis of existing models. Proceedings of the International Conference on Engineering Design, ICED, 2(DS 80-02).

Costa, D. G. G., Costa, J. M. H., & Rozenfeld, H. (2017). A guide to investigating design process models context of use. Proceedings of the International Conference on Engineering Design, ICED, 2(DS87-2), 31–40.

Fettke, P., Loos, P., & Zwicker, J. (2005). Business process reference models: Survey and classification. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 3812 LNCS, 469–483. https://doi.org/10.1007/11678564_44 

Guild, B. A. (2021). PART 1 : INTRODUCTION Purpose of the BIZBOK TM Guide What is Business Architecture ? A Guide to the Business Architecture Body of Knowledge (BOZBOK), 1–12

Osterwalder, A.; Pigneur, Y. (2010) Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers; John Wiley and Sons: Hoboken, NJ, USA.

Rummler, G.A., Ramias, A.J. (2015). A Framework for Defining and Designing the Structure of Work. In: vom Brocke, J., Rosemann, M. (eds) Handbook on Business Process Management 1. International Handbooks on Information Systems. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-45100-3_4 

Smith, H., & Fingar, P. (2003). Business Process Management: The Third Wave., Meghan-Kiffer, Tampa, FL, USA.

vom Brocke, J., & Rosemann, M. (2015). Handbook on business process management 1 introduction, methods, and information systems. International Handbooks on Information Systems. Springer, Berlin, Heidelberg.