Printer Friendly

Using software to integrate the mixing shop.

Modern polymer mixing shops face most of the same production coordination problems common to other manufacturing facilities. However, mixing shops face their own unique production control issues. Generic production software packages designed for build-to-stock and/or custom manufacturing fail to address many areas of key importance to the polymer mixer. While there are a number of packages available on the market today specifically for polymer mixers, most of these packages concentrate on just one aspect of polymer production, such as lab test results or recipe management.

Today's highly competitive marketplace requires tighter control of costs than separate software packages can provide. To control costs most effectively, managers need up-to-the-minute information drawn from every aspect of the operation.

Analysis of the problem

As a result of product searches, we found there were very few software control products available specifically for the polymer industry. Those few products were very narrowly focused. They did not integrate the business, production and technical aspects of polymer production.

After interviewing a number of chemists, compounders and management level personnel, we defined our list of computer automation priorities. The scope of our automation project was calibrated to provide a high level of return on the user's investment, in terms of both initial product cost and costs of maintaining the system, namely, data entry costs, system maintenance costs and reliability related expenses.

Every system, whether manual or computerized, for the management of a polymer production facility must take into account the same basic factors. In our automation project, we chose six main areas of attention for managing and controlling the production of polymers: compound recipe management, compound costing, laboratory test data for development and quality assurance, inventory control, production tracking and traditional business office transactions, that is, sales, purchases and receiving. Our goal was to handle each area as fluidly as any existing software package, while bringing all six aspects under one management information umbrella.

Compound recipe management

Compound recipe management encompasses the storage and retrieval of a vast range of technical information. In its simplest form, a recipe must have a list of ingredients, their proportional parts, and weights to make a batch of a specific size and mixing instructions for the shop floor. Realistically, a much larger amount of batch specific data is needed to efficiently produce a given compound at a profit. Customer specifications, packing and shipping methods, raw material and overhead costs, load factors for internal mixers and specific gravity of component parts are among the extended production data needed.

Compound costing

While compound costing could be considered a component of recipe management, there are a sufficient number of issues to warrant a separate treatment of costing methods. Some highly complex methods have been put forward to calculate the exact cost of a specific pound of product. These complex methods try to amortize R&D, freight, front office and warehousing costs into one absolute production cost. To us, however, the most important issue in costing seemed simply to provide managers and purchasing agents with up-to-the-minute costs of raw materials on hand.

Laboratory test data

Two separate but important sets of laboratory test data are needed for producing compounds. One is what we call identifying data, namely, the overall specification data set for the compound. The other data set is quality assurance data. We recognized that the data storage requirements were very different for these two kinds of data.

Inventory control

Few custom mixers keep extensive finished goods inventory. Therefore, the mixers inventory control effort mostly involves keeping raw material levels as low as possible without interrupting production. As with compound recipes, we saw that a wide range of cost and specification data had to be tracked for raw material inventory items.

Production scheduling

Production scheduling is closely related to inventory control. The companies we interviewed expressed an interest in just-in-time inventory purchasing. Several companies had been implementing this strategy at varying levels of success for years. Accordingly, we viewed production scheduling as a balance between required delivery dates and availability of raw material in inventory

Business transactions

Obviously, customer order entry, purchase order generation, receipt of inventory and price quotations would also need to be included in the system. This business transaction data would need to drive important parameters in any integrated production control system.


Granted our system requirements in these six areas, implementation of our project consisted of choosing the best hardware and software platforms and the proper tools for writing the program we named Compound Manager. During the first stage of analysis we had defined the problems to be solved. Next we needed to design and code processes that would constitute the solution.

Choice of tools, platforms

Because of the well earned popularity of personal computers and local area networks, this hardware/software combination was chosen as the project development and implementation platform. Granted the growing popularity of local area networks in large and small shops, this standard provides a stable, cost-effective, multi-user environment that is quickly replacing minicomputers and mainframes.

The programming language chosen was Clarion, a database language and development environment that provides higher productivity and maintainability than most traditional programming languages. Clarion also supports Report Writer, an easy to use interactive program that end-users can use to produce customized reports.

In choosing the Clarion programming tools we had already made some conscious decisions as to the "look and feel" we wanted to achieve as the end result of our programming efforts. Some of the products we had seen during our product search seemed to have been ported directly from aging mini or mainframe programs. Very little in the way of on-line help, data validation lists or light bar menus were implemented. In short, the interfaces were about ten years behind the times.

