After learning and discovering new design concepts during the making of the new WMS, I now set my mind to rewrite Libero Manufacturing (Mfg) likewise from scratch. One thing that needs to decouple right away from it is the Shipping Distribution Order (WMS has been successfully decoupled in the new version). (Shipping Distribution also sits embedded inside Mfg as was the case before in old WMS.) I also like to rewrite the complex Issue/Receipt module and leave CostCollection out for last.
So with that let's just begin. I like to define first a Forecast / Sales demand of a production product. But take one thing at a time. Remember in Libero it is coupled with the shopfloor dimension of scheduling resources, and workflow. I want to go with the minimalist and 'separation of concern' and 'lazy loading of function' approach that i find useful in WMS.
At this juncture i see Mfg as twin-part. First is the simple 'Adaxa' like production of using a BOM plan and seeing it through the WMS supply chain with a KanbanBoard visibility of action. Those actions can be time-tracked to later estimate its theory of constraints. Second (next phase), a simpler interface with the intricate shopfloor.
The forecast production will incorporate the BOM Drop but with a twist. It will allow lazy cost loading
and low-level progressive bom drops. This is a step further from Adaxa single bom production.
a) Lazy cost loading, is when a product is not determined some late raw materials such as a car not knowing what accessories to fix or a cloth not knowing what design to emboss. The key intent here is to get total direct materials and their roll-up costs.
b) Low-levelling is to properly (as Libero attempted) to get MRP (Materials Requirements Planning) and CRP (Capacity Requirements Planning) across the Shopfloor. This is where schedule estimates are derived. And also indirect production costs.
This will mean a change in the BOM Drop. It may have to work with BOM instances. The instance can be in an extended ProductionLine detail, with BaseQty, QtyVariance, and FinalQty to keep track.
Since the lines can grow a long tail with the raw material ingredients break down, another sibling tab will revert back to the parent singularity at the ForecastLine/OrderLine tab. Thus the ProductionLine remains aribitrary and fulfills at the materials building level.
Now let me introduce another wonderful concept that seems simple but an elegant break-thru in loose-coupling lazy-loading land. I call it the Panel approach. It is to put a custom master model over the core models but not needing to go via the core models. For example a PM_JobProduction with PM_JobProductionLine is created as new models and it forms a loose relationship with core models such as M_Forecast/C_Order and PP_Bom. It does not necessarily need the core models to operate first, saving input time, and hassle of sub tabing too much. The extra work will be in the process or event validator code to rope in those core references.
Such a construct gives few distinct qualities:
1. There is better separation because PM_JobProduction demonstrates better leadership, not been under another core model such as M_Forecast/C_Order to mysteriously trigger stuff. It is also not generated from such core data but in itself is the starting source of data and can immediately summon a M_Forecast instance.
2. It has its own descendant PP_JobProductionLine and its sibling M_ForecastLine/C_OrderLine after associating with a runtime core model.
3. The governing master model can be Kanban Board ready signifying DocStatus conditions that signify its time scheduling in a pseudo manner.
4. The panel model can be modified readily by users for more relevance without worrying about disturbing underlying core models.
5. The custom panel is thus the input point, more usable, easily tuned, and marshall everything else thru its encapsulating plugin.
6. Thus there is even more freedom to maneuver easily around rather than touching any core.
Item (3) is crucial and forms my latest enlightenment just some hours ago. DocStatus of a workflow structured document doesn't need further fresh design as it already is. It nicely sits in a Kanban Board and can be dragged from stage to stage using those arbitrary status conditions.
From there is where we juxtaposed another future model that will then fully govern the shopfloor scheduling. It loops back to the DocStatus without disturbing such arbitration.
Though this lightblub blows my mind, it is not easy to explain to another mind. So i will go ahead and use the Ninja to set it up and hopefully, at least for me too, prove that this concept works and can solve the Libero mess.