Business Process Management Made Easy: Low Code Application Development

Good afternoon and good morning. Welcome to the Industry 4.0 Club's fireside chat. The club's purpose is to engage the power of diverse worldwide talent to accelerate the global evolution to Industry 4.0. We accomplish this by hosting supporting and supporting respectful, thoughtful, and interdisciplinary open conversations and creating quality content on wide-ranging Industry 4.0 topics to expand the reach of our community. We're glad you decided to join us today for our fireside chat with Mike Fitzmaurice. Mike's going to share his insights on the impact of low-code software on business process management. My name is Mike Ungar, and I'm an Industry 4.0 Club co-founder. For the past 3 years, I've been a focal point business coach and executive coach. Prior to that, I spent 35 years at Michelin North America in a variety of continuous improvement, operations, finance, and human resource roles. My co-host today is Mike Yost. Mike, would you please introduce yourself? Sure.

Thank you, Mike, and welcome, Mike. As Mike said, my name is Mike Yost. I'm one of the co-founders of Industry 4.0 Club. I'm also a founder of a company called Bennett, where we work to match manufacturers with the thought leaders and solution providers and domain experts that can help them on their Industry 4.0 journey. Been in the industry for about 30 years, primarily on the solution provider side, technology side of things. So I look forward to talking with Mike and learning from him about how his solutions can help our members.

Thanks, Mike. So I want to take a moment now and introduce our guest today, Mike Fitzmaurice. So Mike is responsible for developing WebCon's North American presence, evangelizing its business process suite, and advocating overall best practices in workflow and business process automation, digital transformation, and citizen-assisted development. He fathered SharePoint evangelism at Microsoft and was a critical part of growing it from an internal startup to an enterprise mainstay. Mike was a frequent and sought-after speaker in industry conferences, webinars, and symposiums. He is a key force multiplier for others' work in marketing, competitive sales, partner relations, and engineering. He moved from Seattle to Halifax, Nova Scotia when he joined Webcon. And for those that have never been to, uh, to Nova Scotia in the summertime, I just want to make sure that to share with you, put that on your bucket list. It's a beautiful place to visit. I've had a chance to be there many times. Mike's also going to be one of our presenters at this year's Manufacturing X.0 Southeast Conference.

It's true.

It's going to take place in Greenville, South Carolina on April 26th. So we look forward to seeing you there, Mike, as well. So we're glad you've taken the time, Mike, to join us from your busy schedule today. As we get started, for those that are on LinkedIn Live, if you've got a question for Mike, please put it in the comment box and we'll be glad to get to it and and share it with Mike for his feedback. Mike, if you don't mind, by the way, we have so many Mikes on the call or on this broadcast. Can we just call you Fitz?

Oh, please. Most people do.

Super. So I'll call you Fitz. That'll make it easier for the conversation.

Yeah.

Fitz, you spent 10 years at Microsoft.

I did.

Can you talk for a moment about how that experience grounds you for what you do today?

Microsoft ages you in dog years, but along the way it teaches you a lot. A lot about dealing with organizations of different sizes, a lot about dealing with the culture of that place, is that nothing happens without a lot of intergroup cooperation and coordination. Even though it really is a decentralized place where a lot of different independent groups are doing different things, they can't actually get anything done until they check in with each other and make sure nothing has a negative impact on other things, or hopefully even has a positive impact. That dealing with complexity, that's dealing with extreme complexity and a wide variety of different kinds of customers. That's what Microsoft taught me.

Well, it seems like a matrix organization to say the least then.

Very much so.

Yeah, that's great. Would you explain to our listeners what makes something low-code? I think you mentioned we talked about this being a low-code conversation, but what makes something low-code?

