#114 Automating Business Process Management

Subscribe to get the latest

on Tue Nov 22 2022 16:00:00 GMT-0800 (Pacific Standard Time)

Darren Pulsipher, Chief Solutions Architect, Public Sector, Intel, and Max Young, CEO of Capital BPM, discuss operationalizing business process management with modeling programs.

Keywords

#compute #businessprocessmanagement #capitalbpm #bpm #automation #camunda #rpa

Listen Here

BMP modeling reminds Darren of when he took drafting in high school, and AutoCAD’s introduction of computer-aided drafting systems changed the game. Before, they would have pages and pages of complex systems and diagrams so people could build, but they couldn’t test the model to ensure it was right. Using computer modeling, they could run simulations to ensure there weren’t problems such as electrical and plumbing running through the same hole.

This is analogous to architects using PowerPoint to show business processes instead of using a modeling tool that can find conflicts and issues in what you thought the business process was.

Using a business modeling tool also solves a practical problem by eliminating the wasted time of getting all the interested parties together for meetings that may need to be more productive. Instead, you can put a deployed model into the hands of the business customer and work through the steps with them.

After articulating and modeling the processes, you can choose integration points that might attach to restful interfaces that get information and pump it back in. This is how business processes can integrate with microservices in the cloud. In the example of the hiring process, these points might be where you need an API to invoke checks for job history or criminal record. The inputs will be items such as social security numbers and dates of birth, and the outputs will be a Boolean - does the information match or not? This is where. You can start having that iterative conversation.

bpm image

There are quite a few manual steps in this process, and you can choose which ones to automate. For example, if you decide that an interview didn’t go well, you can default to HR. After you deploy that new process, you can go back and look at the previous version if you want to, so you have two concurrent versions of the software working and deployed at the prototype.

The Camunda modeler is a native modeler, but Capital BPM has built its own applications that help streamline some of the work and support different user roles.

This system is different from RPA because instead of capturing what a user does with keystrokes, a business analyst looks at the processes and steps across multiple departments. The analyst is looking top-down at the whole process. An RPA can be plugged into some steps for efficiency. A simple example is if a job applicant passes the job history check and criminal record check, it can go to a senior HR person; if not, it’s rejected. Choosing specific steps, or sets of steps, to automate is an iterative approach that has been used successfully in software development for some time.

RPAs can be game changers, but they are tactical and short-term. While these short-term gains may be profitable, you need to look at the entire business process to find optimization and steps you can eliminate. The story of the woman who always cut the roast before baking it because that’s how her mother did it is analogous to some company processes. The woman finally asked her mother why she cut the roast, and her mother replied, “So it would fit in my pan.” Many company processes are only there because they’ve always been done that way, and no one has thought to question why.

Testing, simulation, moving things around, and running processes repeatedly in the modeler, in other words, empirically testing, can help eliminate this process bloat and add significant value. Visualization and experimentation are vital parts of the whole process.

Max points out that there is fidelity between the diagram and the actual execution. Developers often draw diagrams as a starting point. Still, the charts disappear as development moves through the different parties, so what the business thinks is happening and what is happening are different. The diagram and reality are separate. In this type of modeling, the picture is always an accurate representation of what is happening. In addition, it’s easy to see and make changes for improvement.

Podcast Transcript

Hello, this is Darren

Pulsipher, chief solutionarchitect of public sector at Intel.

And welcome to Embracing

Digital Transformation,where we investigate effective change,leveraging people, process and technology.

On today's episode, Optimizing.

Processes with Business Process Modeling.

Part two of my interview with Max Young,

CEO of Capital BPM.

Just so you know what this reminds me ofwhen I was in was I was in high school,

I took drafting.

Yeah.

So I was in three yearsof drafting in high schooland my junior yearthey introduced CAD systemsfor the first time,computer aided drafting systems, AutoCADand it was a huge shiftfrom drawing outbecause we had the big drafting boards,the whole thing,and you would have to draw pages and pagesfor complex systems, pages of diagramsso people could build them.

But you couldn't really test how could youtest that your model was right.

You, you did a lot of workand there was a lot of back and forthbetween the drafters, the architectsand the guys that had to build the thingsright.

All of a sudden, computer aided draftingcame along and they really used a modelinstead of.

That.

By using a model technique,now we could actually run simulationsof those modelsand see if there were any issues like,

Hey, did I have electrical and plumbinggoing through the same holes in a wall?

Well, that's a problem.

You don't want electricaland plumbing together, right.

And small things like that.

So what you're saying with this,this is very analogousto a lot of architectsare using PowerPoint presentationsto architector to show these business processes.

But if you use a modeling tool, itups the game so it it can find conflicts.

It can find issues in what you capturedor what you thought the business.

Process was not.

