The Step Everyone Wants to Skip

When you start an improvement project, there is an uncomfortable moment.

You have the problem on the table, you have ideas about how to solve it, and someone tells you: first we need to document how everything works right now.

And the natural reaction is to resist. I already know how it works. I already understand the problem. Let's get to the solution.

That impulse is the most common — and most costly — mistake in any operational transformation project. I saw it in the master's program, I lived it in real companies, and I understand it: documenting the current state feels like wasted time when you already have the answer in your head.

# What the Process Says — and What the Person Living It Says

My process improvement professor at the Polytechnic University of Valencia repeated something in every class: the AS-IS interview is to understand what is done and why it is done. Not to look for solutions.

But he added something important: in those interviews, the people inside the process are going to give you ideas. They will tell you 'this could be done this way' or 'I always thought it would be better if...' Those ideas need to be noted. Not to implement them immediately — but because they come from whoever truly knows the problem. They are gold. You just don't know yet whether they fit the right solution.

That completely changes the way you conduct an analysis interview. You are not going to confirm what you already believe. You are going to hear what you don't know yet.

# What I Found When I Listened First

When I conducted the AS-IS analysis for a confidential plastic recycling company in Venezuela, the first meeting was with senior management. I didn't arrive with hypotheses. I arrived with questions: what's happening?, what hurts?, what don't you like?

The word that came up most in that first conversation was traceability. They didn't have it. And at first it seemed like a technical problem — a records problem, a data problem, a system problem.

But when I completed the full process analysis, something unexpected appeared: the company believed it had six separate processes, one for each type of raw material they processed. This made them feel that control was enormously complex — they had to manage six different flows, with their own rules, their own owners, their own metrics.

What the AS-IS revealed is that they actually had a single process. The difference was the entry point: depending on the type of raw material, it entered at a different stage of the flow. Dirty plastic entered at the first step — pre-selection, washing, and continued. A clean post-industrial material jumped directly to the fifth step, which was grinding to make pellets. Same process, different entry points.

That finding changed the entire solution design. If we had arrived with the answer already built, we would have designed six separate flows. We would have solved the wrong problem.

# The Solution I Wouldn't Have Chosen

There is something I want to say honestly about that project, even if it is uncomfortable: the solution that was implemented — an internationally known ERP — was not what I would have chosen if the decision had been mine alone.

Not because it is a bad tool. It is excellent. But at that time I was building my own management system for a 3PL company, and I could clearly see that a custom tool, designed exactly for that recycling company's flow, would have been more efficient for their current operation.

However, management had a strategic reason for choosing the well-known ERP: in the future, if they wanted to sell the company or seek investment, having an internationally recognized system gave them credibility. It was a business decision, not just an operational one.

And there is another lesson from the AS-IS: when you understand the complete process, you also understand the context it lives in. Decisions aren't just technical. They are financial, human, strategic. And if you didn't do the analysis, you don't have that context. You only have your favorite solution.

# Designed for the Person Who Will Use It — Not for the Person Who Understands It

When I built the logistics system for the 3PL company where I work, I didn't do a formal AS-IS with structured interviews. I lived it. It was my operation. I knew every pain point because I felt it every day.

But I did something that has the same spirit: before designing any module, I asked myself how that process was done, why it was done that way, and what really mattered to capture. The difference is that I already had the answers myself.

And what guided every design decision was a question I learned from a friend who is an electrical engineer, years ago, while we were doing a wiring job together. He finished the connections quickly and I asked him how he knew so easily what went where. He told me: 'These connectors are foolproof. There is no two ways to connect them.'

I kept thinking about that. A design where error is impossible doesn't need instructions. It explains itself.

When the logistics system was running, I called my mother to test it. She is an educator — she has nothing to do with engineering or logistics. I explained how it worked in ten minutes and then asked her to do a task: create a pre-alert with made-up data. She did it. I asked her to receive the ticket. She did it. In ten minutes, without technical context, she completed a full operation.

That is what I was looking for. Not a system that engineers would understand — a system that any person could use after a short explanation. Because if you need me to be present for it to work, it is not a good system. It is a dependency.

# Who I'm Talking to With This Article