Nobody can say which project orders are ready to schedule without opening four systems first.
01
Lakemont supplies architectural finishes, doors and hardware, flooring, and prefabricated interior components to general contractors, property managers, schools, and healthcare facilities. Roughly 120 employees across three branches and a central warehouse.
Most revenue now comes from project based orders rather than counter sales. A project order is not one item shipping on one date. It is a package of materials, vendor lead times, customer approvals on finishes, and a delivery window tied to a construction schedule that moves.
02
Every morning the project coordination team has to answer one question: which orders can we schedule for delivery this week. There is no view that answers it.
The answer requires the ERP for stock and vendor commitments, the CRM for customer approval status, a shared spreadsheet the warehouse maintains for delivery capacity, and an email thread for whatever changed on site. A coordinator opens all four, per order, and forms a judgment. It takes most of the morning and the judgment is not consistent between coordinators.
When something is missed, it surfaces late: a truck is loaded for a site that is not ready, or a contractor calls about materials nobody flagged as blocked. Leadership sees the escalation but not the pattern behind it.
It has not been solved because everyone believes it is somebody else's system.
03
Design a system that turns fragmented ERP, CRM, and manual information into a single readiness view that tells a coordinator, per order, whether it can be scheduled, what is blocking it, and who owns the next action.
04
Before designing anything, these are the questions I would work through with the coordination team, purchasing, the warehouse, and account managers.
05
The friction here is between groups, not inside a tool.
| Group | What they need | What they are measured on |
|---|---|---|
| Project coordinators | One view that tells them what can move today | Delivery dates hit, escalations avoided |
| Purchasing | Vendor dates trusted and not re-asked five times a week | Cost, vendor performance, on time receipt |
| Warehouse | Stable staging plans that do not change after loading | Throughput, rework, labor hours |
| Account managers | Early warning before a contractor is surprised | Customer relationships, repeat business |
| Branch leadership | A pattern view, not a pile of individual escalations | Branch margin, service performance |
06
The symptom is a slow morning. The causes sit further upstream.
07
Every option here costs someone something. Naming that upfront is what makes adoption possible.
| Tradeoff | What it buys | What it costs |
|---|---|---|
| Enforce one source of truth for vendor dates | Coordinators stop re-verifying and second guessing | Purchasing has to maintain the ERP field with discipline they currently do not owe anyone |
| Standardize the definition of ready | Consistency between coordinators, and a measurable status | Experienced coordinators lose some discretion they currently use well |
| Automate the readiness calculation | Faster mornings, fewer missed blocks | False confidence if the underlying data is wrong, so data quality becomes visible and uncomfortable |
| Keep split delivery decisions manual | Preserves judgment where context matters | The view cannot fully answer the question on its own |
08
09
A readiness layer that reads from existing systems rather than replacing them.
10
Pilot with one branch and one product category for four weeks. Coordinators use both the new view and their current process in parallel, and every disagreement between them gets logged, because those disagreements are where the rules are wrong.
Purchasing has to agree to own the vendor date field before anything else starts. Without that, the readiness calculation inherits bad data and the tool loses credibility in week two.
Training is role based and short. Documented owners for the rules, the data dictionary, and the exception categories, with a quarterly review so definitions do not drift back apart.
11
Not outcomes claimed. Measures I would put in place before starting, so there is a baseline to compare against.
12
The part I would want to test hardest is the readiness rules themselves. It would be easy to write rules that are technically correct and practically useless because they flag things coordinators already know how to handle.
At larger scale, the governance question gets harder. One branch can keep definitions current through a quarterly review. Three branches with different vendor mixes need a clearer owner, and that is an organizational decision rather than a design one.
What designing this simulation clarified for me: the hard part is almost never the view. It is getting two departments to agree on what a single field means.
Portfolio confidentiality statement. All business scenarios, organizations, names, data, processes, and supporting materials shown in this portfolio are fictional and were created independently to demonstrate my approach to operations, systems improvement, project execution, organizational enablement, and cross-functional problem solving. No confidential, proprietary, or internal materials from current or former employers are included.