Customization Options in ERP Systems

A question I often get asked: "Why can't we just create custom fields in your system? Other platforms let us do this easily." It's a fair question. The honest answer is that we probably can, however, the real question is whether we should... and if so, what problem are we actually solving? Legacy platforms have used custom fields as a shortcut to extensibility. It looks flexible on the surface, but in practice, it often means the vendor never fully understood the client's underlying need, and thought through how that need fits into the broader data model of the platform. This matters more than most people realize. Some of these fields are genuinely business-critical. They drive compliance, financial reporting, or core operational workflows. Others are attributes or tags that influence automation, approvals, or analytics across the system. These cannot simply be slapped on as a custom field and scripted around. When you do that, you end up with: → Fields queried without indexing, degrading system performance at scale → Scripts and automations built on top of those fields, creating many dependencies that can break → A maintenance nightmare that can break with a new release → Reporting that looks like it works, but the data behind it doesn't I've seen legacy ERP environments with hundreds of custom fields, each one a small decision made without a full picture, collectively grinding the system and costing clients time and money to maintain. I now think about this differently. When a client asks for a custom field, I start by asking what business problem are they trying to solve. Is this a data attribute that belongs in the core model? Is it a tag that drives a workflow? Is it a reporting dimension that needs to be structured from the ground up? Or is it something that configuration, segmentation, or a native feature already handles? The goal isn't to say no. It's to make sure that when we extend the system, we're doing it in a way that performs, scales, and doesn't become a liability six months after go-live. #ERP #ProfessionalServices #ImplementationStrategy #DataArchitecture #EnterpriseSoftware

If you're evaluating an off-the-shelf solution right now, there's one question you 𝘵𝘩𝘪𝘯𝘬 you might have asked, but probably haven't fully explored: "How will we handle customizations down the road?" Yes, you asked the vendor all the right questions: → Can it connect to our existing tools? → Can we customize the workflow to fit how we operate? → Can we automate this part of the process? And you might hear: → Yes, we have an API. → Yes, we support integrations. → Yes, you can configure workflows. The answer is almost always “yes.” But the truth is... – The integration will need separate scoping – The custom workflow will impact their roadmap – The automation will depend on your existing APIs and your current tech stack So, "yes" just means possible. Here’s why: Most SaaS platforms are designed to scale. That means building for the 80% - the common workflows, and not the edge cases. Custom work is still doable. But it requires: – Dedicated resources – Extra time – Careful prioritization And for product-led companies, those things are intentionally limited. Not because they don’t care. But because they’re focused on keeping their platform easy to maintain and scale for everyone. So when you need to customize the existing solution, you’ve got 3 options with pros and cons to each: 1. Work with the SaaS vendor to build it + deep product knowledge + easy access to internal components/APIs + everything stays with one team - you’re one of many customers in their backlog - longer timelines because of backlog - higher rates because the work is usually outsourced (quality varies) 2. Bring in a third-party integration partner + teams are more agile and focused + they have broader experience across systems + they provide faster delivery and usually higher quality - it does require strong collaboration with the SaaS provider - they need access to APIs and documentation - results might vary - a partner who understands both your operations and the tech is wins here 3. Build it in-house + you have full control + fast feedback loops (requires a strong technology leader to manage teams effectively) + keeps everything internal - most internal teams lack the specific experience - you risk of building quick fixes that don’t scale - it steals devs valuable time from maintaining your core products or ops priorities ________ TL; DR: → The bigger the company, the more unique the workflow. → The more unique the workflow, the more customization needed. → And the more complex the system, the more critical it is to get it right So if you’re in the middle of evaluating SaaS platforms right now... Don’t just ask if it can be customized. Ask who will do the work, how long it will take, and what happens when priorities shift. That’s where the real risk (or opportunity) lives. Anything you want to add? #enterprisedevelopment #customsolutions

In SAP (Systems, Applications, and Products in Data Processing), in-app extensibility refers to the ability to customize or extend SAP applications to meet specific business requirements without modifying the core codebase. SAP provides various tools and technologies to achieve this, allowing businesses to tailor SAP applications to their unique needs. Here's a simple example of in-app extensibility in SAP: Let's say a company is using SAP's Enterprise Resource Planning (ERP) system to manage its business processes, including sales orders. The standard SAP ERP system provides basic functionality for creating and processing sales orders. However, the company has specific requirements that are not covered by the standard functionality, such as additional fields to capture customer-specific data. With in-app extensibility in SAP, the company can customize the sales order process to include the required additional fields without modifying the standard SAP code. Here's how they could do it: 1. Custom Fields : Using tools like SAP Fiori, SAPUI5, or the SAP Cloud Platform, the company can add custom fields to the sales order entry screen. These fields can be tailored to capture the specific information needed, such as customer preferences or special instructions. 2. Business Logic : If the company requires custom business logic to be applied to the sales order process, they can use SAP's Business Rules Framework (BRF+) or Business Process Management (BPM) tools to define and implement the logic without changing the standard SAP code. 3. Integration : In some cases, the company may need to integrate external systems or third-party applications with SAP. SAP provides integration tools such as SAP Process Integration (PI) or SAP Cloud Platform Integration (CPI) to facilitate seamless communication between SAP and other systems. 4. User Interface Enhancements : The company can also enhance the user interface of SAP applications using SAP Fiori apps or SAPUI5 to improve usability and productivity for end users. By leveraging in-app extensibility in SAP, the company can tailor the SAP ERP system to its specific business requirements, ensuring a better fit for its processes and workflows without the need for extensive customization or modification of the core SAP codebase.

Find the Sweet Spot: Customization vs. Configuration Too much sugar hurts; too little tastes flat. Same with ERP. Over-customized ERPs give you a short-term buzz… then an upgrade toothache. Under-customized systems feel “healthy” but no one drinks them—adoption fizzles. The goal with Acumatica: hit the sweet spot—configure first, customize where it truly differentiates. How I frame it with clients: Start with configuration: workflows, approval maps, business events, generic inquiries, dashboards, side panels. Prove value fast: pilot one value stream and track cycle time, first-time-right, margin leakage. Customize with intent: xRP/event-driven extensions only when it drives competitive edge or compliance. Stay upgrade-safe: keep core clean, document a “Customization Manifest” (owner, KPI, test, rollback). Integrate at the edges: REST/OData, iPaaS, Power BI—sweeten without dumping code into the core. Question for you: where’s your current mix—too sweet (over-customized), too bitter (under-customized), or just right? #Acumatica #ERP #Manufacturing #Operations #DigitalTransformation #CIO #CFO #BPM #ChangeManagement