Episode 2 – Why EA and BPM?

Welcome to episode 2 of the What’s Your Baseline podcast.

In this episode we are talking why architecture (“Why EA & BPM?”) and why these two topics might not be even different, but rather be the two sides of  the same coin.

We are discussing the following topics:

• Terminology
• Four phases of process management
• History of EA as a practice
• How organizations practice these two topics and where the discipline moves towards to
• The merge of Strategy groups, architecture groups, and PMOs
• Capabilities as bridge between strategy and the actual execution
• Risks and benefits of capabilities
• Capability configurations as planning tool
• Case studies of retailer and a military client

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

• The Evolution of Business Process Management: A Bibliometric Analysis
  Henry Lizano-Mora, Pedro R. Palos-Sánchez and Mariano Aguayo-Camacho
  IEEE Access 2017

• The Evolution of Business Process Management as a Professional Discipline
  Sandra Lusk, Staci Paley, and Andrew Spanyi
  BPTrends, June 2005

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

• CP1 (Welcome)
• Wish You Knew Me (Interlude 1)
• Be Loved in Return (Interlude 2)
• Airplane Seatbelt (Interlude 3)
• South Wing (Outro)

---

TRANSCRIPT

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey J-M, how are you doing?

J-M: Hey Roland, I’m doing alright. Living the dream as we say.

Roland: Yeah, as you should, that’s the way life should go. You know, you should not think about bad things but live the dream and enjoy the day to your fullest.

J-M: Ahh, Thanks man.

Roland: Like today when we’re going to talk about why architecture? Why business process management? And I’m really looking forward to our conversation about when we look at where those disciplines come from. When we look at how it’s done today. And then we look at: what are the values of having those disciplines in an organization.

J-M: Yeah.

Roland: Maybe we get started with the first point. I know you were very involved in process management in general. How would you describe process management as a discipline for somebody who hasn’t heard about this?

J-M: Before we necessarily talk about the process management itself, we want to define the terms right, so I feel like we both heard a lot of people use / misuse / be confused by these acronyms, BPM, BPA, BPE. What are those? 

So, let’s start with the ones that are the easy ones. BPA: business process analysis, which is the practice of understanding and analyzing and improving the way in which you do processes. The way in which your organization runs business. BPE is the whole practice and organization around the optimization of it. So it’s creating a scenario in a situation that allows people to work in this. And I know you’ve set up a ton of centers of excellence and in process and engineering at organizations. But BPM: We see people talk about the big BPM and the small bpm and get them confused. Big BPM being business process management. Thinking about automation. BPMS. Like the automation of process steps and the integration thereof. And little BPM, or business process management, or business process modeling, being the documentation thereof and the methodology and the creation of flowcharts and the sharing and understanding in a visual sense of how companies work and what do you think about those things, Roland?

Roland: yeah, I’ve seen that in a similar way, but also with a light twist in between. You know. So when I got started with that whole topic, which was back in the late 90s, it was only called –  BPM business process management with a focus on the M. You know?

How do I manage my business processes? So, the perspective coming from the discipline. When I look forward a couple of years, things changed. People were all eager about automation and all those wonderful things, then the term BPM, even though the words were the same, switched. It became automation.

J-M: Yeah.

Roland: And then terms like BPA were invented, right? To make up the gap in between. To me it always feels a little bit artificial. You know, to me it’s all about, OK, is it the business architecture? What do we do from a business perspective as an organization, what requirements do we have to fulfill to be whatever? Regulatory compliance and all these things. What requirements do we derive from a business perspective on systems implementation? So if today would somebody asked me about this – what BPM is, I would deflect more towards: “Oh yeah, actually it’s business architecture, right?” Because you’re talking about the structures (that’s the architectural part). The structures of how you do your business. And then as a follow up you have the methods and the means of doing this.

Roland: You know having the tools, having the notations and whatnot, you know the bread and butter, the working material that you work with in making these things happen.

