Traditionally, manufacturing support software has been developed in various packages–each type identified with a three-letter acronym. MRP, MRP II, CRP, ERP, MES – – -. And each type of support software aims to manage the activities that produce something over a specified period of time. Simply stated, manufacturing is a time-oriented management activity.
So, the goal of any manufacturing support application is to balance needs versus available time. Everything from strategic planning to shop floor execution is managed according to a timephased plan. Even staffing is time-based because it deals with shifts, training times, vacations and other variables.
Most of the functions performed by these 3-lettered software applications include data collection and aggregation, report generation, cost calculation, forecasting, and computation of other key performance indicators (KPI’s). But all this functionality is still derived from timephased activities or timelines. As a result, it is not difficult to envision an architecture for manufacturing support centered on timeline production.
This architecture requires the centralized scheduling software to perform many timelining duties including capacity planning, what-if planning, materials planning, shop floor scheduling, rescheduling, backward scheduling (JIT), resource management, multi-site activity coordination, and so forth. Skeptics will argue that these diverse requirements are based on different time horizons, different levels of aggregation, and different resources. They reason that each type of system requires its own scheduler. And, they maintain that different timelining functions should reside in each type of support system.
This is a false rationale which may result from two circumstances, one historical and the other more technical.
Historically, if a developer set out to build a manufacturing execution system (MES), it would be obvious that he needed a shop floor scheduling application. If the goal was to support capacity planning with a CRP system, it would also be clear that an aggregated resource timeline builder was needed. If managing consumables was the objective (MRP), then an acquisition timeplanner was needed. The necessity for different schedulers has historically been the mother of their invention. Requirements have been formulated from narrow views of the many subfunctions within the sphere of total enterprise management. The ancestors of the various manufacturing support applications have often been systems evolved from one function, or from one vertical market, or from one type of production method (such as discrete or batch or continuous). The original requirements have originated in a niche ”stovepipe” where they have met only the needs of that niche.
The second reason for multiple schedulers within the manufacturing support software marketplace is quasi-technical. Simply stated, there has been no global or universal description of the scheduling problem. All requirements for scheduling have arisen from domain-peculiar views.
In the 1990’s, NASA was trying to find a scheduling software to support mission planning for the space shuttle. Finding none that spanned their requirements, they commissioned a series of studies to find a universal description for scheduling and a corresponding solution framework. If such an overarching framework could be found or developed, then any special-purpose scheduling could be achieved by simply setting the parameters within that framework.
Their success from this research was proven by using the same system first for the shuttle and then for the space station which had more complex requirements. Soon after, the technology was adopted by several Fortune 500 manufacturers that produced vastly different products using a myriad of manufacturing processes. This scheduling framework is still used today.
With universality basically achieved, the advantages of a schedule-centric architecture for manufacturing support software can be realized. These include the integration of all timelining logic across applications at any level and for any end objective. Descriptive models are coordinated, with the differences being only aggregations of the same data–not multiple collections or conversions from one format to another. The logic used for high-level planning,
mid-level planning and execution-level planning is the same. Timeline formats, the modeling of time and time intervals and the description of resources in all applications are the same. Due to these commonalities, organizational coordination among the different enterprise functions is simplified. All managers have similar views of how the organization is operating. User interfaces are familiar, so managers can easily adapt to each other’s functions. Sometimes even organization charts are simplified. The universal framework imposes a unified view of processes, resources, constraints and objectives of the entire manufacturing enterprise.
It is both possible and advantageous to utilize an architecture that coordinates an array of manufacturing support applications by using a universal timeline application to integrate the functionality among the various other systems. The technology for universal scheduling is there, and the data flows and interfaces easily identified and implemented. This type of software is the next generation architecture for manufacturing support.
If you are overwhelmed and mystified by the 3-letter alphabet soup of manufacturing support applications, start with a universal scheduler. You will be surprised by how much functionality you get for a fraction of the cost of the other apps..