Well, low-code has been around for a long time. We've called it different things over the years, but the thing that makes something low-code is Maybe the easiest definition as to what low-code is, is what it isn't. It's not code or it's very little of it. Code, pick your programming language of choice. That could be JavaScript or Python or C#, it doesn't really matter. The point is where you type in things or type in lots of instructions and that becomes, you compile and that becomes your application, your program. The opportunity to get something wrong is really, really high. The chance of a spelling error breaking your work is high. The amount of time it takes to build something is very, very high, and to understand what someone else built. Code is great because there are some things that can't be accomplished any other way. Code is great because you can get something with pristine specificity with code. You basically, you're working at a low level, you can get whatever you want. Code takes a lot of skill. Code takes a lot of time. Code requires a lot of care and feeding. It's very high maintenance. And there are some things I wouldn't write any other way. But business applications would not be on that list. I'd write an operating system in high code. I'd write a database in high code. I'd write some machine firmware in high code. But if we're trying to deal with expense processing or quality assurance testing and so on and so forth, what we think of as day-to-day applications that make the business run. Nobody's got time for that. When you need to build something, because the odds of something doing exactly what we want are probably not that high, but we've got to do it in a better way. Low-code is a way to build something out of pre-written parts. That may be a graphical thing. You drag and drop objects onto a canvas in order to build forms or design workflows. It could be that you work with a very high-level language that looks a lot like English but is a lot more structured so that you aren't likely to run into spelling errors. Low-code is basically a way to still do some custom work, but it takes away a lot of the complexity. It's easier to read, it's easier to do.

How about, Mike— Fitz, sorry. How about from a—

Respond to Mike as well, that's fine.

How about from a skill sets perspective? As we talk about manufacturers, right, especially our reach is typically to smaller and mid-sized companies.

Sure.

You know, staffing software programmers is not high on our list. So what about the difference there from a skill set perspective?

There are 2 different kinds of skills involved in writing applications. There's maybe even more than 2, but certainly let's talk about how to think versus how to execute. So I still need to understand what a database is. I still need to understand what a process is. I still need to understand the way the business works and the goals for what an application is supposed to be. Let's call that semantic knowledge. But low-code frees you from needing a lot of syntactic knowledge. Exactly which command I'm supposed to use to do something and exactly how to spell things and how to format instructions and all the things that make code code. It lowers that bar. There are some people that would argue that it even reduces the need for semantic knowledge, but I don't necessarily agree with it. If you are going to— if you don't know a lot about how to organize data, you're going to write a lousy application. But it does free you from a lot of the muscle memory stuff and syntax-related things.

Would you say in your experience that the manufacturing base typically has those types of skill sets and are they typically in a process engineering type of capability or are they more like an IT I would argue that manufacturing is maybe better at this than a lot of vertical organizations.

I'm not saying it is in practice. I'm saying it could be. The reason for this is, I mean, like any organization, there are lots of manufacturing organizations, and I'm not picking on any particular industry here, where they haven't automated business processes, where they still do a lot of things with paper, And phone calls and email back and forth. And you're an excellent company if this, if this is you. But what manufacturing organizations understand that a lot of other industries don't is they already know what business processes are. They live them in the area of supply chains. You know what a supply chain is? You can't run your business without it. Or just production floor logistics. Those are business processes. What not every manufacturing organization does is apply that kind of thinking to everything the organization does. But that idea of what are the resources I need to accomplish a goal, how do they need to be deployed, when are they necessary, what is done with them, how do we replenish them? How do we combine them? How do we document them? How do we look for ways to improve them on a continuous basis? Actually, your expense reporting ought to be done the same way. Handling, you know, vacation time, handling invoices. There isn't a single part of the organization other than some very high-level strategy and maybe certain creative activities that can't benefit from supply chain thinking. You want to call them supply chains because it's an easier sell, do that. They're business processes.

You mentioned continuous improvement a bit there in your answer to that question. Can you talk for a second about case studies where you maybe have seen where this idea of low-code has actually enhanced continuous improvement?

I can think of a couple. Um, the store— the exact details vary, but I'm thinking about Pratt& Whitney Canada, for example, um, or Haddad Brands. Uh, they're a lesser-known company just because they— well, no, you've heard of a lot of what they do, like Gap Kids, Nike Kids. A lot of clothing brands have a children's line. Haddad Brands is who they outsource that to. Uh, A lot of European companies like Sudzucker and Echo Investment and so on. The story is very common. They all have a greater need for business applications than their capacity to address them. People come to them saying, we need to be able to track this, or we need to be able to accomplish this. It's being done right now in paper or back and forth email, and we're dropping balls, and we're spending too much money, and it's taking too much time. Can we please get something built to deal with this. And they're faced with several choices. Choice number one is do it the traditional way, you know, get into a lot of meetings, write specifications, negotiate requirements, open up your code editor, write a full application, deliver it, test it, etc., etc., etc. Again, Very expensive, very time-consuming. Option number 2 is to just go buy something. And if exactly what you want is available from a vendor, yeah, that's extremely compelling until you want to change it or until you want to adjust it or, and, or until you want to integrate it with something else, in which case it might actually have looked great in the short run and then burn you in the long run. Option number 3 is to build it yourself, but not have to go through all the trouble of a traditional high-code approach. That's where low-code comes in. All of the companies I've mentioned so far, well, what they wound up doing is adopting low-code in order to increase the volume of development of applications. in order to get exactly what you want, but not have it take a lot of time and not have to worry about a lot of the logistics and integration details. Jocelyne Brula at Pratt& Whitney Canada has actually said in the past that development's only about 10% of delivery. In other words, there's all the design requirements and all of the delivery issues and user training and security and documenting and deployment management and change management and all that has to be done with a lot of applications. Being able to handle all of that without having to write it from scratch every single time, there's a lot to be said for that.

