Ep. 74: "Beyond BPM and EA: Why System Science Is the Missing Foundation"

Ep. 74: "Beyond BPM and EA: Why System Science Is the Missing Foundation"

In this special guest episode, Russell and Caspar welcome Petros Panagiotidis, a deeply experienced BPM and Enterprise Architecture practitioner from Greece with four decades of professional experience and a PhD in Systems Science. Petros shares his unconventional academic journey through Business Administration, Computer Information Systems, Business Systems Analysis and Design, culminating in doctoral research on digital transformation and Industry 4.0. The discussion reveals Petros's counter-intuitive thesis: BPM and EA are fundamentally the same discipline, just using different terminology and marketing language. Through a systems science lens, he demonstrates how all the buzzwords around frameworks and methodologies—BPMN, TOGAF, and others—represent surface-level manifestations of deeper systemic principles. Petros introduces cybernetics and system dynamics as the foundational sciences that explain why processes exist and how they behave. He uses the elegant metaphor of water flowing through a river to describe how processes (the water) move through organizational architecture (the riverbed), making clear that process architecture provides stable structure while individual processes represent the flowing events. The conversation explores feedback loops—both negative (deviation correction toward targets) and positive (exponential amplification)—as the deep structure underlying all organizational systems. Petros emphasizes that understanding these foundational principles from systems science would transform how practitioners approach BPM and EA work, moving beyond tool-centric and marketing-driven thinking to genuine systemic understanding. 5 Key Takeaways: 1. BPM and EA Are Fundamentally One Discipline: What we call Business Process Management and Enterprise Architecture are essentially the same thing expressed in different dialects—the distinction exists primarily for marketing purposes around tools and methodologies, but the underlying systemic logic is identical. 2. System Science Provides the Foundation BPM Lacks: BPM and EA have a ceiling beyond which they cannot fully explain organizational behavior; system science (particularly cybernetics and system dynamics) reveals why processes and architectures exist and emerge the way they do at a deeper structural level. 3. Feedback Loops Are the Deep Structure: Two types of feedback loops—negative (correcting deviations from targets) and positive (amplifying deviations)—create the underlying structure from which all organizational processes and architectures emerge as visible manifestations; understanding these explains organizational behavior at a fundamental level. 4. Process Architecture vs. Process Events Are Interdependent: Process architecture provides stable structure and guardrails, while individual processes are the flowing events that move through this structure—like water finding its way through a riverbed; both are necessary and neither alone is sufficient. 5. Stafford Beer and System Dynamics Should Be Foundational Reading: Business schools and BPM practitioners should study Stafford Beer's work on organizational cybernetics and the viable systems model (five subsystems that enable organizational survival), plus system dynamics literature from the 1970s-80s—these foundational concepts should underpin all contemporary BPM and EA thinking rather than being overlooked in favor of current buzzwords. If you have suggestions or questions, please reach out to us via questions@bpm360podcast.com [questions@bpm360podcast.com] If you enjoy our content, please like, rate, subscribe… we do appreciate that…

Ep. 73: "The Performance Analyst: From Data Dashboard Maker to Intelligence Detective"

In this final episode of their BPM roles mini-series, Russell and Caspar examine the performance and KPI analyst role—also known as the process intelligence analyst—responsible for ongoing measurement of process performance, designing KPI frameworks, maintaining dashboards, and turning process data into actionable insights. The discussion reveals this role encompasses two distinct functions: the architectural design of performance indicator frameworks that align with organizational strategy, and the operational analysis of process data to understand root causes and effects. They explore the critical distinction between KPIs (strategic, aggregated outcomes) and PPIs (process performance indicators that measure operational health), using examples like on-time-in-full delivery rates versus quality inspection lead times. Through detailed conversation, they examine how effective performance analysis requires understanding causal dependencies throughout end-to-end processes—recognizing that a bottleneck in one subprocess directly impacts strategic KPIs downstream. The episode emphasizes that this role sits at the intersection of data science and business context, requiring both technical capability to work with data and sufficient operational understanding to design meaningful indicators. They debate whether organizations actually staff this role adequately or whether the framework design responsibility simply doesn't exist in practice. The hosts conclude by positioning this as a "unicorn" role that combines process intelligence tools, root cause analysis skills, and the ability to facilitate dialogue between process owners about where to set indicators for aligned performance across the value chain. 5 Key Takeaways: 1. Two Functions in One Role: The performance analyst must both design the architectural framework of performance indicators aligned to strategy (what should we measure and why) and perform operational analysis of process data (what's actually happening and what does it mean)—these are distinct skills packaged into one position. 2. PPIs Drive KPIs, Not the Other Way Around: Process performance indicators (PPIs) measure operational process health—like quality inspection lead time or credit check duration—while KPIs are strategic outcomes like on-time-in-full delivery; effective analysis connects how operational PPIs aggregate up to impact strategic KPIs. 3. Understand Causal Dependencies Across Processes: The core value lies in understanding how process elements affect each other throughout the end-to-end chain—a three-day delay in quality inspection directly causes late delivery to customers, connecting a seemingly minor operational metric to customer satisfaction. 4. Intelligence Means Root Cause Analysis, Not Just Reporting: Moving from dashboards to actionable insights requires detective work using process intelligence tools to prove points about variance, identify bottlenecks, and understand why processes perform as they do—not just displaying what happened. 5. Prevent Local Optimization at the Expense of End-to-End Performance: Without proper indicator framework design and end-to-end visibility, individual process steps optimize toward the wrong targets—everyone becomes reproducibly fast at the wrong thing, landing on the "left-hand side" of the bell curve when they should be elsewhere for overall chain performance. If you have suggestions or questions, please reach out to us via questions@bpm360podcast.com [questions@bpm360podcast.com] If you enjoy our content, please like, rate, subscribe… we do appreciate that…

