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.

Reasons Why Users Don't Like FlexPLM

This post is to follow up the discussion in my previous post.

 

1. FlexPLM is NOT user friendly.

   Steep Learning curve is required on using FlexPLM. Words or phrases on the screen are not self-descriptive. It is not easy to navigate within FlexPLM to locate data. The wizard or the icons are also hard to find on the page. Data presentation of FlexPLM is not organized logically from user perspectives. The Interface is poorly designed.

 

2. FlexPLM doesn't promote collaboration but frustration.

   Workflow is available on FlexPLM but it is not tied to the actual process flow within the system. Instead, it acts like a complete separate process that requires additional manual steps from users as if they were coming from a different system. Luckily, neglect of any workflow task won't prevent users from working on the products within the system. Unfortunately, it causes some degree of disagreement among departments of how tasks could be done.

 

3. FlexPLM can't streamline or help optimize the process but heavily increase (or triple) workload and rely on user "supervision."

   • Let's take a notification of mailing out development samples as an example for illustration.

     Without FlexPLM, users simply notify the buyers about airway bill info via a single email.

     With FlexPLM, users have to do the following:
     

     Step	Why is this step necessary?
     Send an email notification to the buyers via Outlook as usual	FlexPLM lacks of notification capability.
     Input the airway bill info into the system via Line Sheet or the product page	The business requires to capture this piece of info.
     Consistently search "My Work" to see if the expected workflow task is available for completion.	Some workflow tasks prior to this have not been completed yet. Or the tasks cannot be displayed for users for unknown reasons or a bug. There are no distinguishment between new tasks and the existing. Finding new tasks among tons of existing outstanding items visually is not easy. Some users are even manually exported data into Excel and manage them daily.
     When the workflow task is finally shown up at "My Work", check the selection box and then click the submit button for completion.	It is how the users tell the system of their task completion.
     Be sure to click the Refresh hyperlink at "My Work" again to ensure that the submitted task no longer exists in the outstanding task list.	For unknown reasons, some workflow items require multiple submissions. Additional notes: PTC/ITC said that everything works as designed and it is user fault. As per them, multiple records of completion for the same task showing in the system doesn't confirm the issue. It may be an double-click issue by users.

     This is one of examples. There are plenty out there. All burdens are on end users.

   • Internal data corruption happens all the time. For unknown reason, a NULL value is periodically placed into the data field without user knowledge during "save" or "update", which causes severe data lose or missing orders.

   • In addition, data discrepancy may occur between the pages shown on the screen and the physical print copy from the generated PDF (TechPack). Users feel humiliated when their vendors inform them that they found a few issues from the given PDF. Measurement or grading sheets are usually the victims.

 

4. FlexPLM can't help reduce cost but increase labor cost to ensure everything won't fall apart.

   Users work very late (even till mid-night) after switching to FlexPLM. The company increases the workforce by hiring more data entry for help-out.

   Losing orders happens from time to time and it has been one of the major issues so far. Learning from a few painful experience of missing orders, most users will print and save a copy of their work for future reference and periodically check against the system till the POs are issued.

Experience with FlexPLM

If you're looking for PLM solution or FlexPLM is on your list for evaluation, my experience with FlexPLM may be your interest.

FlexPLM is developed by PTC headquartered in Massachusetts. There are various FlexPLM packages available for purchase, from fully customization to the simple configuration with a very minimum change. For the past 18 months, I have been dedicating my time to administer FlexPLM for a company which purchased the package with the least customization. Thus, most of features are out of the box (OOTB). The software itself is further customized and serviced by one of PTC's software partners, ITC InfoTech, which houses in India.

Up till now, the company has been using FlexPLM for 2.5+ years but the feedback is negative and no one likes it. The more users use it, the more complaints there will be. This company is in the garment industry. Its sourcing offices are all over the world while its retailer stores are exclusively in the states. They do everything themselves from design to product development including choosing fabric, color, lap dip, sample yardage, development sampling, costing, manufacturing and moving products from warehouse to the retail chains. In order to consolidate everything (except PO) in an one single system for all parties (fabric specialists, designers, technical designs, quality assurance, merchants in headquarters, merchants in sourcing offices, warehouse employees, staff in retail stores and even the management), FlexPLM was chosen to replace their existing legacy systems including their in-house developed merchandising software and the PDM.

PTC's sale speech sounds good but what FlexPLM delivers is another story. The management of the company originally focused on job done, As the increase of the anger from users, they realize the simplicity must be taken into the consideration while they want to remain the same process flow on FlexPLM. Overall, here are the voices from users:

• FlexPLM is NOT user friendly.
• FlexPLM doesn't promote collaboration but frustration.
• FlexPLM can't streamline or help optimize the process but heavily increase (or say triple) workload and rely on user "supervision."
• FlexPLM can't help reduce cost but increase labor cost to ensure everything won't fall apart.

* Please also see Reasons Why Users Don't Like FlexPLM

Anger is everywhere in the workspace of every office. After 2.5+ years trying, the company finally gives up and decides not to continue with FlexPLM. The message of discontinuity is firm and even publicly announced to the entire company. They are making no more than 2-year transition plan to be out of FlexPLM. It is noticeably joyful from users' faces as soon as the announcement was made. As a matter of fact, they can't wait for that day to come. Obviously, they would prefer the instant demise of FlexPLM.

FlexPLM may be a perfect fit for most companies in most industries without customization but it certainly does not fully comply with the needs of the company, especially the need of the full life cycle operations from material to product, from product to manufacturing, from manufacturing to dispatching and finally down to the retail stores. The customization is supposed to bridge the gaps but it somehow fails.

We all know that bugs always exist software but FlexPLM is not tested well before production. I personally always wonder how the release could pass the testing if they have or perform proper test cases and suites. The same issues could be re-surfaced in any release. To some extent, the problems are even rooted from the design (I will address this more when I discuss order confirmation in my future post).

The project manager of the company should take some responsibilities. The actual operations executed by each department is somewhat different from the way the system presents. And some of end results also behave somewhat different. To fix all issues, the system keeps being bandaged without root cause analysis. To me, the fix will never be a fix if they keep shoveling the problems under the rug.

Another problem is that the project manager believes that human education can work around the issues instead of finding the fundamental culprits and tailoring the system to guide the end users or simplify the work process. To me, it won't stop the problems if they keep relying on training to teach users what they should or shouldn't do to work around the system issues. Sadly, I just don't see there is any business requirements analysis.

I am not here to judge. You should be the one to decide what to do. I will show you the fact from the system and the end user points of views, and what the company are facing so that you may add them into your substantial criteria for review, evaluation or even customization. I personally hope that they may be somehow useful or even help you make a sound decision.

Please stay tuned if you're interested.