Introduction
If you've been researching ERP systems, you've probably come across the big names: SAP, Oracle, Microsoft Dynamics. They power some of the world's largest manufacturers. They're proven. They're sophisticated. And when you're struggling with spreadsheets and disconnected tools, it's tempting to think, "Maybe we just need to invest in enterprise-grade software."
Here's what you need to know before writing that check: These systems weren't built for facade fabrication. And the mismatch runs deeper than you might think.
The SMB Problem: Cost, Complexity, and the Wrong Foundation
Let's start with the practical realities of implementing enterprise-grade software within a small-to-medium facade fabrication company.
The Real Cost (And It's More Than the Sticker Price)
When you ask SAP or Oracle for pricing, the initial numbers might seem manageable. Software licenses for SAP Business One run $1,500-$4,000 per user. Oracle NetSuite subscriptions quote similarly. For 20 system users, you're looking at $60,000-$80,000 in licenses.
Then comes implementation. For a mid-sized company (50-200 employees), total project costs typically run $150,000 to $750,000, with consulting fees often 1.5 to 2.5 times the software license cost. If licenses are $100,000, expect another $150,000-$250,000 just to get the system running.
Here's the critical question: Where is that money going?
You're paying for breadth you don't need. Enterprise ERPs were built for multinational corporations. That $500,000 implementation includes configuring modules for multi-currency consolidation, transfer pricing, global procurement networks, and dozens of other capabilities designed for Fortune 500 complexity. You're funding the development and maintenance of features you'll never touch, and paying consultants to navigate around them or turn them off.
You're paying to adapt the wrong foundation. Because these systems assume make-to-stock manufacturing, a huge portion of implementation cost goes toward bending the software to handle project-based work. Custom fields for project tracking. Workarounds for one-off BOMs. Manual processes to bridge gaps the system wasn't designed to fill. You're essentially paying to retrofit a system built for a different business model.
You're paying for future consulting dependency. Those customizations create ongoing costs. Annual maintenance runs 20-22% of license fees (so $40,000+ annually on a $200,000 license), but that only covers standard support. When you need to modify your customizations, add a new workflow, or fix something that breaks after an update, you're calling consultants at $150-$225 per hour. Many companies spend $10,000-$100,000 annually just maintaining custom code.
You're paying implementation risk. Industry data shows typical implementations take 12-18 months, and roughly half run over budget or timeline. For an SMB, that's 12-18 months of disrupted operations, key people pulled away from running the business, and uncertainty about whether the system will actually work for your needs when it goes live.
The issue isn't the absolute dollar amount; a comprehensive ERP system is a significant business investment, and that's appropriate. The issue is paying enterprise software prices for enterprise software complexity when what you actually need is software purpose-built for project-based facade fabrication.
If you're going to invest six figures in an ERP system, the question shouldn't be "can we afford this?" It should be: "Will this investment actually solve our problems, or will we end up with an expensive system we have to work around?"
Overwhelming Complexity for What You Actually Need
Enterprise ERPs were designed for Fortune 500 companies with dedicated IT departments, specialized administrators, and processes that span dozens of countries. They're built to handle every possible business scenario, which means they come loaded with functionality you'll never use.
The problem isn't just unused features, it's that all that complexity makes the system harder to learn, harder to use, and harder to maintain. Your project manager doesn't need multinational consolidation features or transfer pricing capabilities. Your production supervisor doesn't need advanced supply chain optimization across 50 distribution centers.
But they still have to navigate through menus and screens designed for that level of complexity. Simple tasks, like creating a project or generating a BOM, require multiple steps through unfamiliar interfaces. One common complaint from SMB users: "We're paying for a Lamborghini but we can barely drive it, and we only needed a pickup truck anyway."
The learning curve is steep. Even with training, it often takes employees months to feel comfortable with basic tasks. This can lead to low user adoption; people find workarounds, continue using Excel for certain things, or rely on a single "expert" who becomes a bottleneck.
Built on the Wrong Foundation
Here's the fundamental issue: SAP and Oracle built their reputations on helping large manufacturers optimize repetitive production. Their core logic assumes you're making the same products over and over, with stable BOMs, predictable routings, and inventory you can optimize through forecasting.
That's make-to-stock manufacturing. Build products based on forecasts, stock them, ship them when orders arrive. Or at most, make-to-order: You receive an order for a standard product and build it.
Your business model is engineer-to-order. Every project is custom-designed after the contract is signed. This difference breaks assumptions throughout the system:
Material Planning: Traditional ERP systems use MRP (Material Requirements Planning) to automatically calculate what materials to order based on production schedules and BOMs. But in ETO work, the BOM doesn't exist when the project starts, it's developed during design & engineering. In facade fabrication, project managers are estimating material quantities based on gross square footage, and then optimally scheduling their purchase orders so that the warehouse isn’t stocking materials for months.
Production Scheduling: Standard ERP scheduling assumes you can optimize machine time and labor across predictable work orders. But when every job is different, you can't optimize the same way. You're managing project timelines with dependencies, approvals, and external coordination, not production line efficiency.
Costing: Repetitive manufacturing uses standard costing: you know a component costs $47.32 to make because you've made 10,000 of them. You're doing project costing: tracking unique costs against unique budgets for unique jobs. The system needs to handle actual costs per project, not standard costs per product.
These mismatches mean you end up fighting the software, creating workarounds, or leaving functionality unused because it doesn't map to your reality.
Why Facade Fabrication Makes It Even Worse
If you were doing simpler custom work (maybe custom furniture or small-batch manufacturing) you might bend an enterprise ERP to fit. But facade fabrication adds layers of complexity that expose every weakness in the generic ERP approach.
Workflows That Don't Exist in the System
Facade fabrication involves constant coordination: submittals waiting for architect approval, RFIs that hold up material orders, GC schedule changes that cascade through your production plan, and installation crews who need real-time updates from the shop floor.
If you haven’t read Why Facade Fabrication is Different from Typical Manufacturing Workflows, we explain these coordination challenges in greater detail.
Enterprise ERPs don't have modules for those workflows. They weren't designed for construction-adjacent industries where document management, approval processes, and multi-party coordination are as important as production.
You'll end up managing submittals in email or a separate document management system. RFIs tracked in spreadsheets. Installation progress updated via phone calls or text messages. The ERP becomes just another disconnected tool instead of the central system that ties everything together.
Every Project is Different
Traditional ERPs assume standardization helps you. Standardized part numbers, standardized BOMs, standardized routings, this is how they drive efficiency.
But you can't standardize when every project is architecturally unique. The curtain wall system for one building might share a bracket or fastener with another project, but the overall assembly, dimensions, installation requirements, and specifications are different.
The system will push you to create thousands of part numbers, one for each unique panel size and configuration. Your item master database becomes unwieldy. Creating and managing BOMs becomes a massive administrative burden. Engineers complain that it takes longer to set up the system than to just build the thing.
And when designs change (which they do) mid-project? The rigid structure of an enterprise ERP makes change management painful. You can't just update a drawing and have materials flow accordingly, you need to create engineering change orders, update BOMs, revise routings, adjust material reservations. What should take minutes takes hours.
The System Stops at the Loading Dock
Traditional manufacturing ERPs track products through production and shipping. Shipped = done. Invoice = closed.
But you need to track products through installation. You need to know which panels are in which crates, which crates are on which truck, what's been installed versus what's still in staging, and whether anything was damaged in the field.
Out of the box, SAP and Oracle don't handle this. The shipping module assumes you're done once the product leaves your facility. You'll need heavy customization to track installation status, site inventory, or field crew activities, if it's even possible.
Service Provider Coordination Doesn't Fit
When you send aluminum extrusions out for anodizing or panels to a painting subcontractor, you need to track: what was sent, when it's due back, current status, and how that affects your production schedule.
Generic ERPs can handle subcontracting for standard operations (like "send this part out for heat treating"). But managing a services calendar across multiple projects, multiple providers, and time-sensitive installation deadlines? That's not in their DNA. You'll end up managing it separately; another disconnected tool.
The Customization Trap
At this point in the sales process, the ERP vendor or implementation consultant usually says: "No problem. We can customize the system to handle all of that."
And they can. For a price. And that price keeps growing.
This is called the customization trap, and it's where many SMBs get caught. You start with reasonable customizations: "Can we add a field for a secondary shipping address?" Then you realize the project workflow needs more adjustments. Then you want to track installation differently. Then you need custom reports to see project costs the way you actually think about them.
Each customization costs money, typically tens of thousands of dollars for meaningful modifications. But the real cost comes later:
Upgrade Paralysis: When the ERP vendor releases new versions or updates, your customizations often break or become incompatible. You face a choice: pay to have your custom code rewritten for the new version, or skip the upgrade. Many companies end up stuck on old versions, missing security patches and new features, because upgrading would cost another six figures.
Vendor Lock-In: You become dependent on the consultants who built your customizations. They're the only ones who understand your system. When you need changes or fixes, you're paying their rates with no alternatives. Many SMBs find themselves spending $10,000-$100,000 annually just maintaining customizations.
Technical Debt: Each customization is code someone needs to maintain. As your custom code accumulates, the system becomes more fragile and harder to modify. You end up with a unique system that's expensive to maintain and impossible to replace.
The customization trap is especially dangerous for project-based manufacturers like facade contractors because the gaps between standard ERP functionality and your needs are substantial. You're not making small tweaks, you're trying to bolt on an entire project management and installation tracking system onto software that wasn't designed for it.
There's a Better Way
Here's the uncomfortable truth: You can spend $500,000 and 18 months implementing SAP or Oracle, customize it heavily, and still end up managing critical parts of your business outside the system.
Or you can choose software that was built for the way you actually work.
Whether you work with simple ACM panels, metal sub-framing, or complex assemblies, Spectr is the first ERP purpose-built for facade fabrication. Not adapted from automotive manufacturing. Not customized from a generic system. Built from the ground up for project-based, engineer-to-order, shop-to-field operations.
It handles the things we've been talking about (submittals, architect coordination, installation tracking, service provider management) not as customizations, but as core features. Because it was designed by people who understand that facade fabrication isn't just manufacturing. It's project management, coordination, and field operations all rolled into one.
The system assumes every project is unique. It expects designs to change. It connects your shop floor to your installation crews. It tracks products from BOM generation through final installation, because that's what you actually need to manage.
No customization trap. No force-fitting your workflows into software built for a different industry. No paying for complexity you don't need.
If you've made it this far, you understand why generic ERPs fail for facade contractors. You're probably wondering: What does a purpose-built solution actually look like? How does it solve these specific problems?
Learn how Spectr solves the specific challenges facade fabricators face every day →
