A Serious Flaw in Order Confirmation (FlexPLM)

FlexPLM: v9.1

From the sourcing or merchandising perspectives, PO is their ultimate goal to finalize the deal. Although all data are captured by the system (FlexPLM), FlexPLM is unable to issue PO nor to generate packing list and labels. A custom interface was developed to transmit data from FlexPLM to the PO system. Order Confirmation (OC) is responsible to capture the ordered data for PO processing. In other words, OC is a stepping stone from FlexPLM to PO. This OC module is customized for PO needs but there is a design flaw along with other long-standing bugs.

Two major components must be referenced by an OC upon completion:

• Cost sheet(s) and
• Product Plan (to specify colorway(s), NDCs, shipping terms, order types, order quantities and etc.) for ordering

A Design Fault Issue

A valid OC must contain at least one or more cost sheets. Each cost sheet is in turn referenced by a cost sheet number. While everyone assumes that the wanted cost sheets are set to the OC, instead the OC only remembers which unwanted cost sheets the user specifies. This design is similar to an email system. The system only remembers what you don't want, instead of what you want. It is not practical and it is a complete fault when this is put in place of ordering.

Let's consider the following situation.

At day one, there are 3 confirmed cost sheets. The user only wants CostSheet2 (CS-123452) to be referenced by the OC. Everything looks perfect in the system.
( Day 1 )
Existing and confirmed cost sheet		User Wants	OC Remembers	System Displays
Name	Number
CostSheet1	CS-123451		✓
CostSheet2	CS-123452	✓		✓
CostSheet3	CS-123453		✓

On the second day, there are 3 more confirmed cost sheets finalized for the product. Because the system only remembers what users don't want. These 3 newly confirmed cost sheets are uninvited and added into the OC. The OC in turns results in error.
( Day 2 )
Existing and confirmed cost sheet		User Wants	OC Remembers	System Displays
Name	Number
CostSheet1	CS-123451		✓
CostSheet2	CS-123452	✓		✓
CostSheet3	CS-123453		✓
CostSheet4	CS-123454			✓
CostSheet5	CS-123455			✓
CostSheet6	CS-123456			✓

[Added & edited on October 20, 2013] Why is the OC in Day 2 in error? The error is not from FlexPLM but the interface which picks up the data from FlexPLM to the PO system. The costs specified in the cost sheet could be appliedy to all or certain colorways of the product. If two cost sheets referenced by an OC contain the same colors, the interface will be confused which cost sheet to use. Let's say cost sheet A defined that color black costs $5.5 totally while cost sheet B said that color black is only $4.4.

To fix this, the merchant has to go into the OC and explicitly tells the system to cross out the other 3 cost sheets. Each sourcing office could create and complete 100 to 200+ OCs per day. Initially all OCs were handled by the merchants themselves. Because of unfriendly GUI and learning curve, the company would like their merchants focusing on the business instead of system operations. Two more headcount or positions are introduced in the office to handle OCs only.

As a matter of fact, the GUI itself refreshes this design problem by asking the user which cost sheets they don't need. The operation is similar to an email system where you delete the unwanted emails. The system will assume that the leftover are the emails you want to keep.

Lesson Learned

I personally wouldn't accept this implementation and won't expect to educate users to work around it either. This situation for sure won't be occurred when all cost sheets are defined and completed ahead of time. In reality, the users unlikely complete all cost sheets before ordering. They usually place orders while they are still working on other pending cost sheets. In this situation, it is no way to prevent the above issue from happening with the current system design. This issue greatly disappoints users and introduces more work. It is also too late for the company to realize this problem. The expense of modification is on the company. Thus be sure the behavior of the system matching the real operations. Don't expect to educate users how to work around the issue when the reality disagrees or/and the system is unable to provide the guidance.