By Omar Singh, president and founder, Surge Transportation
Do you remember studying something in school and asking yourself or your teacher, “When am I ever going to use this?” Well I asked that once of a professor when talking about a calculus class. He explained that we were not studying calculus because we were going to use it in whatever jobs we ended up having. We were studying it to learn how to solve complex, multistep problems: “I know you are not going to use the quadratic equation in your job, but you are going to have to come up with solutions to complicated problems that involve many steps.” I accepted that answer as it seemed to make sense, and honestly it’s been one of my favorite parts about building automation — although only some of the problems are complicated and multistep; others are just routine, repetitive tasks.
Application programming interface vs. robotic process automation — what is the difference? As I learn more about APIs and RPA, I think the main high-level difference is that one works inside your system as an integrated partner (API), while the other works outside your system as a guest user (RPA). They are both forms of automation that involve programming a logical series of decisions and then executing those decisions dozens or hundreds or thousands of times per day. I kind of work at the “if/then” level of decision making and then let the programmers write the code. If refrigerated, then bid; if hazmat, then apply accessorial; if past dates, then do not bid. If refrigerated hazmat with past dates, then which rule applies?
If you are using APIs, then you are integrated partners and working inside of a system — in our supply chain world it is transportation management systems (TMSs) — both shipper and service provider systems. Typically there is substantial financial investment developing the partnership and mapping the systems to communicate with one another. Rather than logging on each time, there is an authentication key that allows constant open access and exchange of information. Most of the information we exchange with shipper TMSs like BluJay, Blue Yonder, Mercury Gate and Oracle is load and rate information — real-time rates. They provide the origin, destination, date and trailer type; we provide a rate. We repeat that exchange a lot. With our own brokerage TMS we have activated API capabilities and are automating go-live schedules for loads, target buy-rates and revenue codes. For example, if a quote ID is present, then, change the revenue code to real time; if no quote ID is present, then default the revenue code to primary award. The point here, though, is that we are integrated working inside of connected systems.
If you are using RPA, then you are not integrated and are working outside of the system as a guest logging on. The decisions can still be automated, tasks can still be automated, but the substantial financial investment is in programming the tasks from the outside rather than integrating a partnership from the inside. In the example of pricing, the bot is logging into a shipper TMS, either exporting or scraping load information, then leaving that system, likely logging on to a pricing engine to retrieve and apply logic to determine a rate, then perhaps logging into a broker TMS to record that rate, and going back to the shipper TMS to provide that rate. At the end of the day, it’s automation and applying a set of rules. The result is the same, it’s just from the outside.
Build vs. buy
In the past, I was a pure advocate of only buy. Let the tech companies do technology; let the supply chain companies build and move freight. I worked at large national supply chain firms with proprietary software that may have been cutting edge when they created it but could never really keep up year after year with periodic releases and updates the way technology companies can. Also, technology companies have the advantage of a large pool of different users who ask for modifications and enhancements that get pushed out to the community of other users. It is not just the ideas of a small team of developers that enhance the product, but the ideas of all of the users — better results in the end.
However, in 2019 we started building as well and it has changed our whole business model — it turned out to be good for us. We even bought an API module for our bought TMS, which allows us to build custom capabilities inside of the system and integrate automation with tools outside of the system. So for us it’s definitely both build and buy. We are a better company that can handle higher volumes with more accuracy while simultaneously reaching out to our carrier partners more quickly as a result of designing these multistep automatic or repetitive solutions. I’m a big fan of doing whatever works for you — yourself, your company, your family — and recognize there is no one size fits all, but in the case of automation I think just find your way to get started and you should achieve some positive results. I haven’t met anybody who has said otherwise.
More from Surge Transportation:
Perfectly executed routing guides fail 100% of the time
7 Steps to Strategic Partnership Between Shipper and Service Provider