All right. So whatyou can actually see here, for example,that this thing has been deployed.

You know, it's at this particular step.

I can submit it, I can have logic,and it allows it to go one way or another.

And what I like about thisis that it solvesa really important problem for me.

And it's, again, a deeply pragmaticproblem, you know as well as I do.

What happenswhen you want to start a new project?

You sit down, you get, youknow, ten, 20 people into a room.

You guys shoot the breeze for about tenor 15 minutes about the kids in the snow.

You know, you talk about stuffsomebody might draw on a whiteboard,somebody takes notes, takes pictures.

There is an analyst in the room.

They go away and, you know,if you're lucky, you know,by the end of the week, they've typed outthe notes as senator everyone.

And then after you're done with that,you find a time when everybody elsecan get in the room again and again.

If you're lucky, somewhere in the next 2to 4 weeks, you have like a second meetingabout this, and you spend most of thatmeeting reviewing what you did previously.

And then you might be ableto move the ball forward in nature to.

Right.

I don't think I'm spellingany corporate secrets.

That's a no, no, no.

This is no, this is corporate. Right.

By here's what I just did.

I just went out and I builtand I deployed this.

I can put it into the handsof my customer, my business customers.

They can actually come in hereand they can say, well,

I'm going to actually drive this task.

Right? I'm I'm going to actually.

I want to step through it.

So you have. To push this. Wow.

Now I come over here and we see thatthe diagram is at this step,like itreally went through these processes.

And if I had told you to do like a checkfor a restfulcall here or here,you would have done those things.

So that's that's the nextthat's kind of the third part here is

I can take it from modelingto integration.

That's it.

So if I, if I, if I look at thethe steps here, we had to articulate.

Right, or capture the business processand articulate it, model it.

And now I can chooseintegration points in these steps.

I can say, hey, at this step

I'm attaching to a rest will interfacethat's out there that getsthat information for me and pumps back in.

So this is how I can integratebusiness processwith microservices or servicesthat are out there in the cloud, whatever.

Exactly.

So, so for example, you could say,hey, if we're going to do this project,the orange spots are the placeswhere we're going to need,you know, someone to come in and createan API for us that we can invokethe checks for job historyand checks for criminal reviewand what are going to bethe inputs and outputs of this?

Oh, well, you know, the inputs are goingto be the Social Security numberof the date of birth and the stateand and the outputs going to be a boolean.

You know, did you knowdoes the information match or does itnot match? Right.

So you can start havingthat iterative conversationand that becomes.

Yeah, so so this,yeah, this, this sounds a lotlike what we do in software development.

It is.

Right.

Which has been kind of missingin the business process or systemsanalyst space where this is mostly sits.

Right.

This mostly says, oh,

I've got a business analyst that's comein, help me do process improvement stuff.

But they're they're not modeling.

They're using, you know, Visio.

Visio is not a model. Right.

This is a drawing tool.

So I really like this.

And then you can drill downon, hey, here's some steps.

You could deploy this as a process today.

No, I just did. Right.

So this diagram,this is a deployed process.

Okay. So sweet.

There's a lot of manual stepsin this process.

No big deal. Yeah.

And that's why you actually.

Now I can choose which ones to automate.

I see what you're saying. Right.

And I can actually, like,do this really fast.

Like, let's say, for the sake of argument,

I want to puta decision on this interviewstaff and go, hey,if the interview didn't go well,maybe we push back to h.r.

And we say, you know,we push it back to the candidatewho said we have questions for you right?

So i can actually comein, i can evolve this, i can say, hey,you know, this is going to bemy default path here.

This is going to be,you know, an expression.

And that would be you know, I'veyeah, we've got toto put a lot of work in here,but we could be examining like a checkboxor whatever to indicatewhether we wantto move forward or not. Right.

And then we build this.

We say that we deploy it.

And now the thing that's actually deployedis this newer processwith the you know, with a gateway here.

And if I wanted to, I could go backand look at the previous version.

So I've got two concurrent versionsof the softwareworking and deployed rightnow, right at prototype.

That's bad and good.

And going at the same time. Right.

So you can actually see in here.

Yeah, like the datathat's going through the system.

So all right.

So I like, I like where we're headed hereif we so we've got our three selves.

What's the next step after

I've integrated.

Right. Because you show me some of that,some of the stuffbefore I can actually run.

You guys have a tool lintfor business process you.

So my thing is without being too braggyof our own stuff, we've actually built,you know, a couple of applicationsthat make this a, a more,a moreeasy thing to do.

So what I was showingwas the native okay on the modeler, butwe've built our own systemwhere you can kind of go on.

To help streamline.

Is it is it targeted primarily for isit targetedprimarily for business analyst?

It is men.

That are doing captureor is it for the developerthat's writing rest interfacesand things like that?

Who what?

