Trust the Data, Focus on the Humans: 14 Years of Process Leadership with Aafke Post

In this episode, Liam O'Neill speaks with Aafke Post, Senior BPM Solution Manager at Philips, where she has spent 14 years building and leading enterprise process governance across complex, multi-country environments.

Aafke's background is genuinely unusual for someone in this space. She started as a sports performance coach before studying Communication and Multimedia Design, and it is that combination of systems thinking and design thinking, always anchored to the end user, that has shaped everything she has done since.

This is a thoughtful and wide-ranging conversation about what it actually takes to make process work useful rather than just correct.

They discuss:

• Why teaching people to abseil taught her more about trusting a process than any business programme
• How she discovered a formal process framework at Philips that nobody in the business knew existed, and what that moment clarified for her
• Why a technically correct process that does not serve the people who use it has already failed
• The gap between how organisations work and how they think they work, and why that gap is so persistent
• What good process ownership actually looks like and why it is rarer than most organisations realise
• Why clean, consistent, agreed-upon data is the foundation everything else depends on, and how hard it is to get there in practice
• How she built a chatbot in Copilot Studio, and what the transcripts of user conversations revealed about the real gaps in the process framework
• Where AI is heading in the process space and why organisations without a strong data foundation will struggle to benefit from it

Aafke brings a perspective that is both deeply practical and genuinely different from most people working in this field. If you lead process, transformation, IT or enterprise architecture and you are trying to build something that people will actually use, this episode is worth your time.

Host: Liam O'Neill, Managing Director at bpmd 

Guest: Aafke Post, Senior BPM Solution Manager at Philips

Transcript

SPEAKER_01 0:00

Avge, thank you so much for coming on the podcast today. Really excited to talk with you through a lot of different subjects going through your background, your experience, and your work in Process. So diving straight in, do you want to give a little bit of an introduction about yourself?

SPEAKER_00 0:13

Yeah, Liam, thank you for asking me. So I'm Afke Post. I work at the intersection of process data and technology. And I love to connect business, IT, and governance, and of course, the people who need to work with the BPM systems. And I'm really happy to join this podcast about BPN and share my journey and perspectives.

SPEAKER_01 0:32

So before you arrived in process management, you studied uh communication and multimedia design and trained as a sports performance coach. It's a really unusual starting point for someone who's getting into processing in a large company. How did that journey unfold for you?

SPEAKER_00 0:46

It is a little bit unconventional, but actually, because of your question, right, I really needed to think about this. And what that journey taught me was how I could read systems or the people inside of them. So I worked a lot in outdoors activities, so climbing, mountain biking, canyoning, all that kind of stuff. And I realized if I help people who are standing on your rock face and they are going to start upsiling, they are nervous. And I asked them, okay, you're standing there, lower yourself into the depth. My job wasn't to motivate that person, my job was to help them trust the process I'm told them to do. And that is a magical moment. And the best performers I had in my team weren't the ones that were the bravest, no, that were the ones who trusted that system, that process that I'm told them to do step by step. So actually, that is amazing. And when I go into communication design, I saw that same principle again from a different angle. So how you present something to a person completely change if somebody engaged with it or walk away with it. So it was always there. I just didn't know it had a name yet.

SPEAKER_01 1:54

That's really interesting. And a little bit of a different scale of uh fear factor, right? Jumping off the top of a mountain versus tweaking a big, big process across an organization. But definitely, definitely uh both can go very right or very wrong sometimes. So your early career took you through Dutch government and a bit of technical consulting before you got into Philips. What were you learning about organizations and how they work during that period, even before process was named as the specific focus?

SPEAKER_00 2:21

Yeah, so I was learning how organizations actually work and how they think they work. And there is a gap between the two. But honestly, before processes even had that name, I was already in a person who thought, okay, everybody's going left. Why aren't we going to the right? Why can't we use the tool we already have? I was very curious about software, what it can do. And I'm a person who really loves experimenting, trying things out, finding the efficiencies, building workflows to make life more easy. And I was noticing also the human side of it. So how the decision got made, what people need versus what they say they need, and where everything falls apart. And that combination, the appetite to explore what technology can do, grounded in okay, how people really behave, that is a little bit my background and shaped everything I've done ever since.

