M365 Show Podcast

About M365 Show Podcast

M365.FM is a podcast about Microsoft 365, Microsoft Copilot, AI, Modern Work, security, governance, Power Platform, Azure, and the technologies shaping the future of work.Hosted by Microsoft MVP Mirko Peters, M365.FM brings together Microsoft MVPs, Microsoft employees, product experts, architects, developers, and community leaders from around the world.Each episode goes beyond announcements and hype to explore what Microsoft technologies mean in practice. From Microsoft 365 Copilot and AI agents to Teams, SharePoint, Power Platform, Microsoft Fabric, Entra, Purview, security, governance, adoption, and automation, M365.FM focuses on real-world experience, implementation, strategy, and lessons learned.Expect expert interviews, technical deep dives, practical explainers, and conversations with people building, implementing, and shaping the Microsoft ecosystem.If you work with Microsoft 365, Copilot, AI, Modern Work, or the Microsoft Cloud, M365.FM helps you understand what matters, what works, and what is coming next.Hosted by Mirko Peters, Microsoft MVP. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support (https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss).

Publisher

Mirko Peters - Founder of m365.fm, m365.show and m365con.net

Category

education · news · technology

Language

en

Explicit

No

First episode

8 Jan 2025

Latest episode

6 Oct 2026

Latest episodes

1,017 episodes in the feed.

1. 

   6 Oct 2026

   Connectivity Is Not Integration — Why Your Connected Factory Still Can't Answer the Right Questions

   A connected factory can move machine signals in milliseconds and still fail to answer the operational questions that actually matter. A packaging machine stops, the PLC reports the fault, OPC UA exposes the event, MQTT distributes it, and the dashboard updates immediately. Maintenance receives an alert and everything appears connected. Then the planner asks which customer shipment is now at risk, and suddenly the answer requires MES data, ERP records, maintenance history, quality status, production quantities, delivery commitments, and often a spreadsheet. That gap is the focus of this episode: connectivity moves signals, while integration connects meaning, constraints, ownership, timing, and consequences. CONNECTIVITY MOVES SIGNALS — INTEGRATION CONNECTS MEANING OPC UA, MQTT, edge gateways, brokers, and modern industrial connectivity platforms solve important problems. They make machine data accessible, standardize transport, reduce point-to-point connections, and allow events to move between machines, applications, and cloud services. But transporting an alarm does not explain its business consequence. A fault code can arrive perfectly, keep the correct timestamp, and reach every subscriber within seconds. That still does not tell a planner whether the stopped machine affects an urgent order, whether approved inventory already exists, whether the current output is on quality hold, or whether another resource can take over. To answer those questions, the architecture needs relationships between the machine, the active operation, the work order, the product, material status, quality state, maintenance information, and customer demand. ONE ALARM, MULTIPLE SYSTEMS, NO COMPLETE ANSWER The episode follows one packaging-machine alarm through the systems that typically hold different parts of the production story. The PLC knows what happened at the machine. MES understands which operation and work order are active. ERP knows demand, due dates, inventory, and customer commitments. Maintenance knows service history and outstanding work. Quality decides whether the produced output can actually be released. Each system can be correct while the factory as a whole still cannot answer the operational question. This is where people become the integration layer: someone checks MES, someone else opens ERP, maintenance searches the service history, quality verifies release status, and somebody eventually pulls the information together manually. That approach works until decisions need to happen quickly, systems change, or the person who understands all the hidden mappings is unavailable. UNIFIED NAMESPACE: A BETTER HIGHWAY, NOT THE FACTORY MAP A Unified Namespace can improve this situation significantly by replacing many direct system-to-system connections with a shared publish-and-subscribe environment. Machines and applications publish information once, consumers subscribe to what they need, and new systems can join without another custom connection back to the equipment. That reduces plumbing, but it does not automatically create context. An MQTT topic structure can tell you where information came from, but it cannot determine which production order was active, which material was involved, which quality state applied, or which customer delivery depends on that order. Publishing MES, ERP, quality, and machine events into the same broker does not automatically create the relationships between them. Those relationships still have to be modeled and governed. THE TAG NAMING TRAP Good naming conventions help people discover data, but names are not identities. One system may call a machine Packer7, maintenance may use PK07, ERP may use a production-resource code, and a cloud platform may know the same equipment through a device identity. All of those records can refer to the same physical asset. <br...

