Common Problems with Scaling Software Technologies in SMBs

Problems scaling small business software trimmed

As a business grows, invariably it experiences inefficiencies and the need for automation, analytics, and other technology tools to compete on 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 observed some problems that appear common - causing unexpected and sometimes severe damage, though every time they appear clear and preventable in hindsight. Keeping this in mind can help better understand and reduce risks.

This article is for the non-technical managers or company owners who need to make decisions on business software but who are not experts in the software or development fields. It provides a few examples on how business technology issues develop and basic advice on how to possibly avoid them.

The issues can seem obvious - I’m sure that many people who work in corporate environments 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 has to do with the lack of strategic planning for general technology implementation. The overall strategy can cover 3+ years of operation; and the choices you make at different times can be in-synch with the end goal or take you off-course and require significant investment to fix.

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 self-service, freeing up the time of the customer service team. Already using QuickBooks Online for accounting and invoicing, the company quickly chooses to implement Shopify or WooCommerce for the online store.

The online store is live within a few months, then website visitor analytics is added to it, then the catalog starts 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 added via a few-months-long project, requiring a full process change with employee re-training (while the team is already at their limit supporting existing sales and making the manual inventory tracking efforts they have rigged 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 amount 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 place for the sales team to login to.

Another year in, the management sees that there are still some manual data transfers made on an on-going basis, and that the business intelligence system that they now want to add cannot easily obtain all the data, as it is stored between multiple systems and in different formats. So the whole set of integrations is rebuilt into a horizontal system via a 6-month long project, requiring another process change with staff retraining, and a data structure change that makes CRM records behave differently before and after the integration, making 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, 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 make a decision 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) would be 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 figure if they are truly in or just saying it to get 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 instead of around the time they need to spend with you. Ask for estimates for what you may need over the next 3 years and ask the consultants/employees to break it up into phases, providing options on how to reach 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 its unavoidable to have multiple pieces of software and even multiple consultants – just get the stakeholders to acknowledge responsibility and point out the likely issues up-front.

Lack of business and functional requirements prior to 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 starts as a small-budget project with the hope of a quick success. The effort starts with a purchase of an off-the-shelf “integration module” (or using an out-of-box integration provided with the software) and is driven by developers, with limited business use requirements input upfront. Once the “base” integration is done and paid, missing functionality is quickly found in testing or live use.

From there, either the users adapt and create semi-manual processes to go around the integration flaws, or the company pays for on-going improvements as flaws surface over the next 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 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. Make an outline of 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 the data should be entered by users 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 have to spend an extra day or two up-front to make a simple plan, but your team would likely spend even more on testing and figuring 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 re-doing 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 for ideas on setting requirements for your integration needs.

~ by Andrey Kolesnikov, business development manager at Steersman