Session Information:

Innovating process automation with a standards-based, highly scalable and collaborative approach for business and IT

Processes define how we work together within a team, across an organization, or with our customers, partners, and suppliers.

• Processes may or may not include human tasks — they may interact with APIs, RPA bots, (even real robots), microservices, IoT devices, machine learning, and AI.
• Processes are the algorithms that determine how an organization runs. Successful businesses grow from proven, effective processes. 

Session Transcript:

So, with no further ado, I would like to introduce our first speaker to you, who will be joining us on screen.

That is Bert, from Commander.

Heart is a software developer who has been innovating process automation deployed in highly scalable, Agile environments. So, industry leaders such as T Mobile, Lift Hunt's, I N G, and Atlassian.

Bird has contributed to various open source workflow engines for more than 15 years. And he's also the co-founder and Chief Technologists of come under.

The company providing leading process orchestration, platform, is also the author of Practical Process Automation with a variety and the cool sort of real life P, P M N.

So please, don't hesitate to check those out. Highly recommended to that. But good morning, thank you for joining us. I'm handing it over to you.

Thank you, Brian. Um, good morning from me as well.

I have to ask that, can you see my screen?

I hope so.

Otherwise, I think somebody gives me a notch. We can say.

Awesome.

Right, so let's jump right into that. So I want to talk about we call it innovating process automation, and I basically want to want to talk about the role of process orchestration within process automation. But first things first, that gets little lights burkean What can you see here?

Some of you might know this, then it's easy to spot when people see that immediately. Some take a little while?

Hmm, It's a doc.

Right? It's a dark walking.

It's very easy if you see the movement, but it's sometimes pretty hard to just see it when you see the dots, and that's kind of interesting idea, which is very often the case.

So, if you have, like, individual things, like, for example, with cooking, you might have different ingredients, which, on its own are probably already nice. But only if you combine them in the right mix. You get a really delicious dish, or the same goes for, for any sports team, and individual sports.

Player is not, cannot do really much. They need a team, where they really play together well, and whatever you can make it a lot of these examples. So it basically bones voice down to that old, saying, the sum is greater than its parts. And I think this is something we should definitely keep in mind when talking about causes automation.

And I come back to why I find this so important, in a minute, OK? So, keep that walking, probably in the back of your. if your hat, if we talk about process automation, I think we don't have to emphasize the importance of process automation. So, in a recent survey was discovered, 92% of Decision makers decree that process automation is one of the keys to digital transformation. Which is probably not a big surprise to anybody here in that audience, I guess.

So, let's look at an example.

And let's probably also make the challenge, more, and more tangible by that.

And this is something I discuss with a customer, or weeks ago, or something like that. So recently, there was a bank of a global bank.

And they were basically telling me, OK, we, we looked at our competition, which is already a good thing to do, probably to see what they're doing.

And our bank account opening takes far too long. They do that in minutes, and they could actually, and I found that interesting.

They could actually tell me the exact amount of time you need to open a bank account with their competition, but it was within minutes, right. So everything online, at the very end, you get your bank account number, and you're ready to go.

And they needed dates in order to do that.

And obviously, they understood that. they have to change this.

So, when you then, And this is a pretty typical thing, right? So, competition is raising the bar, and they are probably using automation for that. Otherwise, you can't do that within minutes. 24, 7, they're raising the bar. Customer expectations are getting higher and higher. And basically everybody has to cope with that, otherwise you're probably out of business at some point.

Um, if you then dive into how this process of bank account opening is implemented, like IT wise, you have to follow a couple of steps.

Obviously, so you have to do these kind of tasks in a certain sequence in order to open the bank account. And, of course, you have to use certain existing IT systems.

Because very often, it's not a greenfield. If you, if you don't start a bank from scratch, you have your existing IT legacy systems and you have to connect them in, in some way in order to make that happen.

The one of the interesting things is, some of that task might be automated already in these kind of IT systems.

So the address check, for example, is fully automated, but it's just a separate system from the rest of the things.

So the wiring together from user, like entering data on the website. Basically ending up in the CRM system.

That might be an API call, But then, how does the human look at that in order to prove it. For example, how does the approval is written into the CRM system? How does that trigger the test check that has to happen next? How is the scoring triggered than, and so on and so forth?

Like, the overall control of that business process happening is, it's very often challenged.

