PRESS INFORMATION - FOR IMMEDIATE RELEASE – 23.02.2004

Controlling the cost of deploying Enterprise Applications

To address their Product Lifecycle Management (PLM) requirements, organisations are now deploying second and third generation Enterprise Applications. In this article, Tony Jessop of Solass, the UK based enterprise applications consultancy specialising in Product Lifecycle Management (PLM) and Collaborative Product Commerce (CPC), discusses the key factors that drive deployment costs and examines how the tools and methodologies from the world of Knowledge Engineering can help address them. 

Enterprise Applications are, by their presence, mission critical pieces of software and an organisation can be placed at significant risk if these applications are compromised. This is brought into stark focus when organisations migrate to a new generation of application. Users are forced to leave behind the familiar face of the legacy system and become proficient in the new system and its processes almost immediately. Data must be migrated and transformed in such a way that it can reside in the new system whilst retaining the same meaning to the business and its users. 

Four key factors

Those experienced in such upheaval consistently cite four key factors that have been critical to their success. 

• Gaining agreement throughout the organisation as to how the new application will be used to support the business processes

• Ensuring that the correct processes and data are migrated to the new application

• Identifying the acceptance criteria that will demonstrate the new application can support the business processes

• Educating a large number of end-users on how the new system will support their day-to-day activities

Business processes

There is a widely-held expectation that an Enterprise Application will automate all the business processes within an organisation. However, business processes cover a broad range of activities. For example, within a PLM system these range from controlling access to data, through configuration management, to starting a new project. Although Enterprise Applications are good at supporting low level processes, such as access control, they are less likely to have in-built support for these higher level processes and most therefore provide configuration and coding capabilities to deploy such processes. In addition, two competitive applications may, on the surface, appear to offer the same functionality (such as access control), however, the method of using this functionality, and the capabilities that are supported, will be totally different.  

Processes fall into three categories: 

• System Processes – are the capabilities that are built into the application. The interpretation of these into the business processes is controlled by the users and the business.

• Business Processes – or company procedures, arise from the need to regulate and manage the organisation, including its contractual and product liabilities. Business processes are often documented to a level that is acceptable to the users, but rarely to a level where they can be readily automated within an application. Therefore, the users must bridge the gap between the business and system processes.

• Custom and Practice – are usually undocumented business processes that utilise the system processes or re-purpose functionality. An example of the latter case is when a comments field is used to capture structured information which is understood by only a subset of the users. Although this is dangerous, such customs and practices are common and often provide critical support to the business.

Users

Although the term “users” appears frequently in the context of implementing an Enterprise Application, it is important to distinguish between two types of users. Firstly, expert users are the data and process creators or owners and therefore understand how the application supports the business processes through the operation of its system level processes. Secondly, data consumers, who comprise the majority of the users,need access to data that has been entered by the expert users. Any change in the application therefore impacts a large percentage of the workforce immediately. 

Interfaces

Few Enterprise Applications stand alone in the organisation. Other systems or tools must create or change the data, or require access to the information that is contained within them. For example, expert users create information using sophisticated software tools such as a CAE package to design a product that consists of a number of components. These must be captured by and made available through the PLM system. An ERP system requires access to the design standard that is held within the PLM system. It is common that the tools which create the information will have a shorter life than the information itself, so it is imperative that access to the information is maintained and the interfaces to new and replacement tools can be developed. 

Managing expectations and costs

Enterprise Application vendors have created high expectations of the capabilities and benefits their solutions can deliver and frequently talk about supporting business thinking such as lean manufacturing, best practice and reuse of data. Such programs are often implemented globally across multiple functions and organisations, both internal and external (including customers and suppliers). 

To assist in the delivery of these programs, the current generation of Enterprise Applications contain an order of magnitude more functionality than the systems they are replacing. Legacy systems were often little more than sophisticated toolkits that enabled developers to create a bespoke application, geared directly to the needs of the organisation. The new generation of applications contain a vast amount of functionality that can be deployed with minimal development work. 

