The following Monday morning, the team reconvened with Stefan and Andrea to begin configuring the scheduling software. Sarah arrived with her notes from the previous week’s data cleanup, ready to translate Alpine’s business rules into software logic.
Stefan pulled up the configuration interface on the large screen. “We have two, maximum days to configure the scheduler before moving to testing and training. These three days include explaining, discussing, and understanding the options so that you can manage them on your own once you use the software productively. Today, we’ll tackle the foundational rules—how you want the system to prioritize work and handle conflicts, and how you want to handle capacity planning. Let’s start with the questions I posed last week.”
He pulled up his list. “How will you prioritize production orders? How will you handle rush jobs? Will you allow them to crash the schedule? How will you deal with already scheduled jobs versus to-be-scheduled jobs? How well are you mentally prepared to leave idle times in your non-bottleneck machine centers? What rules matter most?”
Sarah looked at the list, feeling slightly overwhelmed. “That’s a lot of decisions.”
“We’ll take them one at a time,” Stefan assured her. “And most have obvious answers once you think about your current practice. Let’s start simple: how do you prioritize production orders today?”
The Easy Wins
Sarah thought about her whiteboard process. “I prioritize by delivery date. Jobs due soonest get scheduled first.”
“Always?” Stefan asked. “No exceptions?”
“Well, customer-specific exceptions,” Sarah admitted. “Some customers are more important than others. Brenner Industries gets priority over smaller customers if there’s a conflict. And Emma sometimes tells me a specific order is critical for business reasons.”
Stefan nodded, typing configuration notes. “So you have a hierarchy: delivery date is primary, but customer priority and business criticality can override. That’s common and easy to configure.”
He pulled up the scheduling rules interface. “The software supports priority codes on production orders. We can set up three levels: Standard, Important Customer, Business Critical. Within each level, delivery date determines sequence. Sound right?”
“That matches how I work now,” Sarah confirmed.
Klaus raised his hand. “Who assigns these priority codes? We can’t have everyone marking their orders as business critical.”
“Good question,” Emma said. “Sarah assigns Standard or Important Customer based on the customer. I’m the only one who can mark something Business Critical, and I’ll do that sparingly.”
Stefan configured the priority rules accordingly. “First decision made. That was easy. Now, let’s add more beef to it. What do you if two jobs have the same due date and have the same priority code?”
Sarah nodded. “This is a tough situation, and with the Whiteboard, we applied a pragmatic ‘first come, first serve’ approach. What is your view on this?”
“We actually have an option that we should make use of in these cases”, Stefan said.
“For each production order, we calculate a figure that we call ‘Scheduling Slack Time’ or ‘SST’. This is the time between the currently planned end date and the due date. You can look at this time as a buffer. The lower the SST is, the smaller the buffer is for that production order and hence the higher the risk that the production order will run late. Hence, I suggest that you prioritize by SST – at least if you have production orders with the same due date.”
“This is a great approach”, Klaus said. “Can we even apply it for the entire schedule? That way the scheduling will minimize the risk of us being late.”
“You can”, Stefan confirmed. “However, I recommend that you start using the SST initially just for the mentioned purpose. That way, you do not change too much compared to how you work today. You will gain experience with the SST and its pros and cons and might extend its usage once you are familiar with it and are ready for a full change.”
“I like this pragmatism. Let’s do it and move on”, Emma added.
Stefan smiled and took over again: “Next question: already scheduled versus to-be-scheduled jobs. How do you handle that on your whiteboard?”
Sarah walked to the whiteboard still hanging on the conference room wall. “Once I’ve scheduled something and communicated the concrete sequence to the shop floor, I try not to change the sequence unless absolutely necessary. With our average throughput time, this leads to a kind of 3-day frozen period. Moving already-scheduled work creates confusion and wastes setup time.”
“So, your preference within that frozen period is schedule stability for somehow released and already sequenced production orders over better throughput?” Stefan clarified.
“Yes,” Sarah confirmed. “I’d rather have a good stable schedule than keep chasing a perfect but constantly changing one.”
Stefan smiled. “That’s refreshing. Most companies don’t realize how much cost and disruption comes from schedule instability. The software can enforce this. Once a job is released to the shop floor, it becomes ‘frozen’ in the schedule unless you explicitly unfreeze it.”
He configured the stability rules. “Jobs in ‘firm planned’ and ‘planned’ status can be rescheduled freely by the software. Jobs in ‘released’ status are frozen—the software schedules around them rather than moving them. Only users with special permission can unfreeze released jobs.”
“Who gets that permission?” Patrick asked.
“Sarah and Emma,” Stefan suggested. “Anyone else and you’ll have chaos. The same should also be true for squeezing priority and business-critical jobs into the frozen period. The software will never do this. But we will give Sarah and Emma a manual tool to facilitate an exception if needed.”
“Agreed,” Emma said.
Three decisions made in fifteen minutes. Sarah felt her confidence growing. These weren’t complicated theoretical questions—they were practical rules she already followed.
Capacity Planning Reality: Accepted Idle Times
Stefan moved to the next topic. “This one is trickier. I sense that you aligned on it before, but I must make sure we are still aligned. You are comfortable that are you leaving idle time on non-bottleneck machines.”
Klaus immediately looked concerned. “Why would we leave machines idle? That’s wasted capacity.”
“Is it?” Stefan asked. “Henning, you want to explain this one?”
Henning’s face appeared on the video screen. “Remember our discussion about throughput versus efficiency? If precision machining isn’t your bottleneck, running those machines at 100% utilization doesn’t increase your throughput because it does not contribute to processing the sales order backlog. It just creates more work-in-process inventory.”
“But idle machines mean we’re paying operators to stand around,” Klaus protested.
“That is a misleading way to phrase it,” Henning objected. “You are paying your operators a fixed salary, regardless of what they do and how they do it. Hence, the costs of having your operators do not play a dominant role in that decision process. In addition …”
Otto nodded and interrupted Henning. “Klaus, in addition, our operators don’t stand around when machines are idle. They do preventive maintenance, help with setups, organize tooling, and support quality checks. There’s always productive work to do, which is not necessarily mirrored in the ERP or scheduling data.”
“The question,” Stefan clarified, “is whether the scheduling software should try to fill every minute of every machine’s time, or whether it should focus on delivery dates and to complete the production orders in the shortest possible time This approach will result in a schedule that has gaps on certain machine or work centers, and these gaps are to be accepted.”
“That’s the right approach for a job shop,” Henning confirmed. “The software will be configured to prioritize as we discussed earlier. The logical consequence of this prioritization will be idle time on non-bottlenecks. It sounds wasteful, but it actually is a result of focusing on the goal of finishing production orders in due course.”
Emma made the decision. “I understand why we will have idle time on non-bottlenecks, and I am totally fine with it. We’re striving for delivery performance and flexibility, not machine utilization metrics.”
Stefan gave a thumbs up and concluded: “Fourth decision made. You’re doing well.”
The Rush Job Question
“Now the harder one,” Stefan said. “Rush jobs. How do you handle them today?”
Sarah grimaced. “They crash the schedule. Customer calls with an urgent need, Emma or Klaus tells me it has to happen, and I rejuggle everything to fit it in.”
“How often does this happen?” Stefan asked.
“Maybe twice a week,” Sarah estimated. “Some weeks more, some weeks less.”
“And what’s the impact on the existing schedule?”
“Chaos,” Sarah admitted. “Jobs get delayed, operators get confused, we work overtime to catch up. But we do it because the customer is important or the order is valuable.”
Stefan leaned back. “So, rush jobs are disruptive but necessary for your business. The software can handle this in three ways: One, allow rush jobs to crash the schedule automatically. Two, flag rush jobs, but make Sarah manually decide how to accommodate them. Three, refuse rush jobs that would cause delivery delays on existing commitments.”
“Option three isn’t realistic,” Klaus said immediately. “We can’t tell important customers no.”
“Option one sounds scary,” Sarah added. “Automatic schedule crashing could create cascading problems I don’t see until it’s too late.”
“That leaves option two,” Emma observed. “Rush jobs flag for Sarah’s attention, and she decides how to handle them.”
Stefan nodded. “That’s the most common approach. When someone marks a production order as ‘rush,’ the system alerts Sarah. She can see what’s currently scheduled, what would be delayed if she accommodates the rush job, and make an informed decision.”
“Can the software show me scenarios?” Sarah asked. “Like, if I crash this rush job in, what gets pushed and by how much?”
“Yes,” Stefan confirmed. “It can calculate the impact before you commit. You can test different options—maybe the rush job fits better on Thursday than Tuesday, or maybe you split it across two machines to minimize disruption.”
Sarah felt relief. “That’s what I need. Not automatic decisions, but better visibility into consequences. Also, following what we discussed before, I might need to squeeze a rush job into the frozen period. Please confirm that this will work.”
Stefan configured the rush job handling. “Rush jobs alert Sarah. She evaluates impact and decides whether and how to accommodate them. And yes, you will be able to manually squeeze a rush job into the frozen period. Fifth decision made.”
The Alternate Resource Question
Stefan pulled up the next configuration screen. “Now we need to define your resources. You have six CNC machines in precision machining, plus some special machines, plus manual work centers for assembly, quality control, and finishing. How does the software know which resources can handle which jobs?”
“The routings specify that,” Patrick said. “Each operation shows the work center.”
“Right, but what about alternative resources?” Stefan asked. “If Mazak #2 is down, can the job run on a different machine?”
“Sometimes,” Otto said. “It depends on the job and the machine capabilities.”
Stefan pulled up an example routing. “This bearing housing operation shows Mazak #2 as the primary machine center. Are there alternatives?”
Otto studied the routing. “Mazak #1 could run it—we have similar tooling. Mazak #3 probably couldn’t because the part’s too large for its work envelope.”
“So you have partial interchangeability,” Stefan observed. “Some machines can substitute for each other, others can’t.”
“Correct,” Otto confirmed.
Stefan clicked through more routings. “And agricultural components? The setup debate discussion mentioned these run primarily on Mazak #3 and Mazak #4.”
“That’s our subgrouping strategy,” Otto explained. “We try to route similar work to the same machines to minimize setup complexity. But if #3 and #4 are overloaded, we can use #5 or #7 as backup.”
“This is important for scheduling,” Stefan said. “The software needs to know which machines are preferred versus which are merely capable. Otherwise, it might schedule agricultural work on bearing housing machines unnecessarily.”
Patrick was already pulling up machine and work center definitions in Business Central. “Business Central allows defining alternative work centers. However, I heard that this function is rather rudimentary and hence we were advised not to use it. Also, there is nothing like an alternative machine center function in Business Central. And as we set up our CNC machines as machine centers, we would need it there.”
“Never mind”, Stefan answered. “Our software enhances Business Central’s data model, and we allow first defining alternate work and centers and then second using them for scheduling. I suggest that we decide to use this functionality and that we set up a separate meeting with Otto, Sarah, Patrick, and me to work on defining all alternatives. Then we set them up properly. This is nothing where we would need the entire team for.”
“Agreed. Decision six done,” Emma confirmed. “It matches how we actually operate.”
Sarah was making notes when Stefan asked his next question: “What about operators? Does it matter who runs these operations?”
The room went quiet.
The Man/Machine Realization
“What do you mean?” Sarah asked slowly.
Stefan pulled up a precision machining operation. “This routing says the operation takes 90 minutes on Mazak #2. But does it take 90 minutes regardless of who’s operating the machine? Or does the operator make a difference?”
Otto’s expression changed. “The operator makes a significant difference.”
“How much difference?” Stefan pressed.
Otto thought carefully. “Schmidt can run a bearing housing operation in 90 minutes. Weber might take 100 minutes because he’s less experienced with those parts. Hoffmann might take 85 minutes because he’s been running them for fifteen years and knows every trick.”
“So, the routing time is an average?” Stefan asked.
“It’s an estimate based on whoever typically runs that operation,” Otto replied.
Klaus looked puzzled. “Why does this matter? We schedule the machines, not the operators.”
Stefan turned to face Klaus directly. “Do you? Let me ask you this: can Mazak #2 run without an operator?”
“Yes and no,” Klaus said and smiled.
“What do you mean?”, Stefan asked.
“Well, Otto knows all the details. However, we primarily need the operators to set up the CNC machines and to be with the machine for the first few minutes of operation. Once the machine is running, they walk the floor to another machine for the next setup. That way, the machine needs the operator for the start, but not for the production itself.”
“So, when you schedule Mazak #2 for 8 hours of which 90 minutes is setup, you’re implicitly also scheduling an operator for 90 plus a few minutes,” Stefan continued. “The question is: do you have enough operators? And does it matter which operator you assign?”
Sarah felt something clicking into place. “We’ve been scheduling machines on the whiteboard. But machines aren’t the only constraint.”
“Exactly,” Stefan confirmed. “In many manufacturing environments, especially job shops, the limiting factor isn’t always and solely machine capacity—it’s skilled operators who can run those machines effectively.”
Otto was nodding vigorously. “This is why we scramble sometimes, even when machines are available. I might have three machines idle, but only two operators available who can set up and run the work that’s queued up.”
“Can’t any operator work on any machine?” Klaus asked.
“No,” Otto replied firmly. “Schmidt is certified on all the Mazak machines and can run complex setups. Weber is certified on Mazak #1 to #3 only, and he’s still learning. Müller is great on Mazak #5 and #7 for finishing work, but hasn’t been trained on rough machining. Hoffmann is our agricultural component expert—he can run #3 and #4 better than anyone, but he’s not familiar with bearing housings.”
Sarah stared at her whiteboard. “I’ve been scheduling machines for years without explicitly tracking who would operate them.”
“How do you handle it?” Stefan asked.
“I assume Otto will figure it out,” Sarah admitted. “When I schedule work on Mazak #2, I trust Otto to assign the right operator.”
“And I do,” Otto confirmed. “But sometimes I can’t. Sometimes the work Sarah scheduled requires Schmidt, but I’ve already assigned Schmidt to Mazak #5 because that job needed his expertise. So I have to move things around or call Sarah to reschedule.”
The Dual-Resource Constraint
Henning spoke up from the video screen. “What you’re discovering is that you have a dual-resource constraint problem. You need both a capable machine and a qualified operator, especially during the setup time. The whiteboard could only show machine scheduling, so the operator constraint remained invisible—handled manually by Otto.”
“Can the scheduling software handle both?” Emma asked.
“It can,” Stefan confirmed, “but it requires configuration. We need to define operators as resources, map their skills and certifications, and configure the software to consider both machine and operator availability when scheduling.”
He pulled up a new configuration screen showing resource types. “Instead of just scheduling machines, we’d schedule machine-operator combinations. The software would know that Mazak #2 can run bearing housings, and that Schmidt, Weber, or Hoffmann are qualified operators for that work. It would only schedule the operation if both the machine and a qualified operator are available.”
Klaus looked concerned. “This sounds complicated. How much more complex does our configuration become?”
“It’s another layer of complexity,” Stefan admitted. “But ignoring it means your schedules won’t reflect reality. The software might schedule eight hours of work on Mazak #2, but if you don’t have sufficient qualified operator capacity to set things up, the schedule fails.”
Sarah thought about her weekend scheduling marathons. “This is one of the things I do implicitly. When I schedule work, I’m thinking about whether we have people available to run it. But I never made it explicit because the whiteboard had no way to track operators.”
“Exactly,” Henning said. “The whiteboard forced you to manage operator constraints manually. The scheduling software can make that visible and systematic—if you configure it properly.”
The Skill Matrix Challenge
“How do we define operator skills?” Patrick asked. “Do we need a complete skill matrix showing every operator and every operation they can perform?”
“Ideally, yes,” Stefan replied. “But we can start simpler. Let’s focus on the CNC machines since that’s your primary scheduling challenge. Which operators can run which machines?”
Otto pulled out a notepad and started writing. “Schmidt: certified on all Mazak machines, our most versatile operator. Weber: certified on Mazak #1, #2, and #3, but still developing expertise. Müller: excellent on Mazak #5 and #7 for precision finishing. Hoffmann: specialist on Mazak #3 and #4 for agricultural components. Then we have Richter from assembly: he can work as backup operator and can run #1 and #2 under supervision.”
“Four operators and one backup for six machines,” Klaus noted.
“That’s why we run at 80% capacity utilization,” Otto replied. “We have six machines but only four qualified operators, and not all operators can run all machines. The machines aren’t the bottleneck—the operators are.”
Sarah felt like she’d been missing a fundamental piece of the puzzle for years. “How did I not see this?”
“Because the whiteboard couldn’t show it,” Otto said gently. “You scheduled machines, and I made the operator assignments work. It’s been invisible to you, but it’s been my primary daily challenge.”
Stefan pulled up a skill matrix template. “Let’s build this systematically. We’ll create an operator resource for each person, then map which machines they’re certified for. The scheduling software will ensure we don’t schedule more work than we have qualified operators to handle.”
The Cross-Training Reality
Emma studied Otto’s operator list. “OK, now I finally understand why we have been running in unexpected problems each time that Schmidt was enjoying his well-deserved vacation.”
“Yes. This has been a constant struggle,” Otto admitted. “It always made us work overtime because Weber and the others can cover some of his work, but not all of it.”
“This is a business risk,” Emma said. “We need to cross-train more operators to reduce our dependency on specific people.”
“I’ve been saying that for two years,” Otto replied. “But cross-training takes time. Schmidt has to spend time teaching instead of producing, and the trainee produces more slowly while learning. Short-term, it costs us capacity. Long-term, it gives us flexibility.”
Klaus pulled up Alpine’s P&L. “What’s the impact of this operator constraint on our throughput? If we’re limited by operator availability rather than machine capacity, are we leaving money on the table?”
“Probably,” Otto said. “But not as much as you’d think. Yes, we have machines sitting idle sometimes because we lack qualified operators. But rushing operator assignments creates quality issues, which costs us more than the idle time.”
Sarah was thinking about scheduling implications. “If the software knows operator constraints, it can show us where cross-training would have the most impact. If Müller learned agricultural components, he could back up Hoffmann on Mazak #3 and #4. If Weber got fully certified on precision work, he could back up Schmidt.”
“And the software could show scheduling scenarios,” Stefan added. “What if Müller were certified on Mazak #3? How much would that improve schedule flexibility and reduce overtime?”
Emma made a decision. “Configure the skill matrix for our current operator qualifications. But also give us the ability to model future certifications. I want to see which cross-training investments would have the biggest scheduling impact.”
The Configuration Complexity
By mid-afternoon, they’d built the first basic operator skill matrix:
CNC Operator Skills:
- Schmidt: Mazak #1, #2, #3, #4, #5, #7 (all machines)
- Weber: Mazak #1, #2, #3 (developing)
- Müller: Mazak #5, #7 (precision finishing specialist)
- Hoffmann: Mazak #3, #4 (agricultural component specialist)
- Richter: Mazak #1, #2 (supervised only)
Stefan configured the scheduling software to require both machine and operator availability. “Now when we schedule an operation on Mazak #3, the software will check: Is Mazak #3 available? Is a qualified operator available? Only if both conditions are true will it schedule the work.”
He ran a test schedule with Alpine’s current production orders. The result shocked everyone.
“According to this,” Stefan said, studying the output, “your bottleneck isn’t any machine. It’s Schmidt. He’s scheduled for 52 hours this week because he’s the only operator qualified for certain complex operations.”
Otto nodded grimly. “That matches reality. Schmidt works more overtime than anyone else because we need his expertise.”
“But the whiteboard never showed that,” Sarah said. “I’ve been thinking our bottleneck shifts between machines depending on the order mix. Really, it’s been Schmidt all along.”
“Not quite,” Henning clarified from the video screen. “Your bottleneck is the specific machine-operator combinations that only Schmidt can handle. It’s not Schmidt as a person—it’s Schmidt’s unique skill set relative to your production requirements.”
Klaus was staring at the schedule output. “This changes everything about how we think about capacity planning. We’ve been talking about buying additional machines. But what we really need is additional skilled operators.”
“Or cross-training existing operators,” Emma added. “Which is much cheaper than buying machines.”
The Assembly Work Center Discovery
Patrick had been quiet, but now he raised a question. “Stefan, we’ve focused on CNC operators. But what about lathe, drilling, custom engineering, assembly, and finishing? Especially the latter are manual work centers in our routings. Do we need operator skills for those, too? Or, let me phrase it differently: Do we have overlaps in manual work between these areas?”
Stefan pulled up an assembly routing. “Good questions. How many people work in assembly?”
“Ten full-time assemblers,” Otto replied. “Plus, two people who split time between assembly and final inspection.”
“Are they interchangeable?” Stefan asked. “Can any assembler handle any assembly work?”
Otto shook his head. “No. Jensen specializes in complex bearing housing assemblies—multiple precision fits, tight tolerances. Schulz handles agricultural component assemblies—larger parts, different tooling. The others do general assembly work.”
Sarah felt overwhelmed. “So, we have operator constraints in assembly too? It’s not just CNC work?”
“It’s everywhere skilled labor is required,” Otto confirmed. “Assembly, finishing, quality inspection, lathe, drill—all have operator specialization. I manage it by knowing who’s good at what and assigning work accordingly.”
“Which means Sarah’s schedules might be unrealistic there, too,” Klaus observed. “You might schedule four hours of assembly work, but if it requires Jensen and he’s already assigned to something else, the schedule fails.”
“And, coming back to Patrick’s initial question, it’s getting more complex,” Otto added. “Oftentimes, we need the engineer who worked on the custom engineering to monitor the assembly and to perform the testing. Also, for setting up some of our testing tools, we need help from some operators who typically work on machining. This is actually one of our secret sauces: our people are flexible and skilled.”
Stefan looked at the project timeline. “We need to make a decision. Do we configure operator skills for all work centers, or do we start with just CNC and expand later?”
Emma looked at the clock—they’d been configuring for six hours and had barely scratched the surface. “Start with CNC. That’s our primary constraint and highest complexity. We’ll add assembly, custom engineering, and finishing in phase two after we’ve learned how this works. Then we will also need to find a way to model those overlaps and flexible workers that Otto just explained. As long as we do not have this in the system, we will get a schedule that does not fully cope with our reality. I am fine with this for the sake of starting. But I am also glad that we have software that can grow with our requirements.”
“Agreed,” Stefan said. “We’ll configure the CNC skill matrix now. Assembly and finishing will use simple capacity calculations like you have today. Once you’re comfortable with CNC scheduling, we’ll add operator skills to the other work centers.”
The Evening Realization
As the meeting concluded, Sarah sat in the empty conference room, staring at the skill matrix on the screen. For years, she’d been scheduling machines while Otto invisibly managed operator assignments. The whiteboard had forced that division of labor—she could track machine availability but not operator skills.
Now the scheduling software would make operator constraints visible. That was powerful, but it also meant she needed to understand operator capabilities in a way she never had before. She couldn’t just schedule work on Mazak #3—she needed to know if Hoffmann or Schmidt or Weber would run it, and whether they were available.
Otto appeared in the doorway. “Long day.”
“Eye-opening day,” Sarah corrected. “I’ve been scheduling for three years without really understanding that operators can be the constraint also.”
“You scheduled machines,” Otto said. “That was your job. I assigned people to those machines. That was my job.”
“But now the software does both,” Sarah observed. “Which means I need to understand your job better.”
Otto sat down across from her. “The software can help, but it won’t replace judgment. Just because Schmidt is certified on Mazak #5 doesn’t mean I should assign him there if I know Müller is better at precision finishing. The software sees certifications. I see people—their strengths, their preferences, who’s having a good day versus who’s struggling.”
“So, we still need you making those assignments?” Sarah asked.
“Unless you want the software making purely technical decisions,” Otto replied. “Which might be efficient but won’t be optimal. People aren’t machines. They have bad days, personality conflicts, preferences, learning curves. The software can ensure we have a qualified person available. I make sure we have the right person doing the work.”
Sarah nodded slowly. “So, the skill matrix gives us a foundation—we won’t schedule impossible operator assignments. But you add the intelligence on top—matching specific people to specific work based on factors the software can’t see.”
“Exactly,” Otto confirmed. “The software makes your invisible constraints visible. But turning visible constraints into good decisions? That still requires human judgment.”
Patrick appeared with his laptop. “Sarah, Otto—I’ve been thinking about this skill matrix. It’s going to require maintenance. When we hire a new operator, someone needs to update their certifications. When Weber completes training on Mazak #5, someone needs to add that skill. Who owns this?”
“HR should own certifications,” Sarah suggested. “They track training records anyway.”
“But scheduling needs to know immediately when an operator’s skills change,” Patrick countered. “If Weber finishes Mazak #5 training on Tuesday, scheduling needs to know by Wednesday, not whenever HR updates their database.”
Otto thought about this. “I’ll know when Weber completes training. What if I have permission to update the skill matrix directly? HR can audit it quarterly to make sure it matches their certification records.”
“That works,” Patrick agreed. “You’re the operational owner, HR is the audit backstop.”
Stefan, overhearing the conversation, joined them. “This is exactly the kind of practical thinking you need. The skill matrix is powerful, but it’s also another data source that requires maintenance. Defining who owns it and how it stays current is critical.”
The Path Forward
Sarah looked at the configuration work remaining. They’d spent a full day and had barely completed the basic resource setup. Tomorrow they’d need to configure scheduling heuristics, priority rules, what-if scenarios, and the manual update protocol they’d defined last week.
But today’s work—the dual-resource realization—felt like the most important discovery of the entire implementation. For years, they’d been optimizing machine schedules while ignoring operator constraints. Now they could see both dimensions simultaneously.
“Tomorrow, we tackle the scheduling logic,” Stefan said. “How the software should sequence work, handle conflicts, respond to disruptions. But today’s foundation—understanding that you’re scheduling machine-operator pairs, not just machines—that changes everything about how the scheduler will work.”
Emma appeared, having finished a phone call. “How are we doing?”
“We’re doing well,” Sarah replied. “We discovered something fundamental: the whiteboard was hiding a crucial constraint. It wasn’t only machines. It can also be the required skilled operator.”
“And now the software can show us that?” Emma asked.
“The software can make it visible,” Otto clarified. “What we do with that visibility is still up to us.”
Emma nodded. “Good. Tomorrow, we teach it how to think. But tonight, go home. We’ve done enough thinking for one day.”
Sarah packed up her notes, her mind still processing the day’s revelations. The whiteboard had been a machine scheduler. The software would be a resource scheduler—machines and people together. That was more complex, but also more realistic. Reality, she was learning, was always more complex than the simplified models we created to manage it.
But complexity you could see and understand was better than complexity you ignored. The skill matrix wasn’t perfect—it didn’t capture Otto’s judgment about who should run what when. But it captured what they knew systematically, which was far better than keeping it entirely in Otto’s head.
Tomorrow they would continue building. But today, they’d laid a foundation that acknowledged a truth they’d been working around for years: machines don’t manufacture products. People using machines manufacture products. And scheduling only worked when you accounted for both.