And probably, and as a result, we see very often a broken end to end automations. So, if you look at certain tasks within a cost, I come back to that, and they might be automated very well. But the end to end thing, like from the customer, wants his bank account to, its fully opened, its very often profit problem in terms of automation and integration.

That leads to, not only taking longer, but also a lack of understanding.

So, how do we open bank accounts? It's something you might have to ask a lot of people to understand what's what's actually happening, And that also means you're not able to change it. So for two reasons, first of all, if you don't understand, it's hard to change. Second. Second of all, even if you understand it, you have, you might have to touch a lot of different systems, a lot of different teams, and organizational procedures, or whatever. So it's pretty hard to change it.

That's kind of the, let's say, the balmer off process automation here.

That's kind of the big challenge here.

That's what process orchestration solves. So the idea is to add some kind of orchestration capability.

What I'm using here is BPM, and I'm not going into the, the basics of deep amendments.

It's a modeling standard, ISO standard for, first of all, like, drawing modeling, designing these nice little flowcharts, but also execute the executing them on a workflow engine.

Show you that in a minute in more detail. But the idea is, this orchestration here this Orchestrator. Can basically tell the different parts, different tasks here when their Turn X So, OK. The website basically kicks in new bank account opening request. So, the first thing we have to do is to to check the address, which might be an API call to the address checker. Which is already there. So we're not automating that task itself, we're basically triggering it, And the next step is scoring it. And the next step is probably a manual approval. Same thing. It's not automating the task, but it's making sure the person that does it knows it at the right point in time, and so on and so forth.

Pretty obvious, to some extent, but that's, yeah, press orchestration. So it's orchestrating it's co-ordinating the different tasks here.

one thing that took me awhile to understand when I, when I explain process automation to people, is that there seems to be sometimes misunderstanding here.

So very often two things are actually mixed up. The one is like automating certain tasks.

So when I say process automation, and that's why why I emphasize some process orchestration so much. When I say process automation, a lot of people think of, oh, it's a fully automated process, no human does anything. So, it's really running through end to end. And that's not necessarily true, so we might still have humans involved, so, we might still have some things being not automated, but we want to automate the control flow.

And that's a different thing than automating the tasks.

Like, I could hook in, and whatever an AI driven system to do, an automatic approval that would automate that one task, but still, I have to do the co-ordination of, when should that happen in the overall process?

And that's a really fundamental, different thing, automating like one task, and automating the orchestration part.

And I find that important to keep in mind, automating the task, automating the process. So for example, RPA robotic process automation is a pretty hype topic. It's declined to some extent, but it's still, I think very well known and RPA, for example, automate tasks.

That's a catch the name. It's not robotic process automation.

It should be robotic task automation, because you can automate one task, because you can then like, automatically control or steer a user interface to do one thing instead of the human.

But it's not built to orchestrate end to end business process.

OK, important distinction here.

Um, then if you, if you want to do that orchestration, one of the big challenges here is that you have really a diverse set of endpoints, typically.

So it might be humans, you're talking to, so you need a user interface, a task list, or whatever. You might push that to Slack nowadays, or Microsoft Teams, or whatever it is. Or it might be a simple web interface. So you have to integrate the human in a way, but you also have to talk to a lot of technologies. Like, for example, messaging or it might be a soap or rest, web service.

It might be something really proprietary especially if you talk to mainframes or whatever. So you have all these kind of different technologies you want to integrate here.

Which is very often the big problem I need to do, end to end processes, especially in legacy environments.

I talk about solutions as well. Second, I just wanted to open up that thing.

If you look at, an ask, for example. Come on now, if you, if you, if you know the product a little bit.

one thing, we, kind of our use P, for quite a long time now, is that we allow to plug in any end point. Because we're basically saying, OK, when whenever you have this orchestration, this model, what it can do is you can define it. Or you can write a little bit of programming code in order to clue that. two different end points.

And I'm not sure how much off developers we have in the audience. I still like that slide in a way, because it, it shows how easy it can be, that's a bit of Java code, where, for example, you can open up a rest endpoint. Whenever that is, called, Use the API to the workflow engine in order to create a new process, a customer, onboarding process instance, handover, some data and that's it.

OK, It can be that easy.