Ep. 72: "The BPM Technology Manager: From Tool Guardian to Integration Orchestrator"

In this episode, Russell and Caspar examine the BPM technology and tooling manager role—a position that has evolved dramatically from its origins as a technical gatekeeper to today's integration-focused facilitator. They explore how this person manages the BPM platform ecosystem including process repositories, modeling tools, automation platforms, and process mining solutions while ensuring they remain fit for organizational purpose. The discussion reveals how the role's importance has shifted over time, from the days of on-premises systems requiring deep database schema knowledge and complex upgrades to today's cloud-based environments where new features appear automatically. The hosts debate whether one person typically owns all BPM tooling or if modeling, mining, and automation platforms are managed by different specialists in larger organizations. Through candid conversation, they examine the tension between becoming a product expert wedded to one vendor versus maintaining objectivity and vendor independence to serve the organization's needs. The episode explores critical character traits including technical adaptability, the ability to train users appropriately without overwhelming them with advanced features they'll never use, and understanding how BPM tools fit into the wider enterprise application ecosystem. They emphasize the importance of working collaboratively with BPM architects to extend methodology and integrate with other systems like risk management, quality management, and project management tools. This is essential listening for understanding how the BPM technology manager role has transformed from maintenance-focused to integration-oriented in the modern cloud era. 5 Key Takeaways: 1. The Role Has Evolved Dramatically: BPM technology managers have shifted from being on-premises system gatekeepers who controlled upgrades and configurations to cloud-era facilitators who focus on integration, user enablement, and ecosystem management—the old model of "you must come to me for everything" is history. 2. Vendor Independence Is Critical: The tooling landscape changes rapidly and this person must evaluate options objectively rather than becoming emotionally attached to a single vendor's roadmap—the job is serving organizational needs, not defending a particular product or becoming its evangelist. 3. Train for Actual Use Cases, Not Product Mastery: Like teaching household budgeting versus investment banking in Excel, BPM training should focus on what users actually need (typically 10-15% of tool capabilities) rather than overwhelming them with advanced features they'll never use—practical enablement trumps comprehensive product knowledge. 4. Integration Thinking Beyond BPM: Modern tooling managers must understand how BPM platforms connect with the wider enterprise ecosystem—JIRA for project management, document management systems for quality, process mining tools, risk and control systems—and facilitate smooth integration rather than treating BPM as an isolated island. 5. Partner with Architects for Evolution: The technology manager and BPM architects must work hand-in-hand to expand capabilities—architects need technical feasibility input for methodology extensions, while tooling experts need architectural context to propose automation, dashboards, and integrations that make ambitious use cases practically achievable. If you have suggestions or questions, please reach out to us via questions@bpm360podcast.com [questions@bpm360podcast.com] If you enjoy our content, please like, rate, subscribe… we do appreciate that…

Ep. 71: "The Process Owner Part 2: Experience, Leadership, and Finding Your Sweet Spot"

