In the earlier blogs I have identified five ‘domains of creation’ in a product design venture. Three of them are rather traditional:
- the product is created. All evidence of that, like design drawings, is accessible via the Bill of Material (the parts that the product consist of and all their properties, attributes and documentation)
- the requirements are created. All evidence of that is in the function-tree, describing what the purpose of system, the product, and the parts.
- the manufacturing process is created. All evidence of that is in the bill of process (or process description) in which tasks of assemby, of tests etc are mentioned, their duration, their sequence and the required parts and tooling are specified during its development
Now, in the companies that I used to work for, these three acts of creation were performed in separate departments. System engineering specifies the functional requirements, Development& Engineering does the product design and the department of Production Engineering creates the manufacturing process.
(The production guys will probably shy away from the term ‘creation’. Real Manufacturing Men do not create, they control! )
In the last company that I worked for, I witnessed the advent and rapid growth of a project management office (PMO). It devoted itself to helping project leaders in project management. I dare say that it helped in ‘creating projects’ (and they did not mind me wording it this way). Defining programs and projects is not an easy thing to do. Programs consist of project and projects consist of tasks to perform. At the start of a program there is chaotic process of defining projects, project leads, the tasks, the required competence (and thus the persons) that are to be selected to perform the tasks. Having started a program, it takes a well-organized change process to maintain and communicate the project organization’s description.
Seeing so many people working on project definition and change control, I thought it appropriate to grand ‘defining projects’ the status of ‘an act of creation’. Furthermore, any PLM system will need to report the progress in projects, thus it needs the project data in its data model.
The fifth domain of creation results in the company’s organogram. The importance of considering HR&O labour as an act of creation came about after admiring the way that our HR&O department succeeded in finding the competences that are required in a project. When exotic skills were required, they had to become creative to find people that had such skills and t0 persuade them to join our company. Thus, creating the the company’s organogram is an act of creation and it is the source of competences (organised in competence groups) that are required in design- and management tasks.
Also here, any PLM system will rely on a well maintained organogram to be able to report who is responsible for any act of design, thus it needs the organogram data in its data model.
It seems vital for any succesfull PLM system to contain the five tree-like structures that these five ‘elements of creation’ are arranged in:
- the function tree (from system to module level) with a function hierarchy
- the Bill of Material (from system to part level) with a part hierarchy
- the bill of processes (assembly/test/packing-processes) with a task sequence
- the project organisation (anything with tasks, their interdepencancy and their duration)
- the organigram showing an organisation of people with competences
These five data-trees contain five entities and their interrelations, plus their properties and attributes.
Next, each entity uses data from the other as attributes: who is the function owner in 1 stems from 5, the parts to be assembled in 3 stem from 2, the required competence for a part in 2 to be desinged stems from 4, etc.
Or are there data that are not properties or attributes of these five, and deserve their own domain?