Same thing if you want to call out to a CRM system, and you might provide a little bit of code in order to do that, and I'm coming back to that in a second. So there are also connectors who could use out of the box, but the, the beauty of this is that you're not constrained.

So, if you have your core banking system in whatever beard, technology it was written, whatever, 30 years ago, you can integrate that. It cannot be at that end, because there's always a solution to connect.

And that's actually very, very powerful.

And especially if you look at core business processes of an organization like bank account opening.

It's, it's, it's, it's a core process. If the people who are not opening a bank account anymore, the bank will have a problem relatively soon.

So, this is really core, it might happen that a big frequency, especially for global bank, I was surprised comfortably bank accounts they on a daily basis. So, that was a 4 or 5 digit number.

So it's, it's, it's happening very frequently, so it has to work properly.

Yeah, OK. I always like to show a little bit. At least I will be very quick, because we don't have much time here, but we'll just have to find it.

There it is.

So, what I have here is the demo as an example, which, which is also on GitHub. So it's available. You can play around with that yourself.

So I basically modeled a small onboarding process, where I received the custom order, then score it, then it's manually approved, and depending on the outcomes, are they accepted or not Right, and this is ..., that's what I, what I said early on, the ISO standard, to define this process models in the background.

I'm not going into all the technical details. It's simply XML.

Nothing magically here. And we could, we could adjust that. So, I have that process already running, but just to give you an idea, you could now model more powerful things. Like saying, OK, that takes too long, for example, the approval.

I want, no, I don't and the process, that's mean. I wanted to do something else.

I could do, for example, something like to do, What do we do?

It's too early to be super creative. I escalate something and then I'm done.

But I could do that, for example, imperium, that's maybe something interesting. And then get rid of that over here.

And then I can define, say, this, just add every, like in a cycle, every 2 or 3 times, with the delay of period of time, NaN. So we should be able to see something. So I adjusted the process. What I can do, now, this process, it's, it's executed by workflow engine. So I can deploy it, for example.

I using the Kubernetes sauce here.

So it's a SaaS environment, which, um, you can also sign up for an account. And then you have a cluster running in our thoughts environment with a workflow engine, for example. So there are cluster these credentials and so on so forth, though, I can deploy to this. Let's do that for a second. And then, I can see that in the there are different tools.

For example, in the operation tool, I could see that I have processes deployed, for example, to them.

What is here? Second, right. So, for example, I had my onboarding in version one. I did a test drive early on before before that talk, and I have now that second version of process. I have just deployed, and then I have my little application here.

And be mindful of the time here. And there you see the code, which I showed you early on, but that's not the point. I want to want to hint at. I also have a small web application here, because every good demo starts with that great application, And that's my super simple web application, and I love to do that, Because, then, if you're interested, you can basically dive into how that's done in the background.

And you will see that it's a simple, super simple rest call, the super simple rest call, It, basically pointing to a bit of Java code, which kicks off the process instance. And you can dive into that, that, it's really easy to do, but you would get a very powerful technical solution.

So I can submit and you order that Burt and I will see that an operator go back and refresh, wants to quick, probably, right. I see my new process instance now waiting for approval, if I want to want to do that, I could go to our user front end. And if I write if I wait a little bit, it already got escalated twice because it's already NaN.

So, there comes the third one, Um, yeah, and I can approve it. and decide if it's automatically processed or not. And that's probably not too surprising here, and then I will see that my, my process instance actually will move on.

So, let's quickly look at that, right?

So, if I go into the process instance, I see where I went, I still have these three escalation tasks, procurement, whatever, goes into the details of the amendment. But you can see that it's very easy to change the process, Very easy to see what's going on. You get a lot of like audit data here. For example. How long it took?

You can make use of that audit data.

For example, if you want to do heat maps so you could do a new dashboard for our small process.

Right, like in default dashboard for example, that shows too typical data around what's happening in my process.

OK.

so it Craig, you can see heat map where it takes long, not a surprise when the human is at work and a lot of fun.

So just wanted to give you a quick idea of what I mean by executable executable process models.

So, and, yeah, you can check it out yourself if you'd like. Thing is, if you're more technical, what you've just seen, as I have one spring boot in this case, one Java application containing the process model, the BPM, and file as an XML file. A connection, basically a client library towards our common a sauce.

And a bit of Java custom code to connect to my restaurant.

What we also have in the architecture, or in the platform, you can use connectors.