J-M: I think that it is important to understand that the terminology is there to serve a purpose. It does communicate something. I mean, when I hear customers talk about BPM versus BPE, I know that they’re thinking about it differently. BPM could be an automation exercise. It could be very much about the code and figuring out how to get those little blocks to work in the order you want so you can run an integrated analysis or whatever, and or integrated system. 

Whereas, when I hear people talk about BPE. I think they might have a VP of process working in their organization. Somebody who is focused on the excellence around or the practice around making it better, and I feel like those organizations are much better set up for success. They’re thinking about things at a level of abstraction beyond just “what does a person do at a single point in time”. They’re thinking about “what does our company do”, what is our value chain. I know that value chain analysis is really important, and I know you’ve done that for a lot of organizations. Where do you think about that? Starting and how do you get that off the ground? Where does that fit into the realm of business process management and excellence?

Roland: Yeah, so obviously that’s somewhat important, but let me take a step back. I think when you mentioned, “Oh yeah, there’s a VP or Lead of Excellence group in there” I think this is a different topic because that shows that this organization has understood that you have to have a certain maturity

Roland: in how to manage your processes and they’ve institutionalized by coming up with groups, by coming up with positions where people do this for a living in the more mature organizations.

Roland:  When you look at the history of process management, and maybe you can give us a two minute overview where it came from. You know, the four different stages of process management, I think when you look at this you will see that we are on a very clear trajectory and value chain analysis is one part of that. But maybe, J-M, maybe you can talk a little bit about the four phases of process management. 

J-M: It’s been a heck of a journey. I don’t want to spend too much time giving you a history lesson, but generally there are. It’s accepted that there are sort of four different phases that process management has gone through. The first. There’s sort of three waves of evolution and sort of the foundations. So process management isn’t a new discipline. In fact, you think about it coming from the industrial age in the 1700s, eighteen hundreds and even early 1900s, we talked about the moving towards automated production, mechanical, mechanized production in assembly lines. And so we wanted to understand the sequence of steps that were required for mechanical tasks to be done and when you’re trying to build assembly lines, we think it’ll take a look at process management done by manufacturing engineering. Although that discipline might not have been quite as well defined at that point in time, it was definitely manufacturing engineers that drove the conversation around that, and it was the first, the first conversation around structured and ordered activity management.

That took a change in the 70s and 80s. We think of it is sort of the first wave or the 1st phase of the updated process management – process improvement. And that’s where the terms like TQM, total quality management came into play. Where the first methodologies of documenting really came out and were popularized and accepted, and some of them are even still still around. Like, you know, the IDEF standard is still available at some organizations, and it’s 40 years old. And that’s when we started to take a look at statistical analysis and being able to calculate the efficiency of process, the cost of process, and be able to improve it. 

And that really took a turn in the 90s when we, in a sort of our second wave of really process reengineering, process analysis, we started to get the Six Sigma / Lean Six Sigma as a practice that was adopted.And our first generally available consumer available, or at least corporate consumer available computerized systems for process management process improvement and in fact, you know, the original creators of the product that I work very heavily on -ARIS- IDS Scheer, that’s when that organization was spun up as a tool for consulting. Can say a computerized tool for drawing a process, but it was still thinking of it as processes, very physical. In some ways physicality was represented almost by computer code, ’cause that was what people are talking about. So what is a computer code and automation? 

That we were doing as a result of this step, and that’s where ERP analysis really became a hot topic. SAP focus, Oracle focus of what would the automated steps in the order that they were happening. So even though it was a level of abstraction away from physicality and mechanized production, it was still thinking as one at a time and what you could see a person doing. Here’s a transaction you have to run. 

And now I think about something that’s really golden age. This sort of third wave of business process. And this is the business process management: an excellent site where we’re looking at process management as a layer of abstraction away from the physicality. We take a look at strategic process management, and Roland, you talk a lot about that when we take a look at process value chains and how this synchronizes with organizations and KPIs, and balanced scorecards, and fishbone diagrams and FMEAs and even using things like FMEA as our tools that would come in from more of a mechanized, more of a mechanical and manufacturing engineering perspective. But also flipping it on its head and taking a look, customer journey management and customer perspectives on process. 