SPEAKER_01 3:13

Yeah. You spent 14 years at Phillips, getting really deep into a lot of different things around kind of digital transformation space. Was there a specific moment or experience really early on that kind of shaped that for you that was really fundamental in uh setting up your mindset around process?

SPEAKER_00 3:31

Yeah, there was a specific moment. So before I worked in the core, I worked in the business. And in the business, I was doing my day-to-day work, optimizing stuff like I always do. And by doing that, I discovered something that was a complete formal process framework for the entire organization. And that stopped me in my efficiency, so uh optimization of the normal flow that I've learned. Because I was trained by my colleagues who do this day in and day on. They are not aware of that formal process framework. So I was not aware of that formal process framework. And if you learn, you learn always from the person next to you and not what is written down. And there I really realized, okay, if I want to make a process more efficient, I can't do it when I'm inside that workflow. I need to be at the core. And then I thought, okay, now I really need to make that shift.

SPEAKER_01 4:20

It always amazes me, like whenever you do big change projects and people start to build all that bang, don't let the processes, the knowledge, the documentation of ways of working, but it can be that big disconnect. Like it can be built for a you know change in an ELP or an audit program, wherever it might be. But then you've got new people joining the team, new people coming in. There's so many opportunities to reuse that same information. And so often that's missed. I did a project years ago doing that, and I was doing an improvement project. And I went to a team in Denmark, it was one of the last teams we visited, and they dragged out of one of the drawers a load of old Visio documents from five years ago that no one else in business knew anything about. We shaved off about two months of the project, and uh there's this big disconnect that you say about that management system and then the actual way people are working, where people aren't even aware of it. So your background in communication design and in user experience is quite different from a lot of people in the process space. How do you think that's shaped the way you personally approach process work?

SPEAKER_00 5:18

I think it's a real, real benefit to have that experience because communication and multimedia design is about usability. So how you design something so that the person on the receiving end can really make sense of it and can use it. And that is one of the core questions in CMD. In BPM, most people are focused if the process is correctly written down in that language that they used to have. But that doesn't mean that that language is understandable for the many, many stakeholders who need to use that framework. So it means for me, because I am responsible for creating many solutions out of that same framework, how I can visualize a process in so many ways that it's really meaningful for an analyst, for the end user, for a process owner, for a manager, all at the same time, from the same underlying model. So for me, making sure that insights can actually be gathered from that data, it means also giving the designers an application that guides them to prevent making mistakes in the first place. And there is where my CMD background became very, very valuable, because a process that is technically correct, but doesn't serve the people who need to work with it has already failed.

SPEAKER_01 6:32

I think that's a really interesting point because a lot of the crosses do get caught up in OMG object modeling group kind of notation nuances, and that's a big difference from what people actually need, what people can understand. When you look back on when you first came into the role and there was that big management system, was that legacy architecture of a legacy content? Was that built with that in mind so people could use it, or was it built more for processes?

SPEAKER_00 6:55

No, it was really built for the process, for the experts, and they forgot that the front-end employee needed to use that to do the day-to-day work, and that's where you also saw that gap, right? You were trained by your colleagues and you're just used to do it like your colleague tells you to do. So there is the big gap.

SPEAKER_01 7:12

And by the time you'd left and you'd started to bring in some of those communication design concepts, have that already started to break down some of those barriers and help to drive a bit more adoption or engagement with that management system.

SPEAKER_00 7:23

I'd love to say yes, but in fact, no. It's really, really hard because you need to sell the other way of thinking with the end user in mind. You need to sell that to the people who really believe they are the experts and know exactly how it should be done. And they are right about modeling, but they are not right that the tool that they are using is in fact not for the expert itself. You can have the same data, but you can visualize this in various ways for multiple stakeholders. They don't have that on top of their mind. And it's really hard to convince them to use that same underlying model in various ways.

SPEAKER_01 8:00

Going back to kind of your role in Philips, you mentioned that it was about linking business, IT, data governance, bringing all those different streams together. There's a lot of different hacks you have to worry about, a lot of different capabilities, a lot of different thinking styles. Where do you think that ability to bring all those different thinking styles come from for you?

SPEAKER_00 8:19