So you could go in the modeler.

And I'm, I'm coming back to why this is interesting in a second, so he could also, um, have a new task for, you, basically, go for.

Service task.

What is my problem here?

Millimeter hm.

Hang on.

Anyhow, you can select the, it's normally in the pellet. I was wondering why it's not in my appellate here but I'm going to have configured my my model or wrongly. So, you can basically go to the pellet and say, OK, I want to make this the rest connector.

so you don't have to write code for any any any piece of rest invocation for example. So there are certain out of the box connectors, which you have. So it's basically a choice if you want to use an out of the box connector or if you want to write custom code.

And we even have a lot of customers doing kind of the hybrid in the middle because they have there Core Banking system, for example, which they have to connect to all the time. But it's, It's very bespoke for that situation.

So, what they do is, they build their own in-house, re-usable connector, so it can they can then re-use it across the firm, right. It's not provided by us, or the community, it's their own code, but they re-use it internally all the time.

OK, and that's pretty flexible, actually.

Cool, and that brings me to one of the very interesting questions here, which is around low code, so I Constantly started with showing your Java code actually, so that's very, what we call Pro called, the pro quota approach. So, it's basically Software Engineer.

And if you're a bit into Software Engineer, and you saw T tests, like it's a unit test, automated unit tests, it's a, it's a Maven project, so you can, like, using the normal CI CD, continuous delivery pipeline you're using, and so on and so forth.

So it's pretty using all the best practices from software engineers. But it's software engineering.

If you don't have a software engineer, might not be for you there.

At the same time, we have these connectors, so we're also moving a little bit into that low code space.

And the way we're seeing that S, one of my colleagues once said, we need, we need to show or not, which is an app. It's something you can dial in, or dial out, and in order to make that visual.

And that's actually what marketing did out of that. But I like the slide, it's kinda come on the radio.

It's kind of, you can tune in, or dial in low code as much as you need.

That's basically our vision. We're coming from the Pro code and very can write anything in code, whatever you like.

At the same time, there are low code capabilities, and you can use them if they make sense for you. It's far from our perspective. It's an accelerator for the project.

So it's probably I'm fast to re-use a connector for typical integrations like rest or ATP, or Sendgrid or whatever it is for use Slack teams.

Than writing that from scratch, all the time, at the same time, there might be a lot of situations where pro quotas, superior, faster, quicker, more stable, or whatever. And you can, you can select that yourself.

And, the way I'm thinking about that, is like, OK, there's so many different types of process automation products out there.

And they differ really in complexity.

So, if I look at bank account opening, or order fulfillment, or auto provisioning, or there are a lot of these examples, which are really core business processes, which are super critical for the organization.

And in this area, typically you want to do a full IT product because you want to have all these advantages of the best practices or continuous delivery fee. Quake be fast, have a high quality app, automated test cases, and so on, and so forth. There are a lot of good reasons why you want to want to do that.

For these core processes. So, I think that's not a not a question.

At the same time, there are other types of processes.

So, at the let us say the other end of the spectrum, you might have very simple automation.

It's very simple integrations for probably an individual does some things, so, probably silly example. But, I do my own call for paper handling with a mixture of air table and savior.

It works pretty well for me. I set it up for myself, but that's a very simple product.

It doesn't have a high degree of governance or quality assurance or whatever, but I don't care, right. It works. And we see a lot of these automation as well and they have their space in the organization.

And on the extremes of the spectrum, it's relatively simple. So, so come on, I would definitely be here. And something like what I just said, ..., couple of others, are definitely here. But the interesting part is also in the middle, which we see it's not a binary thing. It's not too complex or super simple. We see a lot of projects in the middle where they might not be that core, They might be a little bit smaller than might be not that critical.

But at the same time, they have these requirements that make them a little bit more complex. But a full IT product can off, not be either justified or not staffed.

I think that's one of the big problems nowadays.

You don't find that many software engineers as you would like to.

And that's why you also see a variety of different different people and skills now, like, it might start with the business person doing something themselves. Are these, what carbon called the citizen developer or power users. At the same time, I'm from the other end. We are coming from the developers, like principal, a senior developers. But we also have other roles.

Like, Career Change are, for example, they are, they can program to some extent, but they are not a pro within that. And you also want to enable these roles in order to do proper automations. And we also see these, what we call low code developers. Or for example, if you look at RPA, we see a lot of organizations they have specific bot developers. They do RPA.

