Two weeks after deciding to pursue integrated solutions, Emma called what she termed “decision day”—a full-day working session to synthesize everything they’d learned and make their final software selection. The conference room looked different this morning, with flip charts lining the walls, each documenting a different aspect of their evaluation journey.
Sarah arrived early to review her notes. They’d spent the past two weeks conducting detailed evaluations of three Business Central-native scheduling solutions. Each had strengths and weaknesses. Each had enthusiastic reference customers and impressive demonstrations. And each, Sarah had discovered, could probably work for Alpine if they committed to making it work.
“Ready for this?” Patrick asked, arriving with his laptop and a thick binder of technical documentation.
“As ready as I’ll be,” Sarah replied. “Though I keep second-guessing myself. What if we choose wrong?”
“Then we’ll figure it out and adjust,” Patrick said with surprising calm. “We’re not choosing between good and bad. We’re choosing between good and good, trying to pick which one fits us best.”
Emma entered with Klaus and Otto, followed shortly by Marcus and Henning on video call. The energy in the room was focused but not tense—everyone seemed to understand this was about synthesis rather than debate.
“Let’s start by acknowledging where we are,” Emma began. “We’ve spent two months evaluating scheduling software. We’ve learned more about our own operations than any software vendor could teach us. And now we need to make a decision and commit to it.”
She walked to a flip chart showing their evaluation timeline. “We’re not going back to the whiteboard. We’re not second-guessing our decision to pursue integrated solutions. Today is about choosing which specific solution to implement.”
The decision framework for the scheduling software evaluation
Klaus stood and walked to a clean flip chart. “Sarah and I worked on a decision framework for our scheduling software evaluation. It is based on everything we’ve learned. Not a feature matrix—we tried that, and it didn’t help. Instead, we identified eight criteria that actually matter for our situation.”
He wrote on the flip chart:
- Functionality – Does it solve our core scheduling problems?
- Integration – How well does it work with Business Central?
- Cost – Total cost of ownership over 3-5 years
- Implementation Time – How quickly can we see results?
- Usability – Will our team actually use it daily?
- Realism – Does it fit our SMB constraints?
- Adaptability – Can it grow with us?
- Support – Will we get first-hand support from the vendor?
“Notice what’s not on this list,” Klaus continued. “Optimization sophistication. Feature count. Vendor company size. Those things might matter in other contexts, but they’re not what matters for us.”
Sarah stood to explain the first criterion. “Functionality isn’t about having every possible feature. It’s about whether the solution solves our specific problems. We need scheduling software that helps us visualize the current order backlog, easily assign production orders to our finite capacities, test different scenarios quickly, and communicate schedules to the shop floor. If it does that well, we don’t need fifty other capabilities we’d never use.”
“Integration,” Patrick added, “is about more than technical connectivity. It’s about whether the solution feels like a natural extension of Business Central or like a separate system bolted on. Can our team work fluidly between scheduling and other BC functions, or do they need to switch context constantly?”
Klaus moved to cost. “We’re not looking at just licensing fees. We’re calculating the total cost of ownership—implementation, training, ongoing support, internal time to maintain and improve. Some solutions have lower subscription costs but higher implementation costs. Others are opposite.”
“Implementation time matters because we need results reasonably quickly,” Sarah explained. “Emma was clear after last quarter’s negative EBITDA—we can’t spend a year implementing before seeing benefits. We need to be scheduling better within two to three months, even if we continue improving over the following year.”
Otto spoke up from his corner. “Usability is whether normal people can actually use the thing. Not IT people, not consultants—the folks who schedule work and run machines every day. If it’s too complicated or too clever, it won’t get used.”
“Realism,” Klaus continued, “is about whether the solution acknowledges SMB constraints. We don’t have dedicated IT staff. We don’t have unlimited training time. We need solutions designed for companies like us, not enterprise manufacturers with massive support teams.”
“And adaptability,” Sarah added, “is about growth. We’re not going to stay at our current size forever. Emma wants to grow smartly. Will this solution scale with us, or will we outgrow it in three years and face this selection process again?”
“Last, but not least,” Emma finished, “we need to make sure that we get first-hand support from the people working at the vendor. We cannot afford to be forced to work through the partner, nor do I want us to use anonymous support forms. Scheduling is crucial for us, and I want to work with a vendor who understands this and does not hide behind procedures. They need to be as hands-on as we are.”
The evaluation results
Sarah projected a summary document showing their three finalists—she labeled them Solution A, Solution B, and Solution C to keep the focus on fit rather than vendor names.
“Solution A,” she began, “is the most sophisticated. Beautiful interface, powerful what-if analysis, impressive optimization capabilities. It scores highest on functionality and adaptability.”
She clicked to the next slide. “But it has the longest implementation timeline—four to six months before we could use it effectively. And several reference customers told us candidly that it has a steep learning curve. Their schedulers needed three months before they felt comfortable using it independently. In addition, the vendor only provides second-level support. All first-level support has to go to their certified partner, which is Marcus’ company. So, the good news is that we can get the software through Marcus, but the support issue is still there.”
“Solution B,” Patrick explained, “has the tightest Business Central integration. It’s built by a Microsoft Gold Partner who really understands BC’s manufacturing module. Implementation could be as quick as six weeks. Cost is the lowest of the three options.”
“Trade-offs?” Emma asked.
“Less sophisticated than Solution A,” Patrick admitted. “More manual scheduling, less automation. And it’s designed primarily for make-to-stock environments. Several features assume repetitive production patterns that don’t match our high-mix reality. Support-wise, their references are gold, and they work directly with clients.”
“Solution C,” Sarah said, “is what we’re calling the ‘balanced option.’ Not the most sophisticated, not the most integrated, not the cheapest. But it scores consistently well across all eight criteria.”
She pulled up reference customer feedback. “Customers describe it as ‘practical,’ ‘reliable,’ and ‘grows with you.’ Implementation typically takes two to three months. The learning curve is manageable. And it’s specifically designed for high-mix, low-volume manufacturers like us. The vendor lets the customer decide how to handle the support: we can choose if we want the support through Marcus’ company or direct from the vendor.”
Klaus displayed his cost analysis. “Over five years, Solution B is cheapest at approximately €50,000 total cost of ownership. Solution A is the most expensive at €175,000. Solution C is somewhat in the middle at €105,000.”
“That’s a significant range,” Emma observed.
“It is,” Klaus agreed. “But remember, we’re not just buying software. We’re investing in changing how we operate. The question isn’t which is cheapest, but which gives us the best return on investment.”
Henning’s perspective
Henning had been listening carefully from the video screen. Now he spoke up with the perspective they’d come to rely on.
“I want to share something I’ve observed working with dozens of manufacturers. The software matters, but it matters less than you think. What matters more is the implementation process, the change management, and the commitment to actually using the system differently than you work today.”
He pulled up a simple diagram. “I’ve seen companies succeed with mediocre software because they had excellent implementation discipline. And I’ve seen companies fail with excellent software because they underestimated the organizational change required.”
“What are you suggesting?” Emma asked.
“I’m suggesting that your real decision isn’t which software to buy,” Henning replied. “It’s which implementation approach gives you the best chance of success. And that depends on factors beyond the software itself.”
He clicked through several slides. “Solution A offers the most sophisticated capabilities, but do you have the capacity to implement it successfully? Solution B is quick and cheap, but will it actually solve your problems or just digitize your current chaos? Solution C is balanced, but is balanced what you need or just comfortable mediocrity?”
The room was quiet as people processed this reframe.
“Let me make this more concrete,” Henning continued. “Solution A requires four to six months of implementation with heavy vendor involvement. That means Marcus and the vendor’s consultants would essentially be running your scheduling transformation. You’d learn the software, but would you truly own the process?”
“Solution B can be implemented quickly, but several features you’d need aren’t in the current version—they’re on the roadmap. So you’d be betting on future development that might or might not match your timeline.”
“Solution C can be implemented in two to three months with moderate vendor support. You’d have more ownership of the process, but also more responsibility for making it work.”
Reality check
Otto raised his hand like a student in class. “Can I say something about the shop floor perspective?”
“Please,” Emma encouraged.
“I’ve been thinking about what happens day-to-day with each of these systems,” Otto said. “Solution A looks impressive in demos, but I watched the training videos. It would take weeks to train our supervisors to use it effectively. Meanwhile, production doesn’t stop for training.”
He stood and walked to the flip chart. “Solution B is simple, which I like. But when the vendor demonstrated how it handles job shop scheduling, I saw problems. It was 100% manual, and I cannot imagine how this could successfully help us to master our dynamic day-to-day business.
“And Solution C?” Sarah asked.
“Solution C feels like it was designed by someone who actually worked in a job shop,” Otto said. “The interface makes sense. The logic matches how we think. It was a mixture of manual and automated scheduling functions. I watched their training videos too—our supervisors could learn this in a week, maybe two.”
Patrick nodded. “I had a similar reaction from the technical side. Solution A has impressive technology, but it’s complex technology. When something breaks—and things always break—debugging would be challenging. Solution C uses straightforward logic that I can understand and troubleshoot.”
Klaus looked at his financial analysis again. “Can I add something about cost? When I calculated the total cost of ownership, I included implementation time but not the opportunity cost of being in implementation versus being operational. If Solution A takes six months before we’re scheduling effectively, that’s six more months of the problems we have today. What’s the cost of that?”
He pulled up a calculation. “Our current scheduling chaos costs us approximately €50,000 monthly in overtime, expedites, and penalty fees. If Solution C gets us operational three months sooner than Solution A, that’s €150,000 in avoided costs that don’t show up in the software comparison.”
The trade-off discussion
Emma studied the flip charts and analyses covering the walls. “I’m hearing that each solution represents different trade-offs. Help me understand them clearly.”
Sarah organized her thoughts. “Solution A trades implementation complexity and higher cost for maximum capability and futureproofing. If we want the most sophisticated scheduling possible and can afford the time and money, it’s the best long-term choice.”
“Solution B trades capability for simplicity and speed. If we want to improve quickly and cheaply, accepting that we might outgrow it or need to supplement it, it makes sense.”
“Solution C trades perfection for pragmatism. It won’t be the most sophisticated or the cheapest, but it fits our reality—our size, our constraints, our timelines, our capabilities.”
Klaus added his financial perspective. “Here’s another way to think about it. Solution A is like buying a sports car—impressive performance, but expensive to maintain and might be more than we need. Solution B is like buying a basic economy car—gets us from A to B cheaply but might not handle all the terrain we encounter. Solution C is like buying a reliable midsize car—not the fastest or cheapest, but dependable and appropriate for daily use.”
“I like that analogy,” Emma said. “But let me challenge it. Are we being too conservative by choosing the middle option? Should we stretch for the maximum capability?”
Marcus answered this time. “Emma, I’ve seen companies stretch for maximum capability and succeed when they have the resources to support it. But I’ve also seen companies stretch beyond their capacity and fail because they couldn’t successfully implement the sophisticated solution. The question is an honest assessment of your organizational readiness.”
“And?” Emma prompted.
“You have one IT person,” Marcus said, gesturing to Patrick. “Your production team is skilled but not IT-savvy. You need results within a few months, not a year. Your budget, while adequate, isn’t unlimited. In that context, stretching for maximum capability is risky.”
Henning added, “There’s also the question of what you need versus what sounds impressive. Solution A can do multi-objective optimization across hundreds of variables simultaneously. That’s technically impressive, but do you actually need that? Your core problem is visibility and coordination, not mathematical optimization. We aligned on this already weeks ago.”
The emerging consensus
Sarah looked around the room, reading body language and expressions. Everyone seemed to be converging toward the same conclusion, though nobody had said it explicitly yet.
“Can I test something?” she asked. “Show of hands—how many people think Solution C is probably our best choice?”
Every hand went up, including Emma’s.
“Interesting,” Sarah said. “So why haven’t we just said that?”
Klaus laughed. “Because it feels anticlimactic? We spent two months evaluating options, and we’re choosing the middle ground? That doesn’t feel very exciting or bold.”
“Or maybe,” Otto said, “it feels right, but we’re second-guessing ourselves because it’s not the ‘best’ option in absolute terms.”
Emma stood and walked to the whiteboard. “Let me tell you what I’m thinking. We’re not choosing the solution with the most features, the lowest price, or the fastest implementation. We’re choosing the solution that best fits our reality—our size, our capabilities, our constraints, our timeline.”
She wrote on the board: “Good Fit > Perfect Solution.”
“Solution C isn’t perfect,” Emma continued. “It won’t do everything Solution A can do. It won’t be as cheap as Solution B. But it’s the right fit for Alpine at this moment in our growth. And if we implement it well, it will solve the problems that are actually holding us back.”
“Are you sure?” Klaus asked. “This is a significant investment. What if we regret not choosing the more capable option?”
“We might,” Emma admitted. “But I’d rather regret choosing the option we could implement successfully than regret choosing the option we couldn’t. Success isn’t about having the best tool. It’s about using a good tool well.”
The decision
Emma looked at Henning on the video screen. “You’ve guided us through this process. What’s your recommendation?”
Henning smiled. “My recommendation is that you trust your own analysis. You’ve done the work. You understand your constraints. You’ve been honest about your capabilities. Your evaluation framework is sound, and your conclusion follows logically from it.”
He paused. “But I want to emphasize something. You’re not just buying software today. You’re committing to changing how you work. The software will enable that change, but it won’t force it. Your success depends on the discipline and effort you put into implementation and regular usage.”
“Tell us what that means practically,” Emma said.
“It means cleaning up your master data, even when it’s tedious,” Henning replied. “It means training your team thoroughly, even when production is busy. It means using the new system consistently, even when it’s tempting to fall back to the old whiteboard. It means giving yourselves permission to struggle at first while you learn.”
He looked directly at the camera. “Solution C is a good choice for you. But it’s only as good as your commitment to making it work.”
Emma nodded slowly. “Understood. Sarah, you’re confident this is the right choice?”
“I am,” Sarah said. “It’s not the most exciting choice, but it’s the most realistic one. We can implement it successfully, our team can learn it, and it solves our core problems. That’s what matters.”
“Patrick, any technical concerns?”
“None that I can’t handle,” Patrick replied. “The integration is solid, the architecture is sound, and I understand how it works. When we hit issues—and we will—I’m confident I can troubleshoot them.”
“Otto, will it work on the shop floor?”
“Better than what we have now,” Otto said. “I showed the demo videos to Schmidt and Weber. They both said it made sense. That’s about the best endorsement I can give.”
“Klaus, final financial check?”
“The ROI is solid,” Klaus confirmed. “If we achieve even half the delivery improvement we’re targeting, the system pays for itself in eighteen months. If we achieve our full goals, it pays for itself in under a year.”
Emma looked around the room one more time. “Then we have a decision. We’re implementing Solution C.”
The contract signing
The vendor joined via video call thirty minutes later. Their sales director, Andrea, and their implementation manager, Stefan, appeared, both looking professionally enthusiastic.
“We’re pleased to inform you,” Emma said formally, “that Alpine Precision Components has selected your solution for our production scheduling needs.”
Andrea smiled broadly. “We’re honored to be selected, Emma. We won’t let you down.”
“I’m counting on that,” Emma replied. “But let’s be clear about expectations. I’m signing this contract with the understanding that implementation will take two to three months, that your team will be actively involved throughout, that you’ll help us with the organizational change aspects, not just the technical implementation, and that you will provide first-level support to us.”
“Absolutely,” Stefan confirmed. “Our implementation methodology includes change management support, comprehensive training, and hands-on guidance during the first few weeks of live operation.”
Emma pulled out the contract they’d been reviewing. “I’m also noting our success criteria explicitly. Within three months, we expect to be using your system for daily scheduling decisions. Within six months, we expect measurable improvement in on-time delivery performance. Within nine months, we expect reduced overtime costs and fewer expediting crises.”
“Those are reasonable expectations,” Andrea said. “Our other customers typically see those results within similar timeframes.”
Emma signed the contract, then Patrick added his signature as the IT contact. Sarah watched the formal commitment happen, feeling a mixture of relief, excitement, and anxiety.
“What’s our next step?” Sarah asked Stefan.
“Kickoff meeting next week,” Stefan replied. “We’ll review your Business Central configuration, validate your master data readiness, and create a detailed implementation plan. Then we start the build and configuration phase.”
“How involved will we need to be?” Klaus asked.
“Very,” Stefan said candidly. “This isn’t something we do to you. It’s something we do with you. You’ll need to dedicate Sarah probably 60-70% time during implementation, Patrick maybe 40%, and we’ll need access to Otto and your other shop floor experts regularly.”
Emma nodded. “We’ll make the resources available. This is our top priority.”
The mixed emotions
After the vendor signed off, the team sat in the conference room with a post-decision mixture of relief and concern.
“Did we just commit to making this work, or did we just commit to a very expensive experiment?” Klaus asked, only half joking.
“Both,” Emma replied. “But that’s true of any significant change. There’s no risk-free path forward.”
Sarah felt the weight of her upcoming role. She’d be the point person for implementation, the bridge between the vendor and Alpine’s operations, the one who’d need to make dozens of small decisions that would determine whether this succeeded or failed.
“Are you okay?” Patrick asked, noticing her expression.
“Just realizing how much work this is going to be,” Sarah admitted. “And hoping I’m up for it.”
“You are,” Emma said with certainty. “But you’re not doing it alone. We’re all in this together.”
Henning spoke up from the video screen, where he’d stayed connected. “Can I share one final thought? You’re feeling anxiety right now because you understand the magnitude of what you’ve committed to. That’s actually a good sign. The teams that worry me are the ones who think software implementation is easy.”
He smiled. “Your real work is just beginning. The software is a tool. Success depends on how you use it, how you adapt your processes, how you train your people, and how you persist through the inevitable challenges. But based on what I’ve observed over these past months, I’m confident you can do this.”
“Why?” Sarah asked.
“Because you’ve done the hard work of understanding yourselves,” Henning replied. “You know your constraints. You know your priorities. You’ve had difficult conversations and made tough decisions. That foundation—that organizational maturity—is what determines implementation success, not the sophistication of the software.”
The ‘No Fancy Plays’ Wisdom
That evening, Sarah sat at the kitchen table with Tom, helping him with a school project about decision-making. The irony of the timing wasn’t lost on her.
“How do you know if you made the right decision?” Tom asked as he worked through his assignment.
“You don’t, really,” Sarah admitted. “Not until you see how it turns out. But you can make a good decision by thinking carefully about what you need, what your options are, and what you can actually do successfully.”
“Did you make a big decision today?” Tom asked.
“We did. We chose software to help schedule production at work.”
“Did you choose the best one?”
Sarah thought about how to answer this. “We chose the one that fits us best. There were other options that were more sophisticated or cheaper, but we chose the one we think we can actually use successfully.”
Tom considered this. “Like how Coach tells us not to try the fancy plays until we master the basics?”
“Exactly like that,” Sarah said. “We could have chosen the fancy option, but we might not have been ready for it. We chose the option we can master.”
Miguel appeared with tea for both of them. “You look tired but satisfied.”
“I am both those things,” Sarah admitted. “We made a decision today that I think is right, but it’s also a little scary. What if we’re wrong?”
“Then you’ll figure it out and adjust,” Miguel said, echoing what Patrick had told her that morning. “You’ve been making things work at Alpine for years. This is just the next challenge.”
Sarah’s phone buzzed with a message from Emma: “Thank you for your leadership today. We made a good decision. Now comes the hard part—making it work. But I have confidence in you and in this team.”
Sarah showed the message to Miguel. “The hard part,” she said. “I guess that starts Monday.”
“It always does,” Miguel replied with a smile. “But at least now you know what the hard part is. That’s better than just being confused about why everything is hard.”
Sarah laughed despite her fatigue. He was right. They’d spent months understanding their problems, evaluating options, and making difficult decisions. They’d chosen a path that wasn’t perfect but was realistic. They’d committed to changing how they worked, with eyes open to the challenges ahead.
The whiteboard that had served them for so many years would soon be replaced—not by something perfect, but by something better. And that, Sarah was learning, was often the best you could hope for in the real world of manufacturing: not perfection, but meaningful improvement through disciplined effort.
Tomorrow, the real work would begin. But tonight, she could rest knowing they’d made a thoughtful, well-reasoned decision that gave them a genuine chance at success.