Yeah, so I started in the business, trained by my colleagues. So I understand how that works. Then I made the shift towards the core, responsible for those solutions. And because those solutions were also developed for various, various stakeholders, I needed to speak that language very quickly. My background also reinforced that. Communication and multimedia design is about usability, having something for various stakeholders. Who is this for? What does it do? Does it work for them? Is this really what they need? So trying to translate needs, priorities, and constraints across all of the boundaries of the various domains, various systems. And I'm always being very comfortable in that unclear area, sort of say. I really love to zoom out and see the whole and focus on the handovers between one to another. That is really where the things will fall apart, and I really love to focus on.

SPEAKER_01 9:17

And then in terms of the different streams you've done across those different fields, from you know getting into the detailed process governance, getting into automation and agile delivery, even compliance. A lot of people tend to pick one stream and specialize in that, but you seem to be able to across all of those. What's it meant to you personally to be able to hold all of those together?

SPEAKER_00 9:36

I really feel comfortable between all of those disciplines because there you can really make a difference on translating those needs. I need A, the other one needs B. So how can you make that happen? And I think it's really interesting to focus on that handover, because for me, there is where the real value can be created. I love to have that 360 view. And if you hold all of those domains together, you can see the end-to-end process, the framework as a whole. Not only the piece you own for yourself. And I've always been very curious. Okay, what is happening besides my own boundary? What are my inputs? Where do they come from? Are they fit for purpose? And what can I do to make sure my stakeholders can actually use it? And that validation, I think, across the full chain of the process framework, that's where I really love to look and I can make the most value.

SPEAKER_01 10:28

Whenever I've done process projects previously, when you look across an end-to-end, it's in the gaps between the teams, the capabilities where things fail. But not just in core processes like in procure to pay, but internally as well. And you've got your data team, your process team, and then your change delivery team. It's not within the process team and doing the work that it goes wrong. You get a very nice project there and a nice output at the end. It's that handover to the change delivery team, and that handover to be a you, it's those pieces where it always seems to really struggle. And what are some of the mechanisms used in Phillips for helping to address some of those gaps between those capabilities and between those teams?

SPEAKER_00 11:02

I think it's also about making things visible, making clear that you are just part of a chain. You are not a silo person in a complete ecosystem. People depend on your input or on your outputs. And if those are not clear, it's like an Estefetta. I come from the sports background. I did some Estefetta as well. If you don't do that handover correctly, the person behind you or in front of you cannot even walk with it. So I think that is the most crucial part. And the only thing you can do that is make that really visible and clear. Hey, but what you think a person needs will not fit their actually requirement to take it a step further.

SPEAKER_01 11:43

Yeah, that unclear handover piece. It's very easy to think you know what someone needs, right? But then to actually understand what the other team needs, what the nuances are, the bits of information, the way they need it, who they need it from, when and how. That nuance can so easily be lost when people try to assume and not take it forward. Early days of my career only used to do improvement projects, we used to do the process piece, do the analysis, come up with how things should work, and call up some change ideas, some nice work packages. And then initially we never really acid tested what the handover to a change delivery team looked like, what data they really needed. So you do fantastic briefs, really detailed, all the stuff you could ever think they need, and the actual thing they needed was just a little bit different. And instead of who's a project manager, who's a budget holder, who's a proof systemer, who's a final say so, what's your uh detailed change review cycle? It was little bits of governance and nuance that you maybe miss without having actually like you do sit in those different teams and get those different perspectives brought in together. So there's a lot of enthusiasm in the process and the transformation and the change space right now around being data-led, being intelligence-led, and uh driving process improvement. From your personal experience, what's it make to actually make that work for you? So actually be able to get results from it rather than just having the theory of being data-led.

SPEAKER_00 12:58

So for me, data-led, right, it means having clean structured data. And that sounds obvious and very easy unless you try to do it. Because the biggest obstacle is not having data, it's about a shared definition across all of the stakeholders. What does it mean having good data? And everybody assumes that what they use is fine until the moment you glue everything together and you try to pull something out of it, and they go, hmm, we have a lot of inconsistencies. They are visible now. And that is the problem in DBM in general, I guess, because we build things based on assumptions rather than validating it with the people who need to work with it every day. So all of them have their own interpretation. But if you not have a shared understanding of what good is, no shared standard, no shared ownership, you can't build anything meaningful on top of it. Before you can do anything intelligent with your data, you need that agreement. And if you don't have that agreement, then it's a fantastic story you still tell over and over again, but you don't get the value out of it.