Bots, OK, there.

They have, understanding of IT, but they couldn't code.

So it's, it's somewhere in the middle.

And I find it interesting, first of all, to acknowledge that it's not a binary thing, it's a local pro code, and they sit there, and you have to find its summer. It's, it's kind of a continuum.

And now, it's interesting, if you want to, for example, select a solution for you, it's interesting to understand the vendor where they're coming from and what's their focus. So, again, making an example, from from our perspective, where that's where we come from, where our customers to Java process execution.

So Pro code, It's IT solutions, but we're also, are a microservice or orchestration. That's what we're doing a lot with a lot of organization. And we also do bot orchestration, recently, Alonso, with telecom, for example, where we're orchestrating a huge army of bots.

So they're already getting less pro quote um, and we're also seeing Goldman Sachs is a good example there, they rolled out coming across the whole firm, and doing basically providing to their end users, kind of a local industry experience. So they're, they're adding a low code layer, on top of CommonLit themselves. So that's somewhere probably here.

So there are these use cases where it gets a bit more low Cody, which are interesting to tech.

Right? And the local tools, if you look at the local tools, they're basically trying the same thing from the other way around there.

Super easy clickable. But then they have this script field where it can enter code and basically go beyond what they have in their their walled garden there.

And depending on where you are here on that spectrum, the one or the other might make much worse.

OK, I hope that makes sense. And I'm coming back to the, to the bank account opening.

So, we automated that with, with, with that process, for example, but we're not yet.

Speed it up, right.

Not sure if you recognize that, but even if you automate that, it doesn't get foster, we're still having, and that might be the problem here and approval.

That's probably not done within minutes, especially if it's in the night on the weekend.

We have to adjust that. And the, the great thing is, and that's what we're seeing in a lot of journeys from our customer, it's actually that.

as soon as you have that orchestration, that process model and you have that understanding, you can now swap out certain things, so you can say aye.

I replaced that manual approval with, for example, an automatic approval.

And that might be AI trend. But it also might be a simple decision table for exemplary.

We're just getting a score and a couple of other elements in order to decide if that's automatic automatic approval, or if probably some humans still have to look at it.

But now you get this much less frequently.

So that actually frees up your people to do other things, loss to scale the process, but it also makes it faster in mosques.

And the important thing is to have that model in front of you to understand the process in order to make that OK. Cool.

So we improve the customer onboarding.

We used to be per men. I said that a couple of times. And analysis of that.

So that's what I believe pass orchestration can fix the problems with process automation. So we're talking about process automation all the time, which makes sense. For me, there are two things. The task automation part and the process orchestration part.

Both are important, and depending on what you, yeah, what the current goals are, the one might be more important than the other.

But both are kind of equally important, and it's important to distinguish them to understand. There are two different things, and now with process orchestration coming back to that, there are basically two main challenges.

And I found that important also to acknowledge end point diversity.

I talked about that, And the process complexity, I go, I go into both, so don't worry, I input diversity, is something we already tackled. So we might have these all these different things, like different IT systems, different technologies, people, whatever.

Now, one important or interesting thought, here, it says, well, so we see a lot of tools, or two categories that focus on integrating multiple endpoints of the same type of the same kind. So if you're only orchestrate bots, for example, that's a different thing. Or if you're only orchestrated micro services, that might also be a bit different, or only APIs like endpoints, and so on and so forth.

So there are two categories which focus on on those categories.

Are, for example, looking at as really having these diverse diversity, or we call it different endpoints. So we have humans, we have APIs. We have bots, we have this, and that, and so on and so forth. And this is a big challenge, also, like technology by scripts. We talked about that.

Yeah, the customer onboarding we already have, And I just want, I want to, quickly mention, are coming back to the Process Complexity aspect of it, because I find that very interesting, as well.

And that's what, a lot of tools they are, not ...

based, sometimes kinda forget, So in real life, most of the end to end processes are relatively complex by nature. So you have all these situations where somebody cancel something, where this goes wrong, where I have to go there, and whatever. It's not a straight line, that's what I'm trying to say.

And in order to automate that orchestration, to co-ordinate that properly, you need the power to express.

These are the situations in your model.

Let's make a quick example. Like order, processing, order fulfillment, your art, or something. And then it gets shipped to you.

