Positioning Technology and Best Practices For Today's Manufacturing |
||
Home | ||
Home
|
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:
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:
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. |
|
Contact us at: 1-800-263-0193 | Copyright © 2004 Hunter Business Group Inc. All Rights Reserved. |