Positioning Technology and Best
Practices For Today's Manufacturing
     
     
HomeCompanySolutionsServicesCustomersNews
Home
Customers Testimonials Success Stories White Papers
Case Study: PRMS Integration with Asprova

PRMS, a fully functional ERP package, consists of a scheduling tool, the scheduling workbench, which assists in scheduling orders that have been released and are of type 'Repetitive' or 'Process'. However, some drawbacks with the scheduling tool, these are:
  • Operations are scheduled serially
  • Lack of a user-friendly GUI enabling easy manipulation of scheduling times
  • Inability to schedule Discrete Orders
  • Schedules to over capacity and manual intervention is necessary to override this over capacity
  • Scheduling within Capacity limits when a work center capacity is used by multiple production lines
  • Inability to schedule around bottlenecks
  • Slow speed when number of lines to be scheduled is large
  • Lack of visibility of non-routing resources, for example, sub or set up resources
It is with a view of overcoming these shortcomings that an interface between PRMS and Asprova was built.

Methodology
The methodology used for the development of the interface is as follows:

Business Process
The first stage was the definition of the business process, down to the task level, covering the life cycle of a Production Order / Schedule. It encompassed all stages between suggested MPS orders or Firm Planned Orders through to Closed Production Orders.

In addition the business process covering the maintenance of master information, namely, Routings, Products, Bill of Materials, Calendar and Shifts were also clearly documented.

In our example we defined orders prior to status 'Released' as eligible for scheduling. Orders of status 'released' were treated as 'frozen' orders in Asprova. While Production Order completion was part of the scheduling operation, considering financial and inventory implications, the closure of production orders was out-of-scope.

Asprova Drill down
For the tasks allocated to Asprova drill down to the data elements required to perform the tasks. At this stage it is essential to take a 'to-be' view of scheduling. For example, item change over times may be shop floor reality but not reflected in PRMS. In Asprova it is essential to define such activities as part of the activity list.

CRUD Analysis
This stage involved identifying data elements in terms of the source, the place where modifications and deletions could be effected and hence which were read only fields. The first step in this stage was the identification of PRMS data elements, using an as-is perspective, which mapped to Asprova's requirements defined above. The remaining data elements were then classified under one of the following:
  • During Data Transfer - Generated during the data transfer process
  • Asprova - Created, updated and deleted in Asprova
  • PRMS New - Change in PRMS business processes to enable data to be maintained in PRMS
An example concerns updating order status, a task that can only be performed in PRMS. Therefore, the data transfer process should ensure that results data from Asprova can only be transferred for operations related to orders with PRMS status 'released'. In order to do so, Asprova's operation level tracking needs to be mapped to PRMS's Order Level statuses.

Operating Procedures
At this stage issues such as the timing of data transfer, whether the data transfer is incremental or complete and batch vs online transfer for each of the files to be transferred were defined. In addition a log file, which tracked the data transfer process and highlighted exceptions, was generated.

Architecture, Build and Test
Considering the AS/400 operating system's compatibility with Windows and Asprova's ability to work directly with Flat files, it was decided that the system architecture would support data transfer through Flat Files and data transport using the FTP protocol.