FERA: Closing the Process/Technology Gap
Vasco Drecun and D.H. Brown

Global economic pressures mandate that manufacturing companies establish faster and more intelligent collaboration throughout the supply chain. “Just in Time” (JIT) delivery initially targeted inventory reduction as a primary objective. JIT has since evolved into a relentless drive to improve all enterprise/supplier workflows in the face of ever increasing time pressures. Improving workflows, however, depends first and foremost on explicitly defining a process framework based on common objectives, clearly establishing expectations and roles for all individuals, and setting a reference baseline for continuous improvement.

A framework fails if it does not address the full scope of the challenge—the extended design and supply chain. Individual companies no longer define the primary competitive criteria for success. Programs that narrowly target an OEM often fail because that OEM alone represents less than half of the scope of issues that must be addressed. Rather, factors in the full supply chain represent the major determinant of success.

To succeed, a process framework must support a single design and delivery platform, encompassing both PLM and supply chain issues. It must integrate across the extended enterprise. Today, a gap immediately arises because technology does not speak a process language. Functional descriptions do not communicate to people involved clearly on their roles, responsibilities, priorities, and milestones.

IT organizations tend to normalize processes and apply narrow definitions to activities involving broader requirements and deeper complexity. Process variations across the design and supply chains break the systems based on those normalization efforts. Research into 113 trading exchanges in the manufacturing sector reveals unusually low adoption rates across the supply chain with less than 5% of the planned and targeted business transactions actually served with the deployed systems.

Design and supply chain processes must be mapped to an affordable technology platform based on common standards that enables the sharing of content rich information in a timely manner while maintaining an accurate business context. Research into successful deployments across the design and supply chains finds that all shared the same generic architecture, named as the Federated Enterprise Reference Architecture™ (FERA). A generic system architecture, FERA describes the classes of configurations that may be mapped directly to the full and complex range of process patterns for PLM and Supply Chain requirements. Thus, with FERA technology and process modeling tools and techniques, an integrated framework addressing both process and technology can be established to assess gaps and requirements, and then accelerate deployment of the full range of solutions needed for design and supply chain collaboration.

As a common abstraction representing a variety of technology deployment components serving loosely coupled collaborative processes, FERA can be reconciled through direct mapping with process models defined as business semantics in plain, non-technical language. The framework not only defines a baseline metric for continuous improvement in understandable terms, it also contributes to the formulation of consensus across the participating companies in the supply chain.

Closing the gap between process and technology resolves one major hurdle—the overwhelming complexity of the processes themselves in optimizing collaboration across the design and supply chain. Processes present far more intricacies than most companies recognize. All too often, IT applies simplifying assumptions regarding requirements that inevitably lead to the wrong technical implementation because a far broader range of interactions ultimately needs to be supported. Either the rigidity only serves processes too trivial to matter, or else the lack of flexibility drives out the intelligence of effective decision-making. Extreme care must be applied in considering the full spectrum of process interactions to fully understand their character before implementing technology, since that will determine deployment framework.

Four generic patterns of collaboration are often used in practice to support collaboration in design and manufacturing. The four range from the simplest data exchange through portals and bulletin boards to fully supported collaboration, reflecting a huge leap in the sophistication of the processes involved as well as the underlying technology.

1. Bulletin Boards and Web Meetings

Many collaborative processes simply distribute or collect data, with humans involved to varying degrees in interpreting the effect of external data on local operations. Participants can download information, and post updates of their data in a designated format, sharing over the Internet through FTP or email. Web meetings may extend to open collaborative sessions supported by visualization tools, and interactive discussions online led by a host. Often, these processes suffice for immediate ad hoc exchange of critical information. However, the approach is meaningful only when the context of the collaboration is already fully established, well defined and intuitively well understood by all participants.

A centralized system supports the business logic, with remote users accessing the system through portals at any time to perform a limited set of information inquiries and submissions, guided by the rules and constraints programmed into the system. Typically, portals are used to support remote user login and security clearance, while services gateways connect the portal system interface to the function calls of the centrally managed system.

2. Personal Interaction Supported by Collaborative Software