That layer of abstraction, I think, really empowers the new business process management to have a better, more comprehensive view of all the impacted parties and where the value can be extracted. And that’s only since the mid 2000s we’ve really had a chance to do that with these modern tools, built on collaboration, built on repository, and ultimately built for end consumers for people at the desktop level / at the cloud level to be able to access and interface with these processes as you go. Both from a design and a consumption perspective.

Roland: Yeah, they also notice this when you think about the technology side of things, which is interesting because as things become smaller, they become bigger at the same time, right?

Roland:  So when I think about API management and all those wonderful things where the whole technical architecture becomes way more smaller nuggets that have to be managed. You know, which then puts a real burden on the people managing these things because they have just a boatload of those, right? So it’s a weird conundrum that we see here. 

J-M: It’s not the way it works. The more you have access to, the more you have to manage, because now you have access to it and that’s where business process excellence and establishing those sort of centers of excellence and the common taxonomy and a common approach to how to manage and improve your processes, chunks that down into bite sized pieces you have. 

You have the division of labor that goes into managing this stuff, and I think in a subsequent episode we’re going to talk more about centers of excellence and how they get stood up in and what people do in them. But just to know, that the more you’re thinking of that as a regimented process management methodology, the more you’re going to be able to control that ballooning of information. The ballooning of responsibilities and the impacts to the organization – the wide reaching. 

But talking about impacts to organizations and how people do things you know, talk about enterprise architecture to me as a practice and what you’ve seen it evolve is because it is definitely a partner to this. And in fact I think we’re going to talk about it a little bit later. It may even be the same thing.

Roland: Yeah, so when you look at what people traditionally call as EA and you might hear with my hesitancy that I’m not really a big fan of that categorization. But that’s a different story that we will talk about in a minute. That discipline is obviously not that old, right? So it’s like 30 years old. Think about Zachman coming up with his first framework, and I’ve seen him in one conference. You know everybody had super ugly PowerPoint slides. He had an old-fashioned slide projector that he put on the stage, you know, and it was giving a lecture like he does in college, you know? Yeah, that’s somewhere in the 80s and the funny thing is it started on the technology side. You know, when the digitization and the whole computer movement came up, people had a need to structure and organize that content, right? And it was literally the physical hardware that they were trying to manage. 

And then in a second wave it moved on to applications because that was then the soft stuff that runs on the hard stuff you know and they need to manage this. And as we all know, it goes in different waves, you know, at the beginning, an organization is super lean, and then they grow and acquire others, and at the end of the day you have a whole mess of applications going on.

And what I see now is more a third iteration of this and some organizations try very hard to bring that thought in. When you think about the Open Group, for example with the TOGAF framework to say no, it’s one thing you know. You need to bring in business architecture and it’s not only that – IT exists because of IT reasons, which I’m pretty sure, all IT folks can be very happy and busy with themselves. But IT has a business reason for existing and it must be driven by business. 

So from that perspective what I see is, when I come back to the tool landscape that you mentioned a little bit earlier before, you know, when things became less paper-based and more computer-based, [there] were different vendors that do things differently, right? And we will talk about in another episode how to select your right architecture tool, but you can see vendors where you still see that split and they sing the song of BPA versus EA, while other vendors have a more holistic approach where they say “Yep, our tool covers different use cases. One use case might be to manage applications but another use case might be to manage processes, but it’s all the same”. And I think that is the right approach going forward. 

You know, and even though I mentioned TOGAF before and I’ve worked, when I was with KPMG [for] 6 years, [being] the global representative of the firm in the architecture forum, which is the standards body.

J-M: Oh alright, that’s exciting. 

