During IntelliShift’s ConnectedOps Virtual Event, senior product manager, Tim Webster, discusses the impact data silos have on an organization and how having data trapped in individual systems and departments reduces efficiency, productivity and profitability. However, breaking down the silos and bringing data sets together using a platform that offers easy integration with an API unlocks business intelligence and additional ROI.
Below is the transcript of this session. You can also watch the session and view all sessions from ConnectedOps 2020.
Tim Webster: Good afternoon, this is Tim Webster. Welcome to Best Practices in IT/API Integrations as part of the ConnectedOps 2020 Conference. I hope so far all the sessions that you’ve gone through today and have provided valuable information and you’re finding today is a valuable day in getting this out of this and helping your businesses grow and move forward.
To give you a little introduction throughout what we’re doing here today, as I mentioned before, I am Tim Webster, the Senior Product Manager here at IntelliShift, and my goal is to understand your business needs, what you need from a company, and what we need to build and communicate that back to our development teams and what products we need to build and things along that line. A couple of bookkeeping notes as we’re going forward today. If you have a question as it’s coming along, we’re going to have some Q&A at the end, but feel free to type those messages into the chat box as we’re going forward. So, if they come up, put them in there, and I’ll address them at the end. If time allows, I may be able to go through and answer them as we need to, but we’ll really have time for Q&A at the very end of this conference or session, as well as we go.
Let’s go through, take a look at a couple of things as we talk about things, and going through taking a look at this image, and what I really want to start talking about is does this picture resonate with anything with your company’s application ecosystems? We have a whole bunch of silos that we’re looking at, and in my previous jobs, and even here at IntelliShift, working with customers and what they do and things along that line is that their software applications and the data that they had was very siloed, right? “We know what we know in my little bubble,” frequently. I know, and if I’m in the billing department, I know what needs to be billed. If I’m in the maintenance department, I know what needs to be maintained in my vehicles, in my assets. If I’m on the dispatch side of it, I know the data about my dispatch and where my vehicles are going, but sometimes, bringing all of that information together is challenging, and that silo idea is really something that we want to look at, and we want to find a way to help you gain value, gain data, so that we’re not looking in these massive silos and these massive approaches. So, really, what we’re trying to get through in this API deal, the APIs within IntelliShift, is using that as a platform that will allow you, within your companies and with the applications that you’re using, to be a connector, to bring all of that information in together and to start breaking down some of those siloes.
Now, before we get into a lot of the data about the APIs, what they are, what you can do with the IntelliShift APIs, I want to talk a little bit about the idea of siloed data and what are the overall impacts of having siloed data. We know what they are, we’re living in these bubbles in our own little worlds, and we’re not really communicating from one side to another. So, as I was doing preparation for this, I came across a number of articles and surveys, and one of them really resonated with the conversation that we’re having today.
So, there’s four big points that I want to talk about. We have financial loss, difficult to analyze data, decrease in employee productivity, and then delayed and flawed decisions. So, to just kind of get an idea of all of these connecting and going through, they’re similar, but there’s an impact in each and every one of them. Let’s start at the top with the financial loss. As I was reading, I came across a Snap Logic survey that estimated that companies in the U.S. and the U.K. alone lose upwards of $140 billion per year, and let me emphasize that, that’s billion with a “B,” because their data is not properly connected and it’s in a siloed fashion. From missed opportunities, to unproductive workers, the cost to the organizations in these two countries alone is completely staggering. I mean, $140 billion is nothing to sneeze at, and if you can recapture some of those dollars and cents, what can you do to your bottom line? Where could your companies be if we were able to eliminate a lot of that financial loss? So, just keep that in mind, that that’s just two countries alone and where that would come into play. If we’re in the global aspect of it, imagine the value in the dollars and cents from there. And, that leads into some of these other things.
The difficulty in analyzing data. If we’ve got disconnected systems or disparate systems, the analysis that we require to get the information that you need to do your day-to-day operations requires a significant amount of heavy lifting. So, if you need to know, what is the real cost per mile for your assets and your vehicles to drive down the road, if you don’t have all of that data connected, you’ve got to go to the maintenance department to get an idea of what does it really cost to maintain this asset? We need to get to the payroll department or the HR department to find, what does it cost me to pay this driver to drive this vehicle down? What is my overall fuel cost? What is my insurance cost? Right? And, you start to bring all of that information together, now you have got to analyze that, you’ve got to put, manually, information together. And then, getting all of that gets you into leading to decreased productivity, right? We’ve got to go in, and I’ve got to go ask John, “Hey, what was the maintenance spend on this asset last month or last year?” and then we’ve got to go to somebody else and say, “Well, what do we really spend on fuel?”
So, now we’ve got to get all of this stuff, we’ve got to manually collect it, we’ve got to put it into a database or put it into spreadsheets, and really start to do this, so we’re spending a significant amount of time to get to the point of getting the analysis that we need to. So, again, it’s difficult. The productivity drops, and then if we don’t have that, it leads to delayed or flawed decisions. We live in a world now that is, “We need answers now,” right? There’s not that, “Give me this and give me an answer in a couple of weeks.” We’ve gotten into that mindset that, “I need a decision and I need it now,” and a lot of that comes from that Amazon effect: we’re so used to ordering things and in two days, it’s on our door, or, “I can order something and go pick it up right now.” So, we’re conditioned that the world is moving quickly, and we need to have that information now. So, if I have to manually collect data and manually analyze this, that might take days or weeks when you don’t have that time right now. I need to make a decision in real-time.
I’ve had customers in the past, in different worlds, I’ve worked in the transportation industry, I’ve worked in the construction industry and software companies and both of those, and I’ve had customers that lost business because they didn’t have that data available to them. Whether they lost the ability to bid on a contract, or to bid on lanes and things like that for delivery mechanisms or a service contract, because they didn’t have that information readily available. Or, a vehicle breaks down, and now we need to make a decision today whether we fix it or replace it. If we don’t know the overall maintenance spend for the last three, four years, they may have gone and spend $6,000 or $7,000 to replace or repair the vehicle, when if they had looked at it, “Well, we’ve spent $50,000 over the last three years just maintaining this when we could have replaced it for $60,000 and gotten significantly more value into that.” So, having that information and that data at your fingertips is critical in value. So, we’re trying to get to a point with using these details, getting all of this information together so that you can make effective decisions in the timeliness and the quickness that you need to go through and do that. So, that’s really where we’re going, and I want to use the idea of APIs, or talking about APIs, as that connector and that layer between where do we gather all of this information together, and how can we present this into a singular fashion?
So, we’re going to talk a little bit here, just getting started, about the idea of how can I break these silos? How can I connect these dots by using APIs? Before we go through some real world scenarios and some real world examples, I’m going to get into some basics about an API: what are APIs? Things of that nature. This is not intended to be technical, we’re not going to go through and talk about coding standards, using APIs, so you’re not a developer or at development level, that’s perfectly fine, we’re just getting high-level details in this.
So, first and foremost, what is an API? API is an acronym; it means application programming interface. Now, what does that mean? Very simply, it’s a program, a computer application, that allows one software application to easily communicate to another through simple commands using things like get, so I want to get a driver ID, I can go in and call the driver through the API and get all the information of the driver, or get the hours of service information. Put, I want to put something in or delete. But, there’s a process flow to go through that, so that’s ultimately what an API is.
What are some benefits that we can do? First and foremost, we have a simplified integration. We have standard APIs that are published and available if somebody wants to build an integration from one platform to another, it makes it simple to connect and share the data between those applications. If we wanted to build a mobile application that uses the IntelliShift data, we could do that through the APIs or connect other pieces. So, just using some examples that we’re going to talk about here in leading into that. We can also help with task automation. So, things that were previously done manually, we can program that to be completed automatically.
Think about if a new asset or a new vehicle is purchased. If we have to maintain it, if we have to talk about dispatching it in terms of where it’s going into it, if we have to talk about billing for it, if we need to talk about a telematics aspect of it, real quickly, there’s four different locations that you might have to go through and configure and set up that same asset or that same trailer, vehicle, tractor, however you want to look at it, so that duplication of effort could take time. Well, what if there was a way that an API allowed you to create it in one place, and that’s the single source of truth, and then an API connects and populates all the other things? So, then your configuration, your implementation, your vehicle IDs, the asset IDs, are all consistent between those applications. But, you only have to do it once. Or, if we need to import fuel details, what is my fuel usage? What is my fuel spend? I can pull that in.
So, a lot of those things that may have been manually done before, APIs can assist you in setting that up and helping to connect those pieces again. It also helps with innovation, because if we have these existing APIs, companies, and I’ve seen this in multiple locations, companies will – or have the ability – to say, “Well, maybe the application doesn’t provide me what I need, but it gives me this connector, so I can go through and I can create my own application or I can create my own connector between application A and B, and now I have, instead of two or three systems, I’ve got one, and they’re connected again, and I can build and I can create on top of that.” So, again, those are three things that help with that: integration, automation, and innovation. Now, we have this option of REST versus SOAP.
They’re two different API protocols. We at IntelliShift provide options for both. Again, not going to talk super tech here. REST is representation state transfer, and SOAP is simple object access protocol, again, just two different platforms of APIs. Depending on what you’re looking for and as we build things out, we do provide API endpoints in both REST and SOAP, so if you’re starting to look at coding these or building your own integration points, you know that we have options available to you.
Alright, let’s move forward here a little bit. This is going to be super simplistic, super high level, just a diagram as to what the APIs allow for you. So, you can see in the center of that, I’ve got that cloud icon, the IntelliShift API, and really using that, hey, this is in the cloud, right? We’re a cloud-based SaaS application, but then you have mobile applications on the left and web apps or an external system that communicate over the internet through the API and then connect into the IntelliShift database, so that allows you to pull and send data in and out through the API, and that’s really what it’s looking to do. This is a very, very simplistic diagram, that’s what our APIs allow you to do.
Alright, let’s move forward again. What do we have available to you within the IntelliShift APIs? So, in current state, we do have, like I mentioned before, we have REST and SOAP options for some of our endpoints. When we’re looking at our REST applications, we have Swagger Documentation, which you’ll see here on the next couple of slides, we’re actually going to do a little bit of a demonstration of our Swagger Docs, but it allows you, and it allows the development teams, whoever is building this, to actually go through and test things out before they build against it.
What happens if I say, “Get this driver,” or “get this,” or “post this”? You can go through and test that, and it’s a testable process that has a graphical UI so that you can go through and actually validate that with inline checking and testing. And then, we have SOAP documentation that we have, and we can provide that, it’s a PDF doc that provide our supported methods and calls. That’s not connected into this demonstration; if you want those later on, feel free to reach out to me, send me an email, and I’ll make sure that you get a copy of those PDFs as well. And, I’ve mentioned again, with the ideas of this, we support get, put, post, and delete methods. It all depends on what that API call is, and what that API endpoint is supposed to do, but you’ll see in our demonstration here in the next couple of minutes that it shows each and every one of those things moving forward.
So, let’s actually move into the rest of the Swagger-based documents. So, I’m going to go through a couple of things that come into play, and some of the first things that you’re seeing here is that there is a bare token, so every time that you make a call, that token needs to be entered in, and if there’s not a valid token, or there’s no token, you’ll see that you’re going to get “This user is not authenticated,” so that will prevent you from moving forward if you don’t have that. Now, after I enter in the token here, I can go back through and I can do that exact same call and get into the alert section of it, and go through and click in the “get alerts” and just try to out. As soon as I get in here, now you’re going to see all of the different alert types that we have in the IntelliShift database, in the demo database that I’m using, that you can go through and call that. So, again, real quick, visual representation that I get it and you can see that you’ve got “get” and “post” already here. You can expand, get the different details here. We can look at the driver information here in just a second, and I can get a list of my drivers. So, go through, see all of my drivers, and then it gets that call and pulls that information in as well. So, again, real quick, nothing super detailed in terms of what’s coming into play, but I just wanted you to see some of the documentation that we have available to you, and getting through this and getting that out of that.
Alright, let’s continue onto this. What about security? We’re always communicating over the internet, right? So, we need to make sure that what data we’re transmitting for you is secure and is protected. So, a couple of things that you need to be aware of with this. First and foremost, all of our communication is encrypted in SLL so that somebody is not going to go through very easily and find out what’s being transmitted, so it’s not open text that’s coming into play. Also, in the last group, I talked about the idea of needing an API token. That token, bare token, expires every 24 hours, so it’s valid for that day, and if you don’t go through and update that, you’ll get the message that we saw before, that that user is not authenticated, so the user gets connected, generates the token, and then that token gets permissions. That token can be cashed locally or cashed in the call, or you can call it every time as well and generate a new token, if necessary. We also use a standard open ID connect option for additional security levels. So, your security is something that we are concerned about, and we want to make sure that what is transmitted is protected and secure.
Let’s go from here and let’s actually look at some of our real world scenarios and real world examples. In some of these, I’ll actually just talk about with some images, others I’ll talk through as some other things are taking place on the screen. But, the first one that I want to look at is the customer 360 quick view, and this is actually part of the Silent Passenger module that you can go through, and you have access to this today, but this actually generates or utilizes a number of API calls that we’ve built to provide this, but it’s using API calls that you would have available to you. So, here’s the quick list, the API call, and what this does, the API call will generate a token-based URL, and that URL can be sent to customers, to end-users, whoever you want to send this out to, and the receiver of this URL can then track the delivery in real-time on a map.
So, here is actually what it would look like. It’s available on both PC or mobile devices, desktop and mobile devices. The API also goes to the driver profile, gets details about the driver, the driver name, the driver picture, the driver ID and some other things along that line, so that customer who is receiving the delivery knows who is coming, who is aware of this. So, again, we’re providing this in real time, and then it updates, you get the position information of the asset, and it’s all based on current weather and traffic. So, again, using our APIs to give you a visual UI of these different details and when things are going to come and when they’re going to arrive. So, that’s the first one.
The second one, I’m going to click a demo here, and it’s going to start going through – and this is actually just our replay screen of a replay of a route, but we also have some other situations where somebody came in and said, “Hey, here’s a challenge, and I want to improve and expedite my loading times.” So, what if we had an option where as the assets are driving through, if they trigger a Geofence, now we know when it’s getting close to the delivery, we can then call out to the API of the ERP system, know the inventory information, know what’s on the order, and then trigger back to help that order be prepared, so it’s on, it knows what loading dock to go to, they can start preparing the freight, so that when the truck gets there and the trailer gets there, they can quickly load and expedite the process, so that time of loading is enhanced and improved, all, again, using APIs to connect one system to another, but I wanted to kind of talk this through so you could see visually, “Hey, we tripped a Geofence,” and then coming back to that. So, that’s another option. Both of these are real-world scenarios that our customers are using today to get that in place.
Some of the other options that we can do and other integration scenarios with the APIs. Now, this doesn’t necessarily mean it’s our IntelliShift APIs. We also have providers that we’ve started working with: John Deere, Komatsu, other OEM telematics platforms that in the vehicle, in the asset, they have their own telematics platform. Well, what if I want to bring that data into the IntelliShift platform so that I can have, again, these business decisions. Where is my reporting? If you don’t have our telematics application, we can still gather that information in. So, we’re working with OEM manufacturers to gain access to those. Or, if we needed to pull an odometer reading from an asset and populate a maintenance application, because we have recurring schedules, we have to schedule this and we schedule a repair every 3,000 miles for service, or so many hours of usage. So, again, eliminating that duplication of work.
I mentioned earlier, having that single source of truth, that you create a new asset, new driver, and then that API allows you to sync from one application to the next, and again, eliminate that duplicate entry and the maintenance that’s required for that. Also, time sheet integration. When did my driver start? When did they end? Well, if it’s based on log-in on the vehicle or asset and log out, or when did their shift start, maybe we can get a connector that allows us to pull that information in from the telematics platform into the payroll system, or your HR system, to allow simplified payroll entry. So, there’s a lot of different scenarios. When you really start talking about it and start looking at it in terms of what can we do, or what could we do that are all available with the APIs that are in place today?
Alright, so, let’s kind of get close to wrapping up here. I did want to talk about one specific case study, and I mentioned this already, but PC Richard & Son, they’re actually one of the largest family-owned appliance, television, electric companies in the U.S., and they came to us and said, “Hey, we have challenges where we are spending a significant amount of time communicating with our customers in terms of when are their deliveries going to be made, and because of that, we’re looking to improve that efficiency, improve our customer satisfaction, so can you help us?” Well, that customer 360 view that I showed earlier in the quick thing is actually the result of that. By employing this, and employing that aspect of it, the number of man hours spent were reduced because we don’t have to call the customers, we don’t have to keep in constant communication, we can send that link out, and the customer has the ability to maintain that and track all the way through. They know when the delivery should be there, they know who is delivering it, they know if there’s delays, all by following the live link on the map and being able to track that. So, that actually is real world, and where that came from.
Now, where are we going? What is the future of the APIs at IntelliShift? Well, I showed you guys earlier the information about the Swagger Documentation. Everything that we do going forward will follow a similar path of that, that it will be fully documented and testable, REST APIs. So, you’ll be able to go to a website, punch the information in, and see what kind of a result that we get out. We also want to provide opportunities for our customers and additional third-party applications to connect into the IntelliShift platform. So, I mentioned the idea of the OEM telematics; that is a perfect example of that. We’re a telematics with our Silent Passenger side, but if you had a different one, we could pull that data in, and now again, we have all of this into that same platform in the same representative tools so that we can connect and allow you to leverage your data to make educated and effective business decisions in real time. So, again, trying to eliminate that duplication of work, that duplication of effort, to chase down that information that you need and chase down the data that you need to find to make those decisions, and that’s really what we’re trying to do, and everything that we build going forward, that’s going to be our goal, to provide that capability with the APIs that you can do that.
For future information, if you want to come back and you’re looking at these later on, these two links actually take you to our existing REST API info. The first link just gets you a list of all of the endpoints that are available, the second link is that Swagger Documentation that we mentioned previously. Now, if you want to use the Swagger Documentation, we will have to work with you to come up with a way to get a bare token, because you’ll need to generate that token before you can test that information out, but that is the URL that would pull that into that. So, again, if you want the PDF of the SOAP details, feel free to shoot me an email, and I will send that over to you without any issues, and then we can go from there.
So, with that, that leads us to the end.
I’m going to give you some time to enter in any questions if you haven’t done so already that we can go through. Here’s our questions, we’ll take some time to answer those. Feel free to enter those in. I appreciate your time, and feel free to reach out to me if you need to.
Watch the video of this session, “Best Practices in IT / API Integrations.”
View all sessions from ConnectedOps 2020.
