The term “Historical Data” will fall under the purview of several areas of APS. Regardless of the area referencing Historical Data, all Historical data can be leveraged primarily for to track performance and conformity to the schedule. The areas where Historical Data come into play are listed below:
- Scenario Histories
- Gantt History
- Publish History
- Recordings
Using Historical Data
Now that we know where Historical Data is kept, what is it used for? Historical Data can be used for performance tracking of the Resources within a Scenario and to track Conformance-To-Schedule.
By accessing the Activity Status of an Operation, a user can record the reported hours (setup, run, post-processing) and recorded quantities (good and scrap). APS can then compare the actuals with the expected hours and quantities to provide a performance report. The scope of the performance report is limited to the aggregated expected hours and quantities that are set to run on that Resource.
A performance of 100% means that the reported quantities and hours match the expected quantities and hours completely.
Scenario Histories
Scenario Histories are stored to the disk from APS in files about 500 bytes large. Each Scenario History tracks the changes made to the schedule in that particular historical snapshot. It will include the following data:
- Description: This will identify the nature of the change, for example, “Changed NeedDateTime from ’1/4/2012 12:00:00AM’ to ’2/29/2012 5:00:00am’
- HistoryType: This is the action that has caused the change, for example, “JobChanged.”
- Key: This is a unique identifier for the object affected by the action
- ObjectType: This is the type of the object that has been affected by the action (ie, “Job”).
- TimeStamp: This is the date and time the change occured.
- User: The user that made the change.
Maximum Number of Histories Stored
This is a part of the System Options dialog that determines how many histories are preserved. Having a large maximum allows for more accurate performance reporting and could help to stabilize standard lead-times and improve future projections, but will also take more disk space as each history stored is stored in a file about 500bytes in size. These histories will also have an impact on the load times and overall performance of APS altogether.
Gantt Histories
The Gantt can be set to display a history of previous Jobs and Operations that have been completed. This is part of the System Options dialog that allows Actuals to be tracked for a predetermined or user-defined length of time. Like the Scenario Histories, this allows for performance and conformance to schedule reporting to be done. Unlike the Scenario Histories, this is done in a visual way instead of table format.
Gantt Histories can also be beneficial in making sure that the first Job on the schedule has the correct setup time set. Although APS will determine the correct setup time even if the Gantt History has been disabled, it can be a useful tool for the scheduler to see what Jobs have already been completed, especially if those Jobs are erased from the ERP upon completion.
Publish Histories
Whenever the Scenario is published, the internal APS data set is copied, typically into SQL Server. APS can be set to store multiple Published Scenarios on the SQL Server database. As with the Scenario History, any number of Published Histories can be recorded, providing larger sample sizes when determining the performance of Resources or how closely the Resources are conforming to the expected schedule.
Keeping Publish Histories has also been of great benefit for manufacturers who are unsure of their standard lead times, as is the case for many manufacturers who have grown rapidly in a short period of time. By keeping a large enough sample size of Published Histories, more accurate time standards can be derived by averaging the Actuals.
Recordings
Recordings are different from the aforementioned Histories in that they do are not typically used for tracking Performance or Conformance to Schedule. Recordings are APS-generated copies of the APS data set. Within each Recording is a number of stored transmissions. Recorded transmissions can be any change or movement within APS, from accessing a dialog window to triggering the Refresh of the planning data. Recordings are therefore helpful as backup scenarios when APS crashes. Each logged transmission is separate from the others to help pinpoint and locate potential bugs or errors in APS, while the Recording file can be used to restore the data set should the scenario become corrupt or lost.