So you might order something which has like many positions there. You already like 20 things. And it's a it's a store that wants to process your order, but they have multiple warehouses actually, to pick that in parallel. Which is not uncommon.

Actually, we are having a couple of big global retailers. They do that all the time, like picking in different warehouses, sometimes, shipping in parallel, sometimes getting that to the same warehouse in order to ship.

But as a customer, I can still cancel, for example, or do I do that? Or if you don't cancel, I might need to pay the invoice date on. I wouldn't want to have a reminder, and so on and so forth. So it can do a lot of these things.

Um, you can express in process model. And you need certain constructs, constructs, we call that advanced workflow patterns to make that happen.

So, for example, I do that in parallel, but dynamically, depending on the number of order positions or, I need to correlate a cancelation message to the right way, to process instance, or running Process Instance. Or, I have to look at time, and so on and so forth.

So, that's, by the way, why I'm such a big fan of the payment, So they hold determined language, allows to express these problems in proper constructs, like wherever I am, whenever I get a cancelation, I do something else, for example, I do that, for every order item, I wait for time happening, or a message coming in. So there are a lot of these, kind of exams, but it can express them ..., Which is very powerful. Because if you don't have that, you, you work around that, or you code around that. Or you do very ugly, like, modeling things in order to get, to express these problems. You have them. And that's what I was super happy with, for example, in ..., coming up with a report, where they, where they also said that simplicity, simplistic process I'll take, simply won't cut it, real-world business process patents are rife with the exception that require sophisticated or ending compensation. And that's the important thing. You have that in real life.

So you need to express that.

And if the language or the tool cannot, you have to do workarounds, which are expensive and slow on for them.

OK, Cool, So, summary, these are the challenges you have to solve for process orchestration and just also kind of a summary.

You have these different tools, I'm opening that up all at once, so you have different categories at the moment which makes the market complex to select something property. So, RPA, for example taskforce which microservices orchestration very much focused only on on microservices I pass only and pundit integration, for example.

And I tried to get across, was process orchestration brings to the table. So, the whole co-ordination part of the different things, very complex flow, logic and diverse endpoints.

Yeah, and also, I hope you get a better idea of how that also like differentiates from the other categories.

We skip that for the moment, and that as well.

So if you want to get started, you can simply sign up and try it out. So we have a couple of get started guides, you can get a precise account immediately.

There are a couple of ways actually, to do that, So that's always my recommendation people, very often very frequently, asked me, OK, that sounds interesting, How can I, how can I check it data for me?

To a small, quick proof of concept, either yourself, or probably together with a, with a consultant, with us, where you automate, where it all comes straight, as small process, for example, in your environment where you get a good idea?

What it does?

And that's normally doable within, depending on what you do, hours or days. So it's not a matter of weeks or months.

Thank you very much.

Let's see if Brian is still there is. I am still though I've been fascinated but thank you so much for a wonderful presentation. Really enjoyed that, and we have some questions that goes through, which I'm really pleased to see. The rest of the audience, if you're out there and you're a bit shy about asking questions, please remember nobody can see you. or hear you, please just submit your question. You've got a great opportunity to interact with one of the world's leading subject matter experts in this space, so if you have any of those questions, continue to get them in. So let's start by driving straight into this.

I think one of the things, which is always top of mind for the people that sort of look at these, I want to get involved in, it is where all the real-world examples, where people are doing process orchestration. Well, what are they doing? Exactly. Why, in your opinion, are they doing something really well that everybody should be paying attention to.

So there, I mean, there, there, there are different types of automation. So that's probably the first thing. We can go back to this line.

This one slide inputs, I think shows that relatively well.

So there are these different types of automations and what I'm looking at. So that's what I can speak to most is actually that, let's say the right hand side of that slide.

And if I, if I look at that, it's, it's very often really caught processes off of organizations.

So bank account opening was one, and we had that, generically, as customer onboarding.

So, whenever a new customer comes on debts, for banks that might be bank account opening, or credit card issuing for up, for an insurance company, it might be issuing a policy for Telco company.

It's actually get a new customer on board and probably send him, send them their sim card, or provision them on the network, or send out a technician for fixed lines, So these kind of avenue customer are very, very typical.

And my.

Yeah. My observation was that it seems to be a big focus on the companies, because it's very early in the customer experience journey.

