Ask for one week of your own data on the screen. That is the whole test. The demo test is one hour of a vendor’s manufacturing analytics software running against one week of one of your own lines, with the gaps left in. An hour against your own extract, from one real line, tells you what the tour leaves out: how much work sits between the data you actually have and the screen you were just shown. I sat in a demo this spring where the buyer, a maintenance planner fourteen years on the same site, let the presentation run for twenty minutes and then asked one question. Where did that reason code come from. The presenter said the sample set had them filled in. She said hers were blank more often than not. The room went quiet for a second. That was the most useful minute of the meeting, and it happened by accident. What a manufacturing analytics software demo is built to show A demo is a sales asset. It is not dishonest, but it is built. The sample data is complete because someone completed it. The tag names are consistent because someone made them consistent. The chart moves because the numbers behind it were shaped so it would move. Every vendor does this. It is not a scandal, it is just what a demo is. Which means a scripted tour answers exactly one question: can this product display an answer when the data is already good. That is the least interesting question in your evaluation, because the data is not already good. In most plants I have sat in, it is somewhere between uneven and unreadable, and everybody in the building knows it. The expensive question is the other one. What has to happen before that screen is true here, and who does it. What your own data shows in the first ten minutes Tag names are the first problem. In the sample the sensor is called Line3_Filler_Speed. In yours it is FL3_SPD_PV, there are two of them, and one has been dead since a controls upgrade three years ago that nobody documented. Watching an engineer work that out live is worth more than any slide. Then timestamps. The machine clock, the historian, and the scheduling system rarely agree to the second, and sometimes they disagree by an hour twice a year. A tool that quietly assumes they match will produce a downtime chart that is confidently wrong. Then reason codes. This is where it usually stops being a demo and starts being a conversation, because the codes are half blank, the ones that are filled in are dominated by Other, and the codes themselves were chosen by whoever configured the system years before anybody knew what would actually break. Then joining the two systems. The count in one system and the count in another are different numbers for the same shift. Somebody in your plant knows why. Nobody has written it down, and living with both systems is usually cheaper than replacing either one. None of that appears in a tour. All of it appears in your first month of ownership. How to run the demo test This takes about an hour of the vendor’s time and maybe half a day of yours. It is the cheapest due diligence available to you. Pick one line and one week. Not the best week. Choose a week with a bad shift in it, because the bad shift is the thing you bought the software to explain. Send what you have, not a cleaned file. The moment somebody on your side tidies the extract, you have hidden the exact problem you are paying to find. Blanks stay blank. Agree the handling terms in writing first. Where the extract lives, who can see it, how long it is kept, when it is destroyed. If that takes a vendor three days and two escalations to answer, note it. That is how they will handle everything else. Give them one real question. Something you could not answer last month without phoning someone at home. Why did lot 4471 ship late. Why does the second shift on that line run four percent slower every Thursday. Watch what happens when it does not work. It will not work cleanly. That is the point. The useful signal is what the engineer says next: a specific diagnosis and a specific fix, or a change of subject back to the sample plant. Ask for the work list at the end. Not a yes. A written list of what would have to be true for this to run on your data every day, who does each item, and roughly how long it takes. Most of what lands on that list is plant data integration work, and it is the part that never shows up in a demo. Run the same hour with every manufacturing analytics software vendor on your shortlist, with the same extract and the same question. You will learn more from the differences between those answers than from any feature comparison anyone sends you. What a fair demo test looks like A week of one line is a fair ask. A full plant history rebuilt inside five business days is not, and a vendor who promises it is either misunderstanding you or lying, and I would not want to find out which after signing. A demo that goes badly against your data is also not proof the software is bad. Sometimes it is proof your data is worse than anyone had admitted out loud, and that is worth knowing before you spend anything. I have watched a buying committee kill a project on the strength of one of these hours and spend the next quarter fixing their reason codes instead. That was the right call. They saved themselves a year of blaming the wrong thing. The worse sign is easy to miss. It is the vendor who takes your extract, comes back with a polished result, and cannot tell you which parts of it came from your file and which came from their sample. Ask that question directly. Watch who answers it comfortably. You are not buying a screen. You are buying a set of decisions about what your data means, and you will live with those decisions for the next several years: in the morning meeting, in the capital request, in the conversation where somebody says the number cannot be right. The demo is the one point in the process where you get to hear that argument before you have paid for it. Spend it on your own worst week. The maintenance planner who asked where the reason codes came from was not being difficult. She was doing the only real evaluation in the room. This week: Pick one line, one week that included a bad shift, and ask your shortlist to run their demo against that instead of their own sample plant.