Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Requirements for both concepts

Comparison

 

Current state

Expanded technology tree concept with auto-generation

New order type with ad-hoc list of operations

New graph-based concept

Comment  Order with technology stay unchanged and will be just another order type, no big integration with product families and unindexed products) 
Handling a very large number of product variants

(minus)

Poor. Each variant has to be added to the products index and have a separate technology.

(plus)

Flexible products index and product system wide support. Technology generation.

(minus)

No system wide support. Some features may be added in the future but we now have to implement them for two types of orders.

(plus)

Flexible products index and product system wide support. Flexible technology definition.

 

Number of predefined technologies to enter

(minus)

Many, you have to enter all the combinations of the whole process

(plus)

Not required, you have to enter many operation definitions but you can generate all the combinations of technologies easily from them. Also technologies are smaller a we have batter support for splitting them.

(warning)

We use order with lists for process that cannot be defined elastically in the current technology. However this type of order has no relationships between operation so its less functiona;

(warning)

Much less, product families and attributes give us more flexible technologies. We also split technologies among production lines. But we still have to enter many technologies if products inside the families need different operations or time/cost norms.

 

Complex dependencies, splits and joins of the production process

(minus)

Only simplified to trees

(minus)

Only simplified to trees

(minus)

Simplified to trees or none.

(plus)

Supported

 

Technologies/Orders for many products

(minus)

Not supported

(minus)

Not supported

(warning)

Supported but only in order with list of oper.

(plus)Supported

Fully supported

 

Technologies/Orders to process components

(minus)

Not supported

(minus)

Not supported

(warning)

Supported but only in order with list of oper.

(plus)

Supported

 

Support for integration of intermediates in warehouses

(minus)

Limited. We can separate orders/technologies but we also separate the balance report.

(warning)

Supported but you have to keep this in mind while splitting technologies/orders. The master order will combine the balance(plus)

Can be added by adding some configuration to operations outputs options.

(plus)

Can be added by adding some configuration to operations outputs options.

(plus)

Configurable on the operation level.

 

Flexible production counting

(minus)

You can only report what was predefined in the technology.

(plus)

Available option to add operations, input/outputs and additional costs while the order is in progress.

(minus)

Not done to minimize refactor.

(plus)

Same as in minor refactor.

 

Individual production

(minus)

Not supported, requires new full prefedined technology every time.

(warning)

Technology can be constructed ad hoc per order. It can also be modified during the orders progress. However defining the tree structure instead just a list is often an unnecessary hassle.

(warning)

Supported but only in order with list of oper.

(plus)

Very elastic support.

 

Calculations complexity (cost of maintenance and development)

(plus)

Simple in current state

(plus)

The same complexity

(minus)

Most algorithms and data structures will have to be generalized to support two types of orders.

Some will have to be specialized.

(minus)

Very complex and not possible if all necessary dependancies are not i place.

 

Technology auto-generation

(minus)

Not implemented

(plus)

Possible from operations definition.

(minus)

Wont be implemented.

(warning)

Possible but very complex.

General cost of implementation 

(warning)

Medium

(warning)

Medium

(minus)

Big