How about the ongoing support of applications that are built using a no-code or low-code solution?

It's usually a lot better than full code because the total number of people that can understand or crawl inside the head of whoever built a low-code application is a much larger number than those that can crawl into a codebase that no one has touched for a little while. The problem with high-code is that no matter how blazing fast it might be, It's also blazingly slow to understand and blazingly fragile to modify.

Right. So we've seen over the years the, the push for off-the-shelf solutions. And that was a build versus buy conversation many years ago. Right. And now it's still sort of— yeah, it is. Right.

Now we're sort of service a lot of the time, but, you know, same milkshake, different glass.

Well, and we're sort of coming back to the build it versus buy it conversation, right? It's easier potentially, right? So how do you manage that? Or is there a way for you to identify and say which companies are going to jump in? And I'm thinking primarily, is there a size of organization or a capability that the manufacturing organization itself may have that says, well, this is, this is the type of organization that's definitely going to be interested in, in this, this low-code approach?

There are 2 kinds of things that you should buy, not build, or subscribe to from a software-as-a-service vendor without question. Thing number one would be if it's a system of record, meaning There are industry standards, there's a compliance dimension to it. In other words, the people that wrote it aren't just about making what the software does good in its own right, it's also making it compliant with a lot of arcane requirements, either from an industry or from a government. So your enterprise resource planning or accounting software, something like that, don't, don't write that yourself. high-code, low-code, just don't do it. Buy that or subscribe to it. The second thing is, if again, if it's your system of operational record, in other words, there's certain specialized packages that are dedicated not just to manufacturing in general, but specific subgroups. In other words, if it's something that is designed to do telemetry with Internet of Things or certain meters or Uh, or regulators. Like, that's specialized knowledge. It's not just specialized software. You're probably gonna buy that too. Almost everything else, you got to take a good look at what might— what you might get out of building it yourself, if building it yourself doesn't take a lot of time and a lot of money and a lot of people. Low-code can help you with that.

So your conversation makes me think about something that's pretty common in, well, in almost all organizations, is that ERP systems.

Sure.

ERP, is ERP something you buy off the shelf or something you low-code develop? I mean, that— I thought there's a thought.

No, it's an excellent question.

Everybody buys it today, right?

So, and I— you probably should still buy it, but you probably don't want to modify it. You probably don't want to extend it, at least because, again, pick something— SAP, for example. And, and I'm just— there are lots of, of fine products out there, but SAP is a particularly useful one for illustration purposes. SAP has got a lot of moving parts. If you start customizing that, you're going to have 2 choices. One, pay SAP to do it, or 2, get really, really good at the inner workings of SAP. The specialized knowledge it takes to adjust that application are, well, arcane at best and highly specialized and highly skilled. I wouldn't do it. Especially because the moment you do that and SAP does an upgrade, the odds of your customization or your extensions also working with that upgrade aren't great. SAP is designed to do what it does very, very well, but SAP is in control of what that software does, not you. And, and that's generally okay because they know what they're doing. But if you need to work with your SAP investment and do extra things with it, maybe connected into some of your marketing assets or order entry assets or production assets, you might want to look at low-code as an integration strategy. There are ways to work with SAP that SAP fully supports. So maybe, in fact, I'll give you a fine example. Say you want to make modifications to your vendor catalog, and to make those adjustments inside of SAP would involve going through 17 different screens. And maybe getting it wrong, and maybe having a lot of licensing challenges. Well, what if you wrote a low-code application that grabbed the vendor entry out of SAP, staged it into something that was much more friendly to work with, routed it around to different people to collect modifications, and then route it through other people to get approvals or comments and so on, and then push that information back into SAP where you can work with it. But so in other words, the structured, the highly structured stuff, yeah, leave that where it belongs in software design for it. But the human activity wrapped around it, the more it looks like a process and less like data, the more looking at building something connected to SAP without it being SAP looks pretty attractive.