So it's ait has support, different roles, right?

So initially you would have a businessanalyst or an SMB come in and sort ofdefine out, well, you know, here'sthe data model that we're working with.

Here is the workflow that we haveand the different rules that are involved.

You can actually have them come inas in this caseand go, Well, here'sa restful API that we're going to call.

Let'ssay this gets a list of all the customers.

And then,you know, we're going to have like a formand the form is going to say,display the customeror display all the different users andand we have like a one way, okay.

So you actually can take itto the next level, what I would callthe next level below testthat model where nowyou're actually creating the application.

Yeah, that's right.

On top of that model.

On top of that business processso that I can watch it go through,

I can drive it through, I can askusers for information, all that.

Yeah.

So for example, I could create a tableand I can say this tablewhen it loads, you know, it'sgoing to make a restful calland the restful callis going to be to say,

I don't know, loadall the customer is right.

So right.

So I want to kindof tease out a little bit onthis.

This is different than RPA. Yeah. Yeah.

Because RPA is I'm capturingwhat a user does with keystrokes, right.

It's doing that.

You guys are saying

I have a business analyst that comes in,really looks at the process and the steps.

Right.

Across multiple depart in in.

My opinion and.

Then. RPA.

Yeah. Would be a step in here. Right.

So you might have like.

Yeah I can see.

How we you know,when we review an applicationand the first thing we do iswe look at the boxesthat come in from criminal backgroundcheck and job history check.

And if that's true, then, you know,we pass it on to a senior h.r.

Person, otherwise we reject it, right?

So at that point, I might plug inlike an RPA step and here I go.

This is just going to invoke RPA, right?

Gotcha.

Okay, so that's that's the mainthat's the main difference.

You're looking top down the whole process.

Yeah, that's exactly right.

Across departments and an RPA isreally how a individualmight be doing a stepin that process or even a couple stepsin that process, whatever the case.

Absolutely right.

You know, RPA,you can get a really fast winlike, you know, creating a trueintegration that talks to the back end andand you put the security certificatesin place and all the right environmentsthat can take months.

Right.

Just from the bureaucratic architecture.

But you put an RPA bot in therethat just opens the email,it takes the two fields out and puts theminto the system and pushes the buttonand you just immediatelysolve the problem.

And in a couple of days ora couple of weeks, that might have takena really long timeto do in a quote unquote correct way.

And you always have the latitudeto come in and change thisand make it a trueintegration down the road.

Right.

And I like that approachbecause there's there's always a pointwhen you're designing a system like thiswhere you have to make a decision onhow howwhat is my return on the investment

I'm going to spend right nowby automating somethingand this I love thisbecause this gives you that opportunityto say, well,

I'm going to automate this step.

And that'show everything else is going to be manual.

But this one step I'm going to automateor the set of steps I'm going to automateand I'm good. I'm in good shape.

So I really like this iterativeapproach that we've been doing in softwaredevelopment for some time.

And it sounds likeyou're doing a great job at bringingthe things that we learned in softwaredevelopment over the last 30 yearsinto business processmanagement and business process.

So, you know, I think I saw a little bitabout some of the thingsthat you had built there, and I think youhad sort of done the same sort of thing.

Like you have a systemwhere you can visualizehow things interactand actually drive that.

And I think that's just what happenswhen you take smart peoplethat have to solve big problems.

We recognize the value of clarity.

Yeah, I like what you said there.

The visualization is key,right?

Because that's how you're communicating.

What's going on knowso and that gives you clarity.

I really like how you brought that out.

So that visualization really helpsother people understand what's going.

Yeah, we,you know, going back to like the,the martial arts metaphor and some ways

I think of the injection of RPAas sort of fighting dirty like,you know, you've got to do an integration.

Oh, all all my RPA buddies out there,forgive me.

Oh, I love it because I.

Know it. Is.

Yeah, it does work like that.

You get quick wins. Absolutely.

And I think that that'sthe highest compliment.

It's pragmatic.

You can solve a problem today, say thatif you took another path, you wouldn'tbe done talking about for two months.

I love that.

It iswithout putting too fine a point onit is a game changer,but it is, in my opinion, a tactical.

But it's a short term gain.

But it's enough, right?

You you could in a corporationthe size of intelor some of the ones that you knowthat we work withshort term gain by three months,millions of dollars.

But but you don't you don't want to restyour laurels on that short term gain.

Right. That's the problem. Right.

Right.

You need to see how that little processfits into this bigger process.

And you need to look at your full businessprocessesto to find optimizations,to find steps that I can get rid of.

I mean, we've had thisthere's this old story.

It's a funny story where this ladyis teaching her daughterhow to cook a Thanksgiving roast.

And she goes and she cuts theroast in half andand puts it in in the pan and cooks it.