At the other end of the spectrum of possibility are the latest graphical user interfaces and pointing devices such as the mouse, best typified by Microsoft Windows. Such interfaces need relatively high powered processors just to support the screens, and there is also a higher learning curve for the user. In the end, we chose a middle ground that relied on a non-graphical, menu driven interface, with context sensitive help wherever needed.

It was decided that in order to keep Compound Manager as simple as possible the user would interact with the program in only four visual contexts: one, use of light bar menus so that commands do not need to be memorized; two, the use of pop-up data item lists to pick the information needed; three, data entry forms, for adding, deleting and editing of information; four, reports, printed on request or automatically as part of a process such as order production.

All this analysis constituted the user view of Compound Manager. Even more importantly, we had to establish the system internals that would support this view. One of the keys fundamental to producing any effective information system is the right file structure. In designing the file structure for Compound Manager we followed the traditional relational structure advocated by Codd (refs. 1 and 2) at the third normalization level. Codd's third normal data form provided us with the right balance of direct data access and minimum data redundancy. Small formal variances were allowed for software performance considerations. Overall, Compound Manager's relational file structure allows for the efficient storage and speedy retrieval of all data. Not surprisingly, the resulting data structure conforms closely to the six part structure we originally designed for the project.

Compound recipe management

In solving the recipe management problem we divided the information that defined a given compound into five components and provided one entry screen for each component. The screens were designated as follows:

* Header screen - The header data entry screen holds identifying information for the compound. The compound code, customer, the final mixing method, batch size, short customer specifications and shipping/packing information are entered on this screen. Final mixing method is entered. Depending on the type of the mixer, internal or open mill, a load factor or batch weight is then requested. Compound Manager translates parts per hundred into batch weights to meet this total weight (load factor).

* Ingredient entry - In keeping with the overall data design, the ingredient screen is a list of the inventory items included in a compound. This screen is used by the compounder to create and modify compound definitions. Items may be inserted into the compound definition through the use of a pick list that displays all inventory items in a scrolling window.

The ingredients are held in the inventory file. For each compound, there are five important pieces of information in this file: the code number used to identify (relate) this ingredient as part of the compound; the specific gravity of the ingredient, used in sizing and costing the compound; the three costs of the ingredient, standard, rolling average and last-in. The compound/ingredient relationship allows for the automatic update of any compound based on changes in underlying ingredient data, usually changes in cost.

The ingredient screen also shows summary information calculated by the program. Total batch weight, specific gravity, cost and individual item weights are calculated according to the following equations:

Chamber size * spec. grav.* load factor = batch size (1)

Then a proportionality factor is derived:

Batch size / total parts = factor (2)

This factor is used to find each ingredient weight as follows:

Parts * factor = individual ingredient weight (3)

Equation 1 is used for internal mixers to find a batch size. Chamber size is recorded for various workstations throughout the plant using total internal capacity in kilos at a specific gravity of one. For open mill mixing, batch size is entered directly. The factor derived in equation 2 is a weighting factor used to determine individual ingredient weight in equation 3.

The ingredient screen also allows for the entry of multiple workstations. In this way, all subprocesses are accounted for, each following the above calculation. From this screen the compound cost sheet may be printed.

* Mixing instructions - The mixing instructions are entered on a free-form word processing screen and are printed on the mixing instruction report. This report is used on the plant floor by the production crew. This form provides only the information needed to produce and ship the compound. Cost data are not included.

* Quality assurance requirements - The quality assurance data are held in a table format with the rows depicting the tests to be done and the columns providing notes on required specs, procedures and frequency. The quality tests default to a list of standard tests but may be changed by the user for each compound.

* General notes - General notes are free form word processing data entry. These notes were originally designed to hold a history of the development of the compound, but can be used to log any additional information on the compound.

Compound costing

We considered a number of highly complex methods for calculating the cost of producing compound, including the cost-algorithm work done by Mastromatteo (ref. 3). While computerization makes the use of such methods relatively easy to implement, there are several practical drawbacks, primarily in the area of accurate data collection. For these reasons we determined to keep the costing method simple.

