Scalability. It’s a term that pops up in the ERP program conversation often–but often with too light a touch. If you’re serious about protecting your software investment, the concept of scalability demands a deeper look.

From a practical perspective, how well a selected product scales can separate a good ERP decision from a great one. Amid hundreds of software options, it’s tempting to define success as simply finding a solution that will meet your unique needs. But the skill that marks a truly savvy ERP evaluator is the ability to locate software that will not only meet current requirements, but protect the investment into the future.

Not sure you’ve developed that particular skill yet? Have questions about what to look for? Don’t worry. There are four simple dimensions of scalability to be aware of: utilization, platform, user count, and functionality. Assessing software options with an eye on their merits in each of these four scalability dimensions is an easy way to tangibly improve your ERP decision. I’ll introduce each scalability dimension in greater detail in short order. But before taking a look at that, though…

What better place to start when considering the topic of scalability than to look back at how it figured into what’s often referred to as the greatest public works project in history?

Scalability: Great Moments in History!

When the Federal Aid Highway Act was signed in 1956 it was billed as a solution to America’s disconnected and inefficient highway system. The resulting Interstate system featured 42,000 miles of roads, tightly defined standards for everything from signage to lane widths, and a radical design decision to limit access to controlled interchanges.

Scalability was built into the Interstate design at every turn and turnpike. In fact, many of the design decisions were not strictly necessary to solve the immediate demands of motorized traffic in the late 1950’s–but were fueled by a desire to future-proof the system. Decisions like larger distance intervals between on-ramp access points even struck many as counter-productive at the time.

But Dwight Eisenhower and the architects of the Interstate system wanted to solve more than the pressing issues of poor road conditions, fragmentation, and failing infrastructure. Envisioning both the increased load that would be placed on the system as more Americans purchased cars and the necessity of high-throughput for national defense reasons, the originators of the Interstate system intentionally over-engineered it–at least, relative to the contemporary requirements.

Largely as a result of the scalability built into the Interstate system, it’s proven to be one of the most durable national investments ever made. Even with more people going more places than ever before–it remains the preeminent mass transit system in the world. Indeed, it’s estimated that the Interstate system has now returned $6 of economic productivity for each $1 invested in it. (“40 Years of the US Interstate Highway System,” PublicPurpose.com)

Scalability and Your ERP Decision

Is it possible that we just set the scalability success bar a bit high? Okay. I’ll grant that. In fact, it’s fair to admit that paying due diligence to scalability in your software decision won’t catapult your organization into global superpower status or girder the greatest explosion in economic prosperity ever recorded in human history. That being said, it can definitely help you make sure you don’t have to:

Reinvest tens of thousands of dollars to overcome foreseeable ERP system shortcomings, or
Pump the brakes on growth opportunities because of limited software capabilities.

Evaluating scalability when it comes to ERP software starts with a simple question: How well-suited is this software to deal with change? Or, to be even more precise: Will this software meet my needs, when my needs intensify or diversify?

The challenge of answering these questions is that change is inevitable, but it’s only partially predictable.

It’s impossible to predict the exact nature of the changes your organization will experience. Wild growth driven by widespread enthusiasm for your product? A slow but stable expansion into new markets? A dramatic makeover of your business model to take advantage of shifting conditions? You can guess–and even guess well–but it’s impossible to know for sure.

While the nature of the change you’ll face is tough to peg, which aspects of your ERP and business software will be affected by change can largely be predicted. It’s these specific software attributes which should be evaluated to understand a product’s overall “scalability.”

The 4 Dimensions of ERP Scalability

When comparing and contrasting the ability of software to scale, consider the capabilities of each system to meet growing needs across the four following dimensions:

Utilization:

How will your system respond when the amount of data stored within it and utilization rates are increased? Whenever you are asking, “What happens when X occurs?” …you’re talking scalability. Reliable performance under increased utilization is largely a product of having the right hardware. But when it comes to ensuring limited latency and strong throughput rates, software architecture plays an important role, as well.

Let’s start with data storage limitations. In some accounting and ERP systems, there are significant tipping points to be aware of that can affect performance. For example, many first-time ERP buyers are moving away from off-the-shelf accounting software options which feature a closed database structure with a hard limit on data-storage. In a program like QuickBooks for example, only 14,500 employees, customers, or other names can be cumulatively stored as a result of the functional limitations of the closed database. An open database structure that allows you to add server space to support increased storage needs is a must-have for any scalable ERP solution.

In situations where a larger number of transactions may push up against the limits of hardware or network capabilities, or traffic is particularly “spiky,” organizations may also wish to target ERP solutions with traffic prioritization features that can help keep certain mission-critical data flowing, even under peak usage.

Another major factor that will affect your software’s scalability is the quality of the software code itself. Many of the hallmarks of bad code (inefficient scripts, duplicate code, memory utilization issues) may not cause issues under light usage, but can have exponentially negative effects with increased system load.

The question is how do you identify bad code before it identifies itself to you? There are a few answers. First, from a practical standpoint, mature code is tested code. Solutions that have been through multiple versions revisions are likely to be significantly more stable. Second, if you are looking to be more precise about the issue, you do have software testing options. Stephen Smith–a software architect who frequently blogs about ERP software–described his company’s efforts to do load-balancing testing on their Sage 300 ERP implementation in a 2011 post. While extensive testing is realistically only financially feasible for larger projects, there are cases when it can be warranted. In fact, there are even companies, such as RadView, that have evolved testing protocols specifically for ERP software. Finally, you’re not inventing the wheel when you purchase ERP software. Others have come before you. One of the best ways to find out what they feel about issues like code quality and performance overall is to ask them. Finding users to ask is as simple as visiting the places where they gather together: namely, user groups and forums.

