You know what I keep hearing from manufacturing leaders? We know we need a new system like ERP, but what if something goes wrong? What if operations come to a halt? Mai kya karu. And because of this one fear, our decisions get delayed. Months pass sometime years. I get it. The fear is real. But today I want to show you that there is a way to test any new system without putting your current operations at risk not even for a single day.
Welcome to my talk series Kya karu for business owners like you. I am Nalin Mehta.
Let’s get into it. So first let’s understand where things actually go wrong. Most companies do one big switch.
Old system off, new system on. done. And that’s exactly where the chaos starts.
Dispatch errors, wrong inventory numbers, invoice problems. Suddenly, your whole team is firefighting and your customers are feeling it. But here is something most people don’t talk about. The system is not always the problem.
Very often the problem exists before the system even comes in. If your processes are not documented. If your team is running on informal knowledge and verbal instructions, then no system in the world will fix that. A system can only automate a process that is already clearly defined. If there is no documented process for how material gets issued, the ERP will not create one for you. It will just make the confusion faster. So before you think about implementation, ask yourself one honest question. Have we actually written down how we work today? Step zero, document your existing process first. This is the step most companies skip entirely and it is the reason most implementations fail. Go through each key process. How is an order received and entered? How is material issued from the store? Are my bombs correct? How is the production planned? How is dispatch confirmed? Write it down. Not how it should work in theory. How it actually works today. Once you have that documented, you can look at it clearly and ask which parts of this should the new system handle? Where does automation actually help and where do we need to fix the process itself before we automate it? This step alone will save you months of pain during implementation. Step one, don’t implement every year at once. Once your
processes are documented, pick one small area to start. Maybe one plant, maybe one product line or even just one process like purchase orders or dispatch. Keep it small, keep it controlled. You’re not trying to prove the system works everywhere. You are testing whether it works properly somewhere. Step two, run both systems together for the next 60 days or so. The
same order gets entered in both the systems. The same inventory is tracked in both. The same invoice is generated from both. Your team will say this is double the work. And yes, it is. But this double work is what protects your business. Because if something breaks in the new system, your old system is right there running everything smoothly. No panic, no disruption, no customer impact. Step three, compare every single day. This one is critical and most companies skip it. They run both systems, but never actually sit down to check the difference. This is where the parallel run fails. Every day, your team should be asking three simple questions. What is the old system showing? What is the new system showing? And where is the difference coming from? Create a simple daily tracker. Note down what the issue is, what the difference is and why is it happening, who will fix it and by when. Without this step, a parallel run is just a waste of time. With this step, it becomes really powerful. Step four, fix ownership clearly. Everything should not go to it or the vendor. Most issues during implementation are not technical. They are process related. So make it clear. Purchase issues go to the purchase head. Production issues go to the plant head. Finance issues go to the finance team.
Their job is simple. Review daily.
Understand the issue. Get it fixed. If no one owns it, no one solves it. Step five, do a weekly leadership review. You don’t need a big meeting. Just check three things every week. How many issues came up? how many got resolved and how many critical ones are still open. If issues are reducing week by week, you are on track. If not, don’t rush the roll out. First fix and then only move ahead. And finally, don’t do a sudden switch. After 60 days, don’t just announce that from Monday the old system is off. Ease into it. Stop the old system only for that one small area you
started with. run the new system alone for a few days. Watch it, make sure it’s stable, then and only then slowly expand. So what does this entire method give you? No panic, no disruption, no surprises. Your team builds confidence gradually. Your systems get properly tested and when you finally scale, you do it knowing it actually works. The 60-day parallel run method works, but it works best when the foundation is already solid. Document first, then test, then scale with confidence. I hope this was useful. Stay connected. There’s a lot more coming in this series. Thank you very much.
