We love to hear about the business challenges that VisibleThread for Docs solves. In this customer interview, I caught up with David Schmidt, Vice President – Project Management & Sales Operations at SPX Transformer Solutions. David shared why SPX wanted to improve their process, the rationale for adopting VisibleThread, and the business benefits around better compliance.
About SPX – Based in Charlotte, North Carolina, SPX is a global multi-industry manufacturing leader with approximately $5 billion in annual revenue, operations in more than 35 countries and over 14,000 employees.
[Fergal] David many thanks for agreeing to share how you use VisibleThread for Docs. Can we start with a little background about what you do at SPX?
[David] Sure, SPX is a fortune 500 manufacturer. Our group has a $400m project portfolio. We have 12 application engineers developing sales proposals across two facilities. On average, we create 85 proposals per month.
[Fergal] What prompted you to look at a compliance matrix process and tooling?
[David] Our entire production, project portfolio is for highly customized, Engineered to Order, large power transformers ranging in value from $500K to $3M. Since we engineer every transformer to order, compliance is a necessity. This means we have a great deal of exposure in unnecessary costs and dissatisfied customers if we miss or misunderstand requirements. Let me explain the type of exposure.
With a growing volume and complexities, the potential for rework, penalties, and general inefficiencies related to missed or misunderstood requirements could easily exceed $1M per year.
- Unnecessary tests being performed, leading to wasted labor
- Unnecessary features being provided, leading to wasted labor and materials
- Necessary features/attributes being missed and excluded from the unit, leading to rework
- Necessary testing missed and not performed, leading to rework and potential warranty claims.
We also have different types of engineers involved, which adds complexity to the process. For example normally a specification is read cover to cover by 4 people; an application engineer, a mechanical engineer, an electrical engineer and a controls engineer. There is a lot of review overhead.
[Fergal] Reducing rework cost, review cost and avoiding risk due to possible warranty claims were the drivers. Can you explain how you solved this?
[David] Yes absolutely, so our original vision was to implement a Compliance Matrix Methodology. We wanted to better document requirements, and allow for a more formal “sanity check” on what exactly we were proposing and pricing.
This would also allow us to bring the customer into the fold on checking that we captured and correctly interpreted all their requirements at the proposal phase. Often we would get into debates over what was and was not purchased at a later date, and then of course who was to “pay” for any differences in scope.
And a by-product of a compliance matrix methodology would be that our customers could do more of an apples to apples comparison between what we were offering for sale, versus our competition.
My analogy to this is fast food.
[Fergal] Really, how so?
[David] well if you think about it, even in fast food restaurants these days, they give you a visual “compliance matrix”… every time.
They present back to you your requirements and re-validate your food requirement. They ask you if what you see on the drive-up screen is correct, before giving you a price. They have brought you into the fold of requirements management, and in essence, this is their quality operating system! Their ‘compliance matrix’.
[Fergal] So how did VisibleThread help, how did you deploy?
[David] We started with a pilot program. We purchased an initial set of user licenses for VisibleThread for Docs. Then we set about using the compliance dictionaries that shipped with the system to shred the RFP and generate the first pass Compliance Matrix.
We also created a custom compliance dictionary for additional searches. This is very important in our context; being able to customize dictionaries with specific technical compliance terminology. Technical compliance means keying off terms like ‘KBa’, ‘Mba’, ‘Ampherage’, ‘Ohms’ etc. and relevant symbols. We group the terms into specific categories in the dictionary, so each engineer can focus on their area of concern.
For example, an electrical engineer will tend to focus on electrical measurements such as ‘Ohms’, ‘Ω’ etc. So we created a category called ‘Electrical’ making that possible.
It didn’t take us long to get going with our more customized dictionary. The VisibleThread support guys pointed us to a starter dictionary that suited our needs available on their support site.
It already had many of the measures we wanted, so we started with that and customized it.
Now our Application Engineers create the matrix from VisibleThread. They refine it and distribute it to the control engineers, electrical engineers and mechanical engineers. Each gets the full matrix but each can focus on his or her specific area. This saves us a lot of time, since everyone no longer has to read everything.
It’s also an excellent artifact to provide to customers.
[Editor NOTE: The starter dictionary used by David is available here for free download:
[Fergal] Now that you have completed the pilot phase of the rollout, can you quantify the business benefits?
[David] Before the pilot, we saw that there was a great deal of non-value added effort, post order booking. Design Engineers were querying Application Engineers on what was or was not sold, as well as how various requirements were being interpreted.
Our pilot program showed that publishing a Compliance Matrix internally, saved numerous man-hours of back and forth, between departments.
Prior to the pilot, every engineer would read the proposal cover to cover. The pilot showed clearly how we could make this way more efficient.
We also learned that, not only did each Application Engineer read every customer specification (sometimes well over 100 pages) cover to cover to find all the requirements, so did each functional engineer (Electrical, Mechanical, Controls). Which meant that if we provided a categorized Compliance Matrix to each designer, it would serve as the “Cliff Notes” for their specific requirements, as opposed to each of them reading 100s of pages to hunt and find distributed requirements and details.
[Fergal] So, final question David, where do you see it going?
[David] well, the pilot was a way to see how it might help in a very specific way. It has been an unqualified success with obvious benefits.
We are now finalizing the implementation and integration phases, so the return on our investment remains to be defined. But we firmly believe that the utilization on Visible Thread, to quickly digest a specification and aid in the publication of a Compliance Matrix, will not only save money in better managed requirements and reduced rework, we also believe we’ll see 10-20% improvement in throughput, for our Application and Design Engineering groups.
[Fergal] David, really appreciate your time and insights.
If you want to see how we scan documents, check out these 3-minute demos to get a good sense.
If you want to see how you can check your document for compliance, sign up for our no-obligation free trial.