The existing legacy system(s) may also contain enormous volumes of data. For example, an existing PDM system for a defence contractor contained around 500,000 business objects (Parts, Documents, Change Requests, etc). This decomposed into some 76 million attributes. In order for such data to have meaning, it is important to understand how the data is used. However, it is difficult to identify the data which is used outside the application and the data which is only used within the application, and since data only has meaning within the context of the application it becomes meaningless and therefore worthless as soon as it is used outside this context. 

When all the above factors are taken into account, the cost of deploying a next generation of Enterprise Application can become very high. Much of this cost is also ‘hidden’. External consulting costs can be double the software cost, but by far the largest cost is the internal resources required, which can amount to twenty times the cost of the software over the course of a deployment. 

Deployment requirements

The new Enterprise Application will be replacing legacy system(s) that have evolved over many years, periodically gaining new functionality and supporting extra users. In contrast, the new application has to take on this mission critical role without the ability to ramp up functionality and users over time. It will be expected to support the business and the user community from day one. 

The legacy system may also contain a significant amount of critical data. This data is the Intellectual Property of the business and is needed to support the future business and the discharge of contractual and product liabilities. The migration of any data must take into account the system processes and how the data was originally created so that the same meaning is provided in the context of the new application. Since many of the system processes embedded in the legacy system may not be immediately obvious, all data from the legacy system should be placed in a long-term format, with immediate access, before the legacy system is retired.

To support many different business models, Enterprise Applications have evolved mutually exclusive functionality. Therefore, the company must decide which flavour of the functionality will be deployed. However, as the legacy system(s) have frequently evolved over ten or more years, much of the reasoning used in the embedded processes was probably never documented. The only people who really know how and why it works are the expert users. 

Acceptance Testing

Rigorous acceptance testing is required to demonstrate that the new Enterprise Application can fully support the business. Established applications are in use with a large number of customers, so it is unlikely the basic functionality will be inoperative. Problems are more likely to be found where the business processes are not correctly supported. In particular, a failure in the processes that support contractual and product liabilities or workflow and control can be severe. Data migrated from the legacy system must be tested to ensure it has the same meaning within the context of the new system as it did within the old. Interfaces must be tested to ensure that the data being sent and received has the same meaning in both applications. 

To generate meaningful tests, it is the process owners and expert users that must identify test cases and scenarios that exercise the subset of system processes to be deployed. 

User education

The users will have been working with the legacy system for many years and be familiar with (although they may hate) its idiosyncrasies. To get to the same level of confidence with the new system requires a significant step up the learning curve. Poor education results in users only taking advantage of 20% of the system, leaving them struggling with the remaining 80%.

Developing a Training Needs Analysis will ensure that the program of education meets the needs of all individuals, that training is fully integrated with the deployment plan and is built around how the system is used rather than how the application works. The processes used in each role must drive the training needs and unique modules should be produced  so that duplication of training is avoided for users with multiple roles. 

There are a large number of business processes in which users must be trained that are supported by a subset of the system processes. To generate meaningful training modules the process owners and expert users must identify the subset of system processes that will be used. 

Knowledge Engineering

Knowledge Engineering is a well-developed discipline that has been successfully used by a number of leading organisations. For example, the MOKA methodology (Methodology and tools Oriented to Knowledge-Based Engineering Applications) is in use with a number of Aerospace and Defence organisations. 

Knowledge can be obtained from many sources. Explicit knowledge is extracted from documents (e.g. Company Procedures), systems (e.g. data dictionaries) and the formal methods embedded in the applications. Implicit knowledge is the expertise and experience held in the minds of the experts. In fact, many experts are unaware of the wealth of tacit knowledge they posses. Implicit knowledge is captured through interviews, conducted as either one-on-one sessions or as workshops attended by a number of experts. Interviews are turned into transcripts that effectively become explicit knowledge.

In order to extract value from this acquired knowledge, it is entered into a knowledge repository. The types of knowledge objects include Concepts, Attributes, Relationships, Processes, Inputs, Outputs, Decision Points, Roles and Resources. The repository contains both the source documents and the knowledge objects. Knowledge repositories are usually based on an extensible ontology that supports the creation of additional subclasses of knowledge objects allowing subclasses to be added as and when they are identified during the modelling process.

Using Knowledge Engineering to support Enterprise Application deployment