In this continuation of their process owner series, Russell and Caspar dive deep into the experience requirements and organizational positioning needed for successful process ownership. They explore why this is fundamentally a senior role that requires solid operational management experience combined with cross-functional influence capability. The discussion tackles the challenge of finding the organizational "sweet spot"—identifying leaders who are senior enough to command respect and drive change but not so consumed by executive responsibilities that they cannot focus on process excellence. Through candid conversation, they examine how experience requirements vary by domain and whether someone needs to be promoted from within or can be brought in externally with relevant domain expertise. The hosts debate the balance between operational hands-on knowledge and strategic thinking, emphasizing that process owners must understand the work deeply while maintaining enough distance to drive improvements objectively. Russell shares a powerful anecdote about entering sales without traditional experience, illustrating how ambition, authenticity, and the right mindset can sometimes matter more than years of experience. The episode provides practical guidance on evaluating candidates for process ownership roles and recognizing that while experience is valuable, the combination of drive, empathy, openness to change, and leadership capability can enable someone to grow into the role successfully. This is essential listening for organizations nominating process owners and professionals considering whether they're ready for this challenging but rewarding responsibility. 5 Key Takeaways: 1. Find the Organizational Sweet Spot: Process owners need to be senior enough to influence across boundaries and command respect, but not so senior (like managing directors or founders) that they're too consumed by executive duties to focus on operational process excellence. 2. Solid Operational Experience Is Non-Negotiable: Candidates must have deep hands-on understanding of how the process domain actually works—theory alone won't suffice for driving meaningful improvements and earning credibility with frontline teams who know when someone lacks real operational knowledge. 3. Domain Expertise Matters More Than BPM Expertise: Process owners don't need to be BPM methodology experts, but they must be comfortable with process data, governance concepts, and have legitimate domain expertise—someone with strong procurement standardization experience can be a great purchasing process owner even without formal BPM training. 4. Process Owners Are Change Leaders: This role requires the mindset, skills, and experience of a change leader—not just maintaining status quo but driving continuous improvement, adapting to market changes, communicating strategic direction, and serving as a role model for transformation. 5. Experience Plus Mindset Beats Experience Alone: While operational experience is important, the combination of drive, ambition, empathy, authenticity, and openness to learning can enable someone with less experience to succeed—stay true to yourself, bring what you uniquely offer, and grow into the role rather than waiting until you feel perfectly qualified. If you have suggestions or questions, please reach out to us via questions@bpm360podcast.com [questions@bpm360podcast.com] If you enjoy our content, please like, rate, subscribe… we do appreciate that…

Ep. 70: "The Psychology of Change: Why Beliefs Drive BPM Success More Than Process Maps"

In this guest episode, Russell and Caspar welcome Thierry Muller, an IT veteran turned change management expert, for a deep conversation about the human side of transformation projects. Thierry shares his unconventional journey from one failed SAP implementation to discovering his true calling in change management when tasked with changing DSM's corporate culture. The discussion explores why every project is fundamentally a change management project, even when organizations try to separate the two disciplines. Thierry reveals how understanding the psychology behind change—particularly the role of beliefs in driving behavior—transformed him from a technical project manager into an effective change leader. The conversation examines why traditional approaches focusing only on communication plans and training fail to create genuine adoption and commitment. Through candid examples, including a continuous improvement program where employees feared their ideas would be used against them, Thierry demonstrates how beliefs shape outcomes more powerfully than any process documentation. The hosts and guest debate the distinction between compliance and commitment, exploring how change managers must work at the belief level rather than just the behavior level. Thierry emphasizes that successful change requires understanding what people believe about the change, not just what they know about it. The episode provides practical insights on creating psychological safety, building trust, and shifting organizational beliefs to enable genuine transformation rather than superficial compliance. 5 Key Takeaways: 1. Every Project Is a Change Project: You cannot separate project management from change management—any project that requires people to work differently is fundamentally about changing human behavior, beliefs, and culture, whether you acknowledge it explicitly or not. 2. Beliefs Drive Behavior More Than Knowledge: The brain doesn't distinguish between beliefs and truth—what people believe determines how they act, so successful change management requires working at the belief level, not just providing information or training on new processes. 3. Start with "Why Change Culture" Not "Make People Comply": When leadership frames transformation as "changing culture" rather than "making people do what we want," it creates the right foundation for genuine change management instead of forced compliance through top-down directives. 4. Compliance Without Commitment Fails: Getting people to follow new processes out of obligation (compliance) is fundamentally different from getting them to embrace changes because they believe it benefits them (commitment)—only the latter creates sustainable transformation. 5. Psychological Safety Enables Improvement: Continuous improvement programs fail when employees believe their ideas will be used against them (more work, job loss)—changing this belief to "improvements benefit me and my team" is essential, as demonstrated by Toyota's guarantee of promotion rather than termination. In case of questions or suggestions, please reach out via questions@bpm360podcast.com [questions@bpm360podcast.com]. If you enjoy our content, please like, rate and subscribe...