The week following the setup debate brought a new challenge that cut to the heart of Alpine’s software selection process. Emma had called a meeting that she described as “the most important technical decision we’ll make” — not about which specific software to buy, but about which architecture to pursue.
Marcus and Henning both joined via video, and Sarah noticed they’d coordinated beforehand. They each had prepared presentations, suggesting they’d discussed this meeting in advance.
“Let’s talk about ERP integration. We’ve narrowed the field to essentially two approaches,” Emma began, projecting a simple diagram onto the screen. “Integrated solutions that work natively within Business Central, or standalone scheduling systems that connect to Business Central but maintain their own separate architecture. Since we excluded sophisticated APS solutions earlier, we should focus on scheduling systems and can leave out those giant APS tools. Marcus and Henning, I asked you both to prepare arguments for the different approaches because I suspect you have different perspectives.”
Marcus spoke first. “I do have a perspective, but I want to be clear—both approaches can work. The question again is which fits Alpine’s situation better.”
“Diplomatic opening,” Klaus murmured to Sarah.
The Standalone Scheduling Solution Argument
Henning pulled up his presentation. “Let me start by explaining why standalone scheduling systems exist and what advantages they offer. These are purpose-built scheduling engines developed by companies that specialize solely in production scheduling. They’ve refined their algorithms and products over decades.”
He showed a case study. “This manufacturer—similar in size to Alpine, high-mix low-volume, precision machining—implemented a standalone scheduling system three years ago. They achieved significant throughput improvements, reduced lead times by almost 30%, and, as a result, improved on-time delivery from 68% to 91%. Here is the whole story on the vendor’s website.”
Klaus leaned forward, clearly impressed. “Those are significant numbers. It seems that they have improved precisely in the areas where we need to take action.”
Correct”, Henning confirmed. “Even if those standalone scheduling systems might not come with the algorithmic horsepower of sophisticated APS solutions, they have one advantage. Their computation happens outside the ERP and does not affect the ERP at all. That means, they can afford to run multiple iterations of their scheduling heuristics to improve the quality of the schedule.”
He clicked on another slide showing technical architecture. “The key advantage is independence. If complex computations run within the ERP system, they might impact the system. I saw solutions that created temporary table locks during computations. And table locks are ugly. When they occur, users cannot access any function that is built on the respective table. That way, those heavy computations literally prevented the users from doing their day-to-day tasks in the ERP system.
Hence, customers and partners added these computations to the job queue so they could run overnight. However, still the table locks were a true pain. They more or less forced the customer to ensure that no job was executed in parallel. And sometimes, nights are also short, and jobs from the jobs queue have to run in parallel. Means: independence is an asset.”
Sarah was taking notes but noticed Patrick frowning slightly. “What’s the trade-off?” he asked.
“Integration complexity,” Henning admitted. “These systems need to exchange data with Business Central—production orders, BOMs, routings, inventory levels, shop floor updates. That means building and maintaining interfaces that extract data from BC, transform it into the standalone scheduling software’s format, run the scheduling engine, and push results back to BC. Especially the latter can prove to be very tricky as writing back into the ERP can truly mess around with core ERP processes.”
“How complex are we talking?” Patrick asked.
Marcus answered this one. “I’ve implemented about a dozen standalone scheduling systems with Business Central over the years. The initial integration typically takes a couple of months of development, testing, and fine-tuning work. You’re essentially building a bridge between two different data models and two different processing philosophies.”
“And maintenance?” Emma asked.
“Ongoing,” Marcus said carefully. “Every Business Central update needs testing to ensure the interfaces still work. The same is true if the scheduling software gets a new release. Every business process change potentially affects both systems. You need people who understand both BC and the standalone scheduling system to troubleshoot issues. It’s not impossible, but it requires sustained technical capability.”
The ERP Integrated Solution Case
Marcus pulled up his own presentation. “Now let me show you the alternative approach. Integrated solutions—sometimes called Business Central apps or extensions—are built using the same technology framework as Business Central itself. Their algorithms are fully coded in Business Central’s AL language, their frontends are embedded in Business Central pages, and they live only in Business Central. “
He demonstrated a scheduling interface that looked remarkably similar to Business Central’s standard screens. “The keyword here is ‘native.’ These solutions share BC’s database, security model, user interface conventions, and update cycle. When you update Business Central, you can make the scheduling app update with it. When you change a production order in BC, the scheduling system sees it immediately.”
“No integration work?” Klaus asked.
“Minimal,” Marcus confirmed. “The app extends Business Central rather than connecting to it. Installation typically takes minutes, not months. And because everything shares the same platform, your IT team doesn’t need to learn a completely separate system.”
He showed data flow diagrams. “Real-time inventory levels, customer priority changes, production progress updates—schedulers can access all of this without switching between systems. The user experience is seamless.”
“What about scheduling capabilities?” Sarah asked. “Henning showed impressive results from standalone systems. Can integrated solutions compete?”
Marcus nodded, appreciating the direct question. “This is where honesty matters. Integrated solutions typically offer less sophisticated optimization than dedicated standalone scheduling systems. They focus on practical scheduling—helping humans make good decisions quickly—rather than finding mathematically brilliant solutions.”
So, integrated solutions help you schedule those same jobs using practical heuristics—schedule forward or backward, respect capacity constraints, show conflicts clearly, make adjustments easy.”
“That sounds less powerful,” Klaus observed.
“It’s differently powerful,” Henning interjected. “And this is where I need to present both sides honestly. Yes, standalone scheduling systems can achieve remarkable scheduling results. But remember what we learned during the setup debate—optimization only helps if you’re optimizing the right things and if your data supports it.”
ERP Integration Complexity: The Real-World Cost
Patrick had been quiet, but now he spoke up with the kind of technical concern that usually preceded important insights. “I’ve been thinking about this integration question from a practical standpoint. Let me walk you through what maintenance would look like with each approach.”
He pulled up a timeline on his laptop. “Scenario one: standalone system. We implement it over a few months, build custom interfaces, and train everyone on two systems. It works great. Then, Business Central releases an update that changes how production orders handle subcontracting. Now we need to update our interface code, test it, and redeploy. That can result in up to two weeks of work.”
“Doesn’t sound too bad,” Klaus said.
“That’s one change,” Patrick continued. “But Microsoft ships two major releases per year. Plus a cumulative update every month. We modify our BC configuration frequently to support new business requirements. Each change potentially affects the integration. Over a year, we might spend 20-30% of my time just maintaining the interface between systems.”
He switched to a different scenario. “With an integrated solution, Business Central and the scheduling app share the same platform. When BC updates, the app vendor updates their code to match. When we modify the BC configuration, the scheduling app sees it automatically because they share the same database.”
“So less maintenance burden?” Emma asked.
“Significantly less,” Patrick confirmed. “But there’s another factor. Right now, I’m the only person here who really understands Business Central’s technical architecture. If we implement a standalone scheduling system, I’d also need to become an expert in that system’s technical architecture. What happens if I’m sick, or on vacation, or—God forbid—leave the company?”
The room fell quiet as everyone processed this angle on succession planning.
“With an integrated solution,” Patrick continued, “any BC consultant can help us. There’s a whole partner ecosystem. With a standalone scheduling software, we’d be dependent on specialists who know both BC and that specific scheduling system—a much smaller pool.”
The Vendor Demonstrations Debrief
Sarah had been coordinating the vendor demonstrations over the past two weeks. “Can I share what I’ve observed during the trials? I think it illustrates Patrick’s point.”
She pulled up her notes. “The standalone scheduling vendor sent a technical specialist who spent three days configuring interfaces. A very impressive person, clearly an expert in their system. But when we had a question about how BC handles phantom BOMs, he didn’t know. We had to call Marcus separately. The same happened when we asked him how his solution would handle the planning flexibility field at the production order line level and how it would impact our MRP. Let me be blunt: He had no clue.”
“And with the integrated solution?” Emma asked.
“Their implementation consultant understood both sides because it’s all Business Central,” Sarah replied. “When we asked how the schedule would integrate with sales orders in case of late deliveries due to production delays, she could not only explain it in terms of BC’s manufacturing module, but also show it within Business Central.”
She clicked through her demonstration notes. “There’s also the user experience factor. With standalone scheduling, schedulers work in one system, then switch to Business Central for order details, then back to the scheduling software for schedule changes. It’s functional, but it’s an extra cognitive load.”
“Did you notice a difference with the integrated solution?” Emma asked.
“It felt like one system,” Sarah said. “I could see the schedule, click on a job to see its full production order detail, check inventory availability, review customer information—all without leaving the interface. It sounds minor, but when you’re making dozens of decisions a day, that friction matters.”
Emma’s Pragmatic Question
Emma had been listening carefully to all the technical arguments. Now she stood and walked to the whiteboard, writing a single question:
“Which approach gives us the best chance of successfully using the system in six months?”
She underlined “using” and “six months.”
“Not implementing,” she clarified. “Not having. Using. I want to understand which approach is more likely to result in schedulers actually using the system effectively six months from now.”
Henning smiled. “That’s exactly the right question, Emma. And it shifts the evaluation criteria significantly.”
“How so?” Klaus asked.
“Because implementation success and usage success are different things,” Henning explained. “I can show you companies that successfully implemented standalone scheduling systems—the integration works, the data flows, the optimization runs. But schedulers don’t actually use the optimized schedules because they don’t trust them, or the system is too complex, or it doesn’t adapt quickly enough to real-world changes.”
He pulled up another case study. “This company—different from the success story I showed earlier—implemented a sophisticated standalone scheduling system. Technically flawless integration. But a year later, schedulers were still using spreadsheets and overriding the system’s recommendations because the system couldn’t handle the daily exceptions and changes that occur in high-mix low-volume manufacturing.”
“Why did that happen?” Sarah asked.
“Several reasons,” Henning replied. “The standalone software was optimized for efficiency, but the schedulers needed flexibility. The optimization took almost thirty minutes to run, so they couldn’t quickly test what-if scenarios. The interface was powerful but intimidating. And when the software’s schedule didn’t match reality—which happened daily—they didn’t understand why, so they stopped trusting it.”
The Organizational Capacity Question
Marcus built on Henning’s point. “There’s another factor that doesn’t show up in technical comparisons: organizational capacity for change. Implementing scheduling software isn’t just a technical project. It’s a change management challenge.”
He looked around the room. “How many major system changes has Alpine implemented in the past three years?”
Emma thought about this. “We implemented Business Central two years ago. That was significant.”
“And how did that go?” Marcus asked.
“Rough first few months,” Emma admitted. “But we got through it.”
“Now imagine implementing scheduling software at the same time you’re maintaining a complex integration between two systems,” Marcus said. “You’re asking people to learn new processes, new interfaces, new ways of thinking about scheduling—while also dealing with the technical complexity of keeping two systems synchronized.”
Patrick nodded emphatically. “That’s my concern. With standalone scheduling, we’re taking on two challenges simultaneously: learning new scheduling processes and managing technical integration. With an integrated solution, we focus on just the scheduling processes because the technical integration is handled by the app vendor.”
Otto, who had been characteristically quiet, finally spoke up. “Can I ask a simple question? If I’m on the shop floor and need to know what job to run next, which system makes that easier?”
“Good question,” Henning said. “With standalone scheduling, you’d probably log into Business Central to see your production orders, but the detailed schedule lives in the standalone system. So you’d need access to both, or rely on printed schedules, or have supervisors translate the stand-alone schedule into work instructions. Or, if the system is architected well, it should update the production orders and then show you the scheduled operations in your machine and work center task list.”
“There were a lot of “or” statements. Sounds vague to me. How’s that with an integrated solution?” Otto asked.
“Everything’s in Business Central,” Marcus replied. “The schedule, the production orders, the job details. Shop floor users see one system, just with better scheduling visibility than they have today.”
Otto nodded. “Simpler is usually better on the shop floor. People have work to do. They don’t want to figure out which system has which information.”
The Total Cost Analysis
Klaus, ever the financial analyst, pulled up a spreadsheet he’d been working on. “I’ve been trying to calculate the total cost of ownership for both approaches over five years. The numbers surprised me.”
He projected his analysis. “Standalone scheduling software: Higher subscription costs, significant implementation costs for integration work, and ongoing maintenance burden. Integrated solution: Lower subscription costs, minimal integration costs, but potentially higher per-user pricing.”
He scrolled through the calculations. “What shocked me is that over five years, the integrated solution is actually less expensive—primarily because we’re not paying for ongoing integration maintenance. Patrick’s time is valuable. If we spend 20-30% of his time maintaining interfaces, that’s real cost even if it doesn’t show up as vendor invoices.”
“How much difference are we talking about?” Emma asked.
“Roughly 40% lower total cost over five years for the integrated approach,” Klaus said. “That’s including the theoretical productivity benefits from standalone optimization solutions, which I modeled conservatively.”
The Strategic Alignment
Emma studied the whiteboard where she’d written her key question. “Let me see if I can summarize what I’m hearing. The standalone approach offers more sophisticated scheduling logic but requires more technical capability, more maintenance, more change management, and—according to Klaus—more total cost. The integrated solution offers practical scheduling in a familiar environment with less maintenance and lower cost, but without the sophisticated optimization capabilities.”
She looked around the room. “Did I miss anything?”
“There’s one more factor,” Henning said. “Strategic alignment with your existing technology investments. You’ve invested in Business Central. You have a relationship with Marcus and his company. They are a Microsoft Gold partner, and this also gives you indirect access to Microsoft. In addition to Marcus’ company, there is an entire partner ecosystem around. An integrated solution leverages that investment. A standalone scheduling product creates a parallel technology track.”
“What does that mean practically?” Sarah asked.
“It means your technology strategy becomes more complex,” Henning explained. “You need expertise in two platforms instead of one. You have relationships with two software vendors instead of one. Your long-term roadmap needs to consider how changes to either system affect the other.”
Marcus added, “And it means your growth path is different. If Alpine expands to multiple locations, adds new business lines, or acquires another company, integration complexity multiplies. Each new situation potentially affects both BC and the stand-alone system and the interfaces between them.”
The Decision Clarity
Emma looked around the table, making eye contact with each person. “I think we have clarity here. Unless someone wants to argue strongly for the standalone approach, I’m inclined to focus on integrated solutions.”
She paused, giving people a chance to object. No one did.
“It’s not that standalone scheduling solutions couldn’t work,” Emma continued. “Under different circumstances—if we had larger IT staff, if our manufacturing was more stable and repetitive, if we needed extreme optimization—maybe it would make sense. But for Alpine today, with our current capabilities and priorities, the integrated approach feels right.”
Sarah felt relief wash over her. The decision made sense not just technically, but practically. They would be building on their existing BC foundation rather than adding complexity.
“So what’s our next step?” Klaus asked.
“We evaluate the specific integrated scheduling solutions available for Business Central,” Emma said. “Not based on feature matrices, but based on how well they fit our operational needs, how easily our team can adopt them, and whether they support our strategic priorities around throughput and delivery reliability.”
She looked at Sarah. “I want you to lead that evaluation. You understand our scheduling needs better than anyone. Work with Patrick on technical fit, Otto on shop floor practicality, and Klaus on financial analysis. But you make the recommendation.”
The evening realization
That evening, Sarah sat with Miguel and Tom at dinner, recounting the day’s decision.
“So you chose the less powerful option?” Tom asked, working on his homework at the table.
“We chose the approach that suits us best overall.,” Sarah corrected. “Sometimes the most sophisticated solution isn’t the best solution.”
“Like in football,” Tom said. “Coach says don’t try fancy moves if simple passing works better. 2 touches. Period.”
Miguel laughed. “That’s actually a perfect analogy. Your company decided that simple passing—using tools that work well together—is better than fancy individual moves that might not fit the team.”
Sarah thought about Emma’s question that had cut through all the technical debate: which approach gives us the best chance of successfully using the system in six months? That question had reframed everything from technical capabilities to practical success.
“We still have to select the specific software,” Sarah said. “But now we know we’re looking at integrated solutions. That narrows the field significantly.”
“Does that make you feel better?” Miguel asked.
“Much better,” Sarah admitted. “We’re not trying to become IT experts in addition to manufacturing experts. We’re building on what we already know and what we already have.”
Her phone buzzed with a message from Otto: “Talked to Schmidt and Weber. They’re relieved we’re not adding another system they’d need to learn. Smart decision.”
Sarah smiled. If the shop floor approved, they were on the right track. All the sophisticated functionality in the world meant nothing if the people who actually ran production couldn’t or wouldn’t use it.
Tomorrow, they would start evaluating specific integrated scheduling solutions. But tonight, she could rest knowing they’d made a strategic choice that aligned with their capabilities, their priorities, and their reality. Not the most impressive choice on paper, but the one most likely to actually work.
Sometimes, she was learning, the best decision wasn’t the one that looked best in a vendor presentation. It was the one you could actually execute successfully in your actual circumstances, with the team and resources you had.
