Organisation

The investigation focuses on a large and diverse organisation; its separate divisions and the disparity in division size can make balanced cross sector decision making complex. Many of the company systems are governed and configured by the Engineering and Technology (E&T) organisation which has to make the judgement as to whether all sectors or divisions should be given equal ranking when balloting changes or proposals. The organisation has grown significantly over the last 20 years, the level of growth across its different business sectors could not be achieved through organic growth alone so it has been accelerated by strategic acquisitions. The organisation has a number of Joint Ventures around the world as well as strategic embedded suppliers of both products and services Due to this

conglomeration over time of many organisations, there has been an accumulation of many systems carrying out the same function and in some instances different configurations of the same system all of which will be on very different architectures.

Internally the organisation operates as a matrix organisation and uses functional ‘Centres of Competence’ within the global ‘Engineering Improvement Centre’ (EIC) to drive

standardisation across the organisation. As a separate entity from the business units, it has a limited ability to enforce compliance to standards and methods and more fundamentally as a function its ability to understand the wider business requirements is entirely dependent on the engagement from the business units. The EIC function largely operates from one site in Derby and its level of influence can be seen to dissipate across organisation, functional and geographical barriers as shown in Figure 3-3.

Figure 3-3 – Representation of the global and cross functional influence of the Engineering Improvement Centre (darker tone = stronger influence)

The organisation is world renowned for engineering excellence, and because of its history, reputation and core business it has a strong design engineering focus; ‘Engineering’ in the organisation is typically an abbreviation for ‘Design Engineering’. This can manifest as an imbalance in some areas of understanding of the wider business requirements: where cross functional corporate systems such as PLM are being deployed, the balance between the traditional design and product configuration engineering activities requirements capture and the Manufacturing and logistical etc, may not be optimal.

The size and complexity of the enterprise, which is exacerbated by the acquired diversity along with the strong lead provided by the EIC organisation has resulted in a general strategy for information system interoperability of bringing all data and systems within the bounds of one unitary system; in this case PLM. This has also developed an approach to the deployment of PLM methods that does not always distinguish between the PLM

methodology and the PLM core system (Teamcentre) i.e. as general assumption that if ‘it’ is not in Teamcentre ‘it’ is not PLM compliant.

3.3.5 Systems and technology

As previously discussed the organisation has a large diversity of acquired and developed systems. Many of its legacy systems are highly customised to meet specific requirements;

this includes the legacy CAD system CADDS5 which was heavily customised by

Computervision (the original vendor) to meet the organisation’s complex design and

parametric modelling techniques. This customisation resulted in an inability to accept further upgrades to both hardware and software which in turn led to increasing difficulty to maintain the system and its interfaces with other systems that were changing such as the analysis systems that used the CAD data it produced.

The organisation uses a very wide range of versions of hardware and operating system; it maintains a basic capability to access data created on legacy systems such as VAXs systems and mainframes due to an inability to migrate these systems and data onto new platforms. Figure 3-4 shows the strategy to move from this position of significant complexity to one where the business uses a small number of unitary systems. The business is

expending significant time and resource investigating how to move all its data into either a single, or one of a small number of databases.

The organisation’s experiences maintaining a number of smaller systems without any clear interface standards, has shaped it approach to systems development. It is focusing on simplifying the management of data in one context at a time; the PLM system is being developed to manage product data, the ERP system manages enterprise planning etc. What has not yet been resolved is how to deal with the use of a unitary system across many domains. The functions within these domains will have different perspectives on the data and information within the systems due to the lack of a common and standard lexicon of terms or ontology. Without the ability to definitively describe the data and information within a system in an unambiguous way the reliability of the decisions taken upon the information will be dependent on whether the person making the decision happens to share the system designer’s view of the data e.g. if a manufacturing engineering process owner sees a ‘yield’

figure in the ERP system of 70% against their process, he or she will assume that 70% of the parts processed will be conforming whereas a MRP controller will assume the cumulative yield of the process route to that point will result in a 70% yield. This relatively simple

difference could result in excess WIP, which if replicated across the company would cost approximately £250M.

As well as pursuing a strategy of large centralised systems the organisation has also implemented strict controls on the development of systems dictating that systems can be configured in line with agreed internal standards that are supported by the OEM but must not be customised. Rather than customising the products after purchase, it is partnering with the systems suppliers i.e. Siemens, Hewlett Packard and SAP to influence the development of future product releases.

Figure 3-4 – The systems convergence strategy (provided by the organisation’s Systems Executive)

3.3.6 Data, information and knowledge maintenance

The organisation has a strategy for the convergence of its systems (Figure 3-4), which is recognised as a long term endeavour. The current situation is that data and information is duplicated in many systems, in many cases using separate and un-correlated domain ontologys. This makes it difficult to identify or resolve this duplication and also makes it almost impossible to ensure the data does not diverge as it is updated. Significant levels of resource are being focused on this issue, and it recognises knowledge and information management as a key business function, and as such there are specialised functions within the organisation leading the development of its information management capabilities.

A common anecdotal example of data duplication and maintenance issues within the organisation is the maintenance of personnel listings: this organisation data is stored in the corporate web based HR Online system, as well as the legacy store in the People and Knowledge module of the ERP system SAP. This data is also in the corporate Excel based load and capacity tools, training planning tools and skills assessment tools as well as a

number of other systems. Some, but by no means all of these systems use a manual

download of the data from either HR Online or SAP. However many rely on repeated manual entry. Virtually all these systems require manually auctioned or at least manually triggered updates. There are also numerous systems which use subsets of this data filtered by meta data such skill type, resource area or function. Unfortunately these meta tags are not

standardised, globally available or populated in a standard way by the contributing functions across domains. The result is that this data is manually entered into many systems and maintained in a divergent manner leading to inconsistent data. A number of managers were approached and none felt that a request for this organisation data from the HR or Business functions would result in a consistent or accurate result. All stated that they would recreate the data from local knowledge rather than correct data stores being used. None of these managers would consider entering a request for a complex subset of this data as they did not believe the data was suitably structured or the meta-data available. If this anecdotal case is representative of other systems and processes there will be a massive benefit from central repositories that are suitably structured and accessible to allow different functional

perspectives to interoperate with them.

In the areas of the business that do have a single authoritative data source e.g. the PDM system, change is managed by rigorous change control boards ultimately chaired by one or two individuals. This level of constraint is required due to the criticality of these systems but this does make them inflexible. It could seem that all of the change mechanisms for these systems are there to prevent uncontrolled change, however, there do not seem to be any mechanisms that promote or aid change ultimately resulting in lower organisational flexibility.

The organisation’s legacy systems have generally been used as data stores, where data is manually managed, with varying levels of access and change control. These stores have little interoperability or cross referencing capability and what integration there is, is hard coded so that any changes to the data store structure will corrupt the communication mechanisms and any related reporting solutions.

The organisation has recently initiated research into knowledge maintenance which should help inform its future systems strategies. It is also developing and deploying web based centralised reporting solutions using the COGNOS system (see Section 3.3.8) which should provide far greater flexibility by providing an over-arching reporting mechanism.