So you want to have a good experience for the customer when they have that first touchpoint. They want They want to get into your product. So, let's make them a good experience. I'm not saying they are not that good, and they're servicing processes, but it seems to be a focus on onboarding at the moment.

Other good examples are order fulfillment, for example.

So we have ..., for example. They're in sport retailer, worldwide.

They do the whole order fulfillment from your web shop you're ordering, to get your puzzle at home thing, and we do that for ..., as well as a couple of others.

That's a typical thing.

So these are also, I think, easy to, to visualize that in a way.

We have, just to mention that because it's, one of my favorite examples is not a common example. So it's my favorite one. It's the nozzle which they are their mass robot.

Perseverance robot, when it sends down pictures from, from from space, they run processes to basically do all the image processing. Because you do a lot of different kinds of things on the images. They take awhile, so you need to co-ordinate those. They happen in parallel. That's what I'm talking about early on the complex flow in a way. They handle that with a process on earth, not in space. And then they basically calculate what the robot should do next and send out you commands to space for it. So, that's also process.

Which item, as an example.

That's pretty cool. I can understand why it's your favorite person, as a follow up to that. one of the questions has covered a lot of the organizations that you have outlined all, essentially, enterprise level. We're obviously they can apply economies of scale, and all those good things. Do the same benefits occur when you get into the sort of mid market SME, SNB arena? And it's built, what can they expect from them?

It's, I find that a very interesting question.

So we're like, I can bet that.

So most stories I know, are from the enterprise level.

To sum X, I think it's two fold.

The one thing is, in the past, already setting up these systems, and setting up the whole environment was quite complex. So the medium sized are very off not capable of doing that, or don't have the resources. I think that's something the whole sauce and cloud thing can fix and does fixed, to some extent, because it gets so much easier. If you start with the development environment, you don't need and to set up anything, having to get up, You have this, and that you also have, for example, come on, I can consume. And, so, you don't have to operate stuff, it gets much easier. I think that's an enabler for the mid-size companies.

The second challenge, very often, are, are the roles, like, do they have software development in-house, and that, that depends really, I know companies, also smaller ones that do have, and others might not, and that, that sets the constraints of what you can apply, and how much effort you can put into that.

I hate to say that, but I say that, like, 100 times a day, it always depends on, it's really also, depending on your business model, For example, you might be a very small company, but you want to automate You're, you're kind of, whatever the product is you're offering, fully, for example, a lot of the IT startups fall into that bucket.

Of course, they can do that, if I'm more in the, let's say, I'm manufacturing, and it might get much more.

Fantastic! Thank you for that.

But as a follow up to that, and still sticking with this project type and sort of skill levels question, what would you recommend, or what would you say, is the right mix for a company to explore in terms of having in-house skills, in terms of a team? To make sure that they are successful implementation almost immediately? And is there a good example of an organization out there that had that mixed right out of the box?

So I think for the mix of people, it's, again, pretty hard to, to generalize, because it, it depends on the size and the type of products, how many of them, and so on, so forth.

What I, what I've seen working pretty well, and that's across the board for a lot of organizations, is to have at least some kind of I don't like the name too much. But Center of Excellence is typically what people understand, like kind of a very central team that facilitates knowledge, let's say, that way. It doesn't have to provide any technology themselves.

But it's kind of consulting part within the organization. And we see that working really well, because then you can have in house, normally it's 1, 2, probably three people if you're a big organization more, but it doesn't have to be big.

But you have to have good people with a good understanding, also of the different tools, for example.

So what I've seen working best is if the center of excellence is not focus too narrow. So it's not a kimono center of excellence, for example. But it's very often a process automation center of excellence. They're, they're looking at kimono. They're looking at RPA probably they're having legacy, still looking at whatever, peg or whatever?

And they have, also this understanding of, OK, if I see this project over there and that's your team, their existing team, that's what they want to achieve.

Then this solution might work for your best, because it's very off nada.

That's probably what I would have made, OK, fine, go with CommonLit. It's also, like, what, what type of people do you have there. What's kind of the environment?

What's like different kinds of things. You have to understand in order to select the proper tooling. And that's why, I think it's important to have at least let's say, at least one person who starts to understand that. And can can basically guide you internally as well.

Fantastic. Thank you for taking the time to explain that. But moving on slightly into more of a more technical question, which I'm sure you just love First thing in the morning.

