Common Problems with Scaling Software Technologies in SMBs

As a business grows, it invariably experiences inefficiencies and the need for automation, analytics, and other technology tools to compete in the market or even remain in business. There are many potential issues with scaling business software technologies. Over the last few years at Steersman, I have observed some problems that appear common, causing unexpected and sometimes severe damage. Although they often seem clear and preventable in hindsight, they still appear frequently. Keeping this in mind can help better understand and reduce risks.

This article is intended for non-technical managers or company owners who need to make decisions about business software but lack expertise in software or development fields. It provides a few examples of how business technology issues develop and offers basic advice on how to avoid them.

The issues can seem obvious - I’m sure that many people who work in corporate environments have observed the “results” at some point. Yet, the decisions leading to these issues continue to be made every day in every industry.

No mid- and long-term business software scaling plans for viable company development scenarios

A common software scaling problem is often attributed to a lack of strategic planning for general technology implementation. The overall strategy can span 3+ years of operation, and the choices you make at different times can be in sync with the end goal or take you off course and require significant investment to rectify.

Example scenario - lack of technology plan aligned with business strategy

A company has an immediate need to create an online store to offer its 200 products online and allow existing clients to use self-service, freeing up the time of the customer service team. Already using QuickBooks Online for accounting and invoicing, the company quickly chose to implement Shopify or WooCommerce for the online store.

The online store will be live within a few months, after which website visitor analytics will be added, and the catalog will start to grow. Over the next year, the product offering expands to over 1,000 products, sales grow, and the company now needs warehouse and shipping management functionality that isn’t supported well enough by the online store or accounting system. The team is overloaded due to low efficiency and manual data transfers, profits are low, and morale dwindles. Upgrade or suffer, even though cash flow is now limited.

At this point, a search for a new system is undertaken, and a budget-friendly inventory system is implemented through a few-month-long project, requiring a full process change with employee retraining (while the team is already at its limit supporting existing sales and managing the manual inventory tracking efforts they have put together). Two semi-custom integrations are made to connect the new system to both the online store and the accounting software. This also brings the total number of logins that users need to 3.

Half a year later, it is decided that the sales process is struggling without a CRM, so it is added on top, partially integrating with the existing infrastructure. This adds another login for the sales team.

Another year in, management realizes that manual data transfers are still being made on an ongoing basis, and that the business intelligence system they now want to implement cannot easily obtain all the necessary data, as it is stored across multiple systems and in different formats. The entire set of integrations is rebuilt into a horizontal system through a 6-month project, which requires another process change, staff retraining, and a data structure modification that alters the behavior of CRM records before and after the integration. This change renders some data no longer suitable for analysis.

Then the inventory system provider stops supporting the old version, and an upgrade is needed. Etc…

How to reduce growing pains in information technology initiatives as the business expands

The “fundamental” fix is to consider various scenarios of where your company may be in a few years, what tools the staff may need, and what type of oversight and controls the owners or managers may want to have over the entire operation.

I understand you are likely reading this as you are preparing to decide on certain technology or partner, so:

If you want to implement a new software system or integrate two or more systems, consider whether your provider (an employee or external consultant) is capable of continuing to work on further systems, integrations, and support. Ask them for input on your future business plans. See if they’ll be with you for the whole run and try to determine if they are truly committed or just saying it to secure the deposit. See if you can motivate the employee(s) based on success, or structure the supplier’s maintenance/support fees around success and uptime, rather than the time they need to spend with you. Request estimates for what you may need over the next three years and ask the consultants/employees to break it down into phases, providing options on how to achieve the target results over time.

The more players involved (software providers, integrators, consultants, staff), the more fingers would potentially be pointed as the responsibility for the cohesiveness of your systems gets distributed. Sometimes, it’s unavoidable to have multiple pieces of software and even multiple consultants. Get the stakeholders to acknowledge responsibility and point out the likely issues upfront.

Lack of business and functional requirements before starting technical integration work

One of the common causes of problems when integrating two or more business software applications or making a non-trivial system implementation is skipping upfront business requirements planning and functional specifications.

Example scenario - no detailed specs at the start of an integration project

An integration project typically begins as a small-budget endeavor with the hope of achieving quick success. The effort starts with the purchase of an off-the-shelf “integration module” (or utilizing an out-of-the-box integration provided with the software). It is driven by developers, with limited business use requirements input upfront. Once the “base” integration is complete and paid, any missing functionality is quickly identified during testing or in live use.

From there, either the users adapt and create semi-manual processes to get around the integration flaws, or the company pays for ongoing improvements as flaws surface over the next few months.

When choosing to significantly modify the packaged integration to better match business needs, the company may lose the ability to use updates and support from the original off-the-shelf integration provider, as the integration is already “custom”. As each software piece continues to evolve and update, integration issues appear. The suppliers of software systems and the integration often point out that the issues are due to the work of another provider, so all further work is paid out-of-pocket because the “included” support no longer covers the problems.

How to reduce issues stemming from business system integration scope creep

Don’t assume that your developer team will know how to integrate your software systems in a manner that’s perfect for your business operations without investing reasonable time into understanding your process needs. Outline the standard business processes in the systems you need to integrate and figure exactly what the systems need to do for each of the processes – what data is sent/received and when, where users should enter the data and where it must pull in automatically, whether you need to block data editing in certain places in one of the systems, etc.

You or your consultants may need to spend an extra day or two upfront to create a simple plan, but your team would likely spend even more on testing and resolving the same issues later. Do this upfront so you stay in control of the time spent on investigation, save on the cost of your developers redoing work, and get a clearer picture of the total cash you’ll need to spend on the work before you pay the developers for already completing what they assumed you needed.

If relevant to you, see my other article with a checklist for an integration between an online store and an inventory management system. Use it as a reference for setting requirements for your integration needs.

~ by Andrey Kolesnikov, business development manager at Steersman