May 17, 2020

Modern warehousing must keep up with eCommerce

Warehouse Management Systems Software
Hein Pretorius CEO and founder of Onpro Consulting
eCommerce warehouse management
Ordering technology warehouse managem
Nye Longman
4 min
Modern warehousing must keep up with eCommerce
Warehouses: where dreams become reality … or turn into nightmares


E-commerce is no longer considered a fad, and the online race for capturing t...

Warehouses: where dreams become reality … or turn into nightmares
 

E-commerce is no longer considered a fad, and the online race for capturing the biggest share of the customer’s wallet has left many a traditional retailer trailing behind.

What’s left them behind is not the technology that makes online shopping possible, but the offline movement of ordered goods that are still largely managed by processes that were put in place when physical stores were the only option available to customers.

It is during this offline chain of events that buyers can either be impressed into becoming loyal customers, or put off to such an extent that they lose all faith in a supplier.
 

So much effort can be spent on developing a slick online shop that makes browsing virtual products easy on a device that fits comfortably in the palm of our hand, that it’s easy to forget that the promises made on the online platform need to be kept by those working offline with physical products stored in and distributed from huge warehouses.

Irrespective of how advanced the ordering technology used by customers is, a warehouse still runs on basic principles of receiving, sorting, and storing goods until it is time to pick a certain amount of goods from a shelf, pack it as per the customers’ order, and direct it to the correct delivery vehicle.

To keep up with the orders flowing in from multiple platforms that are never closed for business, warehouses need some form of system driving it. The technology can be as complex as an entire warehouse run entirely by automated machines, or as simple as a system telling the people in the warehouse where items must be stored.

Many of these systems are however still paper based, which is not reflective of the advances made in technologies allowing customers to easily place orders.
 

The main reason that many warehouses keep their operations paper based is to avoid the problems that have been reported with implementing a Warehouse Management System (WMS). The biggest challenge to implementing any warehouse management systems is the realtime nature of a warehouse; if a system isn’t running properly, it has a realtime, real life impact. If the system can’t tell where the goods need to move, everything is standing still.

We have seen WMS implementations so disconnected from the way the business is actually operated, that staff members refuse to use the system and revert back to their paper based ways of getting things done. This is not only a significant waste of a significant investment by the company, but does nothing to decrease the risk or increase the competitiveness that the WMS implementation was intended to address.

To avoid this type of disconnect, a few fundamentals should be considered before making a decision on which type of WMS would be most suitable to deliver on the promises made by a supplier.

Understand more than just your area of responsibility

Warehousing is part of a larger chain of events, and the more you understand the larger supply chain, the better recommendations you can make to others on how the whole chain can work together to meet changing customer demands.

Understand the difference between exciting features and real business purpose

It’s very easy to get sidetracked by a large list of features once you start investigating WMS, but be warned. A WMS should be built around processes that already work optimally. Processes should not be changed or created just to accommodate a system feature that is often not as robust as marketing material may make it seem.

The decision on a WMS should be made based on an understanding of the business purpose; the true value the business wants to deliver to its customers.
 

Understand that it’s about slow and steady, not rushed and ready

The realtime nature of warehouse operations demand that a new WMS disrupts normal business as little as possible. This is only possible if all stakeholders in the WMS project team understands that rushing the initial planning process, and skimping on dry-run tests, almost always guarantees a problematic or even catastrophic implementation.

Make sure time and budget is made available for running tests throughout the project based on one version of the truth which is established and maintained on a live, cloud-based, collaborative, platform. Testing at the end of a WMS implementation project based on static documents that were created at the beginning of a project causes problems based on a disconnect between the greater business processes, what the business is doing, and what the system is supposed to do.

Hein Pretorius is CEO and founder of Onpro Consulting

Supply Chain Digital's July issue is now live. 

Follow @SupplyChainD and @MrNLon on Twitter.

Supply Chain Digital is also on Facebook. 

Share article

Jun 21, 2021

Google and NIST Address Supply Chain Cybersecurity

Google
NIST
SLSA4
Sonatype
Elise Leise
3 min
The SolarWinds and Codecov cyberattacks reminded companies that software security poses a critical risk. How do we mitigate it?

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”’. 

 

Share article