Use IBM FileNet P8 to drive new product development

A sample implementation shows how consumer products goods companies can use IBM FileNet P8 to accelerate the introduction of new products

New Product Development (NPDI) is a strategic part of the growth strategy for consumer product goods companies. It is a very content centric and deadline driven process. This article describes how IBM® FileNet® P8 can be used to implement a sub-process of NPDI called artwork change management. The article describes how the following parts of the sample implementation were implemented: creating a process flow, using an eForm to launch the process flow, and building a Web interface using Enterprise Content Management (ECM) Widgets. In addition, it describes two other tasks required for this solution: providing an overview of outstanding requests, and implementing an ad-hoc review process. The objective is to provide you with some insights on how to pull together elements of the ECM portfolio to implement your own solutions.


Jeff Douglas (, Industry Solutions, Enterprise Content Management, IBM

Jeff Douglas photoJeff Douglas is a member of the industry solutions team within IBM's Enterprise Content Management organization. Jeff's focus is on integrating the ECM portfolio into strategic solutions within various industries. Jeff has been with IBM for five years and has worked within the information management space for 17 years.

21 January 2010

Also available in Russian Portuguese


For consumer product companies, the key to growth is the ability to introduce new products into the marketplace. The ability to efficiently move from evaluating a product idea to manufacturing and distributing an actual product is critical to success. The implementation of this process requires the integration of a significant amount of diverse information and the automation of a complex, dynamic, collaborative process.

Through its combination of content management and process management capabilities, IBM FileNet P8 can serve as the foundation for an efficient implementation of the new product development (NPDI) process. FileNet P8 can also enable other important functionality, such as compliance and analytic insight into the operations of the business process.

This article describes how to implement one part of the NPDI process: artwork change management. The goal is to provide you with insight on how you can leverage different parts of IBM FileNet P8 to produce similar solutions. The article focuses specifically on creating a process flow, using an eForm to launch the process flow, and building a Web interface using ECM Widgets. It also describes two additional tasks that are required for this solution: providing an overview of outstanding requests, and implementing an ad-hoc review process. The Resources section at the end of the article provides links to resources with more details on the overall NPDI process and the value that ECM provides.

Artwork change management

Within the NPDI process, artwork change management is where artwork is changed or created in support of a new product offering. Figure 1 provides an overview of the steps, participants, and content that make up the process.

Figure 1. Overview of artwork change management
The artwork change management process is initiated by a marketing lead who collaborates with different groups to complete the change request.

The process is typically owned by a marketing lead who collaborates with a number of other groups, including engineering, research, artwork, legal, and manufacturing. A significant amount of content is generated, including design documents, nutritional labels, artwork, legal documents, and review feedback.

The next sections of this article describe how the sample implementation was developed using the "out of the box" capabilities of IBM FileNet P8. The article assumes you are familiar with the components of the FileNet P8 product.

Products used in developing the sample implementation

This entire sample was developed using only existing software components from the IBM FileNet P8 suite:

  • The content repository is P8 Content Engine 4.5.1.
  • The business process uses P8 Business Process Manager 4.5.1.
  • The electronic form was built using FileNet P8 eForms
  • The customized user interface pages were built using ECM Widgets 4.5.1.
  • Search capabilities were implemented using Workplace XT 1.1.4.

Creating the artwork change management infrastructure

Figure 2 shows the process flow for artwork change management, the owners of particular steps, and the critical documents that are produced.

Figure 2. The artwork change management process flow
The artwork change management flow is initiated by marketing. Key documents are delivered by engineering, research, artwork, and legal.

A typical artwork change management scenario could be that the marketing lead initiates a change request in support of the development of a new line of ice cream. The artwork must then be created to fit on the newly designed packaging and meet any marketing, legal, and corporate requirements.

The request initially goes to both the engineering and research groups, in parallel. Each group is responsible for producing or approving a document that is fed to the artwork lead so he can produce the required artwork. Once the artwork is complete, it moves through a review and approval process that can involve multiple groups. Finally, the artwork and supporting content is provided back into the operational product life cycle management system.

Defining document classes

For this sample implementation, we used Content Engine Enterprise Manager to define four document classes. The first three are critical for artwork change management:

  • The Nutritional Label (NLI) is generated by the research lead.
  • The Die Line describes the design of the product packaging and is produced by engineering.
  • The Artwork is created by the artwork department.

Each of the above classes leverages system properties such as owner and date created. Additional properties such as case ID, material ID and product ID were also added. These properties enable flexible searching for documents, which is an important requirement of this solution. Case ID is also important because it enables the grouping of all documents associated with a particular change request. This provides consistent and complete context as the process moves between participants and in and out of various systems.

Each document belonging to one of these classes has a property that indicates the state of the document (draft, review, or approved) as well as the assignee (the person currently working on the document). Finally, each of these document classes leverages the annotations property to enable commenting by process participants. Enabling collaboration through commenting is another important requirement of artwork change management.

The fourth document class is a more basic document class to support documents such as project plans and review feedback documents. This class has three properties: owner, document title, and case ID.

Implementing the business process

Figure 3 shows the artwork change management business process flow for the sample implementation. It was created using the Process Designer tool.

Figure 3 The artwork change management process
The process is initiated by marketing and flows to engineering and research. After they complete their work, the artwork lead completes the change and the marketing lead drives the approvals for the change.

This is a straightforward process. Following are some notes about the design:

  • The outgoing routes for the Case Setup step are marked as "all true conditions" to enforce the requirement that the engineering lead and research lead work in parallel.
  • The artwork lead has a dependency on the completion of the work by both the engineering and research leads. To enforce this, the Develop Artwork step is identified as a collector step in the routing tab. The Corporate and Legal step is also identified as a collector to ensure all documents are final before final approvals occur.
  • It is possible for nutritional labels and design documents to change throughout the process. As a result, specific steps were added to the process flow to confirm that the final versions are in place.
  • For this sample implementation, user interface Web pages were built using ECM Widgets to enable participants to complete steps in the process flow. The creation of these pages is described in more detail later in this article. Once these pages are created, they are linked to the appropriate step by defining a step processor for that step and assigning the URL of the UI page to it.

There are multiple ways to assign particular process steps to a role or individual. Roles or individuals can be assigned to workflow groups. Personal inboxes can be created as well. For this sample implementation, worker queues are created for each step in the process and assigned to particular roles. Those worker queues then feed the inboxes for the role to which they are assigned.

There are a number of data fields defined for the process. Attachments arrays are defined to hold artwork documents, and attachment fields are defined to hold the nutritional label and die line. While individual attachments are used for these, they could have also been included in a single attachment array. Putting them in their own attachment field makes it easier to highlight them in the user interface.

As part of the definition of this process, designers can build in e-mail notifications, milestones, and escalation points to ensure that the process progresses in a timely manner. There could also be various points in the process where data is retrieved from an operational system, such as SAP or IBM InfoSphere Master Data Management. For example, it is quite likely that information would be retrieved from an operational system to initialize the nutritional label for the research and development lead. In addition, at the end of the process, data would be fed back into the operational system prior to completing the process. Since this sample is built as a standalone implementation, this integration with operational systems is not implemented. However, it would be straightforward to do using a component step and some custom code modules.

Initiating the artwork change request with an eForm

The marketing lead initiates the change request by completing an electronic form. This form is shown in Figure 4 below.

Figure 4. Launching the process with an electronic form
To launch the change request, the marketing lead completes an electronic form. Some of the information is provided by the marketing lead, while other information is provided by operational systems.

The marketing lead provides the UPC symbol for the product. The UPC symbol is then used to populate most of the other fields in the form, including material number, packaging type, brand code, and project number. In addition, defaults are provided for the participants in the process. These can be changed by the marketing lead by selecting from a list of participants.

The default values in the field would most likely be retrieved from a database or operational system, using the UPC symbol as the key value. Within the eForm, simple point and click configuration allows connectors (such as a JDBC connection or a Web services call) to retrieve those values.

A form policy is used to associate the eForm with the artwork change process. You create form policies using Workplace XT. When creating the form policy, you choose the form template and the process flow from the repository. Fields from the eForm are then mapped to data fields in the process flow. The easiest way to do this is to assign the eForm field the same name as the corresponding data field (the field names are case sensitive). Doing this allows the form policy wizard to automatically map the fields together.

Within the wizard, you can also setup security to control who can launch the eForm. For the sample implementation, members of the marketing department are given this authority.

Providing a view of outstanding change requests

At any point, the marketing lead may want to see all the outstanding change requests in the system. Being able to see these change requests, their target dates, and their current state, helps her to ensure that each change request is moving along as expected, and take action if necessary.

To implement this functionality, each change request is represented by a special document in the repository. The documents belong to a document class with the properties of owner, case state, and caseID. While there are multiple ways to represent a change request, there are several advantages of using a document to do so:

  • The document persists in the repository even after the process instance that executes the change request is complete.
  • Document properties can store information about the change request, such as its state.
  • The document can serve as a container for a diary about the change request itself — a place where notes and comments about the case can be stored. The diary of the change request is important because it can be used to analyze the effectiveness of the process. Notes in the change request diary may be important for audit or compliance purposes. Different change request diaries can be pulled together to provide interesting analytics on the change request process.

The change request document is added and maintained using steps in the process flow. The diagram in Figure 5 shows the modified flow.

Figure 5. Tracking the status of a change request
To track the status of a change request, create a new document at the beginning of the process flow. Then add steps to update the status of that document at different points in the flow.

Two types of steps have been added. First, immediately upon completion of launch, a component step processor is added to create the change request document (labeled as "Create request document" in the diagram). The lower half of the screen capture shows the configuration of the new step processor. On the right are the parameters for the createDocument Content Engine (CE) function used to create the change request document. The name of the new change request document is set to the process flow data field named CaseID, which was set when the request was launched. Also, a reference to the new change request document is stored in the attachment data field named CaseTracker so it can be accessed throughout the process flow. All case documents are stored in the repository folder that is referenced in the attachment data field named CaseFolder. The document type could be either plain or XML.

The propArray parameter is used to set the properties on the new case document. The format of the array is a series of tuples in the following form:

<property name, type, value>

So, for example, to set the initial state of the change request, set the propArray parameter to:

"{'CaseState', 'STRING', CaseState}"

Where the third argument in the example above is the process flow data field named CaseState.

Once the change request document is created, additional steps can be inserted into the process flow to update the request document. Two such steps are shown in Figure 5: one after Generate NLI and one after Load Die Line. Within these steps (labeled Update Case State) setProperty functions can be used to update the properties of a change request document, such as state or assignee.

Once the infrastructure is in place, the marketing lead is able to use a customized Web page such as the one shown in Figure 6 to view the change requests.

Figure 6. User Interface for viewing outstanding change requests
Through this user interface, the marketing lead can see all outstanding change requests and view details about each one.

(See a larger version of Figure 6.)

The user interface shown above is implemented using IBM FileNet ECM Widgets, which are a collection of Web user interface components that can be linked together to provide a customized Web user interface. There are four widgets on this page:

  • At the top of the page is a Toolbar widget. You can use a Toolbar widget to create a drop down menu of custom actions. From the Toolbar on this page, the marketing lead can initiate a new change request, which will bring up the electronic form described earlier and shown in Figure 4.
  • The next widget on the page is a Content List widget. Content List widgets show the results of repository searches. They are configured by providing the URL of a stored search created using the Search Designer in Workplace XT. The Content List widget on this page shows the outstanding change requests assigned to this lead, along with important information about each one, such as current state and assignee.
  • On the lower left of the page is another Content List widget. When the marketing lead selects a particular change request from the list at the top of the page, a search is executed and all of the documents associated with that change request are displayed in the lower left widget. Using this widget, the marketing lead can review and edit each document.
  • The lower right widget is a Viewer widget. A Viewer widget takes a particular document and displays its contents. For this application, the widget takes the change request document from the selection at the top of the page and displays its contents, which is the diary for the change request. Currently, this is a read only view. However, a custom widget could be created that would allow the marketing lead to add additional comments to the diary.

The widgets in the sample implementation are linked together so that when a change request is selected in the upper Content List, the caseID of the request is passed to the lower left widget as the key to the search and the change request document is passed to the lower right widget. This linking is accomplished by wiring the widgets together. Widgets have default wiring behavior that in most cases makes it easy to link them together.

The wiring of the document Viewer widget to the upper Content List widget is an example of using the default wiring behavior. From the list of widget configuration options for the document Viewer widget you would select the widget wiring option and connect the Content List widget to the Viewer widget in the corresponding dialog. Once that is done, the default behavior is for the Content List widget to pass the referenced document from the selected row into the Viewer for display, which is exactly what is needed.

For custom wiring requirements, you can use the JavaScript Adapter widget, which is a non-visual widget that lets you write JavaScript code to implement custom functionality. In the sample implementation, this widget is used to link the upper Content List to the lower right Content List. JavaScript is used to pass the CaseID of the selected row from the top widget to the lower one where it is used as the key to the search. To do this, you would add a JavaScript adapter widget to the page and populate it with the following JavaScript code:

return [{'name':'CaseID', 'value'}]

In this example, payload is an object that represents what is being passed out of the Content List. The value for the property called name is assigned to the CaseID parameter, where it will be used in the search for documents.

You would then need to wire the Content List, JavaScript Adapter, and document Viewer widget together as shown below in Figure 7 and hide the JavaScript Adapter widget so that it does not show in the user interface.

Figure 7. Wiring two widgets together
Wire the Content List widget to the document widget together using a JavaScript Adapter widget.

Creating a customized work environment using widgets

In the sample implementation, each participant has unique responsibilities. While there is some overlap, the activities each participant engages in are different. As a result, each participant needs a customized environment to complete their work as efficiently as possible. This section of the article demonstrate how you can use IBM FileNet ECM Widgets to create customized Web-based work environments.

Figure 8 shows a screenshot of the work environment page for the engineering lead.

Figure 8. Web-based work environment for the engineering lead
The Web-based user interface is customized using ECM Widgets. There are five widgets on this page: an ECM in basket widget, Toolbar widget, Work Data Widget, Attachment widget, and Step Completion widget.

(See a larger version of Figure 8.)

There are five ECM widgets on this page:

  • At the top of the page is an In-basket widget, which shows all of the tasks assigned to this engineer.
  • Next is the Toolbar widget. For the engineer, the Toolbar widget contains three options: create a new teamroom, conduct a document search, and initiate a review process. New items can be added to the Toolbar by configuring the Toolbar widget and adding new menu items. Menu items can be of different types; in this example all the actions are URL driven, so each menu option is configured with the URL to be invoked when the option is selected.
  • Below the Toolbar widget is a Work Data widget that shows all the properties of a selected task.
  • To the right is an Attachment widget with the label Change Request Documents, which shows any attachments that are associated with this particular task. In the screenshot there is an attachment for the die line (the engineer will populate this attachment when it is ready) and an attachment for the project plan for this change request.
  • At the bottom right is a Step Completion widget with the label Task Actions. This widget is used to save any work done on a particular task, as well as mark a task as complete. Once the task is marked completed, it is removed from the engineer's task list.

To associate this page with the engineering lead and configure the task list to display his In-basket, you would use the following steps:

  1. From the Process Configuration Console, create an Application Space to provide the context for all the ECM widgets that are part of the solution.
  2. Using the Process Configuration Console, define the Engineering Role within the Application Space and specify this page for the Engineering Role's landing page.
  3. When configuring this page to represent the task processor as well as the landing page, configure the In-basket widget to not open a task in a separate window. You should have already specified this URI for the task processor when you built the process flow using Process Designer.
  4. Using the Process Configuration Console, define the In-basket widget for the Engineering role to map to the Engineering Work Queue, which was defined when building the process flow. For this sample solution, you only need one ECM In-basket for each of the Work Queues that you created and used when you implemented the process flow.

These steps would be performed for all of the pages that are associated with particular steps in the process flow.

Enabling dynamic reviews

An important requirement of artwork change management is support for dynamic reviews. The engineering, research, artwork, and marketing leads may all need to initiate a review process as they complete their work. For example, as the engineering lead works through the process of creating the die line, he is likely to initiate an ad-hoc internal review. At that point, the engineer would identify a list of people to participate in the review, the documents to be reviewed, and the target completion date. When none of this information is known in advance, modeling the process flow for the overall process can be challenging.

For this sample implementation, Process Designer was used to create a simple review process and then an action item was added to the engineering lead's toolbar. The action item enables the engineering lead to invoke the review process, which results in the screen shown below in Figure 9.

Figure 9. Launching an internal review process
The engineering lead launches a review process using this form by providing a document, a list of reviewers, and a target date.

The screen shown in Figure 9 is the WorkplaceXT default launch screen for a process flow. It displays the data fields of the process flow and allows the user to initialize the values before launching.

From this screen, the engineering lead can select the team members that will be part of the review, attach the required documents, and provide instructions and comments to guide the reviewers as they look at the documents. When the process flow is launched, the team members are added to the review process workgroup and the documents are routed to them for review. The engineering lead is notified once the review is complete, and he can then submit his design document to the change request.

Using a process flow to model the review process enables ECM to provide automation to this process. This helps to efficiently drive a process that is typically conducted manually and is often a source of inefficiency. Also, because the process is being driven by ECM, upon completion, information can be added to the change request diary indicating who reviewed the document. This information may be important for historical or compliance reasons.


This article walks through elements of a sample implementation that demonstrates how IBM FileNet P8 can serve as the foundation for building a business process for managing changes to artwork. This process is an important part of developing new products in the consumer products industry as well other industries that build and ship products. The article provides technical details on how to create the process flow, use an electronic form to launch the process, and create customized Web pages using widgets. In addition, it addresses two specific requirements of the solution: providing an overview of outstanding change requests and implementing dynamic processes, such as internal reviews. In addition to being critical elements of the artwork change management process, these implementation details can also be useful to you when building other types of case-based solutions.



  • Learn more about IBM business consulting for the consumer products industry; contact your IBM FileNet sales representative or customer support representative to get more information about the sample implementation described in this article or schedule a full demonstration.
  • In the ECM Zone on developerWorks, get the resources you need to advance your skills on IBM Enterprise Content Management products.
  • Learn more about FileNet P8 on the Enterprise Content Management Web page.
  • Find details on the IBM FileNet P8 platform and its related components in the IBM FileNet P8 information center.

Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management, Industries
ArticleTitle=Use IBM FileNet P8 to drive new product development