I was at Autodesk’s Accelerate conference in New Orleans earlier this week. Many great speakers talked about how they are adapting to the realities they find themselves in—demanding customers, changing supply chains, squeezed timelines — and, oh, the complexities of process maps! Autodesk asked these speakers to talk about how they applied technology to transform their businesses, to “collaborate, automate, and make smarter decisions, faster.”

As I listened to the speakers, it became clear that “digital transformation” as a buzzword is almost meaningless. It’s marketing-speak from vendors trying to sell the latest and greatest and, like many things marketed at us, both aspirational and de-motivating. Ooh — what do I get if we buy that? If we don’t buy it, are we behind? If we do, are we better than our nearest competitor? Can it fix all our problems? What does it even MEAN?

At the end of day one of Accelerate, I was on a panel that tried to address some of this. We really did want to help the audience understand how to move along whatever “digitalization” path they were already on, what to consider as they envisioned a new future, and how to avoid some of the pitfalls we’ve already seen. Since this was a technology company event, these weren’t people who had to be convinced to try tech; they needed directional information on where to go next.

The panel, made up of Allan Behrens of Taxal + Stan Przybylinski of CIMdata + Michelle Boucher of TechClarity + our moderator, Chad Jackson of Lifecycle Insights + me, struggled to come up with a unified definition of Digital Transformation. Michelle said it was more than just making something that had been paper, digital — that you want digital technologies to make data available to everybody. I disagreed, since for some, taking that step and making a PDF out of a piece of paper is a great start. Not an end, but a start. I think it was Stan who said that digital transformation means using computers for what they are good at, managing and processing data. And so on — Chad had his definition and Allen had his.

This was frustrating to some in the audience, who wanted a pat answer: “Do this then this then this, and you’ll be digitally transformed” would be so lovely. But it’s impossible to lay out that kind of path since every person in that audience came from a legacy corporate and personal IT environment that has evolved to meet needs. And they were bringing that to bear on what they thought needed transforming and what didn’t.

But here’s the thing. Among many excellent presentations, one little anecdote, an aside, stood out. The speakers from Sandvik Coromant talked about the need to create a work environment and toolset that was ready for the workforce yet to come. They may be less experienced in machine tool use (Coromant’s area of expertise) but would be totally comfortable with digital technology. To illustrate this, one speaker said that a colleague and his daughter were driving the daughter to a friend’s house when they both realized they didn’t have the exact address. The dad handed his phone to the daughter and asked her to call the friend for help. The daughter connected, pointed the phone’s camera at the road ahead, and said, “Tell us when to turn.” I wouldn’t have thought of that — I’d have asked for the address and programmed it into the map for turn-by-turn details. I related this story to someone else who said he would have described what he was seeing and asked for directions in words. Someone else would have used the phone’s browser to Google the address.

How we use technology is directly related to our history with it. I’m a map girl, so that’s how I use my phone. The daughter in the story maybe had never seen a paper map, and her approach made the most logical sense to her—same technology, totally different use scenarios. But we can’t let that history blind us to potential uses. “Digital transformation” has to consider how processes are structured today and then change where needed to take advantage of current technology —and, if possible, coming technologies, too.

Another point of frustration for the audience that we learned after the session was that there are no clear metrics to use to tell if you’re “doing it right”. It’s not like weightless, something else that’s relentlessly marketed to us, where an absolute number on a scale can tell winners from losers. There are many potential metrics to judge the success of a “digital transformation,” but the details of how they apply are specific to each use case. For example, you could consider 

• Fewer engineering change notices, perhaps because of better communication among the design team and partners — but is that due to technology or to a better process that takes that technology into account? 
• Faster design cycles because less time is spent in activities that don’t add value — but how do you measure that? The old chestnut that people spend 30% of their time searching for information or waiting for responses for critical information may or may not be true for any single enterprise. 
• Increased revenue? That would be lovely, but is hard to trace to any single effort and may, in any case, be tied more to market forces than anything the company itself can do
• Lower costs? Again, a fantastic goal but hard to tie to any single effort