Roland: No, it sounds more interesting than it is. I was the person who for 20K a year was allowed to press the button when voting came up.

J-M: Oh wow.

Roland: But anyways, so when you look at it, you can see in their stand out there, they’re still struggling with their IT legacy, you know. So they say “yeah, we want to have business architecture in there.” But in all reality I think they still don’t know how to do this and how to put this in the standard. So that’s room for improvement, which is good.

J-M: Well, on that note, we’re going to take a brief break, and when we come back, we’re going to talk a little bit more about how to put this into practice. 

In the meantime, we’d like each of you to think about something important here. We’ve talked a little bit about business process and we talked a little bit about enterprise architecture. I want you to start thinking about some of the initiatives you’ve got in your organization and write them down. Put it on a piece of paper with two columns. One is “ do you think this fits more into business process”? Or the other column? Do you think this fits more into enterprise architecture? And then in a few seconds will tell you why you’re probably right, and you’re also probably wrong.

Roland: Glad that we’re all back and I hope you did the exercise in your mind. Hopefully you didn’t do this while driving in your car when listening to this podcast. That would be bad and we don’t appreciate this. Yeah, I hope you’re back and we will see how things come together. Is it really two different things? BPM and EA, or is it the same thing? You know? So J-M, what are your thoughts on that?

J-M: Well, let’s talk about what I see. A lot of organizations start when they talk about business process improvement. Where do they start from? ’cause as you might imagine, in my role as a transformation lead, I often deal with people who are doing transformation and that spans a lot of different things. But the group that comes to talk to me is either one coming from the perspective of BPA or coming from the perspective of EA, and they’re really hard and fast. And what they think [of] themselves as. And so when they think about engaging in process improvement, here’s where they start the conversation. 

They say we want to capture our business processes. What does that mean for us? That means we need to understand what people are doing. We need to understand what order they do it in, and we need to understand why they do it. So what are they trying to create for the organization? Either that’s capabilities we talk about directly, directly into products and services that this particular thing creates. We talk about stakeholders. Is this an internal facing process or are we actually interfacing with customers and they’re literally trying to write that down on the page. And you know, this practice of BPA often looks like a whiteboarding session, or people putting big stickies on the wall and trying to create these processes. Either individual process models, or like an end to end flow. We understand the crossover and handoff between different parts of the business.

And so in doing that, they’re essentially setting themselves up as hard and fast. What I care about is the process, the flow of activities? What they essentially want to do is analyze and identify where they can focus on how, where to improve. But first they want to get a handle on what they’ve got today. You always say if you got a GPS you can never use a GPS, unless you know where you are right now. Because you need both the destination and you need an origin and the as-is discovery and facilitated sessions is going to give you that origin point and your business drivers and strategic value of this analysis is going to give you that destination point. And how you get there is what they think of as their business process excellence practice. The management and improvement of those processes and they’re going to create a set of documents and requirements that come out of this exercise so that they can communicate that with these nebulous other groups of people who are going to make it happen.

And Roland, I don’t know, how successful do you think? Do you guess those people are in their efforts?

Roland: It’s fun because it’s not only that one group, but obviously the same thing exists on the other side, right? So when you look at IT, people there … I always joke, yeah, people go into IT because they don’t want to deal with people, they rather deal with computers, right? So they’re happy in their little ecosystem, right? And doing their little thing and I found it really interesting when you see IT departments have business analysts, you know, because it seems that the geeks can’t talk to regular folks and they need somebody to translate it – instead of just talking with them directly.

So I think there’s a lot of trenches that had been built over the last whatever 20-30 years in there, obviously driven by who has more money. And I think the pendulum just swings, you know and and for a couple of years it just swung to the business side. You know where you then see things like “Oh I have that tool available and I just need a credit card. So I just buy it for my department.” And then IT is freaking out because you have shadow IT and whatnot, you know? 

