M365.FM a Microsoft MVP Podcast by Mirko Peters

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

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.

  1. há 2 h

    Content Understanding & Document AI - Simply Explained

    Invoices, contracts, receipts, forms, scanned PDFs, and email attachments contain valuable business information — but most automation still struggles to turn those documents into reliable, structured data. In this episode of M365 FM – Simply Explained, we break down Microsoft Content Understanding, Document AI, OCR, AI Builder, Power Automate, Dataverse, and Power Apps and explain how they work together to transform documents into usable business data and automated processes. You’ll learn why traditional OCR is only the beginning. OCR can recognize text such as an invoice number or amount, but it does not automatically understand whether a number represents an invoice ID, purchase order, bank account, tax value, or phone number. Document AI adds context, structure, and business meaning to extracted information. We explain how Microsoft Content Understanding can take documents and images, extract defined fields, classify information, and return structured results that downstream systems can use. Instead of asking AI to summarize an entire document, organizations can define a schema containing fields such as supplier name, invoice date, invoice number, invoice total, document type, and line items. The episode also shows how Microsoft Power Platform turns document extraction into a complete business workflow. Power Automate can detect new documents in email or SharePoint, send them for extraction, validate the returned information, create records, trigger approvals, and route exceptions to the right person. Dataverse can store structured document records and process history, while Power Apps can provide a human review interface for correcting uncertain or missing information. We also cover one of the most important parts of Document AI: confidence scores and human-in-the-loop review. A high confidence score does not automatically mean a value should be trusted. Critical information such as invoice totals, payment instructions, bank details, or contract dates may still require additional validation against business rules and existing systems. You’ll discover how validation can check whether suppliers exist, purchase orders match, totals make sense, dates are valid, and duplicate invoices have already been processed. This combination of AI extraction, validation rules, governance, and human review is what turns Document AI from an impressive demo into a reliable business process. We also look at practical first use cases including invoice processing, employee onboarding forms, claims, contract expiry dates, supplier documents, procurement workflows, HR documents, legal documents, service requests, and customer forms. The key is to start with one document type, one clear decision, a defined owner, and a review path for exceptions. By the end of this episode, you’ll understand the complete Document AI pattern: Document → Content Understanding → Structured Data → Validation → Power Automate → Dataverse → Human Review → Business Action The goal is not simply to process more PDFs. It is to stop people searching through documents for basic information and instead move structured, validated data directly into the business process where decisions happen. Subscribe to M365 FM for practical episodes about Microsoft Content Understanding, Power Platform, Power Automate, AI Builder, Microsoft AI, automation, Copilot, document processing, and the future of work. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Content Understanding & Document AI - Simply Explained
  2. há 4 h

    IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

    A machine sends temperature readings, vibration data, cycle counts, power consumption, and operating states every few seconds. Then the gateway suddenly disconnects. Are all of those messages simply “events”? Technically, you could describe them that way. Architecturally, that can create serious problems. Azure IoT Hub Message Routing and Azure Event Grid solve different problems. One path is designed around preserving and distributing operational data. The other is designed around notifying systems that something changed and may require a response. Treating them as interchangeable can leave you with expensive workflows processing routine sensor data—or important signals buried inside a telemetry pipeline nobody is actively watching. In this episode of M365 FM, we follow a manufacturing machine through a real Azure IoT architecture and explain where IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions, and Logic Apps actually belong. WHAT YOU WILL LEARN In this episode, we explore: Why machine telemetry and discrete business or lifecycle events require different architecture patternsHow Azure IoT Hub Message Routing works as part of a telemetry data planeWhere Azure Event Grid fits into event-driven and reactive architecturesWhy message ordering matters for manufacturing telemetryWhy Event Grid should not become your primary high-volume telemetry busWhy IoT Hub routing should not be forced into every notification workflowHow IoT Hub and Event Grid can work together in the same architectureHow Event Hubs can support independent stream-processing consumersWhy raw telemetry should often be retained for traceability and later investigationHow Microsoft Fabric and Power BI can consume prepared operational dataWhy MES, ERP, and asset models provide context that device data alone cannot provideHow device disconnect events should be interpreted without automatically assuming production stoppedHow duplicate delivery, retries, timestamps, and idempotency affect reliable industrial architecturesHow to design condition monitoring, predictive maintenance, quality traceability, and production-disruption workflowsHow to decide whether a message belongs on the data plane, the response path, or bothTELEMETRY IS A RECORD OVER TIME Telemetry is not valuable because one temperature reading arrived. It becomes valuable because thousands of readings together describe what happened. A production machine may continuously report: Temperature and vibration measurementsMotor current and energy consumptionCycle counts and production countersRunning, idle, stopped, or faulted statesSource timestamps and sequence informationDiagnostic and equipment-health informationA single temperature value might mean very little. The sequence around that reading tells the story. Was the machine warming up? Was it already producing? Was vibration increasing at the same time? Did cycle time begin to increase? Did the machine stop shortly afterward? Telemetry therefore needs a path designed around sequence, retention, replay, independent consumers, and traceability. EVENTS EXIST TO START A RESPONSE An event serves another purpose. An event says: Something changed. A system or person may need to react. Examples include: A new device was registeredA gateway disconnected from IoT HubA device reconnectedA device was deletedA monitoring process detected a condition requiring investigationAn inspection completed and another workflow can beginThe recipient usually does not need hours of telemetry before starting the first step. It needs enough information to identify what happened and determine the appropriate response. That response might involve: Starting an Azure FunctionTriggering a Logic AppOpening a support investigationUpdating an asset recordChecking the current device stateCalling an external application through a webhookNotifying the team responsible for the affected systemThe event starts the investigation. It does not necessarily contain every fact needed to make the final operational decision. WHY “EVERYTHING IS AN EVENT” BREAKS DOWN Sending every sensor measurement into event-triggered workflows can look attractive during a proof of concept. Then production scale arrives. Every reading triggers another Function. Another Logic App evaluates something. Another integration receives another message. Maintenance creates its own subscription. Quality creates another. Energy management creates another. Soon, every team has slightly different filtering, state management, retry handling, and storage logic. A temperature measurement is not automatically an incident. It may contribute to an incident later, but the continuous measurements should remain available as evidence. When routine telemetry starts generating constant notifications, users can also begin ignoring alerts because the system has trained them to expect noise rather than actionable information.  WHAT AZURE IOT HUB ACTUALLY DOES Azure IoT Hub provides the device-facing cloud boundary. It supports areas such as: Secure device identitiesDevice-to-cloud messagingCloud-to-device communicationDevice managementDevice twinsControlled access between connected equipment and Azure servicesIoT Hub knows that an authenticated device sent a message. It does not automatically understand what that message means to production. A gateway might report: state = running But “running” could mean: Producing approved partsDry cyclingRunning setupPerforming reworkMoving without materialThat context usually comes from additional systems such as the MES, ERP, asset model, or production application. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem
  3. há 6 h

    The 5 Pillars of Data Transformation - Simply Explained

    AI was supposed to clear the backlog, accelerate decisions, and give every team a smarter way to work. Instead, many organizations now have Microsoft Copilot, Power BI, Microsoft Fabric, AI agents, and more data than ever before—while important decisions still crawl through meetings because nobody fully trusts the numbers or knows who can act on them. The technology spend keeps rising. The action does not. The problem is often not a lack of AI. It is the absence of an operating model connecting data, meaning, governance, technology, people, and accountability. In this episode of M365 FM – Simply Explained, we break down the five pillars organizations need to build a reliable foundation for data transformation and AI. WHAT YOU WILL LEARN In this episode, we explore: Why AI cannot compensate for unreliable dataHow data governance creates trust before automation beginsWhy data quality should depend on the decision being madeHow Microsoft Purview can support governance and data discoveryHow Microsoft Fabric supports modern analytics and data platformsWhy semantic models matter for Power BI and AIHow conflicting definitions create conflicting dashboardsWhy business glossaries matter for humans and AI agentsHow data ownership affects AI readinessWhy access, security, and permissions must be defined before AI scalesHow Copilot and AI agents depend on trusted business contextWhy human accountability remains critical even when AI generates the answerPILLAR 1: DATA GOVERNANCE – TRUST BEFORE AUTOMATION Data governance often sounds like policies, compliance meetings, documentation, and bureaucracy. In practice, governance answers a few very simple questions: Who owns this data?Who is allowed to access it?Where did the data come from?Can we trust it for this particular use case?What are people allowed to do with it?What are AI systems allowed to do with it?Without clear answers, AI does not solve a data problem. It can spread the problem faster. Imagine a leadership team preparing a sales forecast. Sales presents one revenue number. Finance presents another. Both numbers come from systems that appear authoritative. The meeting suddenly stops being about future decisions. Instead, everyone starts arguing about which spreadsheet or dashboard is correct. The underlying problem may be that: The CRM contains one version of revenueThe finance system contains anotherManual exports introduce additional differencesNobody owns the definition of revenueNobody owns the quality of the source dataNobody can clearly explain which number should drive the forecastThe company ends up debating the past instead of deciding the future. WHAT HAPPENS WHEN AI ENTERS THE PICTURE? Now imagine someone asks an AI agent: “Which sales region is falling behind?” The answer may arrive within seconds. But it could be based on: Duplicate customer recordsOutdated account assignmentsMissing opportunitiesIncorrect forecast stagesOld dataIncorrect permissionsInformation the user should not have been able to accessThe answer can sound confident. That does not automatically make it trustworthy. Governance creates the working agreement around the data before automation starts using it. A strong governance model typically establishes: Named data ownersClear responsibilitiesData classificationsAccess rulesSource-system documentationData quality expectationsAuditabilityPolicies for sensitive informationRules for AI and automationMicrosoft technologies can support this process. Microsoft Purview can help organizations discover, classify, understand, and govern information. Microsoft Fabric can help bring data together, prepare it, analyze it, monitor it, and make it available for reporting and AI scenarios. But technology cannot decide everything. Organizations still need people to decide: Who owns customer dataWhich definitions are authoritativeWhat data quality is acceptableWho should have accessWhen an AI-generated answer is safe to useWho remains responsible for the final decisionDATA QUALITY MUST MATCH THE DECISION Many organizations approach data quality as if every field in every system needs to be perfect. That is rarely realistic. Data quality should instead be evaluated against the business decision being made. For a sales forecast, the most important fields might include: Opportunity stageExpected close dateForecast amountAccount ownerTerritoryProbabilityCustomer statusOther fields may be less important for that specific decision. The better question is therefore not: “How do we clean all of our data?” The better question is: “Which data must we trust for this decision?” That makes the problem smaller, more measurable, and much easier to manage. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    The 5 Pillars of Data Transformation - Simply Explained
  4. há 1 dia

    Your Factory Cloud Bill Is Much Higher Than You Think

    Cloud storage may look cheap. Sending factory data to the cloud may look cheap. But the real cloud bill often starts when that data begins moving. In this episode, we break down the hidden costs behind modern Industrial IoT, manufacturing cloud, edge computing, and factory data architectures — from data egress and cross-region replication to NAT gateways, backups, dashboards, and high-frequency sensor data. A single MQTT stream from a factory can quickly become multiple data flows once telemetry is copied into storage, analytics platforms, dashboards, data science environments, disaster recovery systems, and external applications. The machine generated the data once — but your architecture may move it many times. Why Factory Cloud Costs Grow So Quickly One of the biggest mistakes in manufacturing IoT architecture is estimating data volume based on the number of machines or connected devices. The better calculation is: Samples × Bytes × Time × Assets A simple machine-state signal may generate very little data. A vibration sensor sampling at 32 kHz is completely different: a single 16-bit channel can generate roughly 5.5 GB of raw data per day before additional protocol and metadata overhead. This episode explores why an edge-first architecture can dramatically change that equation. Instead of continuously uploading every raw measurement, manufacturers can process data close to the machine, retain detailed evidence locally, detect meaningful changes, create aggregates, and send only the information required by cloud consumers.  What You'll LearnWhy cloud egress costs can become more important than storage costsHow MQTT and IoT telemetry can create multiple downstream data flowsWhy device count is a poor way to estimate factory data volumeHow vibration monitoring can generate gigabytes or terabytes of dataWhy cross-region and cross-zone traffic mattersHow NAT gateways and network routing can increase cloud costsWhy replication, backups, exports, and dashboards create additional data movementHow to identify duplicate factory data pipelinesWhen raw manufacturing data should remain at the edgeHow event filtering and aggregation reduce unnecessary cloud trafficWhy edge computing should be a processing layer rather than a miniature cloudHow to design an edge-to-cloud manufacturing architecture around business decisions rather than raw data volumeEdge Computing vs. Sending Everything to the Cloud The key architectural question isn't: “Can we send this factory data to the cloud?” It's: “What data actually earns the trip?” High-rate raw signals such as vibration waveforms, diagnostic traces, and vision data can often remain close to the factory. Filtered events and aggregates can move selectively, while production records, quality outcomes, KPIs, and cross-plant analytics are stronger candidates for centralized cloud platforms. The result is not an argument against cloud computing. It is a more deliberate IT/OT architecture in which edge and cloud have different responsibilities. Topics Covered Industrial IoT, IIoT, Edge Computing, Cloud Computing, Manufacturing Data, Factory Data, MQTT, OPC UA, Data Egress, Cloud Costs, FinOps, Azure IoT, AWS IoT, Factory Automation, Predictive Maintenance, Vibration Monitoring, Data Architecture, IT/OT Integration, Smart Manufacturing, Industry 4.0, Data Replication, Cloud Networking, Manufacturing Analytics Who Should Listen? This episode is for manufacturing IT leaders, OT engineers, cloud architects, IoT architects, data engineers, plant managers, solution architects, and industrial digitalization teams designing or operating connected factory environments. If your architecture contains a neat arrow labeled “Factory → Cloud,” this episode explains why that arrow deserves a much closer look. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Your Factory Cloud Bill Is Much Higher Than You Think
  5. há 1 dia

    From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

    What happens when AI agents start making sense of financial and business data — not just displaying it?In this episode of M365.FM, Mirko Peters talks with Rishi Sapra Microsoft MVP about the architecture required to move beyond traditional dashboards and toward AI-powered, context-aware analytics with Microsoft Fabric, Power BI, Copilot Studio, semantic models, ontologies, and data agents.Organizations already have enormous amounts of information spread across ERP systems, Excel workbooks, Power BI reports, Microsoft Fabric, SharePoint, financial systems, budgets, forecasts, and operational applications.Adding AI on top of that data does not automatically mean the AI understands the business.What does “revenue” actually mean? Which definition of margin should an AI agent use? Which KPIs represent the official version of the truth? And how does an agent understand relationships between customers, products, regions, cost centers, contracts, and business processes?The answer increasingly lies in the context layer between raw data and AI. FROM SELF-SERVICE BI TO SELF-SERVICE AI Rishi explains his journey from financial modeling and Excel through Power Query and the early days of Power BI to today's Microsoft Fabric and AI ecosystem.Power BI helped bring business intelligence out of centralized IT departments and into the hands of business users.But the platform has also become significantly more sophisticated.Semantic models, DAX, lakehouses, OneLake, Direct Lake, Copilot Studio, data agents, ontologies, MCP-based tools, governance, and AI now create an architecture that can quickly become difficult for individual business users to understand.AI agents could change that relationship.Instead of requiring every business user to become a data engineer, BI developer, and AI engineer, agents could increasingly build and operate parts of the technical architecture while humans provide the business context. WHY BUSINESS CONTEXT MATTERS FOR AI One of the central questions of the episode is surprisingly simple:How well documented are your business processes and decisions?Much of an organization's real knowledge does not live in a database. It exists inside Excel formulas, Power BI measures, SharePoint files, business processes, documentation — and people's heads.For AI agents to produce meaningful business insights, organizations need to capture more than data.They need to capture context.Who is asking the question?What decisions does that person need to make?Which KPIs matter?Which business rules apply?What does a specific metric mean in that particular context?This leads to the concept of persona-driven insights: designing analytics around the decisions and questions of specific business users rather than simply exposing more data. DATA MODELS VS SEMANTIC MODELS VS ONTOLOGIES The conversation explores three increasingly important concepts in modern Microsoft analytics architecture.A data model structures the underlying data and relationships.A Power BI semantic model adds business logic, measures, calculations, relationships, and security — creating a governed analytical layer and a reliable source for KPIs.But AI often needs more.An ontology can describe business entities and relationships in a way that allows AI to reason about concepts such as customers, products, stores, employees, regions, contracts, revenue, and business processes.Semantic models help answer:“What is the number?”Ontologies and additional context can help AI investigate:“Why did the number change?”Together, these layers provide much stronger grounding for AI agents. MICROSOFT FABRIC AS THE DATA FOUNDATION FOR AI Microsoft Fabric plays a central role in this architecture.OneLake, Lakehouses, Delta tables, semantic models, Direct Lake, Fabric Data Agents, and integration with Copilot Studio can create a unified foundation for structured and unstructured organizational data.The episode also explains why Direct Lake matters.Instead of repeatedly importing and refreshing data into traditional Power BI semantic models, Direct Lake allows Power BI to work directly with data stored in Delta format while maintaining analytical performance.This can significantly simplify the path from enterprise data to analytics and AI. THE FIVE LAYERS OF AN ORGANIZATIONAL BRAIN Rishi describes an “organizational brain” built around five interconnected layers:Data — trusted enterprise information and source systems.Logic — DAX, SQL, Python, calculations, KPIs, and business rules.Tools — semantic models, APIs, MCP servers, applications, and other capabilities agents can use.Skills — instructions and business processes describing how agents should use those tools and interpret information.Governance — permissions, policies, security, controls, and rules governing what agents are allowed to do.The goal is not simply to give an LLM access to more data.The goal is to give AI a governed environment in which it understands which data, logic, tools, and processes should be used for a particular business question. AI AGENTS NEED DETERMINISTIC DATA Generative AI is powerful because it can reason flexibly.Financial reporting cannot rely entirely on flexibility.Revenue, margins, forecasts, costs, and other business metrics often require deterministic calculations and a governed source of truth.The episode explores why the future of enterprise AI may therefore depend on combining two worlds:Deterministic computing for trusted calculations and business logic.Generative AI for reasoning, interpretation, exploration, and natural-language interaction.Semantic models and Microsoft Fabric can provide the deterministic foundation while AI agents provide the flexible reasoning layer. FROM DASHBOARDS TO PERSONALIZED INTELLIGENCE Traditional dashboards tell users what happened.A dashboard might show that revenue decreased by seven percent. The user then needs to drill through dimensions, filters, reports, and datasets to understand why.AI agents can potentially perform much of this exploration automatically.But good storytelling still requires context.The most important number is not always the largest number. A business metric may need to be interpreted relative to revenue, budget, previous periods, organizational structure, or other factors.This is where persona-driven analytics becomes particularly important.The CFO, sales leader, and operational manager may all ask about the same KPI while requiring very different explanations and actions. COPILOT STUDIO AND THE NEXT GENERATION OF AGENTS The conversation also explores the evolution of Microsoft Copilot Studio from traditional topic- and knowledge-based chatbot experiences toward more capable agentic systems.Modern agents can potentially combine tools, skills, enterprise data, workflows, and reasoning.That additional capability also introduces additional risk.The more autonomy an agent receives, the more important grounding, permissions, governance, evaluation, and clearly defined instructions become.AI agents should not invent financial numbers or arbitrarily choose data sources.They need trusted semantic models, governed data, explicit skills, and clear guardrails. MAKING GOVERNANCE GREAT AGAIN Governance becomes even more important in an agentic organization.Instead of treating governance as a document that employees are expected to read, organizations can increasingly encode governance directly into the environments, policies, skills, and instructions used by AI agents.The discussion explores the idea of treating agents more like digital employees.They need defined responsibilities, approved tools, access permissions, business rules, performance expectations, and boundaries.Governance therefore becomes less about documentation and more about automated enforcement. THE OPERATING MODEL FOR FABRIC AND AI Finally, the episode examines how organizations can manage this architecture at scale.A Center of Excellence can provide the enablement layer while a hub-and-spoke model combines centralized governance with decentralized innovation.Certified enterprise data, semantic models, logic, governance policies, and reusable skills can live in governed hubs.Business teams can experiment within their own domains and promote successful assets into the governed enterprise layer.The result is neither completely centralized nor completely decentralized.It is a federated model designed to support both control and self-service. IN THIS EPISODE We discuss Microsoft Fabric, Power BI semantic models, data modeling, ontologies, OneLake, Lakehouses, Direct Lake, Delta tables, Fabric Data Agents, Microsoft Copilot Studio, AI agents, persona-driven insights, storytelling with data, deterministic computing, enterprise AI governance, Center of Excellence models, hub-and-spoke architectures, self-service BI, self-service AI, and the idea of building an organizational brain for AI.The bigger question is no longer simply:“How do we build better dashboards?”It is:“How do we give AI enough trusted business context to understand our organization — without allowing it to invent its own version of the truth?” Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]
  6. há 1 dia

    Why Your ERP Can't Build an Optimal Production Schedule

    Your ERP can calculate production dates, explode demand through MRP, manage routings, inventory, purchase orders, and production orders. But that does not automatically mean it can create a production schedule that your factory can actually execute. In this episode, we break down the gap between ERP planning and finite production scheduling — and explain why a schedule can look perfectly reasonable in the ERP while multiple orders are competing for the same machine at the same time. THE INFINITE-CAPACITY PROBLEM Traditional ERP planning can place demand against resources without reserving finite blocks of actual machine time. This “infinite capacity” assumption is useful for demand and material planning, but it becomes a problem when planned dates are treated as executable shop-floor commitments. A capacity report may show that a machining centre has 40 hours of demand against only 16 available hours. It identifies the overload — but it does not decide which orders should run first, which should move, or how those decisions affect downstream operations. CAPACITY IS MORE THAN MACHINE HOURS Real production capacity depends on much more than a work-centre calendar. Machines have downtime. Operators have qualifications and shift patterns. Fixtures and tooling may already be occupied. Quality inspections consume resources. Maintenance removes capacity. And an eight-hour shift rarely provides eight hours of usable production time. A feasible schedule therefore has to consider the combination of machines, people, tooling, fixtures, calendars, maintenance, and process rules. WHY SEQUENCE MATTERS Production sequence can dramatically change the result. Running similar product families together might require only one major setup. Alternating between families can create repeated tool changes, cleaning, inspections, or fixture changes. The same orders on the same machine can therefore consume very different amounts of capacity depending on their sequence. THE BOTTLENECK SETS THE PACE When many orders depend on one constrained resource, keeping every upstream machine busy can actually make performance worse. More work enters the system, queues grow, WIP increases, and priorities become harder to see. Effective scheduling instead protects bottleneck capacity and controls when work is released into production. MATERIAL AVAILABLE DOESN’T MEAN READY TO RUN MRP may show that material exists, but that material could be under quality hold, reserved for another order, waiting for inspection, or incompatible with a specific batch requirement. Finite scheduling needs to combine material readiness with resource availability. A component arriving Wednesday only helps if the required machine also has a legal production slot when the material becomes usable. ROUTINGS DON’T RESERVE CAPACITY A routing tells you what comes before what. It can define cutting → machining → inspection → assembly. But a routing does not necessarily reserve the actual resource time required to execute those operations. Several orders can follow perfectly valid routings and still collide at the same machine or work centre. WHY EXCEL KEEPS SURVIVING This gap explains why planners continue using spreadsheets, whiteboards, notes, and local priority lists. They are combining information from ERP, MES, maintenance, quality, production, and their own shop-floor knowledge to create the schedule the factory actually follows. Excel is often not the root problem — it is the workaround for scheduling logic that exists outside the ERP. WHAT FINITE SCHEDULING CHANGES Finite scheduling treats production time as something that must actually be reserved. If an operation needs four hours on a machining centre, those four hours occupy a real slot. Another job cannot use the same resource during that period. The same logic can include operators, tooling, fixtures, and other required resources. When there is no legal slot, the system has to expose the conflict instead of hiding it behind another planned date. FROM FINITE SCHEDULING TO OPTIMISATION Once several feasible schedules exist, constraint-based optimisation can compare them. Should the plant minimise late orders? Reduce setup time? Protect bottleneck throughput? Avoid overtime? Reduce WIP? Keep the near-term schedule stable? There is rarely one universally “optimal” production schedule. The best schedule depends on the constraints the factory cannot violate and the business objectives it chooses to prioritise. ERP VS. MES VS. APS ERP remains essential for demand, orders, inventory, purchasing, bills of material, and transactional planning. MES provides execution truth from the shop floor. APS adds the decision layer: combining demand, materials, routings, resource availability, constraints, and current production status to create a finite, constraint-aware schedule and test alternative scenarios. IN THIS EPISODE You’ll learn why ERP schedules become overloaded, what infinite capacity really means, why bottlenecks and sequence-dependent setups matter, how material availability differs from production readiness, why planners fall back to Excel, and how finite scheduling and constraint-based optimisation turn production dates into an executable plan. The key idea is simple: ERP tells you what needs to happen. A production schedule has to prove when and where it can actually happen. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Why Your ERP Can't Build an Optimal Production Schedule
  7. há 2 dias

    Production Planning Software: When Does a Manufacturer Actually Need It?

    When does a manufacturer actually need dedicated production planning software? It is not when the company reaches a certain size. It is not when Excel suddenly becomes “unprofessional.” And it is definitely not because a software vendor showed you a beautiful Gantt chart. The real threshold comes when production complexity, constraints, and constant change become too difficult for planners to reliably coordinate through ERP dates, spreadsheets, whiteboards, calls, emails, and experience alone. In this episode, we explore the warning signs that indicate your manufacturing planning process may have reached that point. WHEN MANUAL PRODUCTION PLANNING STILL WORKS Not every manufacturer needs advanced planning software. A stable factory with predictable demand, repeatable routings, relatively few shared resources, and experienced planners may work extremely well with ERP, Excel, planning boards, and direct communication. Simple tools become a problem only when the planning environment changes faster than people can reliably evaluate the consequences.  SIX WARNING SIGNS TO WATCH We examine six signals that production planning may have outgrown its current tools: Plans change faster than people can replan. Machine breakdowns, rush orders, shortages, staffing changes, and changing customer dates create continuous replanning. Capacity exists on paper but not in reality. A machine may technically have available hours, but setups, maintenance, tooling, operator qualifications, material availability, and other constraints make that capacity unusable. The same order has different dates in different systems. ERP, MES, spreadsheets, sales, purchasing, and production may each have their own version of the expected completion date. Bottlenecks move but the plan doesn't. Today's constraint may be machining, tomorrow inspection, and next week a specific operator, tool, or downstream process. Expediting becomes the normal workflow. When almost every order becomes urgent, priorities begin replacing the production schedule. Critical dependencies live in people's heads. Experienced planners know which machines, tools, operators, routes, setups, and exceptions actually work — but the system doesn't.  ERP VS. MES VS. PRODUCTION PLANNING SOFTWARE ERP remains essential for customer orders, bills of material, inventory, purchasing, production orders, routings, and MRP. MES provides the execution reality: what started, what finished, quantities produced, machine status, quality information, and what's happening on the shop floor. But neither automatically answers the detailed scheduling question: Given the factory as it exists right now, what work should run next — and what happens to everything else if we change the sequence? That's where dedicated production planning and scheduling software can add value.  WHAT PRODUCTION PLANNING SOFTWARE SHOULD ACTUALLY DO A planning system should do more than display orders on a calendar. It should help planners create feasible schedules based on finite capacity, resource calendars, routing dependencies, setup requirements, material readiness, alternate resources, skills, tooling, maintenance windows, and current production conditions. More importantly, it should allow planners to test alternatives. If an urgent order moves forward, what gets delayed? If a machine goes down, where can the affected work move? If additional capacity becomes available, which orders benefit? If a supplier delivery slips, which customer commitments are now exposed? The goal isn't to remove human decision-making. It's to give planners better information about the consequences before they make the decision.  PLANNING, SCHEDULING, OPTIMIZATION AND SIMULATION These terms are often treated as interchangeable, but they solve different problems. Production planning asks whether demand fits available capacity over a planning horizon. Scheduling determines the actual sequence of operations and resources. Optimization compares feasible alternatives against defined objectives. Simulation lets manufacturers test possible future scenarios before changing the live production plan. Understanding which problem you're trying to solve should come before selecting software.  COMPLEXITY MATTERS MORE THAN COMPANY SIZE A large repetitive factory may have a relatively simple planning problem. A much smaller high-mix manufacturer can face enormous scheduling complexity because orders compete for shared machines, specialist operators, tools, inspection resources, alternate routings, and limited material. The need for production planning software therefore isn't primarily driven by employee count. It's driven by the number of dependencies and trade-offs planners need to evaluate — and how quickly those decisions change.  START WITH ONE DECISION Before buying an APS platform or another planning application, identify one production decision that repeatedly causes problems. For example: When two urgent orders need the same constrained machine, can we determine which sequence is feasible and understand the delivery impact before production starts? Solve that problem first. Then expand the planning model as the organization learns which data, constraints, and rules actually matter. Because the objective isn't to automate the planner. It's to stop skilled planners from spending their day manually doing work that a planning system should already be helping them calculate. Production Planning Software: When Does a Manufacturer Actually Need It? explores where that boundary lies — and how manufacturers can recognize it before buying another platform. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Production Planning Software: When Does a Manufacturer Actually Need It?
  8. há 2 dias

    Can You Simulate Your Factory Before Changing It?

    What happens when you change a factory before you know how the rest of the production system will react? Adding a shift, buying a new machine, reducing buffers, changing staffing, or accepting a different product mix can look like obvious solutions. But factories are interconnected systems. Improving capacity at one resource can simply move the bottleneck somewhere else. In this episode, we explore factory simulation, production planning, Digital Twins, finite capacity, bottleneck management, and manufacturing optimization — and how manufacturers can test operational changes before introducing them on the real shop floor. WHY FACTORY CHANGES ARE HARD TO PREDICT More machine hours do not automatically mean more customer orders shipped. An additional shift may increase machining capacity while assembly, inspection, material handling, maintenance, or qualified labor remain constrained. The result can be higher utilization at one work center while queues simply grow somewhere downstream. This is why production decisions need to consider the entire manufacturing flow, rather than optimizing individual machines in isolation. WHAT FACTORY SIMULATION ACTUALLY MEANS Factory simulation does not have to mean an expensive 3D visualization of an entire plant. A useful simulation models how orders move through production over time. It can represent:Routings and production sequencesMachine and labor capacityShift calendars and maintenance windowsSetup and changeover timesMaterial availabilityQueues and WIPQuality holds and inspectionsLabor skills and qualificationsBatch rulesDowntime and disruptionsDispatching and priority rulesThis allows manufacturers to test an extra shift without scheduling it, evaluate a machine before buying it, change buffer levels without disrupting production, or simulate a different product mix before customer orders are affected. ERP VS MES VS FACTORY SIMULATION ERP provides the commercial and production plan: demand, quantities, due dates, materials, routings, and planned capacity. MES provides evidence about what actually happened during production. Simulation adds another layer: What could happen if we change something? A work center may appear to have sufficient capacity in ERP while the real shop floor is constrained by setups, tooling, operator qualifications, material availability, inspection, or sequencing. MES history can help make simulation assumptions realistic, but historical data alone cannot answer what happens after a future shift change, capacity investment, or different dispatching rule. FROM FACTORY DATA TO A DIGITAL TWIN Data describes events. A factory model describes behavior. A useful Digital Twin connects products, processes, resources, people, tools, materials, quality conditions, and operating rules. It can represent the current production state and provide the starting point for testing alternative scenarios. The goal is not a perfect virtual copy of every object in the factory. The goal is a model accurate enough to support a real operational decision. TEST CAPACITY BEFORE BUYING CAPACITY Before investing in another machine, manufacturers can simulate alternatives such as: New machine → faster cycle time → additional shift → alternate resource → subcontracting → different sequencing rules. The important question is not simply whether machine capacity increases. It is whether throughput, lead time, queue behavior, and on-time delivery actually improve. A new machine may increase upstream output while creating an even larger queue at inspection or assembly. PEOPLE ARE PART OF FINITE CAPACITY Ten employees on a shift do not necessarily represent ten interchangeable units of capacity. Production may depend on specific operators who can perform setups, approve first-off parts, operate specialist equipment, or complete regulated processes. That means realistic manufacturing simulation needs to consider skills, certifications, shift coverage, supervision, support functions, and qualification constraints, not just headcount. PRODUCT MIX AND SEQUENCING MATTER Two production plans can contain the same number of orders and still create completely different factory loads. Different product families can require different cycle times, setups, tools, inspections, skills, and rework capacity. Average capacity figures can therefore hide the constraints that actually determine delivery performance. Sequence matters too. Grouping similar products can reduce changeovers, while prioritizing due dates may improve selected customer commitments but increase setup time. Factory simulation lets planners compare those rules against the same demand instead of relying only on averages. START SMALL You don't need to simulate the entire factory. Start with one decision, one constrained production area, and one measurable outcome. For example: If we add a late shift at this machining cell, can we improve due-date performance without creating an unmanageable queue at the next operation? Once the model reproduces normal production behavior credibly, alternative scenarios can be tested against that baseline. expensive capacity investment. This episode is for production planners, manufacturing leaders, operations managers, plant managers, industrial engineers, data teams, and anyone working with ERP, MES, APS, Digital Twins, or smart manufacturing. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Can You Simulate Your Factory Before Changing It?

Classificações e avaliações

5
de 5
3 avaliações

Sobre

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.

Você também pode gostar de