I think there are many ways to measure success, but it’s tied to how management views these types of investments.

This all gets to one question we got towards the end of the session. Paraphrasing, “If you can’t define Digital Transformation, how do I explain it to my boss and get him to invest? He’ll want measurable impacts.” 

My advice hasn’t changed: 

1. Don’t call it “Digital Transformation”. Sounds too much like a long and expensive IT project. Instead, 
2. Pick something very specific that you know is a problem but one you can deal with relatively cheaply and quickly. Let’s say you run into issues with the supply chain — they deliver the wrong components at the wrong time. A bit of root cause analysis could indicate that the suppliers get too many emails from your organization and do their best to understand what you’re asking for but can’t get answers from the right people; they’re guessing. That’s a communications issue that could be addressed by collaboration technology. All CAD vendors offer something here; you can set up a remote session to look at and annotate CAD assemblies to confirm everyone’s understanding
3. It’s very difficult to measure a negative, so look for a positive way to gauge if this is working. Problems avoided is a negative; on time, as expected component delivery is a positive. Measure that and compare it to the before state to show that this is working.
4. Make sure every human being affected by this change understands why it’s necessary and how they fit into this new world of work. If they don’t buy-in, this can’t succeed — and you want them positively engaged rather than punished into cooperating
5. Celebrate if this effort worked and even if it didn’t quite. I don’t really think you can go wrong trying incremental changes because they will affect the status quo. And you’ll learn and (this was Allan’s point), often come up with an even better idea for the next try at a solution.
6. Repeat.
7. And as you get one or more of these smaller projects in play, start thinking bigger picture. You don’t want to start building a piecemeal IT infrastructure that you have to manage yourself; work with a vendor or reseller who can help ensure that all of the things you do will play nicely with one another. DON’T CUSTOMIZE any more than you have to–it leads to downstream headaches. And the more you use out-of-the-box products, the more you can benefit from the expertise that’s built-in. Why reinvent the wheel when you don’t have to?

Most managers are aware of what’s not going so well and will entertain modest investments to try for improvement. As someone on the panel pointed out (apologies, can’t remember who, but it’s brilliant): people are already busy doing their jobs and can’t be expected to drop everything for this new initiative. By being incremental, they’ll slowly be shifted over to a new way of working, with minimal disruption to their daily.

Another great question was about the cloud: does digital transformation require moving to the cloud? Of course not since many digitalization efforts aren’t about “where” but “what and who” in any given process. But, in very general terms, cloud technology is newer than on-prem, so if you truly want to reinvent and cloud is possible for you, it is a way of jumping ahead more quickly.

And one more, about legacy data. What should you try to take forward? Again, no easy answer, but: all that makes sense. If it’s CAD models you haven’t needed in decades, perhaps not those — but the CAD models for products still in the market, yes. Same for part catalogs, supplier info … But do revisit legacy processes since in some cases those exist only because they’ve always been that way. As I think Chad said, don’t perpetuate a bad process with better technology.

TL;DR? “Digital Transformation” can really be anything you need it to be. Some companies are using this as a lever to change many processes and technologies in an overall reinvention — that’s a “go big or go home” kind of approach. For lower risk, start small, and see what you can do. If it’s a win, great — keep going. If it didn’t work so well, it’s a small investment in doing better on the next try. You’ve learned something and can move ahead with more confidence.

Autodesk Accelerate 2022 was an in-person event but I believe some sessions were recorded and will, in time, make their way onto the web. I’ll try to keep an eye out and will let you know when (and which) sessions are available.

On a personal note: it was AWESOME to see real people, in person and not in little teeny Zoom boxes with fake backgrounds. I hope I run into you, too, sometime soon, if the world continues to open up.

Note: Autodesk graciously covered some of the expenses associated with my participation in this event but did not in any way influence the content of this post.