I think it’s a communication problem that is there. What makes me happy is to see that on a discipline and on a thinking level, people move into the direction to say, yeah it’s all the same. It’s two sides of the very same coin, right? So that when you look for example, and I don’t want to quote it to death, but when you look for example at the architecture development method in TOGAF, the big yellow wagon wheel that you see prominently in all TOGAF slides, well guess what, they come up with different phases of that method and one of them is to do architectural descriptions and they say “Yep, you need to think about your strategy or vision as they call it. You need to talk about your business architecture. That includes processes and organizations and risks and all that type of stuff. And then you need to derive or talk about applications and data. And then at the end you talk about technology. You know that the cables and boxes or puffy clouds.” How you make things happen, right? 

So I think this is a good thing, right? That people start talking to each other and I wish I could see the architecture discipline move towards that direction. And I chose my words wisely so I don’t see, hopefully in the future there is no split between BPM and EA. I think it’s all about architecture. Architectures as building of structures. As designing and defining how a future state moves on, right? 

And I have seen that, to bring that in, in a previous life, where there is a need that you bring together in an organization, the strategy group, right? The people who figure out what to do and you bring in together the architecture group. The people who figure out “how do we do this on all those different levels”. You know? Strategy, business, technology, and so on. And you bring in the PMO, the people who actually should do the work right. So in a perfect world you had a one stop shop organization who does this.

J-M: That’s a really good goal for the people who do it. What do you think about using a bridge of capabilities? ’cause I hear that word thrown around a lot? I feel like business capabilities, IT capabilities, like they’re all really just organizational capabilities. Do you think about using that as the bridge to help translate the way in which each team actually operates into a collective harmonized organizational operating model?

Roland: I like that concept a lot because at the end of the day, what you see is you in some form of fashion need to manifest your strategy, right? That could be strategy diagrams that could be objective trees, KPI trees, whatever. Whatever you choose as a visualization, as a means, right? But then the question ultimately comes up when as part of the strategy you say, “hey, what do I want to say to my customers, right?”

Because that’s the most important thing there. The question is “Oh well, what do I have to do so one is the demand side, the other one is the supply side. What do I have to do to be able to deliver what I want to sell? And for that you typically see capabilities as the thing – even though it’s an abstraction.

J-M: It is, but it’s a helpful dovetailing right? It’s between what people do.

Roland: When you look at what a capability is comprised of, you see all the usual suspects. You see your customer journeys, you know what is the path that my customer goes through. You see the internal processes. What do we have to do to deliver this thing?

You see the applications, you see the data, you see locations, you see organization, all those different things, skills, whatever comes in. That defines the capability. And in a nutshell, the capability is attached to the strategy.

So if you would come to me, as the capability architect or the person sitting on a big pot of gold, and you would ask me. “Hey Roland, can I get the amount of X for my project?” I would ask you three simple questions.

J-M: What would you ask me?

Roland: Which capability do you create? Which capability do you update? And which capability do you decommission? And if the answer is “none of it”, well, then my answer would be: “Sorry J-M, you don’t get a single dime, you know, because it’s not aligned to the strategy.”

So by having that capability architecture or that construct of capability as a bridge between your strategy and the actual execution, I think that’s a good way to align things. And based on that, you then see the, quote unquote, old disciplines of BPM and EA and whatnot fall in line because they play a role in making the capability happen.

J-M: That makes a lot of sense, and bringing those two together unites these divided sets of the House. I mean, I feel like setting these barriers in place only makes your organization weaker. It makes it [you] have to have these handoffs. These conceptual barriers. 

They talk about this in the field of medicine a lot. This continuity of care for a patient. Well, in organizational transformational initiative that continuity of care gets lost if you’re passing it back and forth, back and forth between all these people handing off. But if you bring people together as you’ve been talking about through that lens, and as a collective team, then you’ve got that continuity from all the players being able to collaborate. Being able to improve, and ultimately be able to make good decisions on it.