Um, could we talk maybe for a minute about, um, and Mike, I'm gonna redirect if I'm going somewhere you, you didn't want to go, but, um, from a terminology perspective.

Oh yeah, sure.

Talking about things like workflow, talking about things like BPM and business process automation.

Yes.

Um, I used to run a nonprofit, uh, called Mesa International, and we had, uh, probably the most difficult thing I tried to get launched when I was there was this concept of a production process management working group. So we had a couple of workflow-centric organizations, and we had some BPM providers, which were more enterprise-centric, you know, versus the plant floor-centric, and bringing those 2 worlds together and getting them to speak to each other and understand each other's language.

Oh yeah.

Conceptually, it was all good, but it was probably the most difficult thing, and we actually never fully got it launched while I was there. So maybe talk a little bit if there's language issues there to understand the different terms, and then maybe the, the people involved in those, in those conversations, if they're different.

For the longest time, business process management, BPM vendors and specialists and consultants approached a lot of projects as long, expensive, meeting-intensive, documentation-intensive efforts that took a very long time to pay off. Put a bad taste in the mouth of a lot of people. Sounds like you'd be in that number, which is why a lot of people now tend to refer to the idea of managing business processes as digital process automation.

Mm-hmm.

In other words, yes, it's still business process management, but we kind of need to rebrand it because it doesn't have to be like that. Thinking about processes is a very good idea. The practitioners that dominated the industry even just a few years ago made it into something slow, stodgy, and unwieldy. Didn't have to be that way. You now have a lot of choices from vendors, but also from consultants and various practitioners, even sometimes even in-house, that are really good at nimble approaches to software development and business process automation. The way my own people do it is we kind of believe the most important thing to do is to get a prototype out the door as quickly as possible. So Get user input, get stakeholder input to prepare almost maybe a straw man. It deliberately creates something so that people can criticize it.

Yeah, makes sense.

Don't ask everybody to try and imagine something perfect in the abstract because most people are really bad at it, and even the ones that are good at it are really hard at communicating what that is. But if you give people something to criticize, they're really good at that. So build something, and as long as you're able to change it quickly to match their observations, now you're talking. And in fact, if you get it to a certain level of usefulness, even though it remains imperfect, companies can start getting value out of it as they continuously improve it. It's minimum viable product thinking applied to software.

So does the experience change if the people taking that conversation that you just mentioned forward, if they're plant-centric workflow? Like you mentioned the BPM vendors and consultants, and from their vantage point of how they sell, who they sell to, does that experience change at all if the folks that are championing this concept are workflow-centric plant floor, you know, connecting to machinery and have a, you know, a history of, you know, being on the plant floor and building plant floor apps? Do you see a difference in how people communicate?

Yeah, it helps immensely. There's a hybrid concept that we at Webcon are bullish on, something called citizen-assisted development or citizen designers. There's a movement out there called citizen development where people are tired of waiting for IT to do something, so they take application development matters into their own hands. You let amateurs build stuff, and low-code tools try to help with that. But again, remember I was talking about syntactic versus semantic knowledge? Yeah, low-code frees you from knowing the mechanics of putting together an application, but it doesn't free you from having to understand what the application is supposed to do and how you put things together to make them work. Well, people in manufacturing get this. In citizen development, we need their input for design. They understand it better than just pure software professionals do. But asking them to get involved in the mechanics and the logistics of software delivery, Probably not a great idea. What you really need to do is turn business applications into a conversation, a collaborative effort where you've got business stakeholders, users, and business specialists who help design applications, and then professionals using low-code tools that are change-friendly to deliver them. In which case applications are everybody's business. IT working in an ivory tower, not a good idea. Citizens doing hopefully creative chaos, ultimately not a good idea. Getting people to collaborate, on the other hand, now we've got something.

Yeah.