But, hopefully this will give you a little bit of insight, when somebody is saying, well, why, why, Why do they need a, why would they need especially tool for orchestration? When there are lots of RPA tools out there.

They just kinda, I mean, what, what, what's, what's the mix, OK.

The RPA is interesting because it was quite hype over the last years, and we saw a lot of companies adopting that very often in the first product.

You get it, you gain something very quickly. So the return on Invest might be quick for for first project. So they extend their usage across the company.

And, what, what do you can see in those companies is that as soon as you apply that to And that basically boils down to that slide here, to this one.

So, they are good as kind of that task automation part mm, but, as soon as you start to apply that on the the overall orchestration, what happens is that you have bots calling out the bots.

And we've seen that, one prime example, they, they also have a couple of slides about that start to telecom where they, they started to do that, and they called it spaghetti plot integration.

So, basically they, they automated the, the spaghetti they had before, with people communicating with the bots, which, led to a lot of chaos and hard to understand, processes and processes that are not easy to, to adjust.

RPA tools are not good at expressing these complex and process logic. For example, they're not good at keeping stayed at scale and whatever.

There are a lot of like limitations and that's why they added that orchestration layer saying, OK, we need an orchestration layer co-ordinating that box.

And it's kind of the same thing also, if you look at other tools, if you, if you look at them more low code tools there, they're very often missing.

Again, the the expressing the complex grew up.

Or is it the complexity you have in typical processes?

Or they can't integrate all the endpoints?

So there's a couple of just think requirements that the make an own category in a way or this orchestration.

Fantastic. Thank you very much for the explanation, I hope. Everybody listening understands that process. We always have a conductor in an orchestra and there's a very good reasons for that. And, finally, as a, as part of this, because I'm, we're approaching the end of the time, a quick question is, when should you use the low code? When should they prefer professional software development? It's a question that I'm sure you get asked a lot.

And it's often a question that people really don't know where that point is, or what they should we look forward to, to work out what it means for them.

Yeah, it's, it's actually a question I discuss really regularly.

I, once I once wrote that, which I called the Process Automation Map, which, you can find that by Google easily. And I tried to, for example, come up with a typical aspects. You should look at, like, what's the process is, very unique, or standardized, it's very complex, or not, what's the scale you want to reach, What its task, or process automation? and, so on, so forth.

We're trying to revise that a little bit because I'm still it's raging on what's the easiest understanding around the it depends thing, because it really depends on the process model.

And the simplified version is really this. Then, the more complex it is, the more critical is, the more I would go to the Pro Code side, because then it's It's very often also obvious.

Let's take another example, again. They're, they're having a super high standard on quantity on what happens or not. And so, of course, it's software engineering. It's properly tested in rollout. But the same goes for the typical core processes. We're also looking at, for example, payment of trading use cases. And you don't want to stop them in the middle of the night because of weird thing.

The low code part is very often not so critical.

And this doesn't have to be bad. I mean, it also means you probably putting less effort into that, or it can let different people do it. I'm not even sure if it's less effort. Honestly, but that's my opinion.

But it means you can assign different people, different roles on doing it.

And that has its value, and not every process is as critical as that, or as complex as that.

Simply enough, fine. Go with that.

Right? And where it gets blurry is kind of the middle.

And it depends.

But thank you so much for your time and input today. Really appreciate it, a fantastic opening session. And I know that this is early in the morning for you, so this is even better. So, I hope that the audience will make use of the opportunity to connect with you on social media. I'm sure you'll be happy to continue those conversations. And once again, thank you so much for joining us. Contact details are at the bottom of the slide there, If you want to quickly note that. There also be on the on demand. Very interesting. Move forward. But thank you so much, and I look forward to hearing you speak in the series as we move forward.

Thank you, Peter.

Have a great day today around Thank you.

So ladies and gentlemen, that was an insightful and Energizing start to the morning from Bernd .... Come on up. Next, we have Oliver Michael from Siemens and highly recommend that you get back here at the top of the hour to hear all of us speak. I've had the pleasure of hearing, all of us speak, as I mentioned earlier, on, numerous occasions and always come away from your sessions with something new to add to my .... So, take 10 minutes or so to refresh, and get back and look forward to seeing everybody here at the top of the hour, So I can buy.