Evaluating a Software-as-a-Service (SaaS) ERP solution adds another layer to the complexity of the utilization and performance scalability conversation. As previously mentioned, adding data storage space and protecting throughput is in many ways a hardware conversation. If you’re choosing a SaaS solution where the provider hosts the software for you, your software is effectively married to the specific hardware your provider runs the software on. Looking at hardware specs is a good place to start. But you’ll also want to evaluate the SaaS provider’s service level agreement (SLA) to understand guarantees on network access, storage, and latency.

Platform

You can’t fully evaluate an ERP solution’s scalability, without considering platform. What do I mean by platform? For simplicity sake, think of platform scalability as just the ability of the solution to deliver its functionality in multiple computing environments.

Looking at operating system support is a good place to start when evaluating platform scalability. 90% of desktops run some sort of Windows OS according to 2013 numbers, published by AppleInsider.com. For most companies, the OS analysis goes something like this: “Does it run in a Windows environment? Okay, we’re fine.” And, at a certain level this approach makes sense. But it’s worth asking yourself if you’ll encounter situations where you may need to support a multiple OS environment at any point. Common drivers of an expansion to a multi-OS environment include decisions to support:

Users accessing software from home devices
3rd party business partners who need some limited system access (to project management resources, for instance)
Business units who need to utilize particular OS’s to run certain mission critical applications.

One of the ways organizations have solved the issue of supporting client access from multiple operating systems is via web-enabled software. Utilizing a web-browser as the software client means that the device OS is essentially a non-factor.

The topic of web-based software also open up other platform related scalability questions. Will you need to support mobile device users? What devices are users likely to use? While a web-based deployment will provide an “access” answer for these users, it’s worth considering how well optimized each solution is in terms of user interface and graphical display for these different device enviroments.

A final dimension of platform scalability that often gets overlooked is the backend database. An ERP solution will manage some of your business’s most critical data. While the aspiration of every ERP solution is to provide a comprehensive solution, there may be instances where you will need to directly access the database either for reporting or to support another application. The scalability of these efforts will depend on your team’s familiarity with the db language. Additionally, there’s the cost issue of scaling database licensing. Brent Ozar–an expert in the data storage community–recently wrote a column lamenting the cost of MS SQL pricing. (“Standard Edition licensing costs about $2,000 per CPU core, but it can only access 64GB of memory? That’s ridiculous!”) Should you gravitate instead towards open source database alternatives? It’s a complicated, but relevant question, as the price tag of expanding commercially licensed db’s is one of those easy to overlook factors, which can impact the cost of scaling with growth.

User Count:

Adding users is one of the most fundamental ways to scale software. In fact, it’s so fundamental and commonplace that it’s easy to overlook scalability issues when it comes to adding users. But it does bear some brief discussion.

It’s true that nearly every ERP solution and implementation will allow you to add users. But the cost and relative ease of doing so will differ between solutions.

In order to think through user count related scalability issues, consider the following questions:

Are user licenses priced by an individual count or sold in bundled groups (for example: 1, 5, 10, 25, 50, 100, etc.)?
Can I limit new users to only certain functions?
Can I import new user security authorizations and usage settings from existing users?
Do I need to install new client software for each workstation? How complex is that?
Can I create multiple new users at once?

Functionality

When business conditions change, your software will need to do different things. It’s that simple. But considering all the possible functional contingencies can be overwhelming.

The answer is to break functionality into smaller sections. Looking at the following key functional attributes within software, makes it easier to gauge each solution’s scalability:

Security: Does security scale? Of course! A company with 2-3 users may not require much more than solid log-in protection and audit trails to accomplish an acceptable level of security. However, if conditions push that implementation to a 15-20 user set, it’s likely that the ability to set authorizations, permissions, and access control to different features in the system will be important.
Workflows: One of the things that happens as smaller business grow is that to-do lists become processes and processes become best practices. Planning tools, approvals, and workflow features signify a program that is capable of supporting a transition to defined standard operating practices.
Reporting: Processes are not the only thing that tends to be refined with business growth. As organizations expand and responsibility naturally diffuses across additional hierarchical layers, the importance of quantifying accountability increases. Reporting capabilities can vary widely between different ERP systems. A few aspects that should be considered when evaluating reporting scalability, include the available export formats, the ease of use of the reporting tools, report template saving and sharing, and the presence of graphical tools for displaying data.
Modules: ERP systems are multi-module systems that do lots of things. In fact, comprehensive support of both operational and financial tasks belongs in any workable definition of ERP. But both the breadth of the functionality and the level of sophistication within each module will vary between different ERP solutions. Understanding the modular limitations of an ERP solution requires asking the right questions, rather than exhaustively brainstorming every last functional need. For instance, if you’re a retailer with aspirations of one-day expanding to wholesale distribution, it’s not necessary to predict a need for, say, inclusion of expiration dates and lot-number sorting on product recall reports. But, you should be considering whether the product is utilized only by retailers or whether there is a robust community of distributors running the software to meet their wholesale needs. Another shortcut to understanding the functional breadth of different systems is to use a resource on this website. We’ve identified and discussed [over 50 categories of applications] that appear frequently as part of ERP systems. Feel free to use our collection as both a checklist to score a given products comprehensiveness as well as a gateway to drill deeper into the features found in each module.