Massive Orders Posting 76% Faster? That’s Right!

Speeding up 500+ line orders

A few months ago, we began work on a solution to reduce RFC response time between Corevist Commerce and SAP. One of our clients routinely takes large ecommerce orders with 500+ line items. As I explained in the first post in this series, this client’s customers couldn’t justify the cost of an EDI solution, so that was off the table. These orders had to come in through ecommerce—but the client’s SAP system took forever to process our real-time calls on 500+ line items.

Today, I’m happy to report that our solution to the problem is in production (and working beautifully). We’ve achieved a 76% decrease in response times on these large orders. For orders around 100-200 line items, the improvement is even greater—an 86% decrease in response time.

Here’s how we slashed response times (and what that means).

The solution: Order chunking and parallel processing

We knew that if we broke up large orders into smaller chunks, we could process them in parallel. Essentially, we would process 10 50-line-item orders to SAP simultaneously rather than processing 1 500-line-item order. Due to our solution architecture, economies of scale come into play when chunking orders like this. The key was to determine optimal order size.

Using real performance data, we ran tests to find the optimal order size. Our experiments showed that SAP processed chunks of 25-50 line items fastest. We implemented order chunking in that sweet spot, with chunks processed in parallel.

The results are pretty amazing.

The results: 76-86% decrease in response time

Let’s look at the numbers. I’ll show you two representative scenarios—one for a massive order, one for an order that’s about a fifth that size.

Scenario 1: 861-line-item order

Here are the processing times before and after chunking:

  • No parallel processing = 671.7 seconds (11:11 minutes)
  • 5 sessions, 40 lines at a time = 168.0 seconds (2:48 minutes)
  • 8 sessions, 50 lines at a time = 160.8 seconds (2:41 minutes)
  • 5 sessions, 20 lines at a time = 173.2 seconds (2:57 minutes)
  • 76% decrease in order processing time.

Scenario 2: 169-line-item order

Here are the processing times before and after chunking:

  • No parallel processing = 234.0 seconds (3:54 minutes)
  • 5 sessions, 25 lines at a time =  33.0 seconds
  • 5 sessions, 35 lines at a time =  40.5 seconds
  • 5 sessions, 17 lines at a time =  34.2 seconds
  • 86% decrease in order processing time

What this means for our client and their customers

A non-EDI solution for small customers of our client

As I mentioned above, small companies don’t want to invest in EDI. That made it difficult for them to place large orders with our client. After waiting 5-10 minutes for SAP to process the data from Corevist Commerce, these customers would often find order errors. They had to correct the errors, then resubmit, possibly getting new errors after that. The process was totally impractical.

Now, instead of 5-10 minutes, our client’s customers are waiting 30 seconds to 2 minutes. That’s a huge gain in efficiency, reducing friction in the buying process. It aligns with one of the biggest reasons B2B companies choose Corevist Commerce—they want to become easier to do business with.

An error-free solution that trumps EDI

As our CEO Sam Bayer explained in this EDI blog post, EDI creates errors. If you’ve been around this business awhile, you know for yourself that EDI has some dark secrets. Because EDI orders aren’t verified as accurate in real time, the customer can’t fix them in real time before submitting them.

That’s why the vast majority of EDI transactions fail. An EDI order looks great to the customer. They send it in and think, “Great, we’re all done here, my order will ship tomorrow.” But it’s not until 24 hours later that the customer finds out it’s not all good when a Customer Service rep calls back. One of the more common error conditions occurs when the customer sends their own SKU number that isn’t recognized by the manfacturer’s SAP system. All that was missing was a translation from one SKU to another–but EDI can’t provide that automatically. As a result, the customer has the illusion that the order is ready to go when in fact, SAP is going to reject it and a CSR will have to get involved.

Uh oh. Now the customer has to fix their order. That’s more time and money wasted, both for the customer and the client.

An elegant, hands-free solution that processes large orders with 100% accuracy

Let me put it in terms of numbers. In a nutshell, we took a 24-hour waiting period (EDI ordering) which produced defective orders 60% of the time, and we compressed it to a 40-second period that produces 100% order accuracy. If anyone doesn’t understand why they should use the website for large orders, this makes it clear. You have 2 choices: take 24 hours and get errors, or take 40 seconds and know it will be 100% right.

Moving forward: Case study

Want to know more about real-time order posting to SAP? Read this case study on Blount International. You’ll learn how Blount’s customers started posting 100% accurate orders to SAP in real time only 90 days after the project initiation. Go download it now.

Learn more

Case study: Blount International

Learn how multiple departments came together as Blount International launched ecommerce.
Download Now
See it for yourself

Talk to us

Curious what Corevist Commerce can do for you? Let us show you a personalized demo. You'll see ecommerce with real-time SAP data.
Schedule Demo

Subscribe to our blog