And hopefully everyone out there in the audience is thinking about the capabilities in their organization. So now you’ve got. If you did the previous exercise and maybe you weren’t writing it down as you were driving and you thought about splitting these into different houses, well, now let’s take a look at those as collective things. Now let’s take a look at what parts of these, each of these elements you’ve written down, or you thought about is handled by these different teams. And what if you brought them together? Let’s say they were the same thing. What aspects of these capabilities would need to be addressed or influenced by the opinions and expertise of those, quote unquote, sides of the house? And what if you could bring them together in a single room and have this conversation? 

So look at those topics again and think about the composition of them, what makes them up, and how were you going to address some of the workload or thought leadership that will make them successful. We leave you for a couple of minutes as you think about that and then come back with our thoughts and conclusions.

J-M: And we’re back. Thanks so much folks who are getting that thought exercise done. Hopefully you’ve seen how really those capabilities are made up of some combination of different teams’ inputs and needs, and also thinking of everyone internally and externally as a customer, you’re helping to guide along their journey and give them what they need to be able to do their business better. 

But Roland, what does this all come down to? What does this mean for organizations and why do you want to engage in it? What risks or benefits are we seeing from putting these disciplines together and really getting a comprehensive view of capabilities for an organization?

Roland: Yeah, I think that the biggest chance that I see today is it’s the whole topic around capabilities is relatively new, right? I know that a lot of IT folks try to do this when they try to find redundancies in systems and whatnot, but that was more like IT functionality when they spoke about capabilities and less about business capabilities. And I’ve seen a lot of business people who don’t get their arms around capabilities or business capabilities in general. So I think the biggest risk that I see is that good idea of having business capabilities. Driving things and using business capabilities and then business capability configurations underneath. So think about gold, silver, bronze implementation – using them for project planning. 

Because you work for different organizational groups that have different needs. So for example, I worked on an internal project where we tried to reinvent one of our organizations’ offerings and in the US we had like three and a half thousand practitioners in that offering field while in the Netherlands we had 35 or 50. Obviously the needs for a capability configuration in the Netherlands was different than the need for the group in the United States, right? 

So I think that the danger is if you don’t implement it in the 1st place and the second thing you find agreement on what the business capabilities are. And then use the capability configurations as a planning thing that you’re going to miss out, right? So that on the flip side, you would still have those disciplines that we know for 30 years now. You know you have the business folks doing stuff and you have the folks doing stuff and they don’t talk to each other. And then there’s a bunch of consultants who make a living off making business and ITtalk to each other, which obviously works and is a business model. I don’t want to belittle this, you know. So you can make money from it, but I think you don’t do yourself a dis-favor as an organization if you do not implement the capability approach.

J-M: Yeah, and I feel like there’s a lot of risk of translation error as well. You know how many times have you seen a requirements document that comes out of  IT or business center, sort of thrown or over the wall and the other side reads and goes “I don’t know. I guess I’m going to try my best”. And then what gets designed does not get implemented. And what gets implemented does not get executed. And so there’s that whole myth of requirements translation. And there’s a whole mess of learning and development translation that just doesn’t end up in people executing the processes. The way you’ve designed it and creating the capabilities you strategize.

Roland: I agree. And you answered your own question so I just can chime in on top of it. I agree with that. You know I’ve seen business groups struggle with coming up with requirements because they just haven’t worked in system implementations. So whenever it came up from non-functional requirements they were completely lost. You know, because they might have heard like “Oh yeah, we need to have a 99.6% uptime” and whatnot, but actually they didn’t know what they were talking about. While on the other side, on the functional [they say] “Oh yeah, let’s have a look what the tools do. You know if I want to implement a new risk system or CRM system or whatnot, let’s do some window shopping.” What they didn’t do, and where they missed the boat, was obviously the alignment to the strategy,

Because they thought, “oh, I can’t pick this from this tool and this from this tool and this from this tool”, which obviously then at the end of the day gives a Frankenstein application that was built and nobody loves and – obviously you don’t call your baby ugly – but that’s basically what happens, right?