Personal collaboration may simply be aided by collaboration software such as visualization that reconciles high-level data views among the participants, or even Microsoft Excel spreadsheets, as examples. Two engineers, one from an OEM and the other from the supplier, may participate in a conceptual design review with visualization tools even when they use different CAD systems. One can guide the other through the assembly review analyzing the fit and form features and constraints. The other engineer submits the changes in the part design in his or her respective CAD system influenced by the joint session and communicates the understanding of assembly constraints directly to the peer.

A similar configuration takes place with forecasting collaboration. The two planners may inquire into the sales forecasts over a common portal, whereby each one conducts their own analysis in their respective systems. A joint session concludes by adjustment of their respective forecasts and a list of the potential planning problems that might cover allocations or capacity requirements is jointly reviewed and confirmed.

3. Publish and Subscribe – System to System

Participants generally may not need to directly communicate. Rather, the systems they use exchange information to update each other on actions and decisions. On a predetermined schedule or upon remote invocation, systems exchange information in a context-specific format that each federated system independently interprets. Participants therefore indirectly collaborate, often getting involved through their own workflow systems after their internal systems have already processed the received information using the business logic of their respective domain.

The approach applies to problem reporting, warranty administration, inventory updates, advanced shipping notice (ASN), etc. Often, this pattern can be conducted with asynchronous exchange of information since the subsequent steps performed by federated systems can be performed independently and do not need to be coordinated directly through the collaborative process until the new information defining the next stage has been published.

4. Collaborative Business Process Management

Many collaborative processes do not have a clear definition of a standard process. Given their non-deterministic and ad hoc characteristic, they cannot practically be simplified. In such cases, the exchange of information involves people directly communicating at some higher level of abstraction supported by web meetings and collaborative software. At the same time, data exchange may also be required as supported by the publish and subscribe configuration. Direct coordination system to system involves the reconciliation of distributed business logic and details. The combination of direct personal interchange supported by data exchange and reconciliation ensures the integrity of the collaborative process.

This pattern can have two variations of process reconciliation: one with asynchronous off-line iterative procedure and one with real-time automatic reconciliation. Processes such as engineering change management, RfX and auctioning, or direct procurement can be supported by the iterative reconciliation. However processes like order fulfilment and dynamic replenishment need immediate and synchronous adjustment of the distributed information to the overall agreed upon plan.

Each collaborative pattern described above can be supported by FERA components. However, the number of components and functionality required progressively increases from bulletin boards and web meetings through full collaborative business process management. With FERA technology and process modeling tools and techniques, an integrated framework addressing both process and technology can accelerate an assessment of gaps and requirements for deployment of the full range of systems needed for design collaboration across the supply chain.

FERA can be reconciled through direct mapping with process models defined as business semantics in plain, non-technical language. The reference process model for Product Design for the Supply Chain (PD4SDC) sponsored by the Supply Chain Council (SCC) may be mapped directly into FERA representations.

The FERA research by CPDA was funded by Intel, HP, and Microsoft in conjunction with their drive to establish an open standard with SCC for a business process framework, Design-Chain Operations Reference Model. DCOR will serve users that need to evaluate their internal processes and their current business practices, and to assess gaps and requirements.

Interested parties can join CPDA, HP, Intel, and Microsoft for an update on FERA and the DCOR program at the CPDA conference, PRODUCT LIFECYCLE MANAGEMENT ROAD MAP 2004 on September 22nd and 23rd. Those signing up for the conference may receive a full copy of the complete FERA research report upon request. For more information on PRODUCT LIFECYCLE MANAGEMENT ROAD MAP 2004 visit the CPD Associates website at http://www.cpd-associates.com/ and click on the PLM Road Map logo. To register for this event please email events@cpd-associates.com or call the PLM Road Map Hotline at (800) 573-4756.

Vasco Drecun is Research Director and D.H. Brown is managing partner at Collaborative Product Development Associates, LLC (CPDA), 222 Grace Church Street, Port Chester, NY 10573. CPDA specializes in collaborative research, documenting and analyzing PLM trends in engineering, manufacturing, and technical computing.