Two components were included, cost of raw materials and overhead factors. Overhead is included in the form of a standard charge per minute for a given workstation. Three costs of raw material are used in tracking inventory. Standard cost, defined by the user, last cost in and average weighted cost of inventory on hand are calculated by the program. The cost is displayed on the ingredient screen described above. The compound cost sheet also reports the total cost of the compound using all three of these material cost methods. Cost is calculated using the following equations:
 [Epsilon] (item weight * item cost) / batch weight = cost (4)
 (Cycle time * run charge) / batch weight = add on (5)

In equation 4, cost is the raw material cost per kilo. In equation 5, run charge is determined by the user as the cost per minute of running a specific workstation. Add on is the price per kilo you must add onto the compound cost to cover overhead and profits. All cost data on ingredients are updated as purchased products are received into inventory. Therefore, all compound costing operations can use the most current costs.

Laboratory test data

As the design of the lab test data module progressed, we found it desirable to provide a method for retrieving compounds based on test results. This approach would allow quick "what-if" access to existing compound definitions that would meet a customer's requirements.

The lab test section provides for the entry of data on base polymer, hardness, tensile strength, elongation and other properties. Once entered, the compounds may be retrieved by entering a base polymer type and hardness desired. Compound Manager then searches the database to find all compounds meeting these requirements.

The second type of lab data that must be stored is quality assurance data. These data are collected on production runs to support the documentation that virtually all extruders and molders insist on. At present, several customized test data modules have been produced to work with Compound Manager. An instrumented data acquisition module has been specified as the preferred solution. This module allows data from rheometers, tensometers, Mooney viscometer and mixer and mill data from the shop floor to be stored and compared directly to specification limits in the database. Tolerance gates may be defined so that the operator is immediately informed of compounds outside of specification.

Inventory control and production scheduling

This module of the program helps reduce inventory costs while insuring that sufficient material is on hand for uninterrupted production. The data that drives this material requirements planning section comes from sales orders, inventory, compounds and customers files. As orders are entered into the Compound Manager system they appear on a production list. Both the shop floor manager and the purchasing agent work from this list. A number of function keys allow the status of orders to be changed from a booked order, to the reservation of inventory, to production or partial production to finished. From these orders, total inventory needs are calculated and compared against inventory on-hand. Interactive data display and reports for use by the purchasing agent may be printed using date ranges or the manual hold feature. These reports and displays allow for short and long term purchasing decisions to be made.

Production scheduling decisions follow a similar paradigm. There is a production data filter to show only held and partial production runs. The production manager also enters the actual order of production for the shop floor from this screen. Reports on expected arrival date of ordered inventory round out this module.

Business transactions

The last requirement for the Compound Manager project was to provide price quoting and sufficient tracking of sales and purchase orders to support inventory control. The sales orders module provides for both quoting of compound prices and the booking of orders. Compound prices, held in the compound file, may be accessed and quoted from pre-set or up-to-date inventory calculations. Up to 11 price break levels may be recorded.

The purchase order module links the inventory file with the purchase order files to provide information on incoming orders. Purchase order entry closely mimics traditional paper forms to ensure a familiar user interface. Hard copy purchase orders are printed from this module.


[1.] E.F. Codd, "A relational model of data for large shared data banks," Communications of the ACM 13, No. 6, ACM (Association for Computing Machinery), New York, June 1970, pp. 377-387. [2.] E.F. Codd, "Further normalization of the data base relational model," in Courant Computer Science Symposia, vol. 6:"Data Base Systems," Prentice-Hall, Inc., 1972 [3.] R. Mastromatteo, "A |how-to' for cost accounting the preparation of elastomeric compounds," Elastomerics, October 1991, pp. 35-39.
COPYRIGHT 1993 Lippincott & Peto, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1993, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Norman, David A.
Publication:Rubber World
Date:Feb 1, 1993
Previous Article:Markets, news.
Next Article:Compounding studies using a new DOX.

Related Articles
Microcomputer-based manufacturing software: what it can do for you.
Scheduling & MRP: software buyers' guide.
Up-to-date shopping centers stay ahead of the curve.
Commack shopping center to have 2 new stores. (Retail New York).
Lifestyle design in multifamily development.
Curtain goes up on movie theater.
The Shops at Atlas Park getting Regal in Queens.
Voice Print, Syntora and Pipkins partner for solution.
Amae Software joins Solution Made Easy.

Terms of use | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters