After our vehicle routing app for HoppyFully Brewing Co., the next question was whether the same approach would carry over to a different business problem, and how much faster the second app would come together. The Factory Optimization Planner answers a classic production-planning question: three facilities (North Carolina, Texas, and California), seventeen products, and a known demand for each. Today, every product is tied to one facility. The model behind the app, a SAS program using the PROC OPTMODEL, lets any facility make any product within its capacity and picks the mix that maximizes margin. The app is the front door: multiple users at the same time can run different business scenarios and simulate their results without interfering in each other’s simulations. They can change facility costs and capacities, run the model, and compare the result with the current plan.
Starting from a pattern, not a blank page
The vehicle routing problem project left behind a documented pattern. The app is hosted inside Viya’s own Files Service, on the same origin the browser already trusts, with its stylesheet and script kept in separate files to satisfy Viya’s strict content security policy, and all SAS work runs through the Compute service’s REST API. That pattern is now a reusable skill with a starter command in Claude Code, so this project went straight to the business problem.
Claude connects to Viya through the Model Context Protocol (MCP). It can inspect CAS tables, submit SAS code, deploy the app’s files, and download them back to verify every byte. The rule stayed the same: Claude shows the exact code and the reasoning, and nothing runs in Viya until a person approves it. The architecture is the same presented in the previous blog (link above).
What the planner shows
The page reads top to bottom like a planning conversation. It opens with demand: 17 products, 416,727 units, $33.3 million in revenue, and $15.5 million in product cost, charted by facility. Next comes current production. Today’s facility cost factor of 1.25 adds 25% on top of unit cost, which brings total cost to $19.4 million and leaves a $13.9 million margin. Current capacities are 70,000 units in North Carolina, 160,000 in Texas, and 200,000 in California. Below that, the planner enters a new facility cost and capacity for each site and clicks “Run optimization.”
The model, explained on the page
The page now explains the model itself. A panel beside the planner says in plain words what the model decides: how many units of each product every facility makes, so that all demand is met with the highest margin. It lists what the model weighs (product demand, unit price, unit cost and the facility cost factor) and the limits it respects (meets all demand, facility capacity, whole units), and shows the formulation: maximize revenue minus production cost, subject to those limits. Because all demand is met, revenue is fixed, so the gain comes from making each product where it costs least. Four numbered steps say how to use the planner. A planner can see what the model does before running it, and an optimization specialist can check the formulation immediately.
Data in, model out
Saving the form sends a short SAS program that carries the three facility rows as inline DATALINES into a FACILITYDATA table in the user’s own CASUSER library. The shared inputs, product demand and current cost, live in the Public caslib, so colleagues who open the same link start from the same baseline while their scenarios stay private.
Running the optimization uses %include to run the existing SAS optimization program from the file share, unchanged; the app reimplements no modeling logic. The program writes FACTORY_SOLUTION (units by facility and product) and FACILITY_REVENUE_SOLUTION (revenue and cost by facility). The solver status comes from the &_OROPTMODEL_ macro variable, so the app can tell an optimal solution apart from an infeasible one.
Getting results back to the browser
Results come back the same way as in the routing app: SAS writes each row to the job log as a tagged line (PLANROW:, REVROW:, SOLSTATUS:), and the browser parses those lines. Six headline tiles lead the results. The two margin-gain tiles, in dollars and in percent, sit in dark navy so the answer stands out. Below the tiles, a table shows revenue, cost, and capacity used by facility, and a chart of units by product makes any split across facilities obvious.
A scenario in about ten seconds
Take one scenario: North Carolina at a cost factor of 1.1 with 120,000 units of capacity, Texas at 1.3 with 180,000, and California at 1.5 with 150,000. The run took about 12 seconds and returned an optimal plan. Margin rose from $13,919,401 to $14,187,032, a gain of $267,631, or 1.9%. North Carolina and Texas run at full capacity, and California at 77.8%.
The interesting part is how the plan gets there. Product1 is now split between Texas and California, and Product2 between North Carolina and Texas. Letting facilities share products is exactly what the current fixed assignment rules out, and that flexibility produces the gain. With each run taking seconds, a planner can work through many what-ifs in one sitting.
The bigger point
The second app came together way faster because the first one left a pattern behind. Lessons such as dropping a CAS table from both scopes before reloading it or keeping a shared SAS logo in SAS Content so the security policy allows it, went back into the shared standards. Any existing SAS model can get a lightweight scenario tool this way, hosted entirely inside Viya and built through a conversation, with a person steering and approving every change.
