Lloyd Dugan is a widely recognized thought leader in the development and use of leading, modeling languages, methodologies, and tools covering from the level of enterprise architecture and business architecture down through business process management, adaptive case management and service oriented architecture. He specializes in the use of standard languages for describing business processes and services, particularly the Business Process Model and Notation, BPMn, from the Object Management Group, OMG, and we're going to be talking about all that tonight. And he is also the chief architect here at BPM.com and our regular podcast host. So Lloyd let's get started. My first question to you is BPM as a discipline includes a whole variety of areas, including intelligent automation, robotic process automation, document management, and others. Where do you see the discipline of BPM going over the next few years?
That's an excellent question and let me sort of preface it by this notion of passed as prologue. We have seen BPM Business Process Management as a area of focus discussed in a variety of ways, and then a variety of terms over the years. One of the things that's really most compelling about BPM as a concept, as a discipline, is its durability. It has survived over several cycles, both from the methodological standpoint, as well as from the technological standpoint. But when I say passed as prologue, BPM is out of the same background of other efforts to improve processes, go back far enough. We call them business process re-engineering under Hammer and Champy. We have total quality management as a predecessor to that for Deming. You can keep going back and finding other labels for what's going on. It's again, a mix of technologies as well as analytical practices. BPM, before it really settled on that term, was also called workflow management or document imaging or document management.
Because back in the day, that was the reading technological component to the automation of documents being imaged in and being digitized as the work item that would then be subject to some kind of workflow. And there was a whole industry built around that. And then business process manager came along as the successor to that label. But in truth, it is the successor to all of those prior labels. So that's why being passed as prologue is BPM as a discipline, as a practice area is really the inheritor of decades worth of thinking and technologies applied to how to improve and optimize business processes. Now, why we call it a discipline versus anything else is that the discipline part of it is very inclusive. And we have on the BPM.com site, there's a link, a BPM.com/what-is-BPM hyphens between those .HTML that is the link that will take you to the definition that was created in part by BPM.com and others.
When I say others, I mean leading talk discussion groups on LinkedIn and other blogs sites and just as many gurus as could be lined up. And so the definition is the following, discipline involving any combination of modeling, automation, execution, control, measurement, and optimization of business activity flows in supportive enterprise goals, spanning systems, employees, customers, and partners within it, beyond the enterprise boundaries. Now that's a mouthful. Let's face it. So what BPM is not is it's not just purely a product or a technology, right. But although the research services like Gartner and Forrester, when they were really tracking this market, continue to talk about it that way. Most vendors practicing or delivering products in the space don't use BPM as the moniker anymore. It's not a market segment. It's not a service that we used. It's a discipline that we practiced.
And when I say discipline, I mean, it's like accounting or product management or operations management. These are disciplines in business. BPM is no different. It just doesn't have the cachet, if you will, of these other things I've just mentioned. Long-winded answer, but the evolution of BPM forward has to again be bounced against it. The predicate of what came before it. So now let's talk about where it's going, right. We have new technologies which are disruptors and they're causing BPM to come through another refresh cycle. Things like robotic process automation. Some people think you should improve the process before automating it through RPA. And from my experience and Nathaniel's experience, we see a different light. You shouldn't be trying to improve these processes. Each should be trying to turn them over to the RPA to do while you do something better elsewhere.
But RPA is one of those technologies, artificial intelligence, machine learning, all of the software, ex artificial intelligence kind of stuff. That's coming up. That's what's going to push BPM into new territory because now we're looking at newer ways to automate processes, newer ways to think about how to optimize them, hybrid workforces between human beings and software robots, as well as maybe physical robots. So BPM has got its work cut out because of the advent of these new technologies, the stuff that it used to rely on in the past, sort of define it has hardened underneath and around it. So most of these problems are already well solved. Like what do I do with a document? What do I do with a transaction? How do I manage this over the internet as a channel? So these are the questions that have been largely answered and problems largely solved.
So I think, again, what moves the BPM discipline forward is these disruptive effects of new technologies, new forms of analysis to move it forward, keep it fresh and it's focused. And I'll just close on. One of the two things I think are particularly on the practitioner side, pushing it forward in that respect. One is process mining. Now several years ago, process mining used to be more of a science experiment. It was known and discussed by the handful, but nowadays it's practical ubiquitous. There are many leading modeling tools that have explicitly incorporated process mining into their tool set. And I'll explain what it is in a moment, but just trying to give you a sense of the scope and many RPA vendors are now starting to do the same because they realize the process mining can help them figure out good candidate work streams for being turned over to a robotic, software robot to do.
So process mining takes log information from a system or a set of systems that's executing a complex set of business transactions through automated things and interprets and infers from a set of journeys for the work that's moving, right. So it will provide a map representing those tierings, those transitions from one state to the next. And now you get basically the statement of what the process is actually doing. Whereas the process model tells you what the model should be doing, right. The process model like in BPMn is a prescriptive statement. It does this and nothing else, but a process mining, the tools, focus on tracking what the processes are actually doing and recording that visually in a what it called a process map. So the other thing that's being instructed is business architecture. And business architecture is also a discipline. And one that I think is also right up there with business process management is things that should be taught regularly and undergraduate and graduate business classes.
The advent of business architecture, is pushing BPM to be more responsive, to higher levels of thinking about what the business is doing and where it's going just as the reverse is also true. A BPM is informing a business architecture about those things that are high optimization projects, and those that are not necessarily good ones to go after, or I should say high value optimization projects versus smaller ones that are not as valuable to go after. So those two things are pulling BPM forward from a methodology standpoint, the RPA and AI technologies are pulling it forward from a technology standpoint. And it's these kinds of things that seem to happen every five or 10 years with BPM that keep it fresh, that keep it engaging, keep it growing and evolving.
So you say that no matter how far we go forward with automation, we can't automate it until we understand the process, which is part of what keeps BPM as a discipline fresh.
So let me give a two-part answer to that, right. So yes, because BPM is about process optimization and technology is often the means by which it is done, but also yes, because also a little bit, no, if you will, because the technology is not the only thing that's going on, even in automation efforts, there's some level of what can we do to improve the process? Can we drop this piece or that piece, right, of a process? Can we shift it from being done over here to being done somewhere else? Do we have bottlenecks? And if there are bottlenecks present in the process, how do we get around and how do we make those bottlenecks go away? Those things all still exist, whether you're automating or not. And so that's still part of what has to happen.
So that's the discipline aspect of BPM that is what is really leveraging the automation component of it. But yes, as long as we have processes that require improvement and they're always going to require improvement. BPM will have a place. And I think that is, I think you're spot on. I think that is a key reason why it keeps refreshing itself because it's addressing an enduring problem. That's always going to be present with us.
You're listening to the BPM.com podcast. We're talking to Lloyd Dugan, who is usually on the other side of these questions. Lloyd, there are a lot of new companies that are entering into this business. What are some of the most exciting developments in BPM or intelligent automation that you've seen today?
Well, I think a lot of it is on the RPA side, the robotic process automation side and first gen RPA is really building on a foundation of skill sets that people at the functional testing level already had in terms of understanding the design aspects of the user interface, functional testers with automated tools, for example, had to know this in order to create test scripts, to validate the expected behaviors on a screen, as a person proceeded through it. And that's been a standard part of functional testing for decades now. The people who are really good at that are probably going to make very good RPA designers because they have the same level of thinking. Basically, any skillset or any job that requires you to understand a good user interface design and how to understand the dependencies between steps and working yourself through a screen.
These are the things that will carry over well to RP design. Because what RP design does is essentially give you a visualized programming means of working all that out. So your design looks kind of like a sort of weird looking process model. It'll be done in a notation and a motif specific to the vendor's tool. But if you kind of step back a moment and realize it's just another workflow designer tool set on that basis, again, if I know how a user interfaces work at a deep level, and I understand the basics of workflow design, I could be an RPA designer. And so there are a lot of RPA first gen products on the market. And when I say first gen, what they're doing is they're permitting the use of bots to do very discrete chunks of work.
So you basically program in the software robot to do something that a human user might otherwise do, but it's a very short bit of work. This is a kind of unattended RPA. We also have more expansive versions of that, where you basically create virtual users. So these would be software robots that again, like our human doing the work, they have a registered account, they have authorized access to certain systems. And then they are, per the RPA design, programmed to do certain steps with an assistant, work through a set of screens in a particular way, saving the effort for the human being to do it because that's just repetitive and routine work that they shouldn't be doing. It frees them up to do other more high value added work. There are unattended RPA situations where it's a lot of system maintenance actions rather than have someone come in and do those things, right, or overnight processing of files and stuff like that are not so easily bought off as a con job to do on, on some infrastructures platform.
Again, you can use unattended RPA. So the technology is in the first gen taking all the routine and regular and repetitive stuff away from the union user and giving it over to the RPA software user or the software RPA user. Now what will come next is machine learning and artificial intelligence will expand the ability of the robots to deal with cognitive moments, right. Because everything I just described a moment ago, these are deterministic months, right. In the design, the robot either turns left or right based upon a very discreet evaluation. There's no thinking here. There's just deterministic algorithmic logic that's occurring. But with machine learning and its artificial intelligence, we'll get to the point where the software robot can start to pick up some of the, at least low level cognitive functions that the human beings apply when they do this work making judgments and we'll see how that works out. But that would be next.
Going forward we'll always need training and you are well-known in the training field throughout this industry here on the BPM.com platform and then working with the Object Management Group, which is better known as OMG on their certification exams. Can you talk about some of the new standards and exams that are being developed?
BPM certification is kind of a cottage industry. Everybody has their own certification. We have our own here at BPM.com. So it's not like with the PMI, the Project Management Institute and their PMP certification. That that has become the gold standard. I'm not even sure there's a second place in that race at all. It's something that shows up in RPs, certainly from the government, I think from probably private companies as well as is that they want their project managers to be PMP certified, which means they've gone through the training, the certification exam and whatever else is involved in securing that certification. Nothing like that quite exists for BPM. The one place where the certification question gets a little strange, relative to the cottage industry around it, is that the object manager group at the OMG. So the OMG has a set of certifications. I think a Baker's dozen across different disciplines and six of them have to deal with BPMn.
They're known as the OMG certified expert in BPM 2. That's a mouthful. We just call it OCEB 2. So you could take six exams, three of which on the technical track, three which are on the business track. And that structure has been around for a while. It really, in my opinion, hasn't proven out the way it was supposed to. I am currently assisting the OMG with others along with others in making sure that the current set of exams will work on the new testing platform provided by Pearson. There is an idea which I started to push along with some others that the next round certification should be something very different. Instead of testing stuff that they're stretching out over six exams, for example, we just stretch it over three exams. So we have an entry level, intermediate level and an advanced level.
That's it. We focus on just the standards and that will be focused on the convergence of the three standards. This is Process Model and notation BPMn, the Decision Model and notation DMn and Case Management Model and notation CMMn, and three of them linked together. And that is what we discussed on the last podcast with Denis, the emergence of BPM+, that is the unification of these three standards. That needs to have its own certification process going forward. And it's my hope that this time next year, we will be talking about not only the existence of a BPM+ standard, but certainly the certification framework for that, that will already be underway. And the only one I would mention again, is business architecture, which is coming into its own with its own certificate in exam, except the exams are now subject to the different constituencies behind them, right.
So the Business Architecture Guild, which I'm affiliated with, I'm a contributing member and I'm working with them on the business architecture standard at the OMG has their own certification around what is known as the BIZBOK, the Business Architecture Body of Knowledge, right. If the OMG comes out with this standard and we hope to see this thing emerge this year into the next round of development, wouldn't surprise me if at that point, there is a business architecture certification of belts around the OMG standard, but the BPM+ I hope to get started on later this year with the OMG. Here at BPM.com, we're looking to revamp our program to reflect these emerging opportunities.
I'm going to give you five minutes for your rant for the day.
I need a shameless plug moment because I usually give those out. So my shameless plug is that I'm speaking at the IRM UK offices for Business Analysis and Business Process Management in September and November. So I look forward to those moments. I would encourage you to sign up, anybody listening to this, to sign up for them. They're still virtual. And as a consequence, you get at a heavy discount, insights from a lot of people around the world.
So my rant is on training is that too often, people think that this is book learning stuff. And it really isn't. Now having said that, somebody had to start somewhere and we all had to start with kind of book learning. But even my own journey there, for example, began with decades worth of modeling in other languages. So by the time I picked up BPMn, I had two decades worth of experience and at least three other types of modeling languages for modeling processes as a sophomore.
So it was, for me, it was like I knew Latin so it was easy enough for me to pick up any of the other Renaissance languages. And there's a notion though, in too many places, that training is more lightweight than that. Training on these things is more lightweight than that. And that comes across in terms of people's willingness to spend the hours necessary to learn it. So they get well-practiced at it, it comes in the form of their sponsors only being, not necessarily willing to pay, but so much for it to grant them time away from their work to learn it. And it's a shame because if you look at what happens with Lean Six Sigma still in these organizations today and Lean Six Sigma is one of those predecessor disciplines that really has spent, it's past its peak in some sense, right.
People say, oh, go take three days of this training right, or we'll pay you a thousand dollars or whatever to go get this kind of training. That has happened, even though Lean Six Sigma itself is not the newest thing out there, right. So somehow with BPMn in particular, there's this perception that it is something that they could pick up something, they could be trained on once and be done with it. And the people who took the training and their employers or sponsors can reap the benefit of that going forward. And I'm here to tell you that none of that is true, right.
There is a level of understanding about it that might work, right. And I'm going to make a comparison to something my college roommate said that you can learn enough Japanese symbols to be able to read the paper. Probably anybody could do that. If they've got enough dedicated time to do it, if you really want to write it, know you've got to spend a whole lot more time doing it, by the way, there's some level of investment, but there's a two tier aspect of it. There's enough to read the paper and communicate. Then, there's understanding the language and being able to write about. That's similar with BPMn.
And we have to figure out a way to teach the tier one that is durable and last with impact and utility for the people using it. And then the tier two for the extra, for those practitioners who are using the more advanced forms of the model of the modeling language. And I will confess for myself, I still struggle with how to draw that line between the two, but we do need to do it, but we need something from the marketplace to recognize the value, whichever tier I'm in there's value there in giving the people dedicated time to go take the training, get as much out of it as they can, and to make a practice of it.
If people go into training and they don't have tooling support and methodology support, and corporate support, when they come home from the training, however, wrong it was, right, then it's just going to, it's just going to waste away. It's going to bleed away in a short amount of time. And it will all be for not because six months from now, they're not going to remember how to do anything. So that's my rant is that somehow BPMn training has not been given the stature it deserves, particularly relative to some of its peers, both past, present, and emerging future peers. I'm just at a loss to understand why that's the case. But so my rant is that see BPMn training or any of these modeling languages or even things like business architecture, see these as investment opportunities.
And they're like bringing a plant home. If you don't water it, if you don't fertilize it, if you don't put it out in the sunlight, as much as you can, it's just going to die and you'll have wasted their time, your money. And everybody else is concerned involved in bringing it about. And there's no point in that, right. If we're going to train people, it should be to do something and it should be to do something as part of their job. And if you can't be seen that way, then they should not be getting the training.