And citizens are actually, if you give them tools that establish a common language between what they can ask for So that what they ask for turns out to be actionable, then it can get built by techies a lot more quickly and then modified by techies a lot more quickly. So help them communicate and you'll get better results.

So it sounds like, it sounds like then, because you've entered, you've brought in the term citizen development, it sounds like we have, I'll say, 3 camps for lack of a better word. We have citizens who provide input, citizen development into the programming.

Citizen desires.

Yeah. Then we have on the other side of it, we have these folks that do the high-code work. Then we have those folks in the middle that are able to do the low-code work, who listen to the citizen development side of it. Am I right in thinking that way?

I'd establish the continuum this way. Let me use my— pretend I've got hand puppets or something like that. Over here we've got IT, high level of syntactic expertise. These guys know how to build stuff. They might not know what they should build. Over here we've got citizens, the people that know what should be built, don't really know how to build it. The problem when you had IT responsible for building everything, they didn't necessarily know what it was they were supposed to build, and it took them forever to try to understand their business users and their business decision makers. Over here, when you have business decision makers building things, They don't necessarily know how to deliver software. They know what they want, and if you give them tools that look easy, they think they're able to build it. But in practice, unless it's a really simple thing with a very small user base, usually a user base of one person, they don't do a great job of it, and they create problems that he has to solve later. So, but they understand what needs to be built. So get them together, have the people that understand what's supposed to be built do the design work, help them do that, and then put them together with the people that are supposed to actually deliver the software. And now you got something.

Gotcha.

And if you use a common set of tools that they're both able to understand, especially when they're change-friendly, You can, instead of creating applications like one-off craftsman-style projects, you can take a factory approach as opposed to a studio approach to churning out business application after business application after business application. So you're going to get out of the application backlog by creating an application factory and mass-producing business solutions.

Yeah.

You're not going to do that unless you settle on a common delivery language, not just a design language, but in other words, we're going to audit our software a particular way, we're going to deploy our software a particular way, and so on and so forth. If you're— if I'm going to create another business application, I don't want to have to think through everything. I need to think through the specifics of it, but I don't want to think through where am I going to put the data. I do not want to think about How do we establish who's supposed to do what? I don't want to think about how we're going to secure it. If I have to do that for every single application, I'm getting back to either the chaos of citizen development or the glacial pace of traditional high-code software development. I don't like either of those options.

If you, Mike, and I, since we're all named Mike and they wouldn't want to keep us in the same department, split us up, We each worked in a different department, um, and we were each of this mindset that we understand the problem space, we understand, um, the design capabilities that you talked about, and we understand that, you know, low-code, we should be getting in trouble, we should be deploying, you know, we should be failing forward faster, right?

Right.

Um, so we each go out and we look for a low-code platform and we start building apps to solve the problems in our departments. Do we have to pick the same platform, the same low-code platform for the entire company for the 3 of us to go and innovate? Or if I pick one, you pick another, and Mike picks a third one—

You're describing citizen development. And so let's say there's a Mike in every department throughout our organization.

That would be dangerous.

It would be dangerous.

Yeah.

You're describing citizen development. So each Mike buys something different. Each Mike acquires a certain baseline level of skills, enough to be dangerous. The thing that we bring to the table is that we each understand what our department is doing. But again, I don't think we'll necessarily do a great job of building that software. What's more, remember, development's only about 10% of delivery. Making sure that it's auditable, that it's secure, that it's compliant, that we're able to make changes to it after the fact, that it's documented, that we train people how to use it. We've got day jobs; we don't have time for that. We're going to cut corners, and over time, that's going to cause problems. What's more, we might do crazy. Look, if professional software developers do crazy, unmaintainable things, imagine what happens when non-professional. Get their hands on tools. Someone's gonna have to clean up our mess. So, you know, if we've got a bunch of Mikes, then, you know, someone named Bob is going to have to come around at some point and try to unify things, maybe strike a happy medium. In other words, invite the Mikes to the table. And get them to build, to go part of the way towards delivering software, but then Bob and his team actually finish the job. And it becomes a cycle where we go back and look at what Bob's team did, and then we identify ways to improve it, and then they do it, and then we keep going over and over and over again. This is what I'm advocating, where we, the Mikes, the citizens, assist in the development process. but we don't exclusively own it.

So then there's a corporate oversight or some sort of a higher-level oversight within the business.

Corporate coordination, a corporate collaboration, a corporate cooperation. Yeah.