SPEAKER_01 14:02

In terms of actually getting the value out of it, what are some practical things you're doing out of Philips to get to a point where you didn't just have KPIs but you had real results coming from that analysis?

SPEAKER_00 14:12

Well, if I am truly honest, this is the hard part. Because if you discover something, if you open up your data and you find something, it's really easy to say, hey, this is what you found, and you swoop in the answer. But there you don't force the change to really make the data or make the inconsistency be resolved. People tend to say the data is incorrect, they don't want that issue, they don't want that inconsistency. They just love doing their job day to day, and when something comes visible, it's really hard because you need to do something about it. And I think that is the hardest part, having owners of that process who really think I need to change this and I need to do something with it.

SPEAKER_01 14:59

Going on about ownership concepts, what would you say then makes a good process owner versus a process owner who could be a little bit better? What are the big driving factors for success in that role?

SPEAKER_00 15:09

Yeah, for me is that success, the people who are the champions and the process owners, they have a connection towards the people who need to work with it. And that is various stakeholders, of course. But also feeling responsible of what is in there because it's not about modeling a process, it's actually what you can do with it when you're done with the modeling. Train your people, make analyses of it, create those insights, but also make sure it's audit ready. Open up the gaps between global and local variants of that process, right? So it is so much more than just creating a model. And I think a process owner shouldn't know that. And what I see in our large enterprise is that the process owners don't fully realize what a gold mine actually they have in their hand. So for me, a process owner is a person who is really dedicated to create a model which is fit for purpose, meaning understandable and not modeling all the nitty-gritty things in part. No, having that process model that everybody understands, but also that will suit the various stakeholders to collect their data and make decisions based upon that data.

SPEAKER_01 16:21

So uh you now move into uh Kiva, uh, which is a mid-sized organization that's very data intelligence centric. How, in your view, is that approach to process something that's really gonna scale down to that mid-market size and something that works on for large enterprises, or is it something that's very much applicable at the mid-market level too?

SPEAKER_00 16:41

I think I will not say it will be easier, but the principle will be the same. It doesn't matter if you're large or medium or or small, that doesn't matter. But the biggest enemy of a large enterprise is that there is several layers between the people who need to work with the process and the people who can change the process. So on a mid-sized company, that gap is smaller. Another dimension is that a large enterprise will really struggle with a gap of the globally modeled process and what is locally practiced. So on paper, all the processes are standardized, but in reality, every region, every country, every team has its own variation. And in a large enterprise, it's really hard to visualize that gap. And I guess in a medium-sized organization, it's a little bit easier to visualize that gap and also acknowledge, okay, what is acceptable and what is not acceptable. The other thing is that a large enterprise you have years of complexity and governance taken into account. But maybe within a medium-sized company, it would be a little bit less. The change is faster. You can move towards the continuous improvement faster. So I think that is the biggest difference between a large company or a mid-sized company.

SPEAKER_01 17:52

I always like when you're talking about enterprise change, it always reminds me a bit of the scene from Shrek where it says ogres are like an onion, and sometimes large organizations like an onion. It's just layer after layer of uh approval. And at some point you might start crying. And in terms of Keeba, the organization you're going into, I've read about them, they seem very data and intelligence-led. Are they also on that process journey? Are you joining midway through and helping them get to the very top? Or are you taking them from the early steps into a more mature space on that side of the coin as well?

SPEAKER_00 18:20

Yes, they are starting, but they are already more mature in how they use that data and trying to improve by real life data and automation and AI. While Philips is a very big company, very steady, very stubborn also. It's really hard to turn. So in Kiva, they understand the value of that data, and that is what I like. So I will move from one to another, but I'm definitely need to step up in the real life process intelligence.

SPEAKER_01 18:53

So um, after spending 14 years building really extensive expertise, what's the thing you're most proud of in terms of what you've achieved and what you've left behind today?

SPEAKER_00 19:03

