Dynamism and order
The diversity of the Transformations leads to a growing number of Solutions: we have to not only manage Distribution, Production, Resources and enterprise management Solutions, but also
- Accompany the new Offers made possible by the digital opportunities
- Manage the multi-channel
- Add data analysis Solutions (Big Data)
- Interconnect partner Solutions, which are increasingly integrated with those of the Enterprise
- Allow the different Models to access the different
Do we need a framework to ensure that these multiple Solutions are part of a coherent whole or should we leave every freedom to each Solution to not harm the dynamics?In actual fact, we do not have a choice; different factors lead us to create an overall framework:
- Group the information that enables us to manage the Customer together: his/her behavior, Product equipment, expectations, profitability, risk...
- Agglomerate coherent management data
- Control the end-to-end Processes whatever the channels used
- Offer a uniform Usage to Users so that they are not afraid of crossing from one Solution to another.
- Share identification and security Functions
The real difficulty is in setting up a framework that not only does not slow down the initiatives, but actually accelerates the Transformation projects.Different methods contribute to this. We have grouped them together under the term "Foundation":
- Interconnect the Solutions from the different domains properly
- Reuse Components to build new Product Models
- Reuse Components to build new Solution Models
- Provide consistent user Usage
- Harmonize the Transformation Processes
In this scene, we cover the first method: Solution exchanges.
The different Solutions need to exchange with each other
Solutions supply other Solutions
The first Solutions installed in the Enterprise were independent of each other. We had to re-enter the same information in the different Solutions, which represented a heavy workload, data entry errors, update discrepancies, in short a growing inconsistency in the Enterprise information system.
Then, we understood that we had to interconnect the Solutions to avoid these difficulties and let the information from one Solution flow automatically to another; for example:
- Production feeds into Distribution.
- Payroll feeds into accounting.
- All Solutions feed into the management Solution.
Data is shared
The same Customer Information is useful in different Solutions: Distribution Solutions of the different Product lines, maintenance Solutions, billing Solutions... We must therefore be able to share the same Customer information between different Solutions.
In the same way, Information which describes the Enterprise structure or the user rights and responsibilities are useful in all the Solutions.
End-to-end Processes cross several Solutions
Customer order management can cross different Solutions: quotation Solution, contract management Solution, billing Solution, payment and litigation management Solution, delivery management Solution, sales statistics Solution... Each Solution must be able to feed into the next Solution in the context of an end-to-end Process, while safeguarding the context of the Process.
Different types of exchanges between Solutions
There are different types of exchanges between Solutions:
- Synchronous or asynchronous
- Query or updates of information
- Triggering IT Services (that are frequently implemented today as a Web Service)
- Data replication
- Flows between Solutions
How do we properly define the exchanges between Solutions?
The multiplication of exchanges generates significant complexity: certain IT directors complain that they have become plumbers, spending their time connecting Solutions.
It is quite common that building these exchanges takes more effort than building the functionalities awaited for by the users of the Solution.To limit this complexity, there are 3 ways:
1. Limit the number of Solutions: look for Solutions broad in scope so that a certain number of exchanges are taken into account inside each Solution.
2. Group together the different exchanges in wide reaching Services. For example, if we need to
- know the customer's name by his/her login, for a sales Solution
- know the customer's address by his/her login, for a billing Solution
- know the customer's account by his/her login for a
customer payment management Solution
we can then set up a single exchange Service that, from the customer login, provides all 3 pieces of information: it is then up to everyone to only use what he/she needs. The challenge is finding the right compromise between reducing the amount of exchange types and the increasing heaviness of each exchange.
3. Tool making exchanges so that each build of an exchange Service is quicker.
An overall vision is necessary
The most important thing is to deal with the exchanges as a coherent whole and not as continuous additions of exchange formats as the Solutions are set up.
The right approach consists in:
- Defining the Enterprise data Model
- Defining the Solutions map
- From there, deducing the list of exchange Services.
See the white paper from CEISAR
The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.