Unlike ERPs, Preactor is built to adapt each companies data and buiness rules. This means that the database, calculations, objects and views are fully customized to each companys requirements. At the same time Preactor already contains plenty ready to use tables, views and objects so that companies do not start from scratch and allow for first results to be tested in weeks. Speed and automation tools contained in Preactor also serve this purpose because it makes results evident and easy to communicate
All interaction of the planner with the tools is through graphical interfaces: colored boxes, calendars, grids and alerts are all interactive and graphical which allows plnners to view and edit all variables from only one place and to have immediate alerts regarding any affected variables By double clicking on any object, full order details are displayed containg all relevant variables of each operation, whic can be manually edited or downloaded/uploaded through Excel files
Typically, ERPs handle demand order entry, bill of materials and inventory. Preactor usually handles routes, constraints, calendars, setup matrices, kpis and floor.MRP may be solved by ERP or Preactor depending on specific needs and the detail of pegging rules required
Routes are modelled in Preactor using attribute rules at planning level data. By setting up automatic routing configurations, we avoid having to manually create individual routes for each product and instead we make Preactor produce this information for us automatically.
Gantt chart allows the planner to move operations using a drag drop interface Operations also contain a priority field which can de updated manually or using an Excel file. Priority tells Preactor which orders go first Grid object allows the planner to move schedule table rows up and down to establish a higher or lower start time Algorithm selection and calibration produce different rules and solutions in the board Filters and highlighting tools allow the planner to unschedule or reschedule portions of the plan external Excel files and systems can also be fed into Preactor to enforce a specific sequence on each resource
Constraints and limits are classified within Preactor as either "hard" or "soft". Hard constraints are forbidden, and therefore the system will not allow such limits to be violated soft constraints are monitored and warned as undesired, but not forbidden.Examples of hard constraints or invalid movements include errors on the operations sequence or use of locked resource calendars.The system prevents the user from making these manouvers problems such as idle capacity, suboptimal use of resources or scheduling orders before material availability can be modelled as "hard" or "soft" constraints and may therefore be reported and fixed, but not necessarily forbidden.Preactor requires the user to establish acceptability limits on each relevant variable to monitor and enforce them accordingly the system will then classify and highlight the main problem on each order based on the lmiits and offer customized corrective actions to the planner.The planner can then choose to fix the issue at hand or not
Gantt Planning Board: Preactor main interface allows planner to interact manually with orders and resources to drag and drop the orders and run algorithms planning Grid: Grid view that allows users to read and reaccommodate schedule rows schedule reports: Preactor generates and stores schedules to communicate to the plant the start and end time of each process on each machine Plot Charts: Secondary constraint levels and usages driven by the schedule MPS Inventory Projection: Projected inventory levels for each component over time material Tree View: MRP view to display bottlenecks and shortages on all material levels for each order Action List Panel: Customized actions built to automate multiple tasks
Performance KPIs: Continuous updated KPI performance metrics to monitor plan vs real performance and accumulated productions to date & Shop Floor Execution Panel: Event interface to allow each machine to report their status, progress and relevant event such as brakdowns and material consumption.
Scheduling problems are complex large scale problems that involve the interaction of multiple variables and rules.Planning goals are usually in conflict with each other (eg. We want less inventory and faster delivery, we need higer product mix and less setups) and therefore planning algorithms are typically set up to prioritze some key objectives first and to accomodate the rest when possible. KPI metrics monitor the deisred level vs the planned level obtained by algorithm to meet the planners needs. To determine how good a specific solution is, the planner can manually intervene to edit the solved plan and test o to see if his manually calculated plan has a better (and valid) performance over the suggested solution. If the tools is properly configured, any manual attempts from the planer to improve the performance should result in a diminished performance in a few of the relevant metrics.
Standard external events include changes in demand, changes in material supply, shop floor events.Demand are usually external as a client changes an order priority , duedate or quantity. These changes are normally communicated from sales tables in the RP into Preactor,material supply changes include events such as change in delivery date or loss of quality in inventory. Preactor responds by reallocating material pegs, splitting productions or launching leveling material orders,floor events include machine breakdowns and waste of materials and slow progress. These eventas are usually launched from floor panels at each machine allocation manouvers- Planners can decide to change order priorities, switch an algortihm or lock resource availability.These manouvers affect the schedule plan and the subsequent resource allocations to it resource calendars Resource availability such as labor attendance or incorporating a new machine make Preactor rebalance resource loads
Changes are recorded into a log every time the planner hits the "SAVE" button. The system then compares the old and the new and generates a change log view using the changes report , the user can detect which parts of the schedule changed and why. Another view is the schedule comparison report which allow the user to compare schedules side by side. SO plans generated at one time can be compared with schedules saved at a different time and view the differences.
Automated or manual repairs are optional. Preactor includes an automation tool called PESP which alows the system to be configured to execute scripts automatically based on certain events or triggers. The before and after logs measure not only the schedule positions but also the resource or tolerance levels of any relevant metric to be monitored so before and after levels can be traced. Using the web platform, customized repairing actions can be created and applied to correct multiple orders with the same issue
Scenarios from different algorithms can also be saved and compared side by side or through performance metrics to evaluate them. Just as plan 1 solved by using algorithm X can be saved and compared to plan 2 which was solved by using algorithm Y, plan changes over time and real execution data is stored and considered as a plan or scenario to be compared with the first
Preactor contains mosty heuristic rules that can be customized and created from scratch to produce schedules. As planning algorithm developers we have also incorporated optimization techniques such as linear programming, nonlinear programming, combinatorial optimization, genetic algorithms, machine learning, critical path planning and constraint based scheduling a-mong others to solve specific planning and scheduling problems and theory of constraints applications. Among applied technologies, languages and math solvers such as LINGO (LINDO), PYTHON, R, AMPL (CPLEX) and Preactor simulation API can be applied.
Manip: A shell language to configure high level scripts and filters to configure the system rapidly,Preactor .NET API: Preactor object layer to program and manipulate rules and data flows using customized actions Math Solver: Used to model math optimization models when required SQL: Access to data layers is open which allows users to customize queries, reports and views and to introduce new tables and trigger commands,Web languages: Used to customize platform and apps on web platform environment,SCADA languages: Used to configure sensor level communications with the floor