Hi everyone,
I’m developing RitsuFlow™, a platform for construction companies that started as a production planning tool and is growing into the company’s whole operating system. I’d like to share how three of its core modules connect and hear where you think it will hold or break.
The rule behind it: one project model, built once from the contract, that every department reads from. The project is registered from the signed contract, the scope is written line by line with its contract value, the drawings are divided into locations (floors, areas, rooms), and every task is quantified per location. Planning, the field and procurement all work from that same model.
PLANNING
Planning is location-based and runs at three levels:
- Master plan: locations in production order × work packages. The sequence can be set by hand or generated, and quantities and money are spread over the master plan dates, so the plan also shows production and value over time.
- Lookahead: the next weeks of work, where constraints are identified and removed before the work arrives.
- Weekly plan: the team commits to work whose constraints are cleared, and at the end of the week each commitment gets a result, recorded as PPC (Percent Plan Complete).
Constraints are central. Each one has a required-by date and actions with owners and due dates. A constraint is first resolved and then verified, so “someone said it’s done” isn’t enough to release the work. Constraints raised by procurement (materials, equipment, labor) appear here too, so the weekly meeting reviews everything that could stop the work, not only what the planner wrote down.
OPERATIONS
The field works from the plan, not from a separate list:
- The activities on site are the planned tasks.
- The daily report records production by location, then goes through submission, review and, where the project requires it, approval by someone other than the person who wrote it.
- Deliveries are received on site against the purchase orders, so what arrived is checked against what was bought.
- Approved change orders update the contract value, and every change is kept in the project history.
That closes the loop: actual production by location goes back to planning, and receiving goes back to procurement.
PROCUREMENT
Procurement is pulled by the lookahead, not by habit or the purchasing calendar:
- When a task with pending materials enters the lookahead and nothing covers it yet, it becomes a need, with an order-by date worked backward from the date the material is needed.
- Each need goes to an RFP with at least three proposals, then an award approved by the project manager, then a purchase order or subcontract.
- Until the item is contracted or delivered, it stays open as a constraint in planning, so the planner and the buyer see the same risk.
- Rentals are tracked against the work too: when the task using the equipment finishes early, the system flags it for off-hire.
- Committed cost is compared with the budget per cost category, with a warning before the budget is reached.
WHAT’S NEXT
We’re now designing an “office” layer on top of this. Each person gets a desk showing only what needs their action that day (constraints and the weekly plan for the planner, daily reports for the field engineer, RFPs and late deliveries for the buyer, approvals for the project manager). It’s the same data, filtered by role.
Where I’d like your input:
- Should the lookahead drive procurement, or does that make purchasing too dependent on planning discipline?
- Have you tracked constraints through “resolved” and “verified” separately? Was the extra step worth it?
- What would you need to see on your own “desk” every morning to trust a system like this?
Thanks in advance. I’ll reply to every comment.
Eduardo F. Freitas
