Integrated product- and process planning

[Admin]

Prof. Wilhelm Dangelmaier


Integrated product- and process planning


Initial situation

If you model any transformation-, data- , or production process as an input/output system, the output must be a specific product and the input must be production factors. This input could be classified: Consumption factors will consume (material) whereas input factors (human being, machine, information) at least do not leave the production system immediately. The transformation process has to achieve certain purposes. If the input factors belong to me, you can call that a process of production. If the input factors belong to someone else, you can call that a process of attendance (the business economist will groan loudly).

If you imagine this matter as a chain, it is clear that: I need a specific product with a specification “87”. If it is not available, you have to assemble it. Thus, we look for someone, who can do this transformation process for us. If we do this on our own, we need personnel, machines, programs and consumption products, which we have to search again. The game starts anew. If we make this process external, we look for a person providing a service according to these product- and process specifications.

One should point out, that this black box is variable at will with its restrictions. Every horizontal / object- and vertical / structure is conceivable. Also the problem does not become trivial, if you imagine that companies manufacture a lot of products and employ therefore an immense number of production factors.

- How can I arrange the process / the processes and production factors - to keep the equitable work content and give what I can not do into external hands.
- How can I survey and administrate bought-in parts (purchased programmes)
- Any product- / planning status (“This is SAP at status from 16.10.2008” / This is a Mercedes S-Class at status from 16.10.2008”, Airbus lists every single aeroplane!!!)
- How can I make a meaningful description of products / services that are not yet known.
- How can I assure that a component behaves in a suggested way.
- How can I invent the next (upstream) step in the value-added chain: A process requires 5 cosumption products, of those I can buy 4. I must manufacture the fifth. How can I specify a process, that I do not know and that I will not perform. Due to this matter, I do not know any of my inputs.

Well, we can not tell the future, but over all parties and global distributed locations we “discount at this point”, so to speak. (In all classifications- and standardization approaches, I see the problem, that: We freeze the status quo over the elected formal description.)

The intention emerges that primarily the discussed products are computer programs. Naturally, you can find analogies in every production process that manufactures any product. These analogies refer to the planning- and control programs that are needed for the fabrication too, which also could (must) be composed of systems like SAP.


Example

The project considers the manufacturing process of passenger cars, in case of a car class that could be chosen in view of the (large) quantity of possible configuration attributes.

Several parties give distiction to this manufactoring process.

- The customer, who increasingly always want an individualisation of his car and therefore he initiates a process of gradually individualisation, as well as of the components, too.
- The design / development, which define the arrangement and the exposition of variety of products such as “amount of constructible products”
- The design of processes, which stuctures the product design and which defines and dimensions adequate untis of organisation, as well as which defines the process rules generally.
- The process planning, which makes sure that a creation of manufacturing sequence occures under multi-criterial purposes.

These single processes cannot take place sequentially:

- The Customer demands are changing in quatitative and qualtiative ways.
- A vehicle class is continuously being enhanced
- The process planning in regard to the process structure must be specified long before the first produktion run is constructional terminated.
- A significant change of the equipment components and –units changes shift models, sequencing rules and the environment of the assembly line with its field service personnel.

Basically every basic process can initiate all the other processes.

As our common communication platform we use (among other things) a Priority graph, which on plane

- Vehicle class as a XOR-graph that contains every possibilities
- Single vehicle that contains every specification of the individual vehicle

Every party relies, referring to their own planning task, on the actual Priority graph (the class with all demands which are predicted and terminated). At the start-up of redefining the next product series (“new Smart 2012”) this is the Priority graph of the actual model. This Priority graph will be edited evolutionary, if the vehicles are “similar in design”. The Priority graph will be edited revolutionary, if the vehicle gets new drive concept, an axiomatic modification of the chassis or a variation of the production. (VW Beetle with an undercarriage -> VW Golf with an integral body)

With every revision of the Priority graph you should check, if:

- Components / Material still must be outsourced / must not be outsourced
- Production processes must be exported / re-imported
- Production processes in reference to processes / material / resources and / or human resources must be modified.

There is an increasing variety of products in this context, according to

- the visibility / effectivity / cognition by the customer
- the demonstration of variety of products
- the realisation in production- / procurement structures and –processes

Thus the management of variants should be rearranged and reconsidered, basically.

A decisive role plays the module. Based on the (trivial) basics of system technology, a module is either:

- a component / a vehicle sub-system, that has serveral variants
- an additional component

or

- a certain amount of attributes (Examples: incombustible vehicle, everything made of burl wood, everything amour-cased up to savety class 17, everything made of biological assembled plastic material, the whole electric 220 V), that has consequences orthogonal to the structure of the sub-systems (“aspect” / “part system”)

or

- a composition of sub- and part system

A sub-system can be compounded in an outsourced process (without difficulties). In contrast, a part system can be compounded / integrated in the final assembly / in the last machining step. According to this matter, mixtures are difficult to manage and for this reason it should be dispelled (This is my lightweight personal opinion). It is clear as daylight, that only certain part systems approach components. That is unproblematic, too. It is problematic, even if components can not be isolated in part systems / -aspects.

For this reason a variant is an enumeration of all possible setups, which should be mapped on the module structure. The modular structure makes sure – with a constant demanding care – that

- several production processes in face of an increasing variety of products must be controllable
- variety of products could be addressed for an enclosed subset
- several parts of production systems could be rationally synchronized
- current production programs, which execute assumptions for the class are “not too far away”.

The current Priority graph reflects “updated”, that

- we buy (specification of the article)
- we manufacture on our own (specification of the article, process and production factors)
- we have had manufactured not on our own (specification of the article, process and production factors)

Due to that, every party has its own goals of optimization, so the Priority graph will be updated individually. Thereby, you can recognise certain determinations, during every optimization / modification on its part you can recognise new determinations, which have to be noticed by the other parties (“We buy a new part” / “We have a new distributor” / “We outsource process xy” / “We have a new Synchronisation” / “Our new sequence-control-program has consequences on the high rack storage area”). Although – the examples should point out that - used tools of other parties (e.g. machines, or even computer programs like CAD / optimisation programs) can receive no consideration in each case. Everything should be mapped onto the Priority graph. Instantiating a specific computer program for the board-computer should certainly be included.

As a purpose could be classified:

- Effects on product quality
- Effects on process quality
- Effects on usage of resources / wastage
- Effects on release of harmful substances
- ...

The whole process of “constant vehicle- and production process development” is an online problem. You can understand it in this way that no commitment should be made if other developments will be impossible in future (or at least should be pointed out).

For every individual vehicle will be checked, for the vehicle class defined rules in regard to:

- Manufacturing location
- Components to be built in, to illustrate the configuration variants

against the background of the effective current situation. If applicable, we manufacture something different.


We come to the conclusion that:

1. We can extrapolate from a Priority graph: a given target function, a modularisation and a weighting function with type of costs (“All data with an flag for actualization”)
2. On these basics starts an optimisation process with a specific calendar date
3. Some variants of products, during this optimisation process, will be developed, which will be fixed perhaps on a certain date or maybe only partially fixed, and thus represent restrictions for several parties. On the other hand every party develops proposals which on their part constitute commitments.
4. Everything, which is developed by a party must be specified formally / mapped on the Priority graph. This must be declared as a universal-to-use interface which can be used by every party (e.g.: “We search a component with the specification xy” “We search for a service provider for this part of the graph”, “We map the Priority graph on an assembly structure with 5 parallel lines”)
5. In this, with an input (old Priority graph) and an output (new Priority graph), described planning process must the needed planning processes (“I search for a method, which change a Priority graph x in Priority graph y’ under a restriction as follows and under a target function as follows and that does not obstruct essential developments at the same time”) integrated as a black-box.
6. Every defined production process (steelplate x will be manufactured in process 4711 to a splashboard) according to required production factors and processes must be described in the Priority graph.
7. The Priority graph should be analysed on the basis of:
- number of variants
- frequency of occurence of variants
- complexity of variants
by different target criteria on possible modules (“Every production setup on a central assembly line”, ”All production processes go externally”, “Everything to Vietnam, as possible”).
8. In point 7 discussed questions could be structured in:
- Structure
- Control
of production and assembly robotics.


State of the technologies

This crossed my mind when I was thinking about the state of the technology:

 CIMOSA or AMICE
 CALS

There was the approach, that we (IBM) deliver generic services for CIM/CAM. These will be specified by a user so they will run on IBM-infrastructure.

The classification on production planning and controlling problems can be attached to our developed classification. Also, structure models can be realized. We did not classify the structuring and dimensioning (we will do this in an Excellence-Cluster).

Paderborn, 8th Dec. 2008