Missing Orders - Order Confirmation (FlexPLM)

FlexPLM: v9.1

My previous post mentioned a serious design flaw in OC which causes confusion on cost sheet identification. There is another issue as bad as this design flaw. Missing colorways happens almost every day. All orders are subject to the colorways being placed in the product plan. Thus, missing colorways in OC means missing orders.

For each valid OC, there must be a [product] plan which consists of quantities (Target Volumes), delivery date (NDC), colorways and etc. Each order is organized per row by colorway (see Sample of Plan). Some colorway rows or the whole plan data could be lost without user knowledge.

At first, we thought that it was a human issue due to colorway/size category deletion for the fact that this customized version of FlexPLM doesn't perform any detection including colorway/size category that may be in use. Missing orders haunts the company since moving onto FlexPLM. Similar to the design flaw issue, it requires daily dedication to keep track of OC plans. Recently we've found that one of causes is leaving page including the browser Back and Forward buttons. If the user navigates to some other pages before the plan is saved and exited, and then returns to plan for editing, the issue of losing plan data will occur. By the time comes, the PO specialist tries to issue and approve the PO but finds missing or no orders.

This missing order issue could happen anytime during OC editing or after completion. Today you find the plan look perfectly in the OC but it may vanish in a few hours, next day or even any time in the future. There is no guarantee that the entire plan data exists until PO creation. We still don't know why the plan data will be gone when no one touches it.

Lesson Learned

Be sure your system could handle the situation of users leaving pages without saving data. Your UAT must include this to ensure data integrity. This problem reminds me of my time working for a marketing research company where the applications always allow people leaving pages and then quickly returning to answer the rest of questionnaires.

 

Sample of Plan - This plan is modified for display only; simply expand it to view the plan.

When the plan data is lost, each order (i.e., the colorway row) consists of yellow exclamation mark or the entire plan is even missing or empty. The following plan won't be seen when the problem occurs.

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.