2. 

   5 Oct 2026

   Why Continuous Improvement Needs Better Data

   Continuous improvement is supposed to create learning that compounds over time. In many factories, however, improvement work still depends heavily on workshops, spreadsheets, isolated reports, and what people remember from the previous shift. A Kaizen event can create visible progress, but a few weeks later the same loss often appears again under slightly different production conditions. The issue is not always the quality of the improvement idea. The bigger problem is that teams often cannot prove whether the countermeasure actually worked, where it worked, and under which conditions it stopped working. WHY KAIZEN IMPROVEMENTS OFTEN DISAPPEAR A workshop creates focus for a few days. Teams map the process, identify waste, assign actions, move tools, change checklists, or adjust handoffs. Then normal production pressure returns. The supervisor has another urgent order, maintenance has another fault, planning changes the sequence, and quality puts another batch on hold. The improvement action remains somewhere in an Excel file or project tracker instead of becoming part of the operating rhythm. The important question is therefore not whether an action was completed, but whether the production condition actually improved. PDCA NEEDS A REAL CHECK STEP Plan, Do, Check, Act sounds simple, but many organizations effectively run Plan, Do, and Move On. PLAN should define a testable problem, the current condition, the expected improvement, and the hypothesis behind the countermeasure. DO means testing the countermeasure under real production conditions while recording enough context to understand what actually happened. CHECK means comparing the expected result with real production evidence. ACT means standardizing the change when the evidence supports it, or adapting, narrowing, or reversing it when it does not. • Did the loss actually decrease? • Did the problem simply move somewhere else? • Did the change improve availability while damaging quality? • Did it work across different products, crews, and shifts? • Did maintenance, material, scheduling, or another process change influence the result? A single successful production run is not proof. Continuous improvement needs enough evidence to separate a repeatable improvement from a lucky shift. GEMBA AND DATA NEED EACH OTHER Data does not replace Gemba. Operators, supervisors, technicians, planners, and quality teams understand production conditions that systems often cannot capture. A machine record may show a ten-minute stop, while an operator knows that the stop happened because a component felt wrong, a normal material route was blocked, or the previous shift left the station in an unusual condition. At the same time, observation alone shows only one shift, one event, or one version of the problem. Connected operational data makes it possible to test whether an observation repeats across orders, products, machines, shifts, material batches, and longer periods of time. Gemba helps teams identify where to look and which questions matter. Operational data helps test those questions across the real production pattern. Standard work then carries the learning forward so the next shift does not start from zero. START WITH THE IMPROVEMENT QUESTION One of the biggest mistakes in manufacturing analytics is beginning with the data that happens to be available. A modern production line can generate huge volumes of information from PLCs, sensors, MES systems, ERP, quality systems, maintenance applications, and spreadsheets. More data does not automatically create better decisions. A useful improvement process starts with the production question the team actually needs to answer. Instead of asking “What data do we have?”, ask “What production question are we trying to answer?” A statement such as “changeovers take too long” is still too broad. A better question would...

3. 

   1 Oct 2026

   Building Azure That Survives the Real World — with Mike Martin [MVP]

   Azure architecture looks easy when everything works.The real test starts when dependencies fail, regions become unavailable, traffic spikes, assumptions turn out to be wrong, requirements change, and someone eventually asks the uncomfortable question: why did we design it this way in the first place?In this episode of M365.FM, Mirko Peters talks with Mike Martin [MVP] about what Azure architecture looks like when it has to survive real production conditions rather than just look good on a diagram.Mike brings decades of experience across development, infrastructure, architecture, leadership, coaching, training, and Microsoft Azure. One of his strongest observations is that many of the problems architects face today are not actually new. DNS still breaks. IP dependencies still matter. Costs still become a problem. Integrations still fail. Dependencies still disappear at the worst possible moment.What has changed is the level of complexity we build around those problems. FROM VISUAL BASIC TO MODERN AZURE ARCHITECTURE Mike looks back at nearly three decades in IT, starting as a Visual Basic developer in the 1990s and moving through distributed systems, networking, enterprise software, infrastructure, and eventually Azure.His key observation is simple: the industry keeps solving many of the same fundamental problems, but the architectures around them have become much more complex.Modern systems have moved from client-server applications to distributed architectures, cloud platforms, containers, microservices, Kubernetes, hybrid environments, and now AI-assisted development.That creates enormous possibilities, but it also creates a new risk: overengineering.Mike argues that many teams today make simple problems unnecessarily complicated. Good architecture is often not about adding more technology. It is about knowing what not to add. WHAT DOES AN AZURE ARCHITECT ACTUALLY DO? For Mike, architecture is not about choosing the largest number of Azure services or producing an impressive diagram.It is about understanding which components belong together, which ones should be avoided, which ones are necessary, and how to build something that remains maintainable, scalable, secure, and resilient.Architecture includes much more than compute. Identity Networking Data flows Security Monitoring Integration Dependencies Scalability Operations Recovery Deployment Cost Mike also challenges the idea that cloud-native automatically means Kubernetes or containers.Azure provides many managed and native services that can solve problems without introducing unnecessary operational overhead.The architect’s role is to understand the complete solution and choose the simplest architecture that still satisfies the real requirements. START WITH BUSINESS REQUIREMENTS, NOT AZURE SERVICES One of the most important lessons in this episode is simple: do not start with technology.Before deciding between Azure Kubernetes Service, App Service, Azure Functions, containers, Service Bus, or another platform, teams should first understand what the solution actually needs to do.Questions to ask: Is it internal or customer-facing? How many users will depend on it? Does it need to scale globally? How long can it be unavailable? How much data can the business afford to lose? Which compliance requirements apply? What happens if the application disappears for several hours? Who is affected? What level of operational support is required? These questions lead directly into concepts such as SLAs, SLOs, RTOs, and RPOs.They also determine whether the architecture should be single-region, multi-region, active-active, active-passive, or something much simpler. RTO AND RPO WITHOUT THE BUZZWORDS RTO and RPO are often discussed...

Reach and audience

Public platform figures. Ratings count people who left a rating, not total listeners.

Apple Podcasts (US)

5.0 / 5

3 ratings

Podcast Authority Score: 49 / 100

A composite of feed quality, social presence, YouTube performance and engagement. Read the methodology.

Quality

98

Social presence

0

YouTube

0

Engagement

0

Contact M365 Show Podcast

Guest appearances

Books guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.

Shows with a similar audience

• 

  Everyday AI Podcast – An AI and ChatGPT Podcast

• 

  Using AI at Work

• 

  Infamous AI

• 

  Practical AI: Machine Learning, Data Science

• 

  The AI Breakdown: Daily Artificial Intelligence News and Discussions

• 

  AI Explored