Dexion designs 3.5 million garment-strong Dubai distribution facility
In the United Arab Emirates, logistics solutions company Dexion has been busy designing a high volume, fast moving distribution centre in Dubai for a major retailer responsible for the distribution of more than one million garments per week across the Middle East, North Africa, Russia, Turkey and Europe.
In a distribution centre located in Dubai’s Jebel Ali Free Zone, 3.5 million garments hang, almost enough to clothe the population of Dubai twice over. The labels include some of fashion’s most sought after names. During a busy week, anywhere up to 1 million garments will leave the building, only to be replaced by a million more.
Alongside these garments, there are tens of thousands of storage positions allocated for flat packed items, all of which will be delivered to shopfronts around Europe and the Middle East.
The facility of this UAE Retailer was completed in 2013. It represents a major expansion to Jebel Ali’s Dubai distribution centre, which houses one of the leading retail franchise operators in the world. This UAE Retailer manages more than 2,500 retail stores across the Middle East, North Africa, Russia, Turkey and Europe. In July 2011, it engaged leading storage and materials handling specialist, Dexion to design the high volume, fast moving distribution centre, with a team drawn from the company’s regional network. Dexion’s General Manager of Sales in Asia and the Middle East, Simon Ingram was thrilled that the UAE Retailer selected Dexion as its partner.
The Retailer’s franchise business was founded in 1983. In recent years, its footprint has grown at a rapid rate. The existing Jebel Ali distribution centre was built in 2007 and reached its design capacity just four years later. Despite its significant capability, the site is also expected to reach capacity by 2016. A third site is already at the advanced planning stage.
When first approached to work on the project, Dexion’s team of specialists insisted on reviewing the raw data behind the statistics included in the RFP.
“Some businesses prefer not to issue raw sales data, growth and acquisition projections. However the numbers helped the team define a very clear baseline, from which we could then design the most efficient storage and materials handling solution. For example, we found that we could significantly change the footprint of the existing facility by reducing the flat-pack storage areas by 25 percent and further utilising the planned GOH (Garment On Hanger) storage,” said Ingram.
Construction of the site began in October 2011. Components and equipment were sourced from Dexion’s Asian manufacturing plants and material handling equipment partners. Dexion configured the RDS (Real-time Distribution System) software to meet the client’s defined business requirements.
Dexion’s Project Manager, Murdo MacKinnon described the project as having two distinct phases. The first was the construction of the new building, which adjoined the existing and operational DC.
He said: “A challenge to implementation was the fact that the existing site had to remain operational throughout construction. Timelines were short. Our teams literally worked right in behind the builder as each cured slab was available for handover.
“We installed the VNA (Very Narrow Aisle) Racking, a storage solution providing 36,000 pallet locations and a rack-supported 4-tier GOH solution providing storage capacity for 3.6 million garments.
“Servicing these GOH storage locations required over 12 km of overhead monorail garment conveying rails and trolleys. They also demanded over 4 km of carton conveyors to facilitate the movement of the flat pack items. Each aspect of the DC is centrally controlled by Dexion’s RDS, which acts as the Warehouse Control System (WCS).”
Construction of the new building was completed on schedule after a 12-week construction period.
With the Retailer’s stock sourced globally, most items arrive by sea freight, spending between 3-6 weeks on the water. As part of the project, Dexion and its client were determined to reduce the amount of time that the stock spent on the water.
According to Ingram, cross-docking capability is important as it’s impossible to sell product when it’s in the warehouse. MacKinnon agrees.
“Rather than waiting until the stock arrives to complete the process, we implemented a solution whereby stock is pre-allocated to the stores while still on the water. Using the ASN, when goods are unloaded, the pre-allocated orders are transported via the conveying system to the multi-tier, ‘put-to-store’ module. Then it’s packed, sorted and palletised for dispatch to stores in Dubai or across the wider Middle East. A large percentage of stock will be managed in this manner, with the remaining store replenishment stock to be stored in the DC,” said MacKinnon.
The second phase of the Jebel Ali project involved converting the existing facility and integrating it with the neighbouring new facility. This aspect was still underway at the time of writing this article. In the final solution, the new facility will play a pivotal role in the facility’s cross-docking capabilities – the area contains flat-pack and GOH put-to-store processing modules, tote and carton conveying, garment conveying and carton sortation.
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”’.