And they'd be defining— they may pick the platform that we all use as opposed to each of us picking our own platform.

Correct. And what's more, if you use the right platform, a lot of those things that people that dabble in creating applications hate to do, they get done automatically anyway. So, or they get handled by the platform so that each application doesn't have to be responsible for it. I'll give you a perfect example, security. You know, security is unpleasant to most people. Security is usually in the business of no. And Security in an application, most low-code tools in particular start off with the point of view that everybody's allowed to do everything. Then if you remember, at some point you need to build logic into your application to take away the privileges from people that you don't want them to have. It doesn't have to be that way. You could use a platform that is based on need-to-know or need-to-do and only awards the necessary permissions During a given step in a process to the right person for the length of that step and then withdraws them gracefully. But most application platforms, low-code or high-code, don't do that. But asking citizen developers to deal with that, it's not going to happen. Even professional developers hate getting involved in that. But if the platform provides a common agreed-upon approach to security that you can reuse over and over again, now you got something. It's the application factory coming back. The nice thing about modern factories is that the factory itself does a lot of things that a lot of manual production processes used to have to do themselves. You don't worry about generating your own electricity. You don't worry about a lot of common facilities because the factory has ways to address that. Same approach when talking about software. An application factory approach is a great way to get something done.

Thanks, Mike, or Fitz. I just want to mention just briefly to our audience that if you do have a question for Fitz, if you drop it in the comment box.

Oh, please.

We'd be glad to share that with Fitz. And share any response to that, or let him share a response to that. Could you talk for a second, Fitz, about what you've described seems to make a lot of sense, but why aren't more software companies and IT professionals seeking this sort of approach to low-code development from your perspective?

Well, I would say that— how can I best put this? There's been a lot of money marketing-wise. Spent on trying to make low-code— the typical way most companies push low-code platforms is they don't push them to IT, they push them towards people that want to usurp or bypass IT. Their overwhelming message is, our tool is so easy, even you can use it. I see 2 big issues with that. One, I think the biggest potential users of low-code tools would be IT. And actually, when I say IT, I don't just mean the IT department. I mean consultants IT might bring in. I mean people whose job it is to work on software, technical professionals. But yeah, they're actually able to do more with low-code than amateurs can. But that's okay. Let's go back to this. We're so easy anybody can use us. Only goes so far. Um, there are some— I can count them on probably 2 hands, the number of low-code platforms out there that spend their time making sure they are comprehensive and professional. Um, and, uh, you know, at least 2 of them that I know of are going to be in, uh, Greenville next So, and we're one of them.

Yeah. So talk about that for a second, because I know we're— you mentioned Greenville Manufacturing X-Titles Southeast Conference on April 26th. What do you hope that folks that come to that event learn while they're there?

Well, the supposition, and it seems to bear out because again, manufacturing is hardly unique in this regard. But there isn't an organization out there where the demand for applications is being met by the current supply of tools and techniques and people to deliver them. So what do you do about it? Like, you can buy something, you can build something, and if you build something, how do you go about it? What I would like to get across is Yeah, in a couple of cases you buy something, but most often you probably ought to build it. And if you're going to build it, find a way to build it that— if I say build it, you're probably going to cringe and be, uh, a bit fearful of that idea. Well, if you use the right tools and the right techniques, it doesn't have to be scary, or it doesn't have to be time-consuming or expensive. Or anything else. What's more, unlike most industries, manufacturing already understands supply chains. Manufacturing therefore already understands business process management. Taking the mindset that they take when approaching logistics and production issues and supply chain issues and applying that to other parts of an organization, They're already halfway there. They have the potential to be halfway there. Manufacturing organizations are breeding grounds for good citizen designers. So I'd kind of like to get that idea across, and I would kind of like to see Whether or not that results in a lot of nods or a lot of head tilting.

Yeah, hopefully somebody does something as well, right? Beyond that.

So that would be nice.

Fantastic. Mike, you know, we're— Mike and Fitz, we're kind of reaching the end of our time together. Mike Yost, do you want to first share some final thoughts or a final question for Fitz? Sure.

I think, um, what stands out to me as we have this conversation is, um, sort of the history of us. Um, you know, it used to be build versus buy, right? And, and now, now it's buy versus build. It's sort of like we're coming full circle again. Um, which scares me at some level. Um, and then it also— I think what's different about it, or the takeaway that I would offer to others and maybe ask Fitz to comment on, is the focus on process. And as Fitz talked about modeling a process or digitizing a process, that focus, I think, is the right way to be focusing.

