Architecting Solutions to Discrete Manufacturing Industry

Architecting Solutions to Discrete Manufacturing Industry

Discrete Manufacturing

Discrete manufacturing varies from Process Manufacturing. In discrete manufacturing, the manufacturing floor works off orders to build something. Examples include toys, medical equipment, computers and cars. The resulting products are easily identifiable. In process manufacturing, the products are undifferentiated, for example oil, natural gas and salt.

Discrete manufacturing is often characterized by individual or separate unit production. Units can be produced in low volume with very high complexity or high volumes of low complexity. Low volume/high complexity production results in the need for an extremely flexible manufacturing system that can improve quality and time-to-market speed while cutting costs. High volume/low complexity production puts high premiums on inventory controls, lead times and reducing or limiting materials costs and waste.

Typical Problems in the Industry

Following are some of the typical problems or pain points faced by any discrete manufacturing industry in managing their product lifecycle:

1. Managing the product requirements
2. Translating product requirements to product design
3. Design Data Management & Data Version Control
4. Bridging the gap between the Design & Manufacturing
5. Controlling the Design – Test – Redesign iterations
6. Access Control to Data to various stakeholders of the development
7. Manual Process Work Flows
8. Manual Vendor Participation on Design & Development, Manufacturing
9. Part Classification – Standard, In-House, Outsourced
10. Engineering Change Implementation across the enterprise


Managing Requirements & translating them to Design

Most companies manage their requirements in a document based system. Usually on word or excel formats. If the company is little matured in IT, it may have a document management system where these requirement documents can be uploaded and version controlled. The disadvantage in this way of managing the requirement is the users may not be able to search those based on parameters or words unless there is a Text Search engine integrated with the Document Management System.

So, the solution for this problem is to develop a Requirement Management System which is more than just a Document Management System in which the Requirement Managers should be able to key-in the Requirements for a conceived product. When you architect this Solution, we need to detail out the process for:

1. How the requirements are captured?

2. What are the typical parameters captured in the requirements?

3. How are the requirements classified? (Marketing, Technical, Financial, etc)

4. How the requirements are getting mapped to the Product Features?

5. What are all the stakeholders who participate in the Requirement approval process?

6. How to determine whether the Requirement is measurable?

We also need to understand that the Requirement Management System is the feeder system for the entire product development pathway. So there should be enough control on this entry point of requirements and nowhere else on the Product Lifecycle the requirements should be altered. If so, it will make disastrous effects on the final outcome of the product. The requirement manager should be the sole owner of the requirements entered under any given product.

The requirements database must be easily searchable so that before entering a similar requirement the user can find out whether the same requirement is already satisfied by a feature of an existing product. This will avoid redundancy in developing the same features that already exists in the company. This will save time to market enormously.

Following are the databases that need to be built which will give tremendous benefits to the manufacturing organizations in a long term basis:

1. Requirements Database
2. Feature Database
3. Product Failure Database (Incidents / Issues)


Design Data Management

Design Data is the output of the Product Design. It could be a simple drawing sheet or a CAD file generated using an advanced CAD tool. The control over this data is important to save time over the product development. The design team starts the design by listening to the requirements given by the Marketing Team. So the design team must have read only access to the Requirements Management System. Design Data Management System is similar to a Document Management System. Here, the design data is checked in and checked out by the design engineers and will have parameterized place holder for the files for higher search-ability.

Before starting the design, the design engineer must be able to define a Feature which is going to satisfy a given requirement or requirements from the RMS (Requirements Management System). The defined feature will be developed in the CAD environment. The feature is made up of multiple engineer parts.

The parts are the finite entities that form the Feature and then the whole Product. Parts must be classified by the design team before they get created in the system. Part Classification is a very important activity which gives the following benefits:

1. Control over the redundant Part Creation

2. Easy Data Access

3. Gives precise data against the Part Development Cost under each type of Part

4. Classification between Standard / Non Standard Parts gives you how much standardized components your design is using.

So the DDMS (Design Data Management System) must have the following functionalities:

1. Creation of Products and Define Features
2. Linkage between the Requirements and Features
3. Creation of Parts with Auto Number
4. Integration with CAD Tools
5. Strong role based approval mechanism to approve the Features and Parts
6. Feature / Parts version and revision control
7. EBOM Management
8. Engineering Change Module


Process Flow Management

Following are the typical processes that run on a discrete manufacturing industry to manage various business entities and their release mechanism:

1. Requirements Approval Process
2. Feature Approval Process
3. New Part Introduction Process
4. Part Design Review and Approval Process
5. New Vendor Development Process
6. Vendor Part Approval Process
7. Buying Process (RFQ / Quotation Process)
8. Product Part Approval Process (PPAP)
9. Engineering Change Process

All the above mentioned processes are having sequential linkage to each other. For example, upon completing the Requirements Approval Process, the feature definition and approval process starts. The feature definition will in turn start the New Part Introduction Process if there are new Parts to be introduced to make that Feature. Once the Parts are developed, the decision to make them in-house or outsourcing will be made. This decision will initiate either the New Vendor Development Process or Vendor Part Development Process (for existing Vendors) if the Part is decided to be bought out. If the Part is decided to be made in-house the required Manufacturing Process Planning will take place.

 

Following table depicts the various stakeholders of the sub processes involved in the Product Development:

Early involvement of the stakeholders of the Product Development Process will save lot of time in the Product Development. To involve the stake holders in the early stages (design/concept stages) the following studies are done during the design:

1. Design for Assembly (DFA)

        - Involving the production engineers at the design stage to make sure the assembly you are designing is assemble-able or not

2. Design for Manufacturability (DFM)

        - Involving the manufacturing engineers at the design stage to make sure the Parts you are designing is manufacture-able or not

3. Design for Serviceability (DFA)

        - Involving the service engineers at the design stage to make sure the assembly/parts you are designing is service-able or not

4. Design for Six Sigma (DFSS)

        - Involving the six sigma specialists at the design stage to make sure the assembly/parts you are designing are meeting the sigma achievable standards

5. Failure Modes & Effects Analysis (FMEA) – Design / Process FMEA

        - Predict failure modes by which your part or process could fail and act on them to make the design effective.

Engineering Change & EBOM Effectivity

The engineering change on the parts and its effectivity on the various places of the plant on a given date is a challenging task. Most organizations still having the issue of making the correct version of the part on effective date on the shop floor without fail.

The cost effective engineering change is a very challenging task in the current economic trends. During the change review, the decisions to be made on the existing parts which are lying on the Shop Floor, Under Production, Under the Vendor Order, In the Stores or in the intermediate wear houses. The decisions could be ‘use them up’, ‘scrap them’, ‘rework them’, etc. These decisions are made at the time of the change review. But they are actually implemented later after making the design change.

There should be a stringent mechanism that makes sure the change is actually implemented as specified during the design change process on the Particular date, otherwise there could be older versions of the parts used in the product even though there is a new version released.

The new part revision must be reflected in all the EBOMs wherever it is used. Also, it should take effect in the user manuals, service catalogs and also in the stores of the dealers !!!