I think the biggest challenge what you see now is, especially when people are getting older, and I talk out of experience, when people are getting older at some point in time, that’s the end of their career there, right? So people and knowledge walk out of the door.

J-M: They do, all the time. Oh my goodness.

Roland: And we see that in government a lot right now, which is obviously an issue. So it’s definitely a good idea to have things being brought to virtual paper, to have this in a database. And we’ll talk about the tools in the next episode. To bring it into a repository where you then can have a look at it and your organization still retains that knowledge.

Same thing is when we think about having something like an enterprise baseline, you know where you have your “What runs” being defined and documented. That obviously accelerates the next project because they don’t have to start greenfield and try to find the right people and bring them in a room and let him sit through workshops and whatnot. You know, that’s one thing that helps or you look at. Like I said before, you work on the wrong initiatives, right? Because something is somebody’s baby, you know, and they definitely want to have this thing being implemented. Or a ton of different things, you know, people are confused. They don’t know why this happens before the other one right there for their check out, and they disengage because they don’t understand what’s expected from them. 

And these are all things that I see when organizations don’t have a clear picture of the path going forward. Right, they don’t know what they need to put in place to deliver the promise that they developed to their customers. And then a lot of things come back and say “yeah, ITis crappy” or “whatever that other group didn’t deliver”, you know, and they’re looking for excuses.

And that is, I think, which you can avoid if you have that clear picture to say ”Yep, this is where we’re going. This is what the value is. The product and service that we deliver to our customers. These are the capabilities that we need to stand up internally to be able to deliver towards that promise.”

J-M: This is the processing capability capital of your organization that you’re developing. You want to maintain it otherwise, otherwise it’s going to walk out the door. You’re not going to be able to extract the value you want from it.

And I have a brief story about this meaning. Obviously, Roland, you and I’ve worked in a bunch of different contexts, but I work with a pretty major retailer and you know, when I first approached the organization when they first approached me, it was all about IT driven. They came into the group that says, everyone screaming about what they want, what they want. We can never support all these things. We’ve got a billion different technologies. Architectural Review Board is overwhelmed ’cause there’s a ton of people who want to just “credit card purchase” all this stuff, and we want to get a handle on it.

So the way that they approach it – they said we just need the IT team to get a better set of requirements from the business. So to do that, we want to understand the business processes so we can better satisfy them. Well, it’s not a terrible thing, it’s obviously one side centric. It’s the IT people saying we were just going to satisfy business processes by building a bunch of application capabilities. But what it actually ended up happening is that they ended up reaching out to all these different lines of business who had totally wildly different ways of conceptualizing business processes, documenting business processes, understanding what even happened next and how it was done in their in their process modeling, or even in their operations And what they found is that not only were there requirements incredibly similar, but they were also failing in very similar ways. 

Perfect example is they had a perishable food process where they were transporting perishable goods to particular stores and they were finding that these goods were oftentimes not being properly tracked along the way and arriving perished as a result of the supply chain not being aligned with the IT systems that were tracking time being aligned with the business processes, that had requirements on it from government organizations on the tracking of perishable foods. And so they end up saying, well, listen, actually, a lot of you are doing the same thing. Why don’t we establish a standard business process group? To actually go into other lines of business to take these lessons learned and pass on that to those people and become business partner for this line of business, that comes from a centralized group of people who have knowledge and understanding of their modeling methodologies and expertise and helping to translate into capabilities in helping to disseminate that information across the organization. 

And what did happen is they ended up getting a tight but powerful team of business partners that interacted with different lines of business and their needs, that interacted with the application. architects that were building the systems that were automating their processes, but ultimately acted as this translation. This connective tissue and it took a couple of years to establish and get this practice moving across the whole organization. But by the time we really had this stood up and we had this working with everyone, they were starting to do data driven analysis and cross analysis between different lines of business and between different stakeholders. And so they could say, well, this particular part / this other line of business it’s handing it off is causing our system to have struggles, our process not to meet our KPIs. And they were able to see everything put together through that lens of collective capability. Through this lens of end to end view including all of their different stakeholders and partners and that led to faster application development, it led to better automation and more targeted automation. It led to fewer projects being failing as a result of not having the information they needed or the context behind why they were doing what they were doing and ultimately the organization was able to greatly improve their operational efficiency and bottom line, which was really good to watch this sort of evolution.

But that came from an understanding of what was important, which is the capabilities and understanding of The Who was playing the stakeholders and their particular needs, and they had a centralized system for collecting information to retain that knowledge, analyze that, and ultimately disseminate it to all their stakeholders. And that success was a huge success. For them and watching that happen, really, it gives you a warm and fuzzy feeling to see people’s lives get better as a result of regimented practice.

Roland: I like that. Even though one could make the case, this is – even though it’s good. I really love this story right, but that could also just be an intermediate step, right? So, one project and that was unfortunately the only project that I worked on, which was large scale on this was way back when I was working with the German armed forces of all organizations. You know the military. 

And they went a step further. They even had their own employees doing all the design work. You know, you see typically in organizations: “Oh yeah, I don’t want to do this. I just hire a consultant because I have money for it”. And then you have some poor kid getting thrown into the lions den and trying to figure stuff out of people not knowing what they’re talking about. They went even a step further and I said, you know what? Hey, we want to implement that organization-wide software family package, you know: “Hey, my dear agencies, you know you don’t have anyone doing this. But you do it.” What a weird concept, isn’t it?

And I think this is a skill that they developed, that should be developed in all organizations, right? So imagine you work in a bank, you know your bank tries to implement something new. Why should you say “I don’t have the knowledge of this? I’m a banker. I don’t know how IT works. I don’t know what you want from me.” I think that’s the wrong approach. I think you as a person should see this as an opportunity to grow. And developed those skills right? And this is then all the activities that we spoke about. You know, being able to articulate a good process and bring it to the virtual paper, understanding how processes and capabilities tie together with all the other activities in capabilities and so on and so forth. So get away from the silos and gain that personal skill that you need to bring up as a key skill, I think in the 21st century going forward.

J-M: I agree. Well hopefully folks this is giving you a taste of what we think about business process management, business process analysis, enterprise architecture, two sides of the same coin.

Roland: So think about for the next couple of seconds about which capabilities do you need in your part of the organization? How are those capabilities aligned to your strategy and your implementation project? And think about which skills your group needs to build? And if you come back and hopefully not while driving, you come up with a list of those capabilities. You might be able to bring that in the next conversations that you have in your organization. So let’s take a little break and then we come back and see what you come up with.

Roland: All right, welcome back folks at thanks for making up to this point. We’re getting to a close in our episode, so thank you. Thank you very much for listening to this episode two of the What’s Your Baseline podcast.

We spoke about, just to remind everybody, about the history of the disciplines. We spoke about that EA and BPM are basically two sides of the same coin, and we spoke about that capabilities might be the construct that you’re looking forward to align your strategy with your architecture with your project execution to bring your organization forward. And lastly, we spoke about risk and benefits and had that wonderful example that J-M gave us. 

Thanks again for listening to episode 2. Please reach out to us either via email or via a voice message and I will put a link into our show notes that you just can go to that website and click on the little message button and we’re happy to bring you in and speak about the question that you have in one of our next shows. 

Also, please leave a rating about this show or review of our show in the podcatcher of choice where we’re eager to learn from you and obviously improve our podcasting. And last but not least, you will find the show nodes of this episode at whatsyourbaseline.com/episode2, and I’m looking forward to your comments and your suggestions on how we improve our podcast. 

So with that, J-M, thanks for joining me on this journey today.

J-M: Thank you Roland ,and thank you to everyone for joining us on this journey. We’re here together.

Roland: Alright guys that’s it. Have a great day and I’m looking forward to seeing you again in our next episode.