Na medida em que os processos de negócio ficam mais complexos, torna-se mais frequente a necessidade de suportá-los com mais de uma aplicação. Exemplos comuns são aqueles processos que transpassam diversas áreas ou departamentos na organização sem que, necessariamente, aconteçam “passagens de bastão” – ou seja, todos os envolvido continuam mobilizados até que o processo como um todo seja concluído.
Colaboração ou integração?
“Colaboração”, no contexto que apresentamos aqui, é um conceito um pouco mais amplo que “integração”. Ela assume o pressuposto de suportar capabilities que não eram intencionadas, de forma plena ou específica, por nenhuma das aplicações envolvidas (como componentes) na solução que está sendo proposta.
Na visão do modelo indicada no diagrama acima, temos expressa uma “colaboração” entre os sistemas de ERP e CRM como forma de suportar o atendimento comercial de varejistas. Esta colaboração fica “visível” através de uma API que deve ser consumida, primariamente, através de um website.
Já na visão do modelo indicada no diagrama acima, fica explicitado que o propósito da “colaboração” é fornecer as implementações de funcionalidades necessárias para o atendimento do serviço de order taking, necessário para que compradores varejistas possam escolher e comprar produtos que serão vendidos por suas empresas.
Interessante constatar nas visões de modelo que estamos compartilhando a separação entre a intenção abstrata e realização concreta. Por exemplo, ficou indicado que os compradores realizam suas interações através de um website público (intenção abstrata) que será um website desenvolvido especificamente para este fim (realização concreta). Da mesma forma, está explícito que a execução das funções ocorrerá por meio de uma API específica (intenção abstrata) que, internamente, utilizará uma “colaboração” entre o ERP e o CRM (realização concreta). Finalmente, indica-se que um “serviço de aplicativo” de order taking (intenção abstrata) será disponibilizado para os compradores e que, internamente, esse serviço será “desempenhado” por funções de gestão de pedidos (realização concreta) fornecidas pela “colaboração”.
A separação entre “intenção abstrata” e “realização concreta” permite revisões táticas, como, por exemplo, substituir o website específico por uma solução de mercado, a colaboração por uma solução CRM mais “completa” que precise apenas de uma integração, etc.
Ligação com a estratégia
Idealmente, todos os impactos na arquitetura corporativa precisam encontrar justificação na estratégia. Uma boa justificativa é garantir que os elementos de motivação sejam considerados durante todo o “curso de ação” para implementação da melhoria, bem como garantir patrocínio executivo suficiente.
A visão de modelo, expressa no diagrama acima, aponta a “colaboração” do ERP com CRM para atender varejistas como recurso necessário para a capability de gestão de varejistas, conduzindo a qualificação do relacionamento com estes. Entende-se que tal medida deverá colaborar para o incremento das vendas no próximo ano fiscal e diminuir insatisfações, impactando positivamente o faturamento.
Detalhamento operacional
Uma colaboração não trata apenas de “levar e trazer” dados (o que caracterizaria uma integração), mas, sim, de viabilizar “serviços de aplicação” inéditos. Por isso, a modelagem de uma colaboração precisa “tangibilizar” como isso acontecerá.
A visão do modelo, expressa no diagrama acima, indica que a “colaboração” entre ERP e CRM fornece funcionalidades (realização concreta) para a execução de serviços (intenção abstrata) relacionados a order taking, utilizados pela “saga” de captura de pedidos que é disparada na ocorrência de “eventos” de solicitação de orçamento.
// TODO
Antes de avançar para um outro capítulo, considere ponderar as seguintes questões:
- Em sua organização, há clara distinção entre “colaborações” e “integrações”?
- Há vinculação clara entre iniciativas técnicas e a estratégia?
