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. قبل ١٤ ساعة

    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
  2. قبل يوم واحد

    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]
  3. قبل يوم واحد

    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
  4. قبل يوم واحد

    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?
  5. قبل يوم واحد

    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?
  6. قبل يومين

    APS Software vs. ERP: What's the Difference?

    Manufacturers often rely on ERP systems to manage orders, materials, inventory, purchasing, production orders, and financial transactions. But when a machine goes down, an urgent customer order arrives, or a critical operator is unavailable, a different question suddenly matters: Can the production plan actually run? That is where APS — Advanced Planning and Scheduling — differs fundamentally from ERP. ERP records and governs the business transaction. APS tests whether production can execute the plan under the real constraints of the factory. In this episode, we take a detailed look at APS software vs. ERP, why traditional ERP planning can create a false sense of certainty, and when manufacturers should consider adding finite-capacity scheduling to their production planning architecture. ERP VS. APS: TWO DIFFERENT QUESTIONS An ERP system provides the commercial and transactional backbone of manufacturing. It manages customer demand, bills of materials, routings, inventory, purchasing, production orders, costing, traceability, and financial records. APS looks at those same production requirements from another perspective: ERP asks: What needs to be produced? APS asks: Given our machines, people, materials, tools, calendars, setup rules, and existing workload, what can we actually produce — and when? That distinction becomes critical when several orders compete for the same constrained resources. WHY ERP DATES AREN’T ALWAYS A FEASIBLE SCHEDULE A production order can have a perfectly valid start date, finish date, routing, material list, and due date in ERP. That does not mean an empty machine exists at the required time. Traditional ERP and MRP planning often works with standard lead times, work-center capacity, calendars, and broader planning buckets. These assumptions are extremely useful for enterprise planning, material requirements planning, purchasing, and production control. But the real factory operates with much more specific constraints. A machine may already be occupied. The required operator may not be on shift. Material may technically be in inventory but still waiting for quality inspection. A fixture may be used somewhere else. Changing from one product family to another may require a long setup or cleaning process. This is the gap between a planned date and a feasible production schedule. WHAT APS SOFTWARE ADDS Advanced Planning and Scheduling software brings those physical constraints directly into the scheduling calculation. Instead of simply assigning work to dates, APS can consider finite machine capacity, resource calendars, operator qualifications, tools and fixtures, setup matrices, alternate machines, material readiness, maintenance windows, routing dependencies, campaign rules, changeovers, and production priorities. If a machine only has six available hours, a finite-capacity schedule cannot simply place ten hours of work into that shift and pretend the problem has disappeared. Something has to change. The order may move to another resource. Another order may be delayed. Overtime may be required. The production sequence may change. Or the customer promise may simply be impossible under the current constraints. APS makes those trade-offs visible before production discovers them. FINITE CAPACITY SCHEDULING AND OPTIMIZATION A major difference between APS and traditional production planning is finite capacity scheduling. But creating a feasible schedule is only the first step. A schedule can respect every physical constraint and still be commercially undesirable. Manufacturers may want to optimize for different objectives, including: On-time delivery, higher throughput, reduced setup time, lower work in process, bottleneck utilization, schedule stability, reduced changeovers, or protection of strategic customer orders. There is rarely one universally “best” production schedule. APS can calculate alternatives and expose their consequences. The business still has to determine which objectives matter most. WHAT HAPPENS WHEN A MACHINE GOES DOWN? The difference becomes particularly visible during disruptions. Imagine a critical machine fails on Monday morning while Sales simultaneously asks production to expedite an important customer order. ERP can show the production order, material availability, planned dates, purchasing status, inventory position, and customer commitment. But planners still need answers to operational questions. Can the order move to another machine? Does that machine require a different setup? Is the qualified operator available? Which existing orders would move? Would protecting this order create another late order downstream? Does the alternate machine become the new bottleneck? APS allows planners to test these scenarios against the current constraints instead of rebuilding the entire production sequence manually.  ERP, APS AND MES: WHO DOES WHAT? ERP and APS are not the only systems involved. A useful manufacturing architecture separates business transactions, planning decisions, and execution facts. ERP answers what the customer ordered, what supply is required, and which business transactions need to be controlled. APS determines what sequence is feasible under the available resources and constraints. MES captures what is actually happening on the shop floor. This creates a closed planning loop. ERP provides demand and governed business data. APS creates the constraint-aware production schedule. MES reports actual starts, completions, downtime, quantities, scrap, and other execution events. Those execution facts can then update the planning picture, while the corresponding governed transactions flow back into ERP. ONE SOURCE OF RECORD DOESN’T MEAN ONE SYSTEM DOES EVERYTHING Trying to make one platform own every manufacturing decision usually creates more problems than it solves. ERP should remain the source of record for commercial and supply transactions. MES should capture execution facts close to production. APS should own the constrained scheduling view and planning scenarios. This also explains why different systems may legitimately show different dates. ERP may contain the contractual due date, APS the currently feasible completion date, and MES an expected completion based on actual production progress. The important question is not whether every date is identical. It is whether everyone understands what each date means and who owns the decision to change it. WHY GOOD DATA MATTERS MORE THAN THE APS ALGORITHM Installing APS does not automatically fix production planning. The scheduling engine needs accurate information about how production really operates. Resource calendars must reflect actual shifts and maintenance. Routing data must identify usable resources. Setup rules need to reflect real changeovers. Labor qualifications, tools, fixtures, material readiness, alternate resources, and other restrictions must be modeled where they materially affect scheduling. A sophisticated optimizer using inaccurate constraints simply produces an inaccurate schedule faster. This is why APS implementations often expose something important: manufacturing knowledge that previously existed only inside the planner’s head or in spreadsheets. If the same manual workaround occurs every week, it is probably no longer an exception. It has become undocumented production logic. A practical APS implementation can therefore begin with one bottleneck, one product family, or one constrained planning horizon instead of trying to model the entire factory immediately. WHY EXCEL SURVIVES MANUFACTURING PLANNING Excel remains popular because planners can quickly change assumptions, add missing information, and understand exactly why a calculation changed. The problem is not necessarily the spreadsheet itself. The risk appears when the spreadsheet becomes the only place where the real production logic exists. If critical setup rules, priorities, capacity assumptions, or resource restrictions live exclusively inside one planner’s workbook, the organization has created an unofficial planning system. Understanding those spreadsheets can actually be an important step toward designing a better APS implementation. WHEN ERP SCHEDULING MAY BE ENOUGH Not every manufacturer needs dedicated APS software. ERP scheduling may be sufficient when production routes are stable, product variety is manageable, demand is relatively predictable, capacity headroom exists, setup complexity is low, alternate routing is limited, and disruptions do not constantly force planners to rebuild the schedule. In those environments, rough-cut capacity planning, basic finite scheduling, and strong planner routines may provide enough control. Adding another specialized system would then introduce integration, data preparation, training, and operational overhead without necessarily producing enough additional value. WHEN DEDICATED APS BECOMES IMPORTANT The case for APS becomes stronger when multiple orders constantly compete for shared bottlenecks and the production sequence itself changes available capacity. Typical signals include frequent rescheduling, complex setups and changeovers, scarce tools or fixtures, qualified-labor constraints, alternate resources with different processing times, material timing problems, frequent disruptions, multi-stage dependencies, customer-expedite requests, or planners spending large amounts of time manually rebuilding schedules. At that point, the real requirement is not simply “better planning software.” It is the ability to calculate the consequences of a decision before committing production or promising a customer date. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    APS Software vs. ERP: What's the Difference?
  7. قبل يومين

    Constraint-Based Scheduling: The Architecture That Makes Production Plans Real

    Your ERP says the customer order ships on Friday. The work order is released. The routing looks correct. Capacity appears available. Everything looks fine in the planning report. Then Monday morning arrives. A critical five-axis machining center goes down. One order is already in production. Another is waiting for material. A third could theoretically move to another machine — but only if the shared fixture is available, the correct program is approved, and a qualified operator is working that shift. The ERP plan still says Friday. But a date in ERP does not automatically mean the factory can physically deliver it. In this episode, we explore constraint-based production scheduling and the difference between a production plan that describes what the business wants and a finite production schedule that reflects what the factory can actually execute. Using a hypothetical precision-machining plant, we follow production demand from ERP through routings, machines, tooling, fixtures, labor, material, quality, MES, maintenance, and shop-floor events — and examine how a scheduling engine can combine these constraints into an achievable production schedule. WHEN THE PRODUCTION PLAN MEETS THE PHYSICAL FACTORY Production planning often begins with demand. Customers need products. Orders have quantities. Orders have due dates. ERP translates that demand into work orders, material requirements, routings, and broad capacity requirements. That is essential. But it is not the same as answering the question production needs answered every day: What can we actually run next? A production plan may reserve eight hours in a machining work center. The physical factory needs to know which machine will provide those eight hours. Is that machine available? Can it produce this exact part revision? Does it have the correct tooling? Is the fixture available? Has the material been released? Is the required operator qualification available during the planned setup? Will the order finish early enough to reach the next production step? Constraint-based scheduling takes the demand the business wants fulfilled and tests it against the conditions that actually exist in production. PRODUCTION PLAN VS. PRODUCTION SCHEDULE Production planning and production scheduling are closely related, but they answer different questions. A production plan focuses on demand, dates, quantities, materials, and broad capacity requirements. A production schedule goes deeper. It assigns an operation to a real resource, at a real time, in a real sequence. This distinction becomes especially important when planning systems use infinite capacity. An infinite-capacity plan can place more work into a time period than the physical factory can execute. Two urgent orders can both appear to require the same machine at the same time. On paper, both remain urgent. On the factory floor, one spindle can still run only one operation at a time. Finite capacity scheduling forces the conflict into the open. It accounts for resource calendars, maintenance, setup time, fixtures, tooling and other limitations rather than assuming the work center can absorb whatever demand is assigned to it. FINITE CAPACITY DOESN’T CREATE CAPACITY This is an important distinction. Finite capacity scheduling does not magically create another machine. It does not make material arrive earlier. It does not qualify another operator. It does not repair equipment. Instead, it exposes conflicts before production discovers them through delays, expediting, overtime, and customer escalations. Suppose two customer orders require the same five-axis machine. Both are urgent. Both have tight delivery dates. An infinite plan can put both into the same capacity bucket. A finite schedule must make a decision. One goes first. The other follows. Or one moves to an approved alternative. Or one becomes late. That can make the production schedule look worse than the ERP plan. But the schedule did not create the problem. The physical constraint already existed. The schedule simply made it visible. WHAT IS A PRODUCTION CONSTRAINT? A constraint is a condition that must be respected when production work is placed into time. Some constraints are hard. They cannot simply be ignored because an order is urgent. A machine cannot perform an operation if it lacks the required capability. A fixture cannot be attached to two machines simultaneously. Material on quality hold cannot be consumed. An operator without the required certification cannot perform a controlled setup. A maintenance window removes usable machine capacity. An operation cannot start before the required previous operation has produced the necessary output. Other constraints are soft. They represent preferences or business objectives. You may prefer fewer setups. You may want to minimize overtime. You may want to reduce Work in Progress. You may prioritize contractual customer dates. You may want to keep a bottleneck continuously productive. A useful scheduling principle is therefore: Feasibility first. Optimization second. First determine what production can physically and operationally execute. Then determine which feasible option best supports the business objectives. DUE DATE IS NOT THE SAME AS PRIORITY Production scheduling becomes especially interesting when several orders compete for the same resources. A due date tells you when something should finish. It does not automatically tell you the best sequence. An urgent order might require a long setup. Another order might already have material staged and use the machine's current setup. A third order might need to finish immediately because it must reach a batch process before a cutoff. Simply sorting the production queue by due date ignores these relationships. Constraint-based scheduling evaluates the complete production context. That makes priorities explicit instead of leaving them to whoever calls the planner first. ROUTINGS AND OPERATION DEPENDENCIES A production order is not a single block of work. It moves through operations. In the example explored in this episode, a machined housing needs five-axis milling, followed by heat treatment, inspection, and assembly. Those operations depend on each other. If milling finishes late, the problem does not necessarily remain in machining. The order may miss the next heat-treatment batch. That delay can move inspection. Inspection can move assembly. Assembly can move the final delivery date. This is why constraint-based scheduling needs to understand operation dependencies, not just individual machine utilization. The schedule needs to model the flow of production. MATERIAL AVAILABILITY IS MORE THAN INVENTORY A planning system might show that material exists. But can production actually consume it? Those are different questions. Material might physically be inside the factory while still waiting for incoming inspection. It may be allocated to another production order. It may be quarantined. It may require a customer-specific certificate. It may belong to the correct material grade but the wrong approved lot. A useful scheduling question is therefore not simply: “Do we have material?” It is: “Can this operation consume this approved material at this planned time?” If the answer is no, the operation is not ready — even if the machine is available. The episode shows how material and quality gates become time-based production constraints rather than simple inventory attributes. MACHINE CAPABILITY VS. MACHINE AVAILABILITY Another machine may have open capacity. That does not automatically make it an alternative. The resource must be capable of performing the operation. It may need the correct working envelope. Tolerance capability may matter. A specific controller or approved program may be required. Customer approval may restrict the operation to particular machines. Different machines that belong to the same ERP work center may therefore provide completely different executable capacity. Spare time does not create capability. This becomes critical after a machine breakdown. The scheduler cannot simply search for another empty slot. It needs to search for another valid production path. MACHINE STATE AND TRUSTWORTHY AVAILABILITY Machine data creates another challenge. Modern manufacturing equipment can produce enormous numbers of signals. Running. Idle. Stopped. Setup. Fault. Temperature changes. Vibration changes. Cycle completion. Door states. Warnings. But the production scheduler does not need every PLC signal. It needs an operational interpretation of those signals. A brief stop may require no planning response. A confirmed outage that removes several hours from a bottleneck resource probably does. The scheduling architecture therefore needs to transform raw shop-floor events into trusted capacity decisions. Real-time manufacturing does not mean every sensor event should instantly rebuild the production schedule. It means the right event reaches the scheduling decision loop before the decision window closes. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    Constraint-Based Scheduling: The Architecture That Makes Production Plans Real
  8. قبل يومين

    A Machine Goes Down. How Should Your Production Plan React?

    A machine goes down. Maintenance receives the alarm. The operator stops production. The MES records an interrupted operation. But your ERP may still believe that the machine has capacity. And your production schedule may still promise that every order will be completed on time. That is where a machine breakdown stops being only a maintenance problem and becomes a production planning problem. In this episode, we explore what should actually happen to a production plan when a critical machine becomes unavailable — from detecting the disruption and estimating lost capacity to identifying affected orders, evaluating alternative resources, rescheduling with finite capacity, and releasing a production plan the factory can actually execute. NOT EVERY MACHINE STOP REQUIRES REPLANNING Modern factories generate enormous numbers of operational signals. PLCs report faults. IoT systems detect machine-state changes. MES platforms track interrupted operations. Maintenance systems record incidents. But a machine stopping for a few minutes does not automatically mean the entire production schedule should change. A short interruption might be caused by an operator clearing a jam. It might be a normal tool change. The machine could simply be waiting for material. Or a sensor could report a state that does not represent the actual production situation. The important distinction is between a machine signal and a planning event. A production plan should react when the interruption creates a meaningful loss of capacity that normal shop-floor recovery can no longer absorb. That threshold depends on the production environment. A ten-minute stop on a resource surrounded by large buffers may have almost no impact. The same ten-minute interruption on a bottleneck resource producing a make-to-order component with a tight customer deadline could require immediate attention. Good production planning therefore does not react to every signal. It reacts to operational consequences. HOW LONG WILL THE MACHINE REALLY BE DOWN? Once downtime becomes significant enough to affect production, one question becomes critical: How long will the capacity be unavailable? Unfortunately, maintenance rarely knows the exact answer immediately. A technician may know that a drive has failed but not whether a reset will solve the problem, whether a component needs replacement, or whether additional safety checks will be required. Production planning should therefore avoid building an entire schedule around an uncertain repair timestamp. Instead, planners can work with a recovery window and confidence level. For example: A short outage may require no schedule change. A medium outage may require selected orders to move. A full-shift outage may require active rescheduling. A longer outage may threaten customer commitments and require escalation. This turns maintenance information into a useful planning input without pretending that an early repair estimate is a guarantee. A MACHINE IS MORE THAN AVAILABLE HOURS One of the biggest mistakes in production planning is assuming that another machine with an empty calendar automatically provides replacement capacity. It does not. A resource needs the correct capability. The right fixture may be required. A qualified production program may need to exist. An operator with the necessary skills must be available. Quality may need to approve the alternate process. Material needs to be physically available. Tooling and inspection capacity may also be required. This creates an important distinction: Machine availability is not the same as executable production capacity. An empty four-hour window on another machine means very little if the product cannot actually be produced there. Production planning therefore needs a model connecting Product, Process and Resource. The product defines what needs to be manufactured. The process defines the operations required. The resource defines where those operations can actually run and under which constraints. That context becomes essential when production is disrupted. WHICH ORDERS ARE ACTUALLY AFFECTED? Once a machine failure is confirmed, planners need to identify the work that genuinely depends on that resource. Start with the order currently running. How much has already been completed? What quantity remains? Can the partially processed material safely wait? Does interrupted work require inspection, rework, or scrap approval? Then examine the queue. Which orders are physically waiting? Which orders are released? Which ones have tight downstream dependencies? Which have alternative routings? Which rely exclusively on the failed resource? Not every order scheduled on the machine carries the same risk. Some may easily move. Others may have enough delivery buffer to wait. Some may depend on a customer shipment. Others may feed a critical assembly operation. And some may have no realistic alternative at all. The goal is not to declare every order an emergency. The goal is to identify real production exposure. THE BOTTLENECK CAN MOVE Suppose Machine 4 fails. Machine 6 has available capacity. Moving urgent orders to Machine 6 appears to solve the problem. But what happens next? Perhaps Machine 6 feeds an inspection station that is already operating near capacity. The orders move successfully — and simply create another queue somewhere else. A machine breakdown can therefore move the production constraint. The new bottleneck could become another machine, an inspection station, a qualified operator, a furnace, a fixture, a transport resource, or even a tool. This is why production planners need to evaluate the entire local production flow, not simply find another empty machine slot. Moving work can move the problem. A good rescheduling decision considers what happens downstream and upstream after every significant schedule change. WHAT SHOULD THE PRODUCTION PLAN PROTECT? When capacity disappears, not every order can necessarily remain exactly where it was. Production therefore needs clear priorities. Customer delivery commitments matter. But so do internal milestones. Safety stock can matter. Material shelf life can matter. Campaign rules can matter. Setup costs can matter. Quality requirements can matter. An urgent-looking order may require a long changeover and material that has not yet arrived. Another order with a slightly later due date may already have material staged and require almost no setup. Blindly sorting everything by due date can therefore produce a worse production schedule. Priority rules should exist before the machine breaks down. Otherwise, disruption planning becomes a competition between whoever calls first, whoever complains loudest, and whoever has the most senior manager copied into an email. Production planning needs policy, not panic.  POSSIBLE CAPACITY VS EXECUTABLE CAPACITY Before moving an order to another resource, planners need to test the full chain of constraints. Can the machine technically perform the operation? Is the tooling available? Is a qualified operator available? Is the material physically ready? Has quality approved the alternative? Does the production sequence allow the change? Are batch rules respected? Does shelf life create another time constraint? Has maintenance actually released the resource for production? A resource can be theoretically capable without being operationally available. This distinction between a possible move and an executable move is fundamental to realistic manufacturing scheduling. A possible move says that another machine could perform the operation. An executable move means that machine, tooling, operator, material, process approval, sequence, safety requirements, and available time all align. Only then does that empty slot become real capacity. BUILD SCENARIOS INSTEAD OF SEARCHING FOR ONE PERFECT ANSWER Machine downtime introduces uncertainty. Trying to calculate one perfect replacement schedule can therefore create false confidence. A better approach is to generate a small number of realistic response scenarios. One scenario might keep the work on the failed resource and wait for repair. Another might move selected orders to approved alternative resources. A third could use overtime or an additional shift. Another possibility might involve splitting an order where production and quality rules permit it. Each scenario should explain: What changes? Which orders move? Which customer commitments are protected? Which setups are added? Which resources are required? What assumptions does the scenario depend on? And what happens if the repair takes longer? The objective is not to create dozens of simulations. Usually, production needs a preferred response, a fallback, and perhaps a more aggressive option if delivery risk becomes unacceptable.  WHY EXCEL REPLANNING BREAKS UNDER PRESSURE Excel remains extremely useful for local analysis. But problems begin when the spreadsheet becomes the new production schedule while the actual production environment continues changing elsewhere. Maintenance updates the repair estimate. A supervisor moves an order. Customer service changes a priority. MES records new production progress. Material moves. Another resource becomes unavailable. Suddenly several people have several different versions of the production plan. And everyone believes their version is correct. Then come the familiar filenames: Final. Final_v2. Final_v2_revised. The factory version of archaeology. The underlying problem is not Excel itself. The problem is the absence of a shared, controlled source of truth. Production needs one released schedule that clearly shows which facts were used, which orders changed, when the schedule was calculated, and which version the shop floor should actually execute. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

    A Machine Goes Down. How Should Your Production Plan React?

التقييمات والمراجعات

٥
من ٥
‫٣ من التقييمات‬

حول

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.

قد يعجبك أيضًا