S. Ketharaman’s blog post “When ERP Projects Get Derailed by Silly Reasons” is an excellent read about where the world’s leading ERP systems faced tough situations that they could not handle. He quotes Handelsblatt, “Altering existing COTS software like ERP / SAP is like changing a prefab house, You can put the kitchen cupboards in a different place but you can’t move the walls”.
Introduction
No doubt, ERPs are mammoth systems, and creating an ERP is not a simple affair. Firstly, it is because most ERPs aim to automate a large part of a firm’s operation as opposed to a small part — so the magnitude of the functionality itself is high. On top of it, there are differences among the ways companies run their operations, and ERPs need to cater to all of them in order to be relevant across these companies.
Most ERPs therefore need to be customized for the business environment. The ERP implementation projects are complex enough that they often run for months. As an oversimplified representation of the customization, think of choosing a few items from the list of many (Image by janjf93 from Pixabay). Companies use 20% or less functionality that is available in an ERP.
Against this backdrop, Xsemble offers a unique approach, which holds the promise to ease out the analysis and actual change implementation.
On Xsemble
We cover a few essentials about Xsemble here. For more details, one may refer to xsemble.com.
Xsemble is about visual assembly of software from tiny, molecular, software components. The signature of Xsemble technology is a flow diagram that wires the nodes together. This flow diagram represents both the control flow (gray arrows) and data flow (dashed blue arrows).
A flow diagram is also called a project. The subproject node within a project represents another project. In the sample flow diagram below, “User Validation” node is a subproject node.
When you have the flow diagram and the implementations of individual components, you can generate the application at the click of a button. The runtime code generated ensures that the control flow and data flow of the application work exactly according to the flow diagrams. This step does not require any programming.
Xsemble Based ERP
This post is from the perspective of an ERP vendor, so let us imagine what happens if the complete ERP solution is built with Xsemble. (The ERP process models made in Xsemble may be taken as a starting point if one wants.) There could be alternatives, such as developing ERP plugins or adapters with Xsemble, but we ignore those for now.
The primary differentiating feature of an ERP built with Xsemble will be that you will always have the Xsemble flow diagram to refer to, and it will be a visual yet accurate representation of how the software behaves. There is scope for the complexity of the software itself to come down as we shall see under “Lean ERP” below. But notwithstanding that, we understand that an ERP solution will still remain inherently complex. However, the big difference with an Xsemble based software is that the complexity will be there in the visual flow diagram which can have many eyes on it, and not at the code level. Therefore, it will be orders of magnitude easier to deal with.
As the complete software is made up of tiny components, depending on the size and nature of the change, trivial changes will need changes in a few components and bigger changes will need changes in many more components. Whatever the case may be, the presence of the flow diagram as a true representation of the system will certainly help in the analysis. It is a huge advantage that the change analysis happens at the flow diagram level as opposed to the source code level, because:
- The domain experts can participate in the analysis without needing to know how to read code
- Human beings relate to visual information better and start seeing patterns
Consequently, as moving the kitchen cupboards will be possible (simpler changes), so will be moving walls (larger changes). The latter will be a more difficult but not impossible. Since everything is made up of tiny components (like the Lego blocks), theoretically no change is out of bounds. The customizability of the software is not restricted to the situations the software designers originally thought.
At the time of making changes (execution), the effort will be helped with more expert eyes on the design changes.
In summary, the Xsemble approach will aid you during the change analysis as well as execution, to help your team make even larger changes to the software with a lower risk.
Bonus: A Lean ERP
As a bonus, here is one more thought about going towards a much leaner ERP with Xsemble.
We saw that a client company uses only 20% of the functionality in an ERP software. The rest 80% still clogs the resources, doesn’t it? It gets loaded in the memory and makes the software sluggish. What if this can be taken out?
Here is a suggestion to make a lean ERP, which
- is optimized to the processes of a given company
- consumes less resources and runs faster
- does not need customization
Following steps are indicative of how such a solution can be created:
- Create a Minimalistic ERP: Create your ERP solution with the most common options of functionality. Do not worry about customizability.
- Create Components for Alternate Functionality: Start creating components that implement other functionality. In a typical startup mode where you need to hit the market quickly, at this point you would have hit the market already, and the needs of your prospects could drive the needs of these alternative components.
- Customize the Flow: In the flow diagram, just replace the functional components with the alternative components as per the needs of your customer and sell it.
The cyclomatic complexity of the Lean ERP is orders of magnitude less, which also means that it can receive adequate testing with much lower effort.
In the Lean ERP approach, the customization of what is needed for a client happens at Xsemble level. This means that Xsemble itself doubles up as a PaaS (Platform-as-a-Solution) offering. However, the selection of needed functionality happens at a much more granular level than in the usual PaaS module selection.
The beauty of this approach is that no matter how many functionalities you build, the software that goes to any customer is always lean, and optimally suited to their needs. It will be less resource intensive, and quite fast in performance.
BTW, did you notice that the lean ERP does not need customization? So all the code that is needed for adding customizability into the ERP also goes out of the window, effectively making it even leaner.
Conclusion
The use of Xsemble to build ERP can give a significant competitive advantage to an ERP vendor. The Xsemble approach can make wonders to the flexibility and hence the application of the ERP. Further, a new possibility of a Lean ERP emerges out of this use.
Beyond ERP, the same considerations can apply to other complex software out there.