Wednesday morning marked the beginning of Alpine’s parallel testing phase. Sarah arrived early, coffee in hand, to find both the whiteboard and her computer displaying the scheduling software. For the next several days, she would maintain both—using the whiteboard for actual production decisions while generating parallel schedules in the software to compare results and build confidence.
Stefan had arrived even earlier and had already loaded the scheduling software with current production orders. “Morning, Sarah. Ready to run your first real schedule?”
“As ready as I’ll ever be,” Sarah replied, studying the whiteboard covered with magnetic strips representing today’s work and the coming weeks’ pipeline.
Stefan walked her through the morning routine. “Each morning at 5 AM, the software auto-generates an updated schedule based on yesterday’s completions. But for testing, we’ll run it manually so you can see the process. Click here.”
Sarah clicked the “Generate Schedule” button. The software processed all scheduling data for thirty-five seconds, then displayed a resource-centric Gantt chart showing the next four months of work across all work and machine centers.
“Now compare it to your whiteboard,” Stefan suggested.
Sarah spent the next twenty minutes doing exactly that—checking individual jobs, verifying machine assignments, reviewing sequences. Some matches were perfect. Others showed differences that required investigation.
“This bearing housing job,” Sarah said, pointing at the software screen. “You have it on Mazak #2 starting today. My whiteboard shows Mazak #5 starting tomorrow. Why the difference?”
Stefan drilled into the details. “The software scheduled it ASAP with available capacity. Mazak #2 has an opening today, so it went there.”
“But Otto and I agreed yesterday to hold Mazak #2 for a rush order that might come in,” Sarah explained. “That’s not in the software anywhere.”
Stefan made a note. “Exactly the kind of thing we’ll discover during testing. How should the software know about reserved capacity?”
Sarah thought about it. “I don’t know. On the whiteboard, I just remember. But software can’t remember verbal conversations.”
“Right. So, you need a process,” Stefan said. “A way to formally reserve capacity that both you and the software understand. Production scheduling process design isn’t about the software—it’s about systematizing the tribal knowledge that currently exists only in conversations and individual judgment”
The Production Scheduling Process Gap Revealed
By noon, Sarah had identified seventeen differences between her whiteboard and the software schedule. Some were simple—the software didn’t know about a machine that had gone down for maintenance that morning. Others were complex—business rules she applied intuitively but had never articulated explicitly.
Klaus joined the afternoon session to review the findings. “Seventeen differences in one morning? That’s concerning.”
“Actually, it’s expected,” Stefan replied. “The software implements the rules you configured. When reality differs from those rules, you get differences. In that regard, each difference is an opportunity to either improve your configuration or improve your processes.
Likewise, the software is able to consider more subtle things that you might have overlooked with the whiteboard. Hence, in that regard, a difference might also indicate areas where you will improve by using the software. Over the next few weeks, you will have a lot of those cases: you will gain scheduling quality by using the software, and no longer the whiteboard.
During that time, we just need to spot those differences, understand the reasons, categorize them, and define actions.”
He pulled Sarah’s list. “Let’s categorize these. Some are data issues—the downed machine and incorrect routing. We can fix those in Business Central. But others are process issues—reserved capacity, verbal agreements, business context that exists only in conversations. Those require systematic processes.”
Sarah studied the list with fresh eyes. “You’re right. About half of these are things I do that aren’t documented anywhere. I just… do them.”
“Like what?” Emma asked, having joined to check on progress.
“Like this one,” Sarah pointed. “I scheduled the Hoffmann coupling job after the Brenner housing because I know Hoffmann couples often have quality issues from our supplier. I want them to run when Schmidt is available because he’s best at catching problems early. But that preference isn’t in the system anywhere.”
“So, it’s tribal knowledge,” Emma observed.
“Exactly,” Stefan confirmed. “And tribal knowledge doesn’t scale. When Sarah’s on vacation, does anyone else know how to match Hoffmann couplings with Schmidt? Or does quality suffer until she returns?”
The question hung in the air, unanswered.
The Rush Order Challenge
Thursday afternoon brought the test everyone had been dreading—a real rush order that needed to crash the schedule.
Klaus appeared at Sarah’s desk, slightly out of breath. “Brenner Industries just called. They need an additional bearing housing order delivered by Monday. Fifty units. It’s critical for their production line.”
This was familiar territory. Sarah’s old process was simple: panic, juggle, figure it out somehow. She turned to the whiteboard and started mentally shifting magnetic strips.
“Wait,” Stefan said. “This is perfect for testing. Let’s handle it through the software and see what happens.”
Sarah felt her anxiety spike. “But this is real. If we mess it up—”
“We won’t mess it up,” Stefan assured her. “We’ll use the software to analyze options, but you make the final decision. Just like we configured.”
He pulled up the rush order workflow they’d discussed during configuration. “First step: create the production order in Business Central with rush priority. Patrick, can you do that?”
Patrick quickly created the order in Business Central with Monday as the due date, categorized it as ‘business critical’ using functionality from the scheduling software, and released the production order.
“Now generate a new schedule,” Stefan instructed Sarah. “The software will try to fit the rush order and show you the impacts.”
Sarah clicked the generate button. Twelve seconds later, a new schedule appeared—with the rush order highlighted in bright orange and several other jobs shifted later.
“The software placed the rush order, with a finish date on Friday afternoon,” Stefan explained, “but four other jobs got delayed. See here—these two orders now finish on Tuesday instead of Monday. This one slips from Wednesday to Thursday. And this one moves from Thursday to Friday.”
“Show me those customer names,” Sarah said, leaning closer.
Stefan displayed the customer information. “Kemper, Steinbach, Müller GmbH, and Richter AG.”
Sarah pulled up her customer notes. “Kemper has a hard date—can’t move. Steinbach is flexible. Müller usually is flexible, but let me check…” She made a phone call, asked a few questions, and hung up. “Müller can wait until Thursday. Richter AG has slack in their schedule.”
“So the Kemper job can’t move,” Sarah concluded. “The software needs to find another way to fit the rush order. We basically have a conflict between Kemper and the new rush job, with Kemper being more important”. She looked at Emma, who nodded in agreement.
Stefan showed her how to move the Kemper job back to its initial position, lock it, and then regenerate the schedule to handle the new rush order. The new schedule moved the rush order to finish on Monday morning by making intelligent use of alternative machines centers by selecting Mazak #5 instead of Mazak #2.
“Better,” Sarah said. “The Kemper job stays on schedule. The others shift but within acceptable limits. I can work with this. Klaus: Would Brenner be OK if we finish their rush order on Monday morning and ship immediately with an express delivery?”
Klaus, who had been watching the entire process smiled: “Yes, of course. I wanted to challenge the software and see what it gives us. The true required delivery date is Tuesday. So, all is good.”
The team laughed and, for the first time, realized how well they were on track to reach their scheduling goals. Then Klaus interrupted the laughter: “By the way, how long did that handling of the rush order take?”
Sarah checked the clock. “About four minutes from when you told me about the rush order to have a workable solution.”
“How long would it have taken with the whiteboard?”
Sarah laughed ruefully. “Twenty minutes at least. Probably thirty. And I wouldn’t have been sure I’d found the best solution—just the first solution that seemed workable.”
The Missing Workflow
Friday morning brought a different revelation. Otto called Sarah at 9 AM with a common scenario: the external heat treatment shop had called to say they’d completed a batch of components and would deliver them this afternoon instead of Monday as originally scheduled.
“Great news,” Sarah said. “That means we can start the finishing operations sooner.”
“Right,” Otto confirmed. “But which jobs should I prioritize? I have three jobs that need finishing, and I can only do one this afternoon.”
On the whiteboard, Sarah would have made a quick judgment call based on delivery dates and customer importance. But now, with Stefan watching and note-taking, she realized this scenario exposed another process gap.
“Let me think through the decision criteria,” Sarah said, putting Otto on speaker. “First, check delivery dates. Which job is due soonest?”
“Steinbach order is due Wednesday, Agrar-Tech is due Thursday, Richter is due Friday,” Otto replied.
“Okay, so Steinbach has priority by date. But how much work remains after finishing? If Steinbach only needs finishing while Agrar-Tech needs finishing plus assembly, maybe we do Agrar-Tech first to avoid it becoming the bottleneck.”
“I don’t know that off the top of my head,” Otto admitted.
Sarah pulled up the routings in Business Central. “Steinbach needs finishing and final inspection—about three hours total. Agrar-Tech needs finishing, sub-assembly, final assembly, and testing—maybe eight hours total downstream work.”
“So do Agrar-Tech first?” Otto asked.
“Probably,” Sarah said. “But let me check customer priority…” She reviewed her notes. “Actually, Steinbach is Brenner’s supplier. Everything for Brenner’s supply chain is a high priority. So, despite less downstream work, Steinbach should go first.”
After she hung up, Stefan looked at his notes. “That decision took seven minutes and required you to check three different information sources: delivery dates, remaining work, and customer relationships. Every time heat treatment delivers early—which you said happens two or three times a week—someone needs to make that same multi-step decision.”
“You’re saying we need a standard process for it,” Sarah realized.
“I’m saying you have a process—it’s just in your head,” Stefan replied. “We need to make it explicit so anyone can follow it consistently.”
He pulled up a blank document. “Let’s design the workflow. When heat treatment delivers early, who gets notified? Who checks delivery dates? Who checks the downstream work? Who knows the customer priorities? Who makes the final decision? And how does that decision get communicated to the shop floor?”
By the end of the hour, they’d mapped a workflow that involved Otto receiving the notification, Sarah checking priorities through a decision tree, and then updating the schedule in the software. It wasn’t complicated, but it was explicit—something anyone could follow.
“How many other scenarios like this exist?” Emma asked, having observed the discussion.
“Dozens,” Sarah admitted. “Material arrives late. A machine breaks down. A customer changes an order. An operator calls in sick. Each one requires decisions, but we’ve never documented how to make those decisions systematically.”
The Authority Question
The next week’s Monday afternoon brought the conversation everyone had been avoiding: who has the authority to change schedules, and under what circumstances?
The trigger was simple. Otto had moved a job from Mazak #3 to Mazak #4 because #3 was making unusual noises, and he wanted to check it before running critical work. He’d made the change in the software as they’d trained him to do. But when Sarah generated a new schedule that afternoon, the software moved the job back to Mazak #3.
“Why did it undo my change?” Otto asked, frustrated.
“Because you didn’t flag it as manually scheduled,” Stefan explained. “When you moved the job, did you check the box that says ‘lock this assignment’?”
“No,” Otto admitted. “I didn’t know I needed to.”
“Without that flag, the automatic scheduling engine treats your assignment as temporary,” Stefan said. “It recalculates based on the information in your Business Central master data. That means that the operation will get placed again on the machine center that is defined in the routing.
In this case, this is why it was moved back to Mazak #3. By the way: if you work with alternative work and machine centers, it will move the operation to one of the work/machine centers that is allowed for that job and can finish it at the earliest.”
Otto looked at the schedule with growing concern. “So every time someone runs the schedule, it might undo changes I made?”
“Unless you lock them,” Stefan confirmed.
“But then what’s the point of the software?” Otto asked. “If I have to manually lock everything, we might as well use the whiteboard.”
This was the crux of the authority question, and everyone in the room knew it.
Emma stepped in. “Let me reframe this. The software applies rules consistently. Otto applies judgment for exceptions. The question is: when should Otto’s judgment override the software’s rules, and how do we make sure those overrides don’t create chaos?”
Stefan nodded. “That’s exactly right. I recommend a clear authority hierarchy: the software schedules everything automatically every morning. Sarah reviews the schedule and makes strategic adjustments such as changing priorities, moving rush orders, and resolving conflicts. Those adjustments get locked. During the day, if Otto or other supervisors need to make tactical changes for operational reasons—like a machine acting up—they can make them and lock them. But they should notify Sarah so she’s aware.”
“And if Sarah disagrees with Otto’s change?” Klaus asked.
“Then we have a conversation,” Emma said firmly. “But the default is trust. Otto has twenty-five years of shop floor experience. If he says a job should move, we trust that judgment unless there’s a specific business reason not to.”
Sarah felt the weight of this new responsibility. She’d been the sole decision-maker for scheduling for three years. Now she was becoming a coordinator of multiple decision-makers, each with their own domain of authority.
“I’m okay with this,” Sarah said. “But we need clear rules. Otto can move jobs for operational reasons—machine issues, operator availability, or quality concerns. He locks those changes and sends me a quick note explaining why. I’ll review them but trust his judgment unless I see a conflict with customer commitments or business priorities.”
“Let me add one thing”, said Henning, who had joined the meeting remotely to see how they were progressing. “You also should find a consensus on the type and timeframe of the changes that Otto makes. What do I mean by this?
Well, with type, I refer to manual versus automatic changes to the schedule. Given that Otto runs the shop floor operationally, I suggest that he will do manual schedules only. The power of the automatic scheduling engine should be with Sarah and Klaus, as this matches with their area of responsibility.”
“I can happily live with this”, confirmed Otto. “I actually would be scared to trigger all those sophisticated calculations. But you mentioned two things that we should align on. Type and … .“
”Timeframe”, answered Henning. “With this, I mean that we also should look at your manual changes in terms of the timeframe that they get applied to. The more manual changes you make, the more implicit restrictions you set for the automatic scheduling engine. Ultimately, if you schedule everything manually, you are back to the whiteboard scheduling – just with a different interface.
Hence, I recommend that you look at manual adjustments as a tool to manage production orders for which you need to override all rules of your scheduling. Typically, the need to do so arises on very short notice and applies to jobs that are close to hitting the shop floor. Having said this, my clear recommendation is that you do manual changes only and solely within the frozen zone we defined before. Anything that goes beyond the frozen zone has an impact on Sarah’s work and hence should require her approval.”
“This sounds like great advice,” Emma nodded. “Otto, are you OK with this?”
“Of course. I am all in. The more we look at and agree on clear processes, the better for all of us,” was Otto’s dry response.
“What about supervisors below Otto?” Schulz asked. “Can I make schedule changes for my area?”
“Assembly scheduling is less complex,” Sarah replied. “You can make changes within your area—which assembler handles which job. But I suggest you apply the same principles to your area: scope and timeframe. Plus, if you need to change the timing of work coming from machining, coordinate with Otto and me first.”
They spent the next hour documenting the authority protocols: who could change what, under what circumstances, how to lock changes, and how to communicate them. It wasn’t complicated, but it was explicit—removing ambiguity that had existed for years.
The Reducing Buffer Principle
Tuesday morning, the team met again, and Sarah came up with an issue: “I reviewed the schedule very early this morning with Otto already. We compared actual data from the shop floor and updated the schedule to reflect the reality.”
“Excellent”, Stefan said. “I truly like how you start to establish processes and routines.”
“Yes and no”, Sarah answered and grinned. “I understand that the routines are of great value. However, right now, they just throw up too many questions at a time. When Otto and I did the exercise this morning, we recognized that we had to make a lot of changes to the schedule, as our execution was consistently behind schedule. We analyzed the reasons and concluded that in many cases our routings were just way too optimistic when it comes to timings.”
“Well, this does not surprise me”, Stefan replied. “Remember the data quality work that we did even before we started to configure the scheduling software? Remember that Emma concluded that work with confirming that you guys will go into a continuous improvement process when it comes to data quality?”
“Yes, of course,” Sarah said while shaking her head a bit impatiently. “But this is not what I wanted to refer to. We know that we have data quality issues. However, we still schedule based on this data. And it seems that it creates a too optimistic schedule, which in turn creates constant friction between Otto’s team and me. How to handle this?”
Henning raised his hand, looking at the team from the screen: “This is a common situation that I have been experiencing with many clients of your type. I am glad that you brought this up, Sarah. My recommendation is that you tackle this issue early in the process.”
“What do you mean?” Sarah, still impatiently, interrupted him.
“Well, you must acknowledge that you have data quality issues, which you will fix over time. This is a marathon, not a sprint. If you acknowledge this, you should take this insight into account when you make your very initial delivery time commitments to your clients.”
“Ah,” Sarah nodded. “I see where you are heading. You want us to add a kind of safety buffer to the delivery times that we communicate. If the software tells us that we can deliver in 20 days, you recommend that we add some more days to that prediction”.
“You nailed it,” was Henning’s direct answer. “That way, you add realism to your schedule. I also recommend that you start with a sufficiently large buffer. You then can make it smaller and smaller the more you advance with your continuous data quality improvements.”
Sarah jumped up and made a ‘high five’ gesture towards Henning. “This is exactly the advice that I was looking for. Stefan, can we implement a buffer in your software?”
“This is not needed”, was Stefan’s prompt reply. “What we are agreeing here is adding human sense to the software’s dependence on the ERP data landscape.”
The Communication Protocol
Wednesday afternoon brought another process gap into sharp focus: how to communicate schedule changes to customers and suppliers.
Klaus had received a call from Müller GmbH asking for confirmation of their delivery date. He looked at the schedule and told them “Wednesday next week.” But when Sarah generated an updated schedule that afternoon, the Müller job had slipped to Thursday due to a material delay.
Klaus called Sarah, irritated. “I just told Müller Wednesday. Now you’re saying Thursday? They’re going to think we’re incompetent.”
“The material delay came in after you checked the schedule,” Sarah explained. “The purchasing system flagged a two-day delay on a critical component. The schedule adjusted automatically.”
“So how am I supposed to give customers reliable dates if the schedule keeps changing?” Klaus demanded.
Stefan intervened. “This is a common challenge. Let’s design a process. Klaus, when do you typically need to confirm delivery dates to customers?”
“Usually when they place orders—two to three months in advance,” Klaus replied. “Sometimes they ask for updates as we get closer to delivery.”
“Okay,” Stefan said. “For orders two to three months out, the schedule is predictive but not locked. Things will change as new orders arrive and priorities shift. So you should communicate dates as ‘currently scheduled for week of…’ rather than specific days.”
“And closer in?” Klaus asked.
“Within the frozen zone—the next few days—dates should be solid,” Stefan replied. “Those jobs are already in execution. They won’t move unless something breaks. So you can commit to specific dates confidently.”
“What about the middle zone?” Klaus pressed. “One to two weeks out. Not frozen, but not distant future.”
Sarah thought about this. “Those should be ‘expect to ship…’ dates. Likely but not guaranteed. If something changes, we communicate immediately rather than letting the customer discover the delay.”
Emma joined the discussion. “Who’s responsible for proactive communication? If we see a job slipping, who calls the customer?”
“Klaus for major customers,” Sarah suggested. “Supervisors for routine updates. But we need a daily report showing any jobs that slipped more than a day since yesterday’s schedule. That becomes our action list for customer communication.”
Stefan configured the software to generate exactly that report—a daily “schedule change alert” listing any jobs that moved more than 24 hours. Klaus would receive it each morning and could immediately reach out to affected customers.
“This is what I mean by process over software,” Stefan said. “The software can show you what changed. But humans need to decide what to communicate, to whom, and how. That’s process design, not software configuration.”
The MRP Integration Handoff
Thursday’s discovery came from Patrick. He’d been working on the integration between Business Central’s MRP functionality and the finite capacity scheduler, and he’d found a significant gap.
“The MRP planning worksheet generates manufacturing requisitions based on customer orders and inventory targets,” Patrick explained to the team. “But it calculates infinite capacity—it doesn’t know about our machine and operator constraints.”
“So?” Klaus asked.
“So MRP might suggest we start ten jobs next week, but the scheduler says we only have capacity for six,” Patrick continued. “We need a process for reconciling what MRP wants with what scheduling says is feasible.”
Stefan nodded. “This is a classic integration challenge. MRP does demand planning—what needs to be made. Scheduling does capacity planning—what can be made. You need a workflow that connects them.”
Klaus thought about their current practice. “Right now, I look at MRP recommendations once a week. I mentally filter out what’s unrealistic based on capacity, and then I let the system create production orders for what we can actually do. But it’s not systematic.”
“Let’s make it systematic,” Emma decided.
They spent two hours designing the MRP-to-Scheduling workflow:
- MRP runs Sunday night, generating and updating planned production orders for the next 4 months
- Monday morning, Klaus to review the planned production orders and convert them into firm planned production orders
- Tuesday morning, the scheduler loads those orders, adds them to the already scheduled orders, and generates a capacity-based schedule
- Orders that fit within capacity within an “extended MRP frozen zone” of 8 weeks would get flagged so that MRP would no longer touch and change them
- Orders that don’t fit generate a “capacity conflict report”
- Sarah reviews the conflict report and decides: delay the order, expedite other work to make room, or escalate to Emma for capacity investment decisions
“This handoff is critical,” Stefan emphasized. “MRP creates demand. Scheduling validates feasibility. Humans resolve conflicts. Each stage has clear inputs, outputs, and decision authority. And just to complete this, and reconfirm on what we aligned already before:
- Purchasing to run the requisition worksheet on Wednesday morning – once we have realistic demand dates for all purchase components. Realistic = based on a finite capacity schedule
Patrick began documenting the integration workflow, noting system settings, automation triggers, and manual review steps.
The Sarah Realization
Friday afternoon, Sarah sat alone in the conference room reviewing the week’s process development work. The whiteboards around the room were covered with workflow diagrams, decision trees, and responsibility matrices they’d created:
- Rush order handling process
- Early material delivery prioritization
- Schedule change authority protocols
- Customer communication procedures
- MRP-to-scheduling integration handoffs
- Manual override documentation requirements
She’d come into the week thinking they were testing software. Instead, they’d been designing an entire operating system—the processes, protocols, and decision frameworks that would govern how Alpine made daily production decisions.
Stefan found her there. “What are you thinking?”
“That I’ve been doing this job wrong for three years,” Sarah admitted.
“How so?”
“I thought my job was to make good scheduling decisions,” Sarah explained. “Move jobs efficiently, meet delivery dates, keep the shop floor running. But really, my job should have been to design the system by which those decisions get made.”
“That’s a profound insight,” Stefan said, sitting down across from her. “You’re transitioning from being a tactical scheduler to being a strategic process architect. From making decisions to designing how decisions should be made.”
“It feels bigger than scheduling,” Sarah said. “These processes we’ve designed the past few days—they’re about coordination, communication, authority, accountability. They’re about how the whole organization works together, with scheduling as just one piece.”
“That’s exactly right,” Stefan confirmed. “The software doesn’t solve scheduling problems. It reveals coordination problems, forces them into the open, and provides tools to address them systematically. But the actual solving requires human processes.”
Emma appeared in the doorway. “Status check?”
“We’re not ready to go live on Monday,” Sarah said.
Emma looked concerned. “Why not?”
“Because we’ve built software configuration but not operational processes,” Sarah explained. “We know how the scheduler works. But we haven’t trained the full team on the workflows we designed this week. We haven’t tested the handoffs. We haven’t practiced the new communication protocols.”
“How much more time do you need?” Emma asked.
Sarah looked at Stefan. “Another week? Run these workflows with real scenarios, train the broader team, practice the new processes alongside the whiteboard?”
“That’s wise,” Stefan agreed. “The software is ready. Your organization needs another week to be ready for the software.”
Emma nodded slowly. “Okay. One more week of parallel operation and process training. Then we go live the following Monday. But Sarah, I want you to lead the process training. This is your design. You need to own it.”
After Emma left, Sarah sat quietly processing this evolution. She’d started Alpine’s scheduling journey thinking they needed better software. She’d spent months evaluating features, comparing algorithms, and analyzing capabilities.
But the real transformation wasn’t about software at all. It was about transforming from individual heroics to systematic processes. From tribal knowledge to documented workflows. From reactive firefighting to proactive coordination.
The software was just the tool that forced them to design those processes explicitly. Process over software. That was the real lesson.
The Weekend Reflection
Saturday evening, Sarah sat with Tom and Miguel watching Tom’s football game. Tom’s team had won 2-1, and Tom had played well in midfield—not scoring but controlling the game with smart passes and good positioning.
“You played differently today,” Sarah observed as they walked to the car.
“Coach changed our system,” Tom explained. “Before, everyone tended to run wherever the ball was, and everyone wanted to be a striker. Now we have positions and responsibilities. I stay in midfield and connect defense to attack. It’s more organized.”
“Do you like it better?” Miguel asked.
“Yeah,” Tom said. “Before, I was always chasing the ball and getting tired. Now I know my job. It’s actually easier because I’m not trying to do everything.”
Sarah glanced at Miguel, who smiled knowingly.
“That sounds like your week at work,” Miguel observed later, after Tom had gone to bed.
“It does,” Sarah agreed. “We’ve been chasing the ball—everyone trying to do everything, reacting to wherever the crisis appeared. Now we’re designing positions and responsibilities. Clear roles, clear processes.”
“Is it easier?” Miguel asked.
“Not yet,” Sarah admitted. “Right now, it’s harder because we’re learning the new system while still running the old one. But once we learn it…” She paused, thinking about the process diagrams covering the conference room whiteboards. “Once we learn it, yes. It will be easier because people will know their roles.”
“When do you actually switch?” Miguel asked.
“Another week of practice,” Sarah replied. “Then we go live. The whiteboard becomes a backup, and the software becomes our primary tool.”
“Nervous?” Miguel asked.
“Terrified,” Sarah admitted. “But also excited. We’re not just changing software. We’re changing how we work as a company. That’s much bigger than I expected when this started.”
“Good scared or bad scared?” Miguel pressed.
Sarah thought about it. “Good scared. The kind where you know you’re attempting something important and challenging but necessary. Like learning to ride a bike—scary but worth it.”
Miguel kissed her forehead. “Tom learned to ride his bike by starting with training wheels. Maybe that’s what this past week was—process training wheels before you actually ride.”
Sarah laughed. “That’s actually a perfect analogy. We’ve been practicing with the whiteboard still there as backup. Next week, the training wheels come off.”
She looked at her phone, reviewing notes from the week. Rush order workflow. Communication protocols. Authority matrices. MRP integration. Each one represented a process that had previously existed only in conversations and individual judgment, now documented and systematic.
The software hadn’t solved their scheduling problems. But it had forced them to solve their coordination problems, their communication problems, their authority problems. It had forced them to become a more systematic organization.
That transformation, Sarah realized, was far more valuable than any scheduling algorithm. The software would be outdated in five years. But the processes they’d designed—the discipline of systematic decision-making, clear authority, documented workflows—those would serve Alpine for longer.
Monday, they would continue their process training. The following Monday, they would go live, replacing the whiteboard with the software as their primary scheduling tool.
But the real go-live had already happened this week. They’d gone live with a new way of working—systematic, documented, and designed. The software was just the visible symbol of that bigger change.
Process over software. That was the transformation. And it had only just begun.