Yeah.

And these tools, these easier-to-use tools, easier-to-understand tools, and deploy are going to open people up to the opportunity to do what, what Fitz has talked about as far as being able to solve more problems more quickly for folks. I do think there's a lot of work that still has to be done with regard to the skill sets and having the right support capabilities and some of the nuances that Fitz was talking about. But, but yeah, I guess that's probably my biggest takeaway or support of what Fitz has been talking about is the focus on process.

Well, yeah, and I, I appreciate you bringing that up because this is what gives manufacturing organizations an edge. They understand process. Most traditional software developers, process is the third thing they think about. They typically think about the data first, they think about user interfaces, and then they think about process. Users usually think about the user interface first, and all of the other stuff comes after the fact. But manufacturing organizations are rife with people that have a sense of process. They've got a really good chance. And when you talked about just a moment ago about knowledge or skill requirements, the thing I really want people to understand is that it's not one person's job to deliver an application. It's a, it's a group of people, hopefully a smaller group, but still a group of people contributing different levels of expertise in different areas. Citizens contributing an understanding of what the process is and what the end product should look like, and then technical professionals contributing ways to deliver it, and then armed with tools that allow them to do it better and faster and more customization-friendly and evolution-friendly than they've worked with in the past. That's a pretty big deal.

Yeah, I appreciate that.

Nice. Fitz, do you have any final thoughts on it in addition that you'd like to share with the audience today?

I hope as many of you head to Greenville at the end of next— at the end of this coming month, and I hope to see all of you there.

Man, that's just as a comment. That's the website if you're interested in learning more about the conference, www.mx0southeast.com. Please don't hesitate to check that out. Fitz, I really appreciate the time together. I guess as I'm listening to the conversation today, the other thing that comes to my mind anyway is the need for a leader in the organization to be really intentional about structuring their go-forward plan with this in mind. You know, sometimes as we kind of trip over some things and, you know, start this way or start that way, but this requires a bit of a strategy.

And it does, but we have to do it. Uh, you know, we're seeing the, the, the end of the pandemic era, a multi-year period of this. But it was the beginning of the pandemic era that radically accelerated the need to build a lot more applications. They were needed to facilitate remote work. We've kind of gotten used to that, that taste for building business applications. We need to meet the demand somehow. Buying didn't do it, or if it did it, it got really expensive. And then the integration and customization costs were prohibitive anyway, wound up not saving money. Building the traditional way isn't going to do it. Letting users do it eventually creates a mess that somebody has to clean up. That gets expensive. There's no one magic bullet. It's really bringing the right things together and making them work together in an assisted collaborative way. That's going to get us past this application backlog, or we tolerate the fact that we're not getting stuff done.

Yeah. Well, thank you. That's insightful. I want to thank Mike and Fitz for joining us today for this very insightful discussion. As we mentioned, please join us for the 2nd MX.O Southeast Conference to hear more from Fitz and other small, mid, size and global manufacturers just to share their case studies ranging from how to get started with digital implementation to how to standardize and scale across global plants. The event's going to take place, as we mentioned, on April 26th, 2023 at the Hyatt Regency in Greenville, South Carolina. And as I mentioned earlier, you can register for that event through the website at mxosoutheast.com.

Is that an O or a zero? I'm looking at the link.

I think it's MX0.

Okay. Yeah, yeah, it's all one word. Yeah, or, or just look in the comments box, guys.

Yeah, but yeah, anyway, thank you. So thanks to everybody who joined us in the audience as well. Bjorn, I, uh, I noticed you've been making comments. Thank you for that. If you like this conversation and others like this, please look for them on LinkedIn Live or LinkedIn Audio. through our Industry 4.0 Club or group page. We host conversations like this on Tuesdays and Wednesdays, typically alternating topics around the themes of women in manufacturing, the future of manufacturing, our fireside chats with industry leaders like Fitz, and people, process, and culture. Please join our LinkedIn page and visit the website at www.industry40club.com. And I want to wish everybody a good afternoon and rest of the week. Thanks again, Fitz.

Excellent. Thanks, Fitz.

Thanks, Mike.

Bye.