26-03-2024
Adjacent and Between: Demystifying Digital Transformation with Power Apps and Power Automate
Everyone talks about digital transformation, but it seems like no one really explains what it means... until now. In today's episode, Rob and Justin dive deep to cut through the buzzwords and lay out the reality. They're tackling why digital transformation isn't about making huge, instant changes but rather about the smart, subtle tweaks in areas that usually get ignored but badly need a digital lift. They dive into how leveraging tools like the Power Platform can spark significant improvements, showing that it's the small changes that can really boost efficiency and smooth out your workflow. Ever found yourself wondering how to translate all the chatter about digital evolution into actionable steps? That's exactly what Rob and Justin are unpacking. They're guiding you through how minor, yet clever adjustments can transform your processes. It's all about enhancing the routine, one step at a time. And, as always, if you enjoyed the episode, be sure to leave us a review on your favorite podcast platform to help new listeners find us. EPISODE TRANSCRIPT: Rob Collie (00:00): Hello, friends. In today's episode, Justin and I demystify what is meant by the phrase digital transformation. Phrases like that are one of my least favorite things. Why do I say that? Well, these are phrases that get used a lot. They cast a big shadow. You encounter them almost anywhere you go. That's fine by itself. But in the case of digital transformation, that massive shadow is multiplied by no one understanding what it actually means. (00:30): Now earlier in my career, I used to be really intimidated by things like this. Everyone seems to know what this means because they're using it all the time. I don't know what it means, so should I just pretend and play along like everyone else? But at some point, many years ago, I had this moment where I realized that the Emperor has no clothes. It almost never has clothes. Now when I encounter phrases like this, instead of being like paralyzed or intimidated, I instead start working in my own definition and this process takes time. I've been picking apart and stewing on the definition of digital transformation now for probably the better part of a year plus. Somewhere along the way in that process, I realized that we at P3 are doing quite a bit of digital transformation work, I just hadn't realized it yet because I didn't have a good enough definition. (01:18): Lately, I've been noticing that my definition for digital transformation has reached a steady state. It's not changing over time anymore, which tends to be my signal that I've arrived at a definition that works. Now seemed like a good time to sit down and compare notes with Justin, who's been following his own parallel process of arriving at a definition. I'm very pleased with where we landed. A practical and specific definition that can be reduced to practice with an almost paint-by-numbers type of approach. (01:47): If you asked someone for a definition of something like digital transformation, and by the time they're done giving you their definition, you can't practically boil that down to what it means for you, that's not a problem with you, that's a problem with the definition. A lot of times, people's definitions for terms like this are almost like deliberately vague, as a means of projecting power, as a means of actually controlling you. You'll get a lot of definitions that are engineered to sound smart, engineered to sound authoritative, but not engineered to provide anything resembling clarity. Because if you sound smart, and you sound authoritative but you leave your audience hungry, you create a feeling of dependency. Folks, I just think that's yucky. That's just gross. (02:35): To show you what I mean, I just ran the Google search, "What does digital transformation mean?" The very top hit, enterprisersproject.com, defines digital transformation as "the integration of digital technology into all areas of a business resulting in fundamental changes to help businesses operate in how they deliver value to customers." Did that clear it up? Nope. Boiling that one down, it sounds a lot like you should use computers and use them to make changes. But it sounds smart, sounds authoritative. (03:06): Here's the second result from our old favorite, McKinsey. McKinsey defines digital transformation as "the process of developing organizational and technology based capabilities that allow a company to continuously improve its customer experience and lower its unit costs, and over time sustain a competitive advantage." All right, so that one sounds like McKinsey is almost starting with that original definition and adding additional value to it. They're saying use computers to improve, and to make money, and to compete. If you have $1 million to spend, you can get advice like that. (03:43): All right, with those two definitions, we don't even need an episode. We can just skip it? Because everyone knows exactly what they're talking about. These are the top two hits on Google, folks. Useless. Part of the reason these definitions are useless, again, is because they're designed to be useless. But I also think though, that a lot of times you hear definitions like this is because the people writing them actually cannot boil them down. By the time you come up with a truly useful definition, or a framework, or a guide for understanding a topic like this, it almost by its definition, it's not going to sound nearly as sexy, nearly as smart. It's going to sound relatively simple, mundane. But those are the valuable definitions, the ones that we can actually apply, that make a difference in how we actually view our own business. (04:29): That's what we set out to do in this episode. I think we succeeded, came up with a very practical, applicable definition that you'll never find on McKinsey's website. Let's get into it. Speaker 2 (04:42): Ladies and gentlemen, may I have your attention please? Speaker 4 (04:46): This is the Raw Data by P3 Adaptive Podcast, with your host, Rob Collie, and your cohost, Justin Mannhardt. Find out what the experts at P3 Adaptive can do for your business. Just go to p3adaptive.com. Raw Data by P3 Adaptive is data with the human element. Rob Collie (05:12): Justin, one of the things that we really like to do, I really like to do, I think you do as well, is to take a phrase or topic, and demystify it. Especially phrases that you hear repeated over, and over, and over again, and everyone has to pretend that they understand what they mean. But even when they do, they often have very different pictures in their heads. (05:33): One that I think is due for a treatment, and we've hinted at it once before on this podcast but not with any depth, is digital transformation. What does it mean? Justin Mannhardt (05:45): What does it mean, what does it not mean, all parts in between. Rob Collie (05:50): Starting with the places where I hear it. I often hear it in the context of this is something that's already done. The big talking head analysts at places like Gartner- Justin Mannhardt (06:00): Yeah. Rob Collie (06:00): Will talk about it like it's in the rearview mirror. "The shift to digital, the pivot to digital has forced the following things," so has forced, it's a past tense thing. Which further underlines the idea that well, if it's already happened, clearly everyone knows what it means. They don't stop to define it, they're just tossing that aside as a means of getting to the next point. I find that to be one of the most troubling habits of the talking heads. (06:28): The first few times I encountered this phrase, I didn't really know what it meant. I imagined that it meant switching to ecommerce from brick-and-mortar. Justin Mannhardt (06:37): Yeah. Rob Collie (06:37): I didn't even realize that that was the impression I had, it was just this vague feeling in the back of my head. Justin Mannhardt (06:42): The word digital, I'm just thinking about this now because a lot of times, you'll look at one of these diagrams, it's like, "Your digital transformation wheel includes all these things." You'll see something like, "Move to the cloud." I'm like, "Okay, were the servers with the software, was that software analog or something?" Rob Collie (06:59): Yeah, we've been digital for a long time, right? Justin Mannhardt (07:01): Yeah. Rob Collie (07:01): Most broadly defined, you could say that the digital transformation really got going with the adoption of the PC. Justin Mannhardt (07:09): Right. Rob Collie (07:10): That was when digital transformation started. In the sense that it started in the 1980s, maybe it is something worth talking about somewhat in the rearview mirror, but that's not what they mean. They don't mean the adoption of the PC. Justin Mannhardt (07:23): No. But it's interesting, when you think about the timeline of technology evolution. People say, "Oh, you described it as past tense." Digital transformation has occurred in en masse in market. Now today, it's like AI is here, en masse in market. But the pace at which new things are coming out, what's really happening is just the long tail is longer back to where companies were at in this journey. It's not like the entire industrial complex has been collectively moving to the modern current state across the board. There's companies that are still running SQL 2000, that's their production world still. This isn't something that's happened. Rob Collie (08:09): I think that the big talking head analysts often tend to really only talk about the most elite sub-strata of even their own clients. When they talk about this as something that's completely done, even most of Gartner's paying clients, I would suspect, aren't anywhere close to done. But we still haven't really started talking about what it actually means. (08:32): Let's say it is not the switch from paper and pencil systems to electronic line-of-business systems. Not only do we have the PC, and that's been long since mainstreamed, the notion of line-of-business software, server based software, whether cloud or otherwise, line-of-business software is also I think incredibly well entrenched. We're done with having key business systems running in a manual format. That's long since rearview. That also isn't what they mean by digital transformation. (09:07): Of course, both of those are digital and they were huge transformations, but that's not the digital transformation we're talking about. It's anything that's happened after that. Justin Mannhardt (09:15): Yeah. Rob Collie (09:16): It's a lot harder to pin down the things that happened after that. Justin Mannhardt (09:20): In general, I agree with you because the big blocks, software, the availability of the cloud, not having intensive paper process in most companies, that's largely been accomplished. To different levels, of course. Then, what's left? What's the definition? What are we trying to do? Rob Collie (09:41): Well, if you think of the line-of-business application and the PC, the PC interfaces with all the line-of-business apps. I would say that, and even this is not 100% true, but I would say that the conversion to digital systems is complete, or complete-ish. Justin Mannhardt (09:59): Okay. Rob Collie (09:59): When you look at your business as individual silos. Justin Mannhardt (10:03): Say more. You've got a digital environment for finance, digital environment for sales, is that what you mean? Rob Collie (10:09): Yeah. Core workflows have largely been digital for a while. All the workflows that take place between systems, or the workflows that take place adjacent to a system, those are the things that we're talking about when we talk about digital transformation, going after those workflows. (10:30): Everything we've been doing in the world of business software since at least the 1980s has been digital transformation. Justin Mannhardt (10:38): Yeah. Rob Collie (10:39): But our digital transformation, we're really talking about at least the third chapter. It's not chapter one or two. It's like the next frontier, identifying and going after a new class of workflows that would benefit from essentially software support. Justin Mannhardt (10:56): Right. Rob Collie (10:56): Okay. Now because almost by definition, just by subtraction ... We're saying, "Look, we've got the PC, we've got the line-of-business systems that handle the core workflows within a silo. What's left?" Well, it's almost like a perfect mathematical proof. What's left is the stuff between and outside. (11:14): Given that everyone's mix of line-of-business systems is, I like to say, best of breed, meaning random. It's whatever we decided at the time. It seemed like a good idea at the time. Legacy. Justin Mannhardt (11:25): Yeah. Rob Collie (11:26): You're never going to have anything off-the-shelf that helps you solve the workflows. The middleware problem between your systems is always going to be a custom solution. (11:38): We should give examples of these. When I said outside or adjacent to, there's even workflows that they're not really between systems, they're just the offline portion of working with the system. I'm thinking about a budgeting process, for instance. The world's first budgeting systems were mostly there to record your budget that you enter into it. As those budgeting systems have gotten better, they've included more and more of the human workflow that goes into creating, and evaluating, and kicking the tires before it's finalized. Those offline human workflows, getting more and more structured about them, can make a huge difference. Justin Mannhardt (12:19): Not just structured, Rob, more tightly integrated with the adjacent system itself. I like that adjacency, because if you have a financial system where your budget or your forecast lives, there's a martialing of activity, analysis, input. Then you say, "Okay, we need to get it look like this," and then we put it in the thing. What happens in that processes, you get all sorts of scattered iterations of ideas and it gets loose. But if you could have all that iteration tight, the final submission is already handled or much easier. Rob Collie (12:51): Yeah. Sticking with the budgeting example for a moment, it still echoes one of the themes I mentioned for the between systems, the between silos case. Which is that one-size-fits-all systems, off-the-shelf systems, they really struggle to address all the nuances of your particular business. It's very, very difficult. The more, and more, and more you try to get the offline processes, the human processes brought into the digital workflow, the more an off-the-shelf software package is going to struggle. It's getting further and further away from the safety of the core of the task. (13:28): This is why the Power Platform approach to budgeting and planning is often, in fact almost always, a more effective, in terms of cost-effective, time effective, results effective. The core libraries for doing all of the things that you need to do are basically already there and it's inherently designed to be customizable. Justin Mannhardt (13:48): And very nimble. Even the big players in FP&A software, they're not that great, in our opinion, at the end of the day. But the price points just exclude anybody that's not a very sizeable, formidable company. You're not looking to spend that kind of money if you're even a few hundred million a year type operation. You're just not going to sign up to that agreement. You are left with a middleware type of a problem, that you're either solving with spreadsheets, pen and paper, or something else. Our platform can slide right in there. Rob Collie (14:26): Of course, there is a huge advantage to performing a "digital transformation" on a process like that because the human, offline, pen and paper, sending random emails, getting answers, tracking them, it's incredibly tedious, it's incredibly error-prone. Just super, super slow. It's not like you can perform many iterations. You're not even really going to be able to pull off one iteration and you call it good. But you're just going to miss so much. The budget could have been so much better. If you've got a bad budget, of course you're going to pay for that later. (14:58): That's the adjacent case. Let's talk about the between a little bit as well. What's an example of a workflow that would span across different line-of-business systems but require a human being essentially, or humans, to essentially carry the buckets of water between those different pipes? Justin Mannhardt (15:18): We'll make up a company today, Rob, we'll start a new company and it's going to be called I Manufacture Things, Inc. Hey. At I Manufacture Things, Inc., I've got a sales team. Rob Collie (15:28): Do we make things other than ink? Justin Mannhardt (15:30): No, that's incorporated. Rob Collie (15:32): Oh, okay. Justin Mannhardt (15:32): We just make things. Rob Collie (15:34): Can't help it. Can we be We Manufacture Things Ink, Inc.? Justin Mannhardt (15:38): Sure. Rob Collie (15:39): All right. But anyway, we manufacture things. Justin Mannhardt (15:41): There you go. We've got a sales team and they're using a CRM system, such as Salesforce, or HubSpot, or whatever. They're out there, they're doing quotes, they're tracking opportunities, and eventually someone says, "Yeah, I'd love to buy a palette of ink," or whatever. Our company, we're not using the CRM to deal with the production and fulfillment of that order. Okay, so now there's this process where my order form, let's not use any paper in this example, it's still digital but it lands as a PDF form in someone's email inbox that says, "Hey, Customer Service Rep, here's an order." Oh, okay. Now I'm keying said order into our production system that says, "Go manufacture this thing." Now we need to ship the thing out somewhere, and now we're in our logistics system. (16:33): There's all these little hops between systems. Which technology has become more open, and sure there's things like APIs and code based ways to integrate them, but that's not in range for a lot of companies. That's an example of where you could stitch in these little Power Platform type solutions to just, "Hey, let's map the relevant fields and information from the CRM into the order management system." If there's some blanks that need to get filled in, that's okay. Maybe I'm just starting from a queue of new orders right in the system, and I'm maybe adding three or four pieces to that puzzle instead of all of it. Rob Collie (17:12): Okay. I want to make a global note here. Note that we're talking about this broad topic, digital transformation. We're already way down into very detailed, specific use cases. In my opinion, that's what digital transformation is, it's a collection of all of these individual use cases where things can get faster, more efficient, more accurate. It is the sum of many small things. Each one of them might have tremendous impact. This is the way. (17:46): In this particular example, I've been describing the Power Platform as the world's best middleware for a while now. Even Power BI is middleware. It's beautiful, beautiful, beautiful capability is that it can simultaneously ingest data from multiple different line-of-business silos that have never once talked to each other. The only place that they meet is in a Power BI semantic model. Justin Mannhardt (18:10): Yeah. Rob Collie (18:10): And they play a symphony together that Power BI makes them play. They still have never seen each other, but Power BI is what bridges the gap. Now, Power BI is read-only by itself, it doesn't make changes to any systems. (18:25): In this particular case, it sounds like Power App's and Power Automate's music. Let's just get really tangible here. I know that it's a very specific, but it's a fictional example. But lots of people have almost exactly this problem. Justin Mannhardt (18:39): Yeah. Rob Collie (18:39): Just talk me through what a solution to that particular problem might look like if we implemented it in the Power Platform. How much work, how much elapsed time do you think it would take? Let's dig into this one a little bit. Justin Mannhardt (18:51): If what I want to do is, when we receive an order or close a deal in our CRM, I want that to move some data to another system, let's just say that's assumed. Power Automate can solve this need. Obviously there's a lot of detail, you can look some things up online, or you can email robandjustin@p3adaptive.com and we can trade some ideas here. But there are tons of out-of-the-box connectors, and in those connectors they have what's called a trigger. I could say, "When this happens in Salesforce," for example, "I want to start building a flow." I can say, "Okay, I want these fields, and I want to write them from Salesforce to this destination." Maybe that destination's a database, maybe that destination is another system that Power Automate supports that you can write to. (19:37): It could be just this simple mapping exercise. When this happens over here, grab this data, and create a new record over here in this system. Rob Collie (19:46): Okay. A trigger in this case would look something like, "When a record in Salesforce is marked as a win," we've signed a deal, someone wants to buy a palette of whatever. Then automatically, it wakes up, looks at the record in question that the data associated with the sales win in Salesforce, grabs certain fields out of the Salesforce record, certain pieces of information. Let's keep it simple for a moment, and just pushes them into a simple SQL database or something, that could be stood up in minutes. We don't have to spend a lot of time. Or maybe, we just drop it into OneLake. Justin Mannhardt (20:23): Lots of options there. I think this is a nice little simple example, because when you talk about Power BI, that's a very tangible apparatus. These are the things you set up, and you never really go ... You monitor it of course, but you never really go engage with it. You put the glue in place, and it's magic and it's cool. That's a simple version. (20:44): But sometimes, the data coming from its source is incomplete relative to what it's destination requires to take the next action. In this type of scenario you could either say, "Well okay, once it gets over there, we're just in that system, maybe we're adding to it." But this is where you might insert a Power App into the process. Win a deal in Salesforce that triggers, grab these fields. Let's go ahead and write it over to Dataverse, this is a back end of a Power App, for example. Or a database, or SharePoint, who knows. It depends on what makes sense. (21:18): Now we've got a Power App that maybe has a little work cue that says, "Hey, Rob, you've got new orders." You're either approving them, or you're annotating them with additional information. You're doing the human process, like you were describing before, maybe ensuring some hygiene, completeness, whatever. Then you do something in Power App that says, "Okay, go ahead and kick this down the line from here." Rob Collie (21:40): Yeah. Here's an example. In the CRM system where the sale is being executed, there's probably an address for this customer that is associated with that account, especially if we've done business with them before. But this customer might have many different physical locations. A palette of stuff showing up at the wrong physical location would be a real problem. Justin Mannhardt (22:06): Yeah. Rob Collie (22:08): Even just a sanity check Power App that hits the sales rep back, shows up in their inbox or something, shows up in Teams, somehow there's a cue for them to process these things, where they need to just glance at the order and validate that the shipping address is the right one. Justin Mannhardt (22:28): Yeah. Rob Collie (22:28): Even if that's all it is, that's the only additional piece of information is yes, no, that's the right address. Justin Mannhardt (22:34): Yeah. Or sometimes there's a material that is sold is related to a bill of materials to produce. Maybe there's some choices that need to get made in the manufacturing process, such as what specific raw materials are we going to use for this order? Which machine are we going to produce it on this week? Maybe you're just adding the execution instructions. Rob Collie (22:59): This is interesting because you could stop yourself at this moment and go, "Wait a second. Shouldn't those questions be encoded and implemented into the CRM?" The answer is of course, they could be. But your CRM might not be a nimble place to make those sorts of changes. Justin Mannhardt (23:20): That's right. Rob Collie (23:22): It's also a dangerous thing to be customizing. Justin Mannhardt (23:24): Yes. Rob Collie (23:25): There's a lot of validation and testing that's required. There's a reason why modifying and writing custom code into one's CRM doesn't happen all that frequently. Whereas this process you're describing is relatively safe, by comparison. It doesn't rock the boat. It's between. Forcing these sorts of modifications and customizations into the individual silo line-of-business applications, if that were so feasible, that would already be happening. Justin Mannhardt (23:55): I've worked for companies like this, I've engaged with companies in my consulting career like this, where they have done that. They said, "We've got the talent in-house, so we're going to customize this thing." Then you get into a conversation of, "We'd like to upgrade to the newer version." They realized, "Oh, we can't." Rob Collie (24:18): Yeah. "It'll break out customizations," yes. Justin Mannhardt (24:20): Or sometimes, the programming language that the customizations are done in is not the same programming language in the newer version. While it's possible, if you have the resources, the time, and the money, it becomes a heavier lift. It begs the question, why? Rob Collie (24:36): I was describing the heavy lift being that the original line-of-business system might be resistant to change, resistant to the customizations that you want to implement. You're describing it as also, even if you do perform those customizations, the next major software upgrade is going to be a problem. That rings true for me. I remember the object model in Office- Justin Mannhardt (24:59): Oh, yeah. Rob Collie (25:00): All the VBA solutions that were out there, being incredibly paralyzing in terms of the things we could do with the product, because if you broke people's macros, they wouldn't upgrade to the new version of Office. Justin Mannhardt (25:09): Yeah, been there. Yeah. Rob Collie (25:12): I promise you that, at Microsoft, we took that problem and approached it with a level of discipline that it was probably 10 times greater than the average line-of-business software vendor. Because most line-of-business software vendors see themselves as platform vendors. They want to be considered like that, but they don't want to pay the price of it. So that's good. (25:30): But then, the other thing is is if you built it into the line-of-business system, then inherently you're saying, "Okay, whatever that extra logic is, then it's up to that line-of-business system to then push those records across the wire." The new information has to go from the CRM to the other system. That kind of customization, both ends of the process are going to be very non-cooperative with this. This is another reason why doing this in a lightweight, nimble, intermediate layer provides a shock absorber to the system. Justin Mannhardt (26:08): I like that analogy. Rob Collie (26:09): It's pretty easy for Power Automate, all it's doing is pushing a handful of doing to something and that other something is going to take care of all the validation, all of the retry. Validation with human beings, but also the logging in to the other system and all of that. Coding all of that into your CRM is almost a non-starter. This is why the between workflows have remained so non-digitized. Justin Mannhardt (26:42): Yeah. There's also a lot of tedium should be in play here, too. You have a written process, you look at your SOP documents and you say, "Oh, when this happens, Jan sends an email to Rob." Okay, well we could probably just get the Power Automate to send the email to Rob, if that what needs to happen. (26:59): An example of this is something I built for myself at P3. When a potential new customer reaches out to us, and they want to meet with us and just chat, I wanted a process that reminded myself to go check out who that company is, understand who I'm going to talk. I just had a trigger that said, "When a meeting gets scheduled from this arena, just create a task for me to remember to do this before the meeting." Even little things like that, that are just personally useful, have been really beneficial as well. (27:33): It's much easier to say well yeah, dashboards, charts, graphs, cool. Or even fabric, even though that needs some demystifying still. This middleware, it's invisible, there's so many options. There's 100,000 little improvements you could make with it. Rob Collie (27:48): The world has spent a long time coming around to why dashboards could be valuable. Justin Mannhardt (27:55): They still are. Rob Collie (27:56): Yes. When you say the word dashboards and you show that work product, even in the abstract to someone, the communication of what the value is benefiting from all of that history of the world waking up to the value of dashboards. Honestly, it wasn't that clear 15 years ago. It wasn't clear to people, most people anyway, why they needed them, why they were better than just running the reports out of each line-of-business system. But because it's such an inherently visible work product, it is a lot easier, I'm going to use the word, it's a lot easier to visualize what the impact will be, what it does for you. Whereas these other workflows, until you know that they're improvable, this is why digital transformation is so hard to understand because it is really talking about spaces where it's hard to visualize software helping because it's never been able to help. (28:53): Let's go back to this example where the sale happens in the CRM system. Some information just automatically gets dropped in a data store, off to the side for the moment. There's potentially some Power App clarification. There are human inputs that are required here and you still want a human being to provide those. Justin Mannhardt (29:16): I want to point out here too, it's easy to get into a situation where that data store is simply being read by a report, even a Power BI report. But if the human's going to say, "Yes, no," or add to it, the Power App is just a way better piece to put there. Rob Collie (29:32): Yeah. Let's have this example be like an example that we would look at and smile, be proud of. The Power App is involved. Then when the human interaction is done, they press okay or approve in the Power App. Take me to the next step. Justin Mannhardt (29:49): Well ideally, we are pushing data and information into the next system or workflow. Rob Collie (29:57): This is a two silo problem. We have the CRM system and then we have the manufacturing, work order and shipment system, the fulfillment system. Justin Mannhardt (30:06): The WMS. Rob Collie (30:08): Is that what that is? Justin Mannhardt (30:08): Yeah. Rob Collie (30:09): Okay. We've already covered the first silo. We've gotten the human interaction. Now it's time to send it on to the second silo. How does that work? Justin Mannhardt (30:20): This just comes down to what the point of integration is in the second silo. We could be inserting records into a SQL database, we could be making a post request to an API endpoint. In Power Automate, most of these things are WISIWIG in nature. There is an open code interface if you need to get to that and want to do that, need it. But usually, it's just mapping. You find your destination and it says, "Oh, here's the fields to map to." You say, "Okay," you just drag and drop. It just depends on what your destination system is, but you're just creating a target in your workflow, and the data goes. Rob Collie (30:55): The way I like to look at this is that, even though each line-of-business silo system, they're never really built to talk to each other. Justin Mannhardt (31:04): Right, they need a translator. Rob Collie (31:05): Yeah. The translator and the shock absorber. But at the same time, it's not hard to get the information you want out of one system, and it's not hard to write the information you need into another. But when you try to wire them directly through to each other- Justin Mannhardt (31:23): Yeah. Rob Collie (31:23): That is actually really difficult. You need this referee in the middle, that's able to change gears, like the ambassador between the two systems. When you think about a translator system, an ambassador system, a shock absorber, whatever you want to call it, whatever metaphor you want, you can also imagine an incredibly expensive, elaborate piece of custom software that's being written to do that. That's not what we're talking about. Justin Mannhardt (31:47): No. Rob Collie (31:48): Let's recap. Trigger fires in CRM system, some data gets slurped out related to that sale, dropped in an intermediate location that then powers a Power App. Power App is able to read that information, it knows who to reach back to to get the clarification, the approval, et cetera. It might be multiple people that need to provide some input. Justin Mannhardt (32:09): It could be a whole workflow that lives right there. Rob Collie (32:12): But eventually at the end of that workflow, in this case we'll just assume it's one step, one human being, the sales rep just needs to sign off, then the Power App's job is done. That's the human interaction part. Now we're back to Power Automate, correct? Justin Mannhardt (32:24): That's right. Rob Collie (32:25): Power Automate will notice there's another trigger that the Power App is done with its part, the approval button was pressed. Justin Mannhardt (32:31): Clicked, yeah. Rob Collie (32:33): Then it turns around, and it knows, because again we wire it up ... It sounds like we might be lucky, it's just drag and drop, one time development. But if it's not, it's probably not that much code, to go inject the new work order into the WMS system? Justin Mannhardt (32:52): Yeah, it's the WMS, warehouse management system. Rob Collie (32:53): Let's call that the end of the story for this one integration. Let's say things go incredibly well in this project. We don't really encounter any hiccups. Best case scenario, how long on the calendar would it take for us to wire something like this up? Justin Mannhardt (33:12): Yeah, best case scenario this is something that gets done inside of a week. Rob Collie (33:15): That's the difference. Justin Mannhardt (33:16): Yeah. Rob Collie (33:18): All right. Worst case scenario, both of these systems are more stubborn than usual, the connectors aren't built into the system, and they still have some relatively rudimentary ways of data access, but it's nothing WISIWIG off-the-shelf. We just get unlucky with these two stubborn line-of-business systems. How bad can that be? Justin Mannhardt (33:37): Well, instead of being inside of a week, maybe it's weeks, like two or three. The only reason that gets extended would be okay, instead of pure WISIWIG drag and drop, maybe we are having to do some light handling of adjacent array. But there's tools for that. You can say, "Parse this into fields so I can now drag and drop it." Maybe instead of our Power Automate workflow having three, four steps, maybe there's 10. Some of those steps have a little bit more involvement. Maybe there's some time because we got to troubleshoot a little bit more and make sure we've got it all right. But I think the overall point here is these are relatively light touch on the calendar. Rob Collie (34:18): I had a job in college that I've never brought up on this show. Justin Mannhardt (34:23): Ooh. Rob Collie (34:23): I was obsessed about this workflow for nearly a whole decade afterwards. Where I was working for a construction company, and there's this thing in the construction industry that I'm sure is still a thing, and it's called the submittals process. Where it turns out, when you're going to build a building, there's an ingredients list for a building. You were talking about different material options for manufacturing. So we're going to make a brick exterior. Okay, what kind of brick? There are many different colors, kinds, textures, levels of quality. Literally, the owner of the building, the person paying to have the building built, that owner and their architect, and sometimes their structural engineers, are going to want to hold a physical brick in their hand. Justin Mannhardt (35:05): Right. Rob Collie (35:06): This is the brick that you are going to use. They want to inspect it with their eyes, whatever, they want to feel ... Maybe even run tests on it. Justin Mannhardt (35:14): Smack it with a hammer. Rob Collie (35:16): Right. Then, when you build the building, you better use that brick because they're holding onto the brick, the sample, the reference brick. You think about the number of ingredients that goes into building a building, and the building in question that I was working on helping out with this process was the new chemistry building at Vanderbilt University. It was not just a regular building, it had all kinds of specialized hardware, and exhaust, and crazy stuff that wouldn't be in a normal building. (35:44): There's this long list of materials that need to have submittals produced for them, samples.