And her daughter says, well,why do you cut the roast in half?

And she goes, Well, because my momtaught me to cut the roast in half.

So they asked Grandma, right, hey, why?

Why are you cutting roast?

You know, why did you do that?

And says,because the pan I used wasn't big enough.

But this processof cutting the roastpassed down from generation to generation.

We have stuff like that in our companiesall over the place.

Why are you doing it that way?

Well,because it's always been done that waywithout anyone sittingand really analyzing why?

What is the purpose of doing it?

So we end up with process bloatall over the place.

Yeah, yeah.

And and bureaucracies that fit in.

And I think that'swhere our training as engineers comes inbecause we have to be clear eyedand look at why are we doing it this way.

What is the benefits doesn't have onethat I'm that's a variablethat I failed to capture in this equationright andand testing simulationrunning things again and againlike one of the things that I loveto do as,as a stress relieving mechanism is once

I deploy a process,

I will pull it upand I'll start moving activities around.

I'll do this this thing before that thing,and I'll see if I can doparallel processing.

I'm, I'm playing with it.

I'm empirically testing itand that adds a value to it.

That does add a lot of value. Absolutely.

And it's somethingthat we need to be able to do more of.

And that is I don't know whatyou would call that permutationsjust test the model by pulling it aparta little bit or the processby rearranging things.

I call it experimentation again.

I like.

There you go.

That's the word

I was looking for experimentation.

We did something like this.

I was on a big projectat a former company, Cadence

Design Systems, where we were doinga running test of our softwareevery night and our software runswould take 24 hoursto test our software and we had to run it.

This is back in the good old dayswhere you had to run on HP X

Air x Solaris, all the flavors of Linux.

So we had these massive, massive gridsof compute, all compute resourcesthat we ran these tests onand we would run them one test on CPU,we would run front ways and the other oneon air X would run backwards.

So halfway through the nightwe would know like 12 hoursand we would know how the testgenerally did of crazy that we did that.

So we started looking at optimizing,how could we make this faster?

And we took the same approach.

What if I pulled things aparta little bit,move things around, group tests together?

If they failed, they failed earlyand I didn't run more tests.

We were able to get that cycletalent to about four or five.

So all of a sudden Icould run tests in the middle of the day,

I could run them at night, I could run.

So this whole idea of experimentationand the only reason we were able to dothat is because we could visualizeand we could see the stepsand how they interrelated.

And I love how this all fits together,right?

Yeah.

And and this should really empowerbusiness analyst and process engineershow to really do this rightinstead of I'm just going to copyexactly what we've always donein the same order we've always done that.

That's not the real benefitfrom absolutely right.

Absolutely right.

You literally couldn't have said thatany better.

I think that thethe thing that I really like about thisapproach is what and I'm not sayingit's the best approach in the world.

I know that there are softwareengineers just as goodor better than mewho take a completely different approach.

And I am sure they're.

Very they're just not as enlightenedas we are.

But I'm sure there are validcounterarguments.

But what I really like about thisis that it feeds the business.

And here's what I mean by that.

There is fidelity between the diagramand the actual execution.

A lot of timesin the business that you and I are,and we'll draw the diagramsand that will be the starting point.

But and then from there.

On, right, people,the developers make a compromise,they do something or anotherand it doesn't reflect back.

So what the business thinks is happeningand what it is really doing.

And what's.

Happened, they've separatedwhere with this the picture is the codeis always an accurate representationof what you're really doing.

And the business can come and look at youand go, No, dummy, you're doing it wrong.

Do step two before you dostep one, it'll save you a lot of trouble.

You know, we we hadwe had a system where we werechecking to seewhat country somebody was in.

And then based on that, we were givingyou were looking at what rewardsthey were entitled toand then giving them discounts.

We know we did this for a long time.

We model thatbecause the way I was showing youas a has a rule engine embedded into it.

And then one daywe showed it to the businessand they're like, Well, that's stupid.is in the United States.

Why don't you check for that first?

Why is it down at the bottomafter all these other kind of bottom?

Yeah.

Right.

Drastic improvementsbecause.

It's so I love

I love that the model it's not a diagram.

Right. That's what we want to get across.

It's a model and it drivesthe simulation,it drives the application itself.

It representsso I love how that's all tied together.

Max, this has been wonderful.

Yeah, Wichita. Wichita, 4 hours.

I already know.

That's about eight.

Our listeners will get tired.

So Max,thank you so much for coming on the show.

We most certainly will set itsome time again.

I really enjoyed this timeand thanks for having me on.

Thank you for listeningto Embracing Digital Transformation today.

If you enjoyed our podcast,give it five stars on your favoritepodcasting site or YouTube channel.

You can find out more informationabout embracing digital transformationand embracingdigital.orguntil next time, go outand do something wonderful.