Scentbird

JD Woods is an operations and business transformation executive whose career has centered on helping organizations make complex change practical. His experience spans supply chain, logistics, technology, customer experience and organizational improvement, with a particular focus on the point where systems, processes and people meet. He believes the best transformation work begins with understanding how people actually work, where friction lives and what leaders can do to create the conditions for better decisions and better execution.

I have spent much of my career working in business transformation, although that phrase can make the work sound cleaner than it usually is. In practice, transformation has meant ERP and WMS implementations, process redesign, automation, reorganizations and more than a few projects that began as a systems problem and gradually revealed themselves to be something larger. That distinction matters, because the technical problem is often the most visible part of the work, but not necessarily the most important one.

Organizations do not change in response to a flow chart. People change how they work, how they make decisions, what information they trust and what they do when the formal process fails them. Technology can enable change and process design may give it structure, but neither carries very far if the people doing the work do not understand what is changing, why it matters or how the pieces are supposed to fit together.

I learned that lesson very clearly during a recent ERP implementation that had stalled. At first, the problems looked familiar enough: configuration issues, consultant issues, missed expectations and the sense that the project had developed a life of its own. The instinct is usually to repair the project plan, clarify deliverables, push harder on the consultants and get everyone back on schedule. But as we worked through the problems, it became clear that the business itself had never really been introduced to ERP.

“Software can connect transactions, data and workflows, but it cannot by itself teach an organization to think interdependently.” 

People had been given assignments. Attend this meeting. Complete this worksheet. Test this transaction. Provide this data. What they had not been given was a meaningful explanation of what the system was intended to do for the business, why decisions mattered across functions, or how the pieces connected.

That gap was especially striking because ERP is, by definition, intended to integrate the business. Yet the project had been designed and tested in fragments. Each person or function approached the process as the task immediately in front of them, rather than as work created by an action upstream and producing an output someone else would consume downstream. Individual steps were designed, tested and formally signed off, while the handoffs between them were breaking down almost everywhere.

We had, in effect, asked people to help build a house without showing them the plans, and then inspected each room without paying attention to whether the doors opened and closed.

The immediate system problems still had to be solved, but the larger issue was context. People needed to understand the operating model, not just the tasks assigned to them, and needed a line of sight between their work, the work that came before it and the person or function depending on what they produced.

An earlier WMS implementation approached the problem from the opposite direction. Before designing the configuration, we selected a cross-functional team representing the operation from several points of view and asked them to define the problems they were already living with. Where did work stall? What information was missing? What workarounds had become normal? Where were people compensating for limitations in the existing system? Only after answering those questions did we begin designing how the WMS should work.

More importantly, the group began to work as an integrated operating team. Instead of asking only, “What does my department need?” the conversation became, “If we change this here, what does that do to you?” A decision in receiving was considered in terms of its effect on inventory, replenishment, picking, shipping, customer service and reporting. The people designing the future state were learning to see the operation as a connected system rather than a collection of functions.

That sequence seems obvious when stated plainly, but it is not always how implementation projects unfold. Teams can become absorbed in functionality, configuration choices and milestones until the organization begins adapting itself to the tool rather than using the tool to solve the organization’s problems.

Starting with the work changes that conversation. The people who will eventually use the system are no longer waiting for a finished solution to be delivered to them; they have helped identify the problems, explained the exceptions, understood the dependencies and defined what better should look like.

In my experience, capable people usually do not need to be “managed through change” nearly as much as they need the conditions that allow them to succeed within it: clear objectives, useful information, processes that make sense, enough authority to act and leadership available to remove friction when the work begins to break down.

Friction often contains valuable information. The spreadsheet no one likes may exist because the primary system does not provide something people need. The extra approval may have been added after something went wrong. The side conversation between departments may be the only reliable way information crosses an organizational boundary. Those workarounds should not automatically be preserved, but they should be understood before they are removed. Good transformation should remove friction, not simply relocate it.

A system can go live on schedule and still fail. The real measure of transformation is whether the organization behaves differently afterward, whether decisions improve and whether the people closest to the work are better able to do it.

There is a certain irony in implementing technology designed to integrate the business inside an organization whose people still work as separate functions. Software can connect transactions, data and workflows, but it cannot by itself teach an organization to think interdependently.

That part is still leadership.