Exclusive: 5 challenges which hamper supply chain flexibility
Inflexibility is the bane of an efficient supply chain. Ironically, the problem is often rooted in supply chain software that years ago was billed as delivering the flexibility that companies needed for fast and adaptable inventory and supplier management, distribution, sales, purchasing and manufacturing.
Manufacturers and distributors have indeed gained important flexibility over the past two decades with implementations of ERP and other supply chain applications and the adoption of Six Sigma, Lean manufacturing, Kanban and other approaches. But the ideal of flexibility is a moving target. As time passes, they’re facing new challenges that their on premise software systems are ill equipped to handle.
Changing market conditions. Customer expectations for speed and low cost have reached new highs in our always-on, digital and global world. Economic and supplier volatility are a constant threat to supply chain continuity. Meeting such challenges requires real-time transparency that yesteryear’s applications can’t support.
Systems sprawl. Over the years, organisations have duct-taped together various point solutions to run their supply chains. This systems sprawl now confronts them with poor visibility and limited capacity for internal and external collaboration while requiring manual workarounds just to maintain baseline performance.
Inherently poor customisability. On-premise ERP is notoriously difficult to customise. Tweaking an application to accommodate new needs in order management, purchasing or other areas can take a team of developers; often from a costly third-party consultant, weeks if not months to accomplish.
Version lock. Dreading the time, expense and disruption of upgrading on premise software, many organisations make do with “business as usual,” effectively locked in to outdated software. If they do elect to upgrade, they risk losing any customisations that they did build into their systems.
Subpar compliance and security. Without the ability to readily customise software, organisations often resort to documenting data, metadata, processes and audit trails outside the core ERP, in spreadsheets or disparate applications. Without a single authoritative record, compliance, security and auditability can be compromised.
These weaknesses conspire to undermine a company’s competitive position. It’s difficult to synchronise processes for maximum efficiency, or to pursue innovations. Costs creep up, while customer satisfaction and retention can be jeopardised. Meanwhile, some competitor that has mastered supply chain flexibility is winning new business and gaining an advantage in increasingly fast-paced and volatile markets.
A flexible and visible supply chain has become an imperative in today’s business environment, the global consultancy PwC said in its article ‘How a Flexible Supply Chain Delivers Value’. Getting there will require companies to prioritise supply chain operations and tightly align them with other business functions.
Adapting software to the business
Limitations in the bespoke nature of on premise ERP is a key culprit behind supply chain inflexibility. Companies are forced to adapt their business processes to the constraints of their software, rather than adapting the software to their business processes. Yet for a growing number of enterprising organisations, cloud ERP is changing the equation.
Google and NIST Address Supply Chain Cybersecurity
As high-level supply chain attacks hit the news, Google and the U.S. National Institute of Standards and Technology (NIST) have both developed proposals for how to address software supply chain security. This isn’t a new field, unfortunately. Since supply chains are a critical part of business resilience, criminals have no qualms about targeting its software. That’s why identifying, assessing, and mitigating cyber supply chain risks (C-SCRM) is at the top of Google and NIST’s respective agendas.
High-Profile Supply Chain Attacks
According to Google, no comprehensive end-to-end framework exists to mitigate threats across the software supply chain. [Yet] ‘there is an urgent need for a solution in the face of the eye-opening, multi-billion-dollar attacks in recent months...some of which could have been prevented or made more difficult’.
Here are several of the largest cybersecurity failures in recent months:
- SolarWinds. Alleged Russian hackers slipped malicious code into a routine software update, which they then used as a Trojan horse for a massive cyberattack.
- Codecov. Attackers used automation to collect credentials and raid ‘additional resources’, such as data from other software development vendors.
- Malicious attacks on open-source repositories. Out of 1,000 GitHub accounts, more than one in five contained at least one dependency confusion-related misconfiguration.
As a result of these attacks and Biden’s recent cybersecurity mandate, NIST and Google took action. NIST held a 1,400-person workshop and published 150 papers worth of recommendations from Microsoft, Synopsys, The Linux Foundation, and other software experts; Google will work with popular source, build, and packaging platforms to help companies implement and excel at their SLSA framework.
What Are Their Recommendations?
Here’s a quick recap: NIST has grouped together recommendations to create federal standards; Google has developed an end-to-end framework called Supply Chain Levels for Software Artifacts (SLSA)—pronounced “Salsa”. Both address software procurement and security.
Now, here’s the slightly more in-depth version:
- NIST. The organisation wants more ‘rigorous and predictable’ ways to secure critical software. They suggest that firms use vulnerability disclosure programmes (VDP) and software bills of materials (SBOM), consider simplifying their software and give at least one developer per project security training.
- Google. The company thinks that SLSA will encompass the source-build-publish software workflow. Essentially, the four-level framework helps businesses make informed choices about the security of the software they use, with SLSA 4 representing an ideal end state.
If this all sounds very abstract, consider the recent SolarWinds attack. The attacker compromised the build platform, installed an implant, and injected malicious behaviour during each build. According to Google, higher SLSA levels would have required stronger security controls for the build platform, making it more difficult for the attacker to succeed.
How Do The Proposals Differ?
As Brian Fox, the co-founder and CTO at Sonatype, sees it, NIST and Google have created proposals that complement each other. ‘The NIST [version] is focused on defining minimum requirements for software sold to the government’, he explained, while Google ‘goes [further] and proposes a specific model for scoring the supply chain. NIST is currently focused on the “what”. Google, along with other industry leaders, is grappling with the “how”’.