Play the King & Win the Day!
The Play the King & Win the Day podcast features discussions on business, technology, strategy, and the psychology of success, with insights from professionals, leaders, and entrepreneurs.
*Sponsored by omi.co
Play the King & Win the Day!
Episode 7 - The Building Blocks of Digital Transformation with Daniel Chilcott Flowgear
Episode 7: In this episode we interview Daniel Chilcott, Managing Partner of Flowgear. Daniel shares the latest trends and business use cases in the Digital Transformation space leveraging (RPA) Robotic Process Automation and how organizations are leveraging custom API's to enhance and connect on-premise and cloud technologies to give unified data access across any platform to achieve better business outcomes.
About Flowgear: Flowgear’s internationally renowned platform enables companies of all sizes to overcome data silos by creating powerful Application, Data and API integration on-premise and in the Cloud from a single interface.
Podcast Sponsored by OMI "We Make CRM Work!"
This podcast is sponsored by OMI the company that makes CRM Work! We're speaking with Daniel Chilcott CEO of Flowgear.
Speaker 2:My name is Daniel Chilcott I'm co-founder and CEO of Flowgear. We're a cloud-based integration platform. My fascination with computers started at a pretty young age where my parents brought a Xanax spectrum into the home, and that was kind of where I learned basic. So by the time I kind of came of age, I knew that software was something that I wanted to do, and had that opportunity at a start-up basically as an employee, number one in a in a CRM company. And what started to happen is as we delivered the CRM to our customers, and this is kind of mid to late 2000. What was happening is every time we sold this product, the clients like the product itself, but it was a very little use to them if they couldn't integrate it with their existing systems. So for example, they had a, a lead that they were tracking through CRM, but ultimately they generated a quote. And when that quote got accepted, it needed to become an invoice in the accounting system. And so this is where the process kind of started ticking over in the back of my head. How do we make that repeatable? And so being very naive at the time, I didn't actually know what was available on the market. Basically there's the set of tools called, E SB or Enterprise Service Bus. I didn't actually know about any of that, but it really p iqued my curiosity and just got me to think about how we could in the same way that a CRM i s kind of this reusable thing you can s ell over and over. Could you do the same thing for the integration space and long story short that's where Flowgear comes from.
Speaker 1:So Daniel, you know, I came to this as a consumer and I imagine that a lot of people listening will have had that experience. So I, I was telling you before we started recording that I would use if this an d t hat to sort of automate, like, being able to turn on my lights with my voice, right. Or, or every time I got a phone call logging that in a, in a spreadsheet or something like that. Can you give me just a very brief backstory on, you know, API is w hen they came into use, would your business have been possible 20 years ago? I know you started in 2010. Uh, y eah. W what does that whole picture look like?
Speaker 2:So the truth is that integration always been around in one form or another, just the way that it's applied as a traumatically changed in the past decade. As I mentioned, the sort of predecessor to the category that we fit into is called an enterprise service bus. And, you know, back in the day, that would have been lift and shift of data in and out of databases, file systems, FTP, that kind of thing. That was kind of the way that you moved stuff around. What was also happening is that we think kind of before the cloud era is businesses were using these large monoliths. So basically you had kind of one application that did everything, and you just packed on more and more modules to that. There weren't that many separate applications in the, in the organization, and what's happened with cloud, and this isn't a bad thing, but it's just a side effect what's happened is that businesses are now able to find applications that services that are highly suited to their specific verticals. So we've gone from having maybe three or four apps to run the organization to like 50 apps. Um, and so what that necessitates is to be able to integrate across them because the data in each of those apps is necessarily siloed from each other app. Right. And so it's a question of how can you get data to move effectively between them now, the API is the answer to that today. Um, but if we didn't have API APIs, we'd still be doing it through database calls and that kind of thing.
Speaker 1:Oh, interesting. So you've mentioned this, this term robotic process automation where most people think of robots, I guess this is a very, very basic question. Somebody who's, doesn't live in this space day-to-day that we think of like these physical objects, um, at what point did, did a robot stop being a thing and start being a, like a spirit or something within the machine, I guess, or is that just a really naive way to think about this?
Speaker 2:You know, um, I'm not sure I can answer that question because I also think it's a bit of a, an odd acronym, frankly. Um, it's not to say that this type of tool set didn't exist. Um, let me just kind of differentiate the two, two ways that you can integrate into products. One is through the API, which we spoke briefly about, but the other is through what is now called RPA, but really all that RPA is doing is emulating a human user. And we've had tools like that since windows 95, uh, you know, tools that would affect these, you know, synthetic clicks and capture of text into the front end of applications. So it's been around a long time. Um, and the RPA term is one that's, uh, kind of risen to prominence because of a few select, uh, pure play vendors. Who've done some really effective marketing around it and coupled it with machine learning, which helps it to be probably a lot more robust than it was previously, but basically no, no new ideas under the sun.
Speaker 1:How has the market changed since you guys launched, um, you know, over a decade ago, I imagine that you're doing a little less explaining about the basics about what you do to, to customers.
Speaker 2:Yeah, well, that's, that's actually quite an interesting question because when we launched, you know, we're a South African company and every time we'd engage with a new prospect, the first thing that we had to do was explain why we deliver this type of capability as a cloud service. Um, you know, and so we've, we've kind of moved a long way beyond that now. Um, but I would say in terms of the way that the solution gets delivered in search and need, certainly in terms of the features that we've added to the platform, we've moved away from kind of these self-contained integrations, where the integration will kick off and pull data from one place and then send it to its destination. It's kind of this sealed off unit. We've moved away from that to more kind of API centric stuff. So even though our platform is calling all these other API APIs, our platform itself is actually being augmented and invoked by third party, API APIs. And so a lot of companies are starting to use us to fire up workloads and real time queries from their own third party applications.
Speaker 1:So I've asked you to look into the past and describe that to me. Can I ask you to look into the future now, where are we in the sort of the evolution of this space? Um, and I know that this you're going to have an imperfect view, uh, into the future as we all do, but what would you say to that?
Speaker 2:Sure. So I think we're going to become even more API centric. Uh, we, we kind of had a bit of a, uh, a period of maybe five years where we were starting to use API APIs. Every product that comes out is going to be equipped with an API, but frankly its feature set is quite rudimentary. And so, although you could use it to capture new records into a system, it's very ineffective to run any complex kind of queries. Um, it's usually very ineffective at getting kind of analytics, great data out. And so what we're starting to see now is a lot more emphasis on the design of those API APIs, uh, at some companies there's, there's some great examples of these, but they take the design of the API as seriously as they take the kind of human user experience. So I think we're going to persist further along that trend. I think we're going to, we're going to see some trouble on this front as well. So, you know, there've been a number of cases that have made headlines recently of users and companies being D platform, but to a lesser extent, that same kind of problem that actually exists in API APIs. Uh, there are companies that build their entire business around their access to a specific API. And if one day the vendor decides they don't want that to happen, they can shut off access and basically kill the business. So there are companies that do things like data aggregation, but then there are less extreme examples of that as well. Um, for example, we were recently trying to help a client out, uh, who's engaging with Amazon, um, uh, seller portal and they've, they've been able to work with it. They've been able to receive the order data, but at a critical point in the project realized there was a lot more information required to be able to access personal information. Now, of course there needs to be the appropriate protections around that, but they were kind of blindsided by it because they weren't aware of that upfront. So the level that you restrict or open access to your API and how it kind of democratized it is has a massive effect on the ability of other people to consume it. And you could potentially have very damaging effects on the businesses that are dependent on you as a result. So I think we might see kind of a more circumspect attitude, before you're going to invest i n, in consuming some other v endors A PR. You want to kind of understand that you can trust them down the track that this is going to be a good thing to invest into.
Speaker 1:That example was really helpful. I wonder if you could give me another one to make this really concrete for me! How are companies using flow gears to, to execute in the market? What is a case where it's, just a run of the mill successful integration that, you can illustrate for me?
Speaker 2:Well, most of my clients come to us because they have multiple apps and services they need to connect. And so it's more than just a, I need to connect product a, to product B. They understand that they have 10 different products. All of them have data that needs to move across them. T hen they'll adopt our platform t o, to help smooth that process. But that's not to say there aren't some common use cases. So I think, for example, a client running an e-commerce store, has orders placed on the site. Those orders are finalized and paid for, and then they need to make their way through to the ERP. So our platform would be used to retrieve a list of those approved orders, translate them into an invoice, a nd then generate that in the ERP. And there might be different notifications that need to get triggered internally, so that that order can be processed for picking and d ispatch a s the case may be. So that kind of ERP e-commerce sync would be a very common one for us. We do a lot of CRM to ERP, and then we do a lot of third party stuff as well. So, customers who are providing mobile apps to their customers, focus on building a great user experience for their customers, so that they're able to, verify things like order status or update, contact information, or request a service call out. But instead of the developers o f that mobile app, having to get into the weeds of how to connect into the internal systems, Flowgear just provides that layer, abstracts away. All of the technical complexity around connecting into a Sage or an SAP f ully, it takes care of that reduces the time to delivery and the associated c ost with it. Flowgear can provide a great end user experience through those a pps.
Speaker 1:It sounds like each of your customers has a pretty specific need for what you do! How do you measure the performance enhancements that you guys provide? Is it on a case by case basis, or do you have some, some general metrics that you guys use for every engagement?
Speaker 2:I think some of them are more subtle, so there certainly are some obvious ones. I mean, we've had clients in the past way, you know, if you're moving from kind of a manual process to an automated one, it's very easy to measure the ROI. We've had clients who, have orders from a particular customer and they arrive on a Sunday and there's, thousands of them and it was taking them a couple of days to get those orders captured. And of course, by using our platform, they're ingested virtually immediately, they get it i n M onday morning and they co uld s t art p icking. So those ones are pretty easy to measure success around, but others ar e, are quite subtle. It's more a case of if the bu siness i s q uite forward-thinking, t hey can generate a competitive edge for themselves because they are able to fe ed b a ck q uicker to their customers. Because they're able to get useful insights on th e d ata because it's been meshed together, c orrectly, those types of things in the lo nger t e rm g iven advantage, but they're definitely a lot harder to measure
Speaker 1:Daniel within an organization that you might work with. What are some of the areas that Flowgear really can help, just improve what they're doing! I guess supply chain comes to mind, you mentioned e-commerce, what are some others?
Speaker 2:You know, it's very broad and that makes it difficult to talk about specific use cases that stand out. We certainly have clusters of customers in financial services in it and telecoms. I think those are probably our top two. But generally any business is going to be using multiple apps. And if that's the situation, they're absolutely always going to need to recap key data or recapture data from one app to another those will be cases where they can look to optimize just purely on the basis that they can reduce the time for data to transfer. They could reduce the error rate and transmission, those types of things. I would say the kind of ERP to CRM or a CRM to e-commerce use cases are the most prevalent.
Speaker 1:To what extent do you guys communicate with, and perhaps work with the companies that are publishing the APIs? Are you sort of passive recipients of those APIs or are you working with them to sort of standardize and form them and tell them exactly what you would need from those APIs?
Speaker 2:Well, I'd love to say we had sufficient influence to actually sway design decisions. Generally speaking, we have a formal partnership with those vendors. So with a lot of the major ERP's we have onboarded into partner program. There's usually some kind of certification that we need to keep up from our side. And then from time to time, when the vendor releases new product updates, we need to make sure that our connectors, that rack, that API are going to be functional with it as well. So it's not just a case of, building the connector at one time and we're done. It's something that is a, is a living thing, and we have to maintain it over time.
Speaker 1:I think that Segues nicely into my next question, which is, I wonder if you could speak directly to the leaders in in these organizations you work with, both technical, non-technical, and executive, w hat should they be doing and thinking about as, as they want to move their businesses to more of an RPA API driven culture with their suppliers, their partners, their customers.
Speaker 2:Well, I think, you know, you start small, if you try and do everything, you usually those types of projects fail. So pick the specific use cases. And I like to look at it as kind of sorting by the level of pain descending, and then picking them off from the top of the list, right? So what are the areas that are creating the worst customer experience this can mean different things, depending on the industry. It could mean you're taking too long to process an order. It could mean you have errors in what you ended up sending to the client or areas, y ou are recording. So, you k now, sort o f by the cases that are causing the most disruption or delay or most error prone, and just kind of slot them in one a fter the other, one of the things about our platform is it is kind of based on a very iterative design process. And so you don't have to design the solution that you want 12 months from now, right upfront, you can start with something and you can just kind of iterate on it very quickly. We have a lot of tooling in the platform that allows you to ship early and then continue to make incremental improvements and then ship those once they release, once they have reached an appropriate stage of maturity. So I think the key thing is just to start doing something, obviously there are bigger conversations and discussions to be had around, which tools do we want to invest in from a Business Intelligence standpoint, but usually t here a re some things that you can do without even changing any of t his software infrastructure.
Speaker 1:Are there certain hallmarks of a company that you work well with, size of the engineering team, maturity of the business, anything that you look for that you think that's an organization that's right for what we do that could really harness it?
Speaker 2:Well, the type of customer where that really affects you is where you're actually providing the implementation of the platform. So we do carry our own professional services division in Flowgear, but a lot of the implementation gets done by our partners. And so it's the question of which customers do our partners find it easiest to work with, and it's those who are sufficiently motivated to solve the problem. If you kind of have to go in there and first figure out what the problem is, and then how to solve it. And there's not really a, what we would call an integration custodian. So someone who wants to kind of lead that and really wants to see the reward of getting these solutions bedded down. That's very difficult to work with because you can suggest a hundred things, but if there's an inertia and no desire to progress them internally, it's very difficult to, for those projects to reach fruition.
Speaker 1:That's so interesting! Let's revisit something that I asked you early on. I was asking you about the state of the industry. I guess if I could ask you to look around the next corner, what is the next thing that you're really excited about? Maybe it's not technically possible yet, but you see it just becoming a reality. What is next, and let's center this on Flowgear. What are you guys really looking forward to?
Speaker 2:Well, I think all our mission is to try and reduce the complexity of connecting systems. So if you look at what's happening, you pick any two products, yes, they've got APIs, but they see the world completely differently. So if two products are able to present an invoice, it's not just that, then the names of the fields for the invoice are different, but the actual taxonomy, the way of seeing the structure of those documents is completely differnt across them. And so our kind of never ending goal is to look at how we can reduce an abstract away that complexity without also diminishing the level of sophistication of the solutions that we can deliver. It's not a perfect thing. It's something that would never be 100% achievable, but it, this kind of is the sweet spot that you'd sort of tending towards. So what I would like to see is, increasing maturity in APIs, our platform is able to leverage that and provide a much simpler design experience to our customers and our partners who a re implementing.
Speaker 1:Daniel, can you tell, tell our listeners where they can learn more about Flowgear and what are the next steps if somebody wants to get started with your company?
Speaker 2:Yeah, sure. So head on over to flowgear.net, probably the easiest way to get exposure to what we do is to just sign up for one of our weekly webinars. So you can do that direct from our website. If you do have a technical background, you're welcome to take a look at a trial account as well. You can sign up for, it gives you access to basically all of the features in the platform. It'll walk you through some common scenarios. And so you can start to find your feet in the platform. Once I have a certification course that you can go through on you to me to kind of skill up on that sort of self-serve basis. And then one of the ways that we help a lot of clients and our partners is with a proof of concept integration. So you pick two products that you want to integrate, and our team in collaboration with a partner will help get that solution baked out, and then actually live, present that to you, before you make any commitment from your side.
Speaker 1:So you're obviously, you guys are partners with, with OMI, with their Salesforce and Microsoft CRM expertise! Could you mention a few other partners that you have, and maybe some key customers?
Speaker 2:Yeah. Most of our partners are spread across South Africa and the United States. The U S is a market that we sort of focusing on probably about two years back now. What we found is there's a big demand in companies like OMI who have expertise around third party products. In OMI's case that'd be the Salesforce Platform, right. We have found generally there are a lot of Salesforce partners are looking for a right size integration platform, that they can take to their c ustomers. So they implement Salesforce, but then they need an effective way to integrate that into other systems. We found that across, not just Salesforce and a few other CRM's, but also some ERP, for example, SAP, NetSuite, and Sage would be some popular ones for us.
Speaker 1:Beautiful Daniel, thanks for your time today.
Speaker 2:Great. Thank you, George. I appreciate it.