How to Audit Your Current Engineering Workflows for Digital Readiness

The majority of engineering organizations believe that they know the level of digitalization of their workflows. However, when they stop and take stock, they typically discover that requirements live in three different databases, change control is handled through email, and nobody actually knows which spreadsheet contains the truth.

Most systems engineering teams have a poorly understood digital readiness problem, because no one has taken the time to measure it, and you can’t improve what you haven’t mapped out.

And while mapping out your digital workflows can be a time-consuming process, it’s a hundredfold less expensive than buying new tools, finding out you underestimated the work and the cost, and being stuck with the same choices you had before.

Organizations often don’t put the needed effort into their as-is assessment because they believe they already know enough to justify the business case. However, if you skip the assessment, you’ll often find that you’ve based the business case on assumptions that were overly optimistic.

Map the Workflow End to End

To start, visualize and document the actual process followed from capturing requirements to designing, verifying, and validating the design. We don’t mean the ideal, codified version of the process found in your quality manual: we mean the steps taken any time an engineer begins work on a new requirement.

Once you’ve documented the as-is process in flowchart or swimlane form, look for broken traceability links between stages. Can you conveniently click from a requirement to the design element intended to satisfy it, and then to the test case that verifies the satisfactory implementation of that requirement?

Or do you need to ask someone and wait for a day or so while they hunt across three different software applications and a shared network drive to determine the answer? Broken traceability is one of the most evident symptoms of low digital maturity, and it’s usually the first tell of trouble caught in an audit against the ISO/IEC 15288 lifecycle stages.

Find Out What’s Actually the Source of Truth

Here is a basic test, If a drawing or a schedule delivers different info or conflicts with the model, which has authority? If you must answer either the illustration or the PDF, then the drawings, schedules, and the models you build on are your system of record.

Partnering with a digital engineering consultant early on can help you figure out whether your MBSE is just decoration or whether you actually have a digital thread.

Count the Manual Handoffs

Let’s go through your toolchain and identify all the areas where an individual exports data from one tool and then has to input it into another. For example, exporting data from requirements management and entering it into CAD, then taking the CAD output and manually entering it into a simulation tool.

Finally, taking simulation results and re-entering them into a requirements tool to update the verification status.

At each of these points, errors can occur. Data may not transfer correctly, mistakes can be made during manual entry, or some data may not be entered into the new tool at all. Interoperability between tools is generally poorer than the team expects, and in all likelihood, this is due to having inherited legacy point solutions.

Look Hard at Change Control

Engineering change requests are perhaps the most indicative element of a workflow when it comes to evaluating digital readiness. If a requirement changes, what do you get?

In a well-digitalized environment, the appropriate tools will automatically keep track of every downstream artifact, design, test, other requirements, that’s affected. In other cases, a line in a spreadsheet is the extent of it, and “Joe remembered to email the right five people” passes for impact analysis.

It’s about configuration management and change control, and barring a few exceptions of blissful ignorance, either digitalization is real where it happens, or it’s just not really happening, and there’s no “kind of” about it.

Check Skills and Appetite For Change

Introducing a new tool will not improve a process that’s already flawed. You will simply have a faster and more expensive version of the same flawed process, unless the users of the tool have the necessary modeling skills and motivation to operate differently.

Find out if your team would be willing to build and manage models instead of documents. Inquire how they would react to a new change management system that requires them to adopt different work habits.

If the answer is that they will resist these changes, it’s not a training issue that can be fixed with a short lunch-and-learn session. It’s a change management issue that must be integrated into your roadmap, rather than being treated as an add-on once the tool is already implemented.

Turn Findings Into a Phased Roadmap

Once you have identified your gaps, do not attempt to solve them all at once. Begin by identifying and implementing low-hanging fruit tool integrations. These are manual export/import handoffs that can be easily automated and provide people with quick relief.

Larger business-process changes, such as transitioning from documents to models as your primary source of truth, will come in later phases as trust in the new tools is established.

This is often the point at which many engineering organizations also realize they lack the internal bandwidth or experience to sequence the necessary changes themselves. Data governance rules, exchange standards like STEP, and digital-twin ambitions all have to line up in the right order, or you will be recreating work you just completed.

An audit like this shouldn’t take more than a few weeks if you’re honest with yourself. The value isn’t in the paperwork it produces, it’s in knowing exactly which broken link to fix first, instead of guessing.