A knowledge repository is an extremely effective way of supporting the deployment of a new Enterprise Application. First of all the relevant documents, processes and implicit knowledge must be captured into a repository.  

The data dictionary, comprising the types of business objects and the relationships between objects and the attributes, can be used as the basis for populating the knowledge repository. If there is a list of methods, these can be used to populate the repository with the base system processes. If the methods are available only as manuals, these will need to be analysed to identify the methods. A process is performed by a role, so roles must also be added. This is a large undertaking and so in practice only subsets of the most important system processes are modelled. If the methods are incomplete, experts such as application consultants will need to be interviewed, the results of which will then be added to the knowledge model. 

On completion, the knowledge model will contain the system processes that are available linked to the business objects and data created by each process, as well as to the roles involved in the processes. 

Each business process that is to be supported by the application is then modelled in the repository. The majority of this information may have to be supplied by the experts. The ability to link the source documents to the knowledge objects is of critical importance. In addition to the business processes, the business objects and attributes that are created by the processes and roles are modelled and linked to the processes. 

Generating deployment specifications

The knowledge repository can now be used to generate a specification for the deployment of the Enterprise Application by linking the business processes, roles, objects and attributes with the system processes, roles, objects and attributes. The links will be identified by the experts from within the business and the application and can be explicit or implicit. For example, by linking a business process with a system process an explicit link has been created, but there is also an implied link between the associated roles.

By modelling both the legacy and the new application in this way, both sets of system processes, objects and attributes can be held in the knowledge base. Therefore, the specification of the data migration can be created by linking the legacy processes, objects and attributes to the new processes, objects and attributes. 

Generating acceptance tests

Acceptance testing can be achieved by demonstrating that the system specification and the data migration specification have been satisfied. The detailed requirements of the two specifications are modelled in the repository, therefore the acceptance tests can be created by adding test cases and scenarios to the repository and linking them to the objects that are being tested. If additional knowledge is needed to support acceptance testing the correct expert can be easily identified and new knowledge added into the repository. 

Generating education programmes

The roles that users perform in the organisation are already part of the repository, so the users themselves can now be added and each user assigned to one or more roles. The business and system processes identify what users need to be trained in. Therefore, the training modules can be added to the repository with links to the processes and the roles. 

Publishing of knowledge

The information in the knowledge model can be made available to experts in the form of Trees, Maps, Matrices and Diagrams. Symbols and colours can be used to differentiate the different classes of knowledge objects. These can be used to verify that the inputs from the experts have been correctly interpreted as well as to inform and advise the experts of the knowledge supplied by other experts. In addition, the information can be automatically published as structured web pages. 

To make the knowledge available to other systems, the knowledge objects are stored in a formal XML model that can be easily re-purposed to comply with a wide variety of input standards.

Time, Risks and Costs

The use of a Knowledge Engineering approach in the implementation of an Enterprise Application addresses a number of common success factors, including: 

• Experts are a scarce resource. By making better use of their time, deployment time will be reduced.

• Information is needed to support decision making. By making all the necessary information accessible in a well structured manner, faster decisions can be made.

• Contractual and product liabilities are encapsulated into the business processes. By identifying and analysing these liabilities, the organisation can ensure that the application is able to support the business processes, thereby reducing the risks to the business.

• The legacy application contains the intellectual property of the company. Through rigorous analysis of the legacy application and the new application, the requirements and the specification are fully understood and can be implemented with confidence.

• The data and processes must be migrated correctly from the old to the new application. By eliminating errors in migration the amount of lost or corrupted data will be minimised.

• Demonstrating that the application is capable of supporting the business processes. Comprehensive acceptance testing identifies any deficiencies and builds confidence that the new application can support the business.

• Users embracing the new application. Effective and tailored end-user education enables all users to take full advantage of the new application.

• Introduction of changes during deployment. By incorporating changes efficiently and inexpensively into the deployment process, the costs can be reduced significantly and any impact on deployment time minimised.

• On-going changes and additions. Capturing the knowledge of the implementation provides a ‘future proof’ capability for the organisation. For example, the detailed understanding of the requirements for the interfaces to other tools and systems enables a more rapid deployment when these are changed or new ones introduced.