Project Overview:

Development Methodolgy 

Requirements:

KBA System Specification:

KBA Functional Design:

Project Summary:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

             Radio Frequency Data Collection System

Project Overview:

KBA Systems were asked to implementing a Shop Floor Data Collection System (SFDCS) using the Radio Frequency Communication protocol for a multinational customer. The primar y objective was to enter various transactions through a user friendly, barcode enabled user interface. The transactions were seamlessly integrated to the backend BPCS ERP System.

Development Methodolgy 

The critical development steps for the SFDCS were:  

1.      Statement of requirements:

The functional requirements from users and administrators in the client company were categorized and documented as a checklist against the solution and for system validation.

2.      System Specifications:

All required Hardware and Packaged Software were listed and described. In addition the system architecture was detailed, including transaction flow and database design.

3.      Functional Design:

A detailed description of each function to be implemented, with the screen layout, and processing

logic required, as well as details of all data required to be input, and the source and destination of

data required.

4.      Implementation Plan:

Providing a schedule for the setup, development, testing and implementation of the proposed new system.

 

Requirements:

Some of the customer requirements, from a Shop Floor, perspective, are listed below:

  • Collect labour or machine bookings against a specific operation on a specific shop order. Each operator will perform this by scanning a bar-code that contains the shop order number and the operation number from the SO, and scanning the employee's bar-coded identity badge.

  • The system validates that the shop order is a valid order, that the operation number can be booked on, and that the operator is not booked on rework, setup, or another SO.

  • Re-scanning the operator ID will automatically request the total quantity of pieces processed and shall allow for the proper designation of quantities accepted, scrapped and reworked.

  • Quantities are entered using a numerical keypad.

  • The system allows the scanning of reason codes for the disposition of either scrap and /or rework. These reason codes will be available on a laminated template adjacent to each data collection unit.

  • Collection of indirect labour.

  • Allow for Kaizen cell bookings.

  • Transaction history inquiry.

  • Real time validation.

  • Inquiry Screens.

  • System allows for optional quality information.

  • Interface with product labelling system.

  Warehouse requirements included:

  • Multiple Lots to be stored in the same location for the same item. This requirement was due to a limitation in the amount of space that could be allocated to kanban locations of sub-components. 

  • Interface with a Carousel.

  • BOM sheet to be printed for all Shop Orders

  • Issued parts to be accompanied with a label print that is to be attached to the SO. 

  • Validate that a maximum of two lots for a given sub-component can be issued to a SO.

  • Returned (un-used) sub-components will be transacted back into the system..

  • Exception Reports to be printed at completion of Issue Transaction for any exceptions to required pick.

  • All products entering the warehouse should be barcode labelled using an industry specific labelling standard. 

  • The system should be capable of printing labels (number of multiple labels to be specified by the receiving clerk) at the point of receiving. 

  • Identify default locations for the put away of received items in accordance with ERP item master settings.

  • Verification the put-away location has been used by the warehouse operator. 

  • Produce optimized pick list for the delivery of items to requisitioning manufacturing departments.

  • Provide visibility of released or uncommitted items available for picking, and conversely 'hide' items that have been requisitioned but not yet picked.

  • On-line confirmation that the correct picking location has been selected.

  • Allocation of semi-finished products or components (FIFO basis) to assembly orders, and the generation of pick-lists for these sub-components.

There were also many other requirements relating to the Finished Goods Warehouse and employee Time and Attendance.

KBA System Specification:

Prior to the System Specification stage, KBA and the client detail the business benefits, accruing from the system.

The specification outlines the different hardware, middleware and software requirements as well as how the various components of the system fit together. The hardware description includes the Data Collection Terminals (DCTs), Access Points (APs) and controller PCs/Networks. Other parts of the specification include how the system will interact with the back-end ERP system. This section also discussed the development of the hand held & vehicle mounted terminals.

The system overview shows the architecture of the overall system and how the components fit together.

KBA Functional Design:

The functional design document shows the process flow of the various transactions. A number of flowcharts show the detailed process flow. The RF screens are also developed and copied into the Functional Design Document. Each function is detailed along with  the transaction details.

The details of the data flowing between the system and the back-end ERP system are described as well as the database schema. Validation and Error Messages were also outlined.

The functional design document was critical in developing a successful system. This was a live document for the duration of the project and a number of changes were made as the project proceeded. The informaiton in the document was then provided to KBA's software development team where the code was written.

Project Summary:

There were many and varied requirements related to this project. The customer was very sure how they wished the system to work and the amount of data the captured. The key components in the project were:

The System Architecture - Hardware & Software

Transaction Handler - KBA developed Interface between ERP system and front-end collection system.

Process Flow for each transaction.

Transaction Validation.

Error Logging & Reporting

Data Integrity

Ensure System would work even if ERP system failed.

The project was delivered within a pre-agreed time-frame at cost welcomed by the customer.