Yeah, so I could point out here amazing stuff that I've done, but actually it's not about the project or the model I've worked on, or it's the people who dare to step out of side of their own boundaries, who are willing to pioneer something new without a guarantee work, or the people who were not afraid to say no if something was not right. That is the real value for me, because it really takes courage in a large company to say no or step up and do something unconventional. And what I'm proud of is that BPM could play a role in all of those different projects I worked upon. So when I look back, it's not per se the project, it's the people who dare to take that extra step.

SPEAKER_01 19:44

Fantastic. We can always leave behind a legacy of things, but leaving behind a legacy of people is I think so much, Rachel. And then instead of looking back, looking forward, obviously there's this big disruption on the horizon of AI playing into every digital transformation space in a million and more different ways, and it's playing into the process space as well. So I understand you've already been exploring it. So from your personal perspective, where do you think this is heading and what is it about it that excites you the most?

SPEAKER_00 20:12

What excites me is that AI is going to be a separator of the organizations who have an amazing fundament of their data, which I just explained, that data needs to be aligned consistent and agreed upon. Companies that have that fundament of data will really benefit. It will amplify everything that they will do. Companies that's lack of clear and understandable data with consistency, every crack in their organization will be visible. And that is not even the thing that really excites me. It's about what we're having next. Right now, you see the process designers design or model their process once, twice a year. What will happen is that there will be AI process intelligence collecting real data with process mining, will create those models for you and will visualize and open up everything that is real time happening on the ground. And that shift from designed assumptions to a real living process intelligence is coming way faster than any organization will realize.

SPEAKER_01 21:18

I was speaking with uh a senior um exec at a large ERP company, and he mentioned that his view is five, 10 years' time down the road, we don't talk about UI, we don't talk about process or process intelligence or anything. Instead, there's just one point of interface. A CFO will log on, say what are my top priorities for the day, be fed back the three, four things we need to make a decision on, and everything happens in the background. All the way we interact with before modeling processes, entering fields, that might disappear. And that's a scary world. It's a lot of change. Definitely very interesting. I should mention actually, while we're on the topic of AI, I heard that you created a chatbot in uh Copilot Studio using some of your processes. Models. How did that go for you? Was that something that worked very well in getting people to engage with the content we had already there?

SPEAKER_00 22:06

I'm always that curious person. I tried to experiment and explore things myself. So yes, I built the chatbot, but the chatbot itself was actually beside the point. I realized that chatbot has a transcript for all the conversations that our end users, it will store the data. And I was thinking, okay, if we really want to know what people are thinking about, what their struggle is, what their needs are, I need to use those transcripts. So I build a second chatbot which would analyze those transcripts and would tell me what they need, what were the questions, what is the underlying struggle of everything that they put into that model? And it visualized something amazing. We had a very complex governance. People were asking how I can improve my modeling? What are the best practices on optimizing my workflow? And it told us we have a too complex governance model in place. The system might be too complex for the people who just model once or twice a year. We created an expert platform and we expected everybody to be an expert as well. And it was also a little bit the link back to my CMD background because here I had the real data, not what people told me in a workshop, but the actual underlying needs. And people will not use what you have built correctly, no matter how well-intentioned the design is, if they don't understand it.

SPEAKER_01 23:27

So you've owned end-to-end process frameworks across complex multi-country environments. In your experience, what's the hardest part in making a process framework genuinely useful rather than just a document that exists?

SPEAKER_00 23:41

Yeah, so the hardest part isn't the framework. Hardest part is not the framework, it's everything around it. So we have encountered many of process experts and analysts, but we lack higher management to really understand what is the value that we are doing, what we are building. We lack of capabilities to really promote this internally. We are very good at creating, but not good at selling. And without that, the framework is just something that will sit there. But the second challenge is also that real process ownership is rare. In practice, you will end up with many experts pulling in different directions. And because the process framework serves a very high number of different stakeholders, they all have different priorities and outputs. And when a topic is very urgent, but the topic is very urgent for everybody, nothing is really urgent. And we have learned that without having a clear owner who can make decisions, and without management that can really understand and advocate for this value, the best framework just becomes another document that will exist in the company.

SPEAKER_01 24:45

One of the challenges I do find with owners is they can be appointed, but then different companies see them as different things. Some see them as actually accountable for performance and they have ownership of the approval of change. And in others, they're more just modeling stewards and it's more of a technocratic role. In Philips, were you more of the mindset that process owners should have that authority, that license to make change and be accountability for it working? Or were you more on the nomenclature modeling semantics side of the coin?

SPEAKER_00 25:15

How it's currently set up with Philips is that every process has their own global business process owner, has their own process owner, and has process experts. But what is the actual responsibility of all of those different members of the same domain or process? For me, is still a little bit vague. Because if you truly look at those roles, what is the actual mandate that they have? I don't think as much as they would like. And we see within Philips that the quality management systems has a very loud voice in how things are made also for the global processes, which makes it sometimes a little bit hard to balance the two.

SPEAKER_01 25:55

Yeah, I always find it it shows up in the wash when it actually comes to delivering changes. So say it was a tweak to a system, automating early payments where you get another payment discount. And there's a little bit of work associated with that. Finding the person who's going to put the neck on the line and say, Yeah, I'll own that project, that initiative. I'm accountable for making that happen. I'm accountable for the improvement in performance off the back of it. Getting one person to hold the hand up and say, Yeah, I'll take on that responsibility. That little small project for initiative management role, that's a really difficult piece sometimes to get people to put the head above the parapet. I think that's definitely the role of the process owner. You're owning the way it works. You should be owning the changes to it. Even if you delegate the actual day-to-day management of a change, I think for me, that's a big piece that you have to see to me. Process ownership is really effective.

SPEAKER_00 26:43

Then maybe it's also because we make the transition now, right? So the years we are in now, that digital transformation was going so fast that also the people who are now responsible for the process don't realize that the data that they have in hand can help them so much and provide them so many insights they did not even know they existed. And I think that is also a missed opportunity.

SPEAKER_01 27:07

There's a few companies who have a million one KPIs, I mean there's so much data that can get lost in the wash, so many different things to look at. When you've got 50 different metrics that are adjudicated, how effective you are, really you don't have any. It's too noisy. But if you have one, two, three, four, maybe even five that you are actually held to account for the ones that are the big tick items, the ones that actually matter. And they might be massively different for a really senior global process owner versus a process, but for a very specific process, very different, if you have that data that's very intentional and the behavior is trying to motivate, that's when it can be really useful. In that theme, you've used process mining before to identify uh inefficiencies. What does it feel like when the data shows you something that the organization didn't know about itself? And how do you use that moment?

SPEAKER_00 27:54

Well, yeah, so I did not really use process mining. I worked in projects where other teams did the process mining itself, but we helped collecting that data and revealing the insights that we had. But I think what the hard part is you can reveal an insight and you can create amazing dashboards. But if people don't really have the appetite to do something with that insight or present that to higher management, then it doesn't tell you anything. So we cannot force people to do something with it. We can only make it visible.

SPEAKER_01 28:28

Yeah, having a dashboard doesn't change anything for anyone. It's only when someone sees it, engages with it, those sort of things. So I think it's been a really fantastic talking with you. And just as a closing question, if you were talking to yourself, right at the set of your career, or someone else who's just beginning a career in this space now, what would be the piece of advice you think would be most important, most viable for them to hear?

SPEAKER_00 28:50

Yeah, I can speak from my own experience. With my background, of course, I would say focus on the humans, but trust the data you collect. And you need both, because people can tell you what they are doing and explain their experience, but they see the problems through their own perspective. The data doesn't have the perspective. The data will show you the issue behind the issue and the thing nobody noticed or nobody wanted to admit it existed. But beyond that, I would say never stop looking outside of your own boundaries. The most valuable work happens at the edges in the handover between the different disciplines. Be curious about the tools and technology and everything that is popping up right now. Experiment, pioneer, don't be afraid to say no, and always design for your audience. And of course, uh, a technically perfect process, a brilliant data model. None of it matters if the people who need to work with it don't engage with it.

SPEAKER_01 29:47

Fantastic. Thank you so much. It's been an absolute pleasure. And this has been work in process, a BPMD podcast. Thank you to everyone listening, and uh hope you have a wonderful rest of your week.