Several employees at (TC)2 were interviewed to determine the standard operating procedures, dataflow, and terminology used. Also examples of forms, reports, tickets, and inventory lists were obtained; these were analyzed to determine the exact sources and destinations of the information contained on them.
Many forms of information were studied, but the following five eventually became the focus of the prototype: Production Schedule, Cut Order, Marker History List, Piece Goods Inventory List, and Fabric Specific Trim List. The five are listed below along with a list of the data contained on each:
Production Schedule: The following information was looked up manually and written into spaces on a large production schedule grid for each cut order:
Cut Order: The Cut Order was maintained with Microsoft Excel on a PC. It used the same information that the Production Schedule used, and then added this extra information for each cut:
Marker History List: This list was found to be kept manually with a word processor on a PC in the CAD room. The list contained the following information for each marker:
Piece Goods Inventory List: This list was in an R:BASE data table on the PC network. The data table contained the following information for each roll of fabric:
Fabric Specific Trim List: This list described the trim that was to be used with each color of fabric. The color is referred to as 'fabric code'.
With the information gained studying (TC)2, rough drafts of IDEF0 models were constructed by hand. These rough models provided a valuable communication medium (eg, after each interview with a researcher or manager, a simple picture was drawn in the form of an IDEF0 model of what had just been talked about, and by looking at the picture the interviewee could tell if their thoughts had been conveyed correctly to the interviewer.)
The IDEF0 models were continually changing and growing. Often, a change to one page of an IDEF0 model needed to be echoed on several other pages; IDEF0 modeling software automatically echoes the changes throughout the entire model. Keeping the models up-to-date was much quicker and easier after the arrival of the IDEF0 software than it had been by hand.
In this project, the main benefit of IDEF0 software was that it improved the quality of the IDEF0 model by making the modeler more receptive to changing and improving it.
About seven weeks into the ten-week project, the IDEF0 model was frozen (ie, no more changes were allowed). A model can always be improved or broken down into more detail, but if work on the model was continued, no time would have been left to design the prototype CIM database.
The final IDEF0 model was an AS-IS representation of some of the functions at (TC)2 and the information flow between those functions. The model's main focus was on the manufacturing functions.
Next, IDEF1 models were created. They described the relationships and interdependencies among the Production Schedule, Cut Order, Marker History List, Piece Goods Inventory List, and Fabric Specific Trim List.
The main component of the IDEF modeling technique is the IDEF0 Function Model; Figure 8 shows a top-level view of the entire IDEF0 Model. The Node Index (Figure 9), describes the level of detail the IDEF0 Model goes to. The complete set of IDEF models and accompanying documentation are found in the Appendices. This section, 4.2.2, attempts to describe the purpose of each piece of the model, and provides the basic rules needed to read and understand it.
The Node Index (Appendix 7.1) is a 'road map' of the IDEF0 model. It shows the structure of the model in an indented format. Each node (ie, function) is represented in this indented listing. The indentation and numbering systems show the hierarchical structure of the IDEF0 model. For example (Figure 10) function A4 Manufacture Order is broken down into the more detailed functions A41 Plan for order, A42 Produce Order, and A43 Store in Warehouse.
The Function Definitions (Appendix 7.2) list gives the definitions of all the functions listed in the Node Index for the context of the IDEF0 model. Different people have varying definitions for the same function names, so the intended definitions must be specified to avoid uncertainty and ambiguity. In (TC)2's case, the definitions will also be useful to non-textile people who might be creating a CIM system.
Similarly, the Selected ICOM Definitions (Appendix 7.3) list provides definitions of any ICOM names that might be ambiguous. ICOMs are the Inputs, Controls, Outputs, and Mechanisms of the IDEF0 unit blocks (see Figure 11)
Next, in Appendix 7.4, are nine pages of the IDEF0 model. Each page represents a function and has a node number at the bottom left corner that corresponds to a number in the Node Index. Each page contains several numbered 'unit blocks' (Figure 11). If the number is outside of the unit block, then that block is described in greater detail on a page of its own.
The last Appendix (7.5) contains two IDEF1 models; one for the Production Schedule and one for the Cut Order. Here are some basic rules for reading the IDEF1 models:
Since this thesis project was on Computer Integrated Manufacturing, the most effort was concentrated on the A4 Manufacture Order function. Looking at the A4 Manufacture Order diagram, it was evident that the A41 Plan for Order function served as a major source of information, and could be a prime target for information flow automation. It was decided that the Production Schedule and Cut Order should be the major targets for information flow automation.
If all of the information described in Section 4.1 was integrated through a computer database system, only a few key pieces of information would have to be entered manually to produce a Projection Schedule or Cut Order. Most of the other values could then be found or calculated automatically.
The basic data tables to support the chosen areas of information automation included the Marker History List, Piece Goods Inventory, Fabric Specific Trim List, and Production Schedule. (The Production Schedule table contained information for both the Production Schedule and the Cut Orders since they used the same basic information.)
Each table contained several entities (ie, rows), and each entity had a number of attributes (ie, columns). A key attribute in each table was established to uniquely identify the entities in that table. The following lists show the attributes for each table (the key attribute is shown in bold type):
Marker History List:
Piece Goods Inventory:
Fabric Specific Trim List:
The R:BASE Relational Database Management System (RDBMS) provided an easy means of creating data entry forms to go along with these data tables. The entry forms prompt the user for the desired information and enforce rules (eg, type and length of attributes) of the tables. The entry forms also force the user to supply values in the key attribute fields.
An RDBMS allows relationships between tables to be established. The prototype CIM database uses these relationships at the time a Production Schedule or Cut Order report is requested to 'look up' and calculate the current values needed for the report.
The relationships are documented in the IDEF1 format in Appendix 7.5. The following are English descriptions of some of those rules:
For the Production Schedule:
Using the marker number in the Production Schedule Table, go to the Marker History List Table and find the entity there with a matching marker number and retrieve the style, yardage, and size information.
Using the roll numbers in the Production Schedule Table, go to the Piece Goods Inventory Table and find the entities there with a roll number that matches. Then retrieve the color, width, and length of the rolls.
For the Cut Order:
Using the Marker Number in the Production Schedule Table, go to the Marker History List Table and find the entity there with a matching marker number and retrieve style, yardage, size, bundle, and cut file information.
Using the number for roll 1 in the Production Schedule Table, go to the Piece Goods Inventory Table and find the color for that roll. Then using that color, go to the Fabric Specific Trim Table and find the entity there with a fabric code that matches the color and retrieve the color description, composition description, threads, button, zipper tape, and slider information.
The R:BASE RDBMS provided the database designer with an easy means of creating output reports by drawing lines, boxes, and text on the screen. The reports looked very similar to the ones that were already in use at (TC)2. The RDBMS then allowed the designer to define variables and assign to them the results of R:BASE queries to implement the needed relationships. The values of the variables could then be used in the output reports. See Addendum 8.2 to compare the (TC)2 production reports to the versions calculated directly from the CIM database using R:BASE.
All of the input forms and output reports of the CIM database can be accessed through user-friendly menus provided by R:BASE. The reports can be sent to the printer, or viewed on the screen.