Business Management Portal

This page describes a representative operations portal. The client is not named. We do not claim a measured saving. The work was an ASP.NET Core system for production, inventory, and orders, built because the factory was running the same facts in more than one spreadsheet.

The situation

Production wrote the day's output in one sheet. Stores wrote receipts in another. Orders lived in a third, usually as a workbook that had been copied forward from last month. Each sheet was right about the thing its owner typed. None of them was the place another department could trust in the afternoon. A customer asking "where is my order" got an answer that depended on who picked up the phone.

The company did not need a public website. Staff needed a login, a short list of today's jobs, and a stock figure that did not change because someone sorted a column and saved. Email was already how they sent files. Email was a bad database.

What we took on

The portal is ASP.NET Core with SQL Server. We chose that because the next person to maintain it should be able to find the rules in the code, and because the data had to survive a bad edit. A spreadsheet does not give you that. A page builder would have hidden the rules inside a plugin.

The first release covered three jobs only: record production against a work order, receive material against a purchase, and see an order with its current stock. We did not start with a dashboard of charts. A chart of bad data is still bad data, and it takes longer to argue with.

We sat with the person who actually typed the sheet, not only with the owner. The field names on the screen match the words they already use. A work order has a status they can say out loud. Stock movements are lines, not a single number someone overwrites. If yesterday's figure was wrong, the correction is a new line, so the history stays. Permissions follow the job: production does not edit a receipt, and sales does not close a works order.

What shipped

Staff sign in. The home screen is the work that is open, not a menu of every module we might build later. Production can close a job. Stores can book a receipt. Sales can open an order and see whether the material is in the building. Exports exist for the accountant, because the books did not move in this release.

The old spreadsheets were not deleted on day one. For a short overlap, the portal and the sheet were both filled, and the differences were listed. When the differences were explainable, the sheet stopped being the source. We would rather run two systems for a few weeks than discover a missing column after the sheet is gone.

What we refused

We did not replace the accounting package. We did not build a customer login. We did not add a mobile app for the shop floor until the desktop flow was the one people opened on Monday. An app that repeats a broken process just moves the argument onto a smaller screen.

What a similar project needs from you

The real spreadsheets, including the messy ones. One owner for production, one for stores, and one person who can say which column is the truth when they disagree. A list of who may see cost and who may not. If that is the problem you have, read the .NET development page. If the sheets are really a finance system in disguise, the better fit may be an ERP, and we will say so before we start.