Skip to content
Home » Proactive ERP Story: The Week Nothing Went Wrong

Proactive ERP Story: The Week Nothing Went Wrong

    Proactive ERP Story: The Week Nothing Went Wrong

    Two Rayas

    Nurul runs a family food business in Selangor that makes biscuits and festive cookies. For most of the year, the factory hums along at a comfortable pace. Then, about six weeks before Hari Raya, everything changes. Orders triple. Supermarkets, hampers companies and corporate buyers all want their tins of cookies at the same time. The ovens run late into the night, and the whole company holds its breath until the last lorry leaves.

    This is a story about two of those peak weeks, one year apart.

    In the first, almost everything that could go wrong did. In the second, nothing did. The products were the same. The people were the same. The factory, the ovens and the customers were the same. The only thing that changed was when the business found out about its problems.

    The week everything went wrong

    It started on a Monday with tins.

    The festive cookie tins, printed with that year's design, came from a single supplier with a three-week lead time. On Monday morning, Kumar, the production manager, went to the store for another pallet and found two cartons left. Mei, who handled purchasing, had been meaning to reorder. She had a note about it on her desk, under several other notes. The supplier could not deliver for eighteen days. Production of the best-selling line stopped while Mei begged, borrowed and paid a premium for plain tins from another supplier.

    On Tuesday, Farah in finance noticed that the company's largest hamper customer had placed another big order. The customer already had invoices more than sixty days overdue and was well over its credit limit. The order had been accepted by the sales team, produced and packed. Stopping it now meant an unhappy customer at the worst possible time. Letting it go meant more stock out the door with no idea when it would be paid for. Nurul let it go. The invoice was eventually paid, four months later.

    On Wednesday, the main tunnel oven broke down. A belt bearing that should have been replaced at the last scheduled service had been skipped, because the service had been postponed twice during a busy period and then forgotten. The technician came the next day. The factory lost a day and a half of production in the busiest week of the year.

    On Thursday, a supermarket returned several cartons of cookies because the remaining shelf life was shorter than their receiving policy allowed. The cartons had come from an older batch that should have been sold first. Nobody had noticed it sitting at the back of the store.

    And on Friday, while Nurul was trying to recover from all of the above, a letter reminded her that a key food safety certificate was due for renewal at the end of the month. The audit had to be booked, the documents prepared, and the whole thing squeezed into the busiest weeks of the year. It was done, but only just, and with everybody's nerves in tatters.

    By the following Monday, the business had survived. Customers mostly got their cookies. But Nurul sat in her office and asked the question every business owner eventually asks.

    "Every one of these problems was visible weeks ago. Why did we only find out when it was too late?"

    Last year: the week everything went wrong, with tins running out, a broken oven, a returned batch, an overdue order and a certificate due

    Why it kept happening

    The answer was uncomfortable, but simple. Nurul's business was entirely reactive.

    The information that would have prevented every problem already existed. The stock level of the tins was in the system. The customer's overdue invoices were in the accounts. The oven's service schedule was in a file. The batch dates were on the cartons. The certificate's expiry date was on the certificate.

    What did not exist was anything that looked at that information at the right moment and told the right person to act. Everyone was busy doing their jobs. Checking was something people did when they remembered, and in peak season nobody had time to remember.

    So problems were discovered the way they usually are in a reactive business: when they hurt. The tins ran out, the oven broke, the cartons came back. The business was always responding, never preventing.

    The pain points behind the story

    None of Nurul's people were careless. The business simply had no way of acting before things went wrong.

    Thresholds lived in people's heads. Everyone knew roughly when the tins should be reordered, but there was no rule that said "when stock falls below this level, purchasing must act." Reordering depended on someone noticing.

    Sales did not see finance. The sales team could accept an order without knowing that the customer was over its limit or seriously overdue. Finance found out after the goods had been made.

    Dates were scattered and passive. Service schedules, certificate expiries, batch dates and contract renewals were recorded in different places. A date written down is not a reminder. Nothing told anyone that a date was approaching.

    Nothing escalated. When a task was postponed, like the oven service, there was no deadline and no one above to notice that it had slipped again and again.

    Peak season made everything worse. The weeks when the business was most exposed were exactly the weeks when people had the least time to check.

    What it was really costing

    The direct costs were easy to count: premium-priced replacement tins, a day and a half of lost production, a returned delivery, emergency repair charges and an invoice that took four months to collect.

    The indirect costs were bigger. Overtime to catch up. Customers who received late or incomplete orders in the one season that mattered most to them. A management team that spent the most important week of the year firefighting instead of selling. And a constant, low-level anxiety that something else was about to go wrong, because nobody could see far enough ahead to be sure it would not.

    Why the obvious fixes fell short

    After that week, Nurul tried several things.

    She asked Mei to set reminders on her phone for reorders. It helped, until Mei went on leave and the reminders went with her.

    She asked Farah to send the sales team a list of customers on credit hold every Monday. The list was out of date by Wednesday, and nobody checked it before accepting an urgent order on a Friday afternoon.

    She started a weekly operations meeting to review stock, maintenance and orders. It was useful, but a weekly meeting only catches problems once a week, and it depended on people bringing the right information to the table.

    Each fix relied on a person remembering to look. What Nurul needed was for the business to look for itself.

    How APES made the business proactive

    Nurul came to Appnicorn with a clear request: "I don't want more reports telling me what went wrong. I want to know before it goes wrong, and I want the right person to deal with it."

    The Appnicorn team started with the five things that had gone wrong in that terrible week and turned each one into a rule in APES. Every rule followed the same simple pattern. When something happens, if a condition is true, then the system takes an action and gives it to a named person, and if that person does not act in time, the work moves up.

    How a proactive rule works in APES: when, if, then, if late, using a packaging reorder example

    Packaging stock. When stock of a packaging item falls below its reorder level, APES creates a reorder task for purchasing, with the supplier's lead time shown. If the purchase order is not raised within two working days, the task escalates to Nurul. In the run-up to Raya, the reorder levels for festive tins are set higher, because Nurul knows the season is coming.

    Customer credit. When a sales order is entered for a customer who is over their credit limit or has invoices overdue beyond the agreed period, APES holds the order and sends it to Farah for a decision before anything is produced. She can release it, ask for payment first or reduce the order, and her decision is recorded.

    Machine maintenance. Each oven and key machine has its service schedule in APES. A service task is created ahead of the due date and assigned to Kumar. A service can be postponed once, with a reason. If it is postponed again or becomes overdue, it is escalated to Nurul.

    Batch shelf life. Every finished batch is recorded in APES with its production and expiry dates. When stock is picked for an order, APES directs the oldest suitable batch first. Batches approaching the shortest shelf life that customers accept are flagged to the sales team, so they can be sold or used in time.

    Certificates and renewals. Food safety certificates, licences and key contracts are recorded with their expiry dates. APES creates a renewal task months in advance, with reminders as the date approaches and escalation if nothing has happened.

    None of these rules needed APES to predict the future. They simply made sure that the company's own rules were applied at the right moment, every time, for everyone. Each task arrived with the information needed to act, each decision was recorded, and every step was kept in a tamper-evident audit trail.

    AI inside APES helps too. Each morning, it summarises everything that needs attention that day, so Nurul and her managers can see at a glance what is waiting, for whom and for how long. It prepares the picture. People make the decisions.

    The week nothing went wrong

    A year later, the Raya rush arrived on schedule. Here is how that same week looked.

    Three weeks earlier, packaging stock for the festive tins had dropped below its seasonal reorder level. APES created a task for Mei. She raised the purchase order the same afternoon. The tins arrived the week before peak production.

    On Monday, a sales order came in from the same hamper customer. APES held it, because two invoices were overdue. Farah called the customer, who paid the older invoice that week. She released the order with a note. Nobody had to stop a lorry.

    On Tuesday, nothing happened with the oven. That was the point. Its service had been done a month before, when APES assigned the task to Kumar. He tried to postpone it once during a busy week, and APES asked him for a reason and a new date. The technician replaced the bearing then.

    On Wednesday, a batch of cookies from earlier in the season was flagged as approaching the shelf life limit for supermarket customers. The sales team offered it to a hamper customer, whose requirements were different, and it was sold within days.

    On Thursday, Nurul glanced at the certificate renewal. The audit had been booked two months earlier, when APES created the renewal task. The documents were ready. It was not even a topic of conversation.

    And on Friday, Nurul did something she had not done in the peak week for years. She left the office at six.

    Same week, one year apart: problems found too late last year versus caught early by rules in APES this year

    What changed for Nurul's team

    This part of the story is illustrative, but it shows the kind of change a business can expect.

    Mei no longer keeps a pile of notes on her desk. Reorders reach her when they are needed, with the information she needs to act. Farah makes credit decisions before goods are produced, not after they have shipped. Kumar's maintenance schedule runs itself, and he can no longer postpone a service indefinitely by accident. The sales team knows which batches need to move. And Nurul spends the peak season talking to customers instead of chasing problems.

    The most striking thing about the second week was how boring it was. No emergencies, no late nights, no heroic recoveries. That is what a proactive business looks like from the inside. Problems do not disappear. They are simply found, and handled, while they are still small.

    Is this your business?

    You do not have to make cookies to recognise Nurul's first week. Ask yourself a few questions.

    When did you last run out of something you knew you would need? Can your sales team accept an order from a customer who is over their credit limit? Are your service schedules, certificate expiries and contract renewals in one place, and does anything remind you before they are due? When a task is postponed, does anyone notice the second time? And in your busiest season, who is checking all of this?

    If the honest answer is "someone, when they remember," then your business is running reactively, however good your people are.

    Turn your next busy season into a quiet one

    APES (said "A-pes") is a custom ERP made by Appnicorn, a Malaysian IT company with years of experience building business systems. Every module in APES is customised to your company's unique needs, and your own rules are built into the work itself: checks, reminders, escalations and flags that act before problems cost you money.

    Requests and tasks go to the right people with deadlines and escalation, documents are numbered under control, and every step is kept in a tamper-evident audit trail. Each business gets its own workspace, so stock, orders, maintenance, finance and compliance sit in one place. If the module you need does not exist yet, Appnicorn designs and builds it with you.

    Pricing depends on the process being built, so the best first step is a conversation. Tell us about the worst week your business had last year, and we will show you which rules would have caught it.

    Talk to our team about making your business proactive.