エピソード

  • Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]

    Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]
    2026/09/24
    Microsoft 365 Copilot can help people find information and get work done faster, but its answers depend on the content and permissions already in an organization’s Microsoft 365 tenant. In this episode of the M365 FM podcast, Mirko Peters speaks with Microsoft MVP Paul Keijzers, founder of KB Works, about preparing Microsoft 365 for Copilot in a practical, responsible way. They look beyond demos and licensing to the foundations that shape Copilot results: SharePoint, Microsoft Teams, OneDrive, data quality, access controls and governance. Copilot can make existing access issues more visible. Files that have been shared broadly, outdated documents, old versions and content with unclear ownership may all affect what employees can find. Paul explains why organizations should review their sharing settings and understand where sensitive or unnecessary access exists before rolling Copilot out widely. SharePoint oversharing reports can help identify potential issues across SharePoint, Teams and OneDrive, although organizations still need to check whether flagged sharing is appropriate for their business.

    GOVERNANCE, LEGACY DATA AND INFORMATION PROTECTION
    The conversation explores how to manage years of legacy SharePoint content. Old project files may need to be retained for legal or business reasons, but that does not always mean they should appear in everyday search or Copilot results. Organizations can consider archiving content or restricting access, depending on how often it needs to be used and how the tenant is structured. Paul also highlights the need to plan for Microsoft 365 backup and recovery, including how a company can retrieve its data if it changes backup providers. Microsoft Purview is part of the wider governance picture. Paul recommends reviewing sensitivity labels, checking whether they are applied consistently, and considering automatic labeling where appropriate. Data Loss Prevention policies can help protect personal and sensitive information, while Power Automate DLP policies need attention when Copilot uses connectors to work with services such as Jira. These controls should fit the organization’s actual needs, since a global company and a small business may require different policies.

    SHAREPOINT STRUCTURE AND COPILOT ADOPTION
    Good information architecture remains important even as AI becomes better at understanding natural language. Paul discusses using metadata and content types to make information easier to organize and retrieve, while keeping SharePoint libraries practical for employees. His guideline is to avoid overly deep folder structures and excessive metadata fields, since people are less likely to maintain a system that is too complicated. Copilot can help suggest or populate information, but organizations still need a clear structure and reliable content. Copilot adoption also requires ongoing support. Rather than delivering a single training session and expecting employees to figure out the rest, organizations can share regular tips, demonstrate useful prompts and agents, and help teams solve real daily frustrations. Paul recommends starting with the work people actually do, then identifying where Copilot could save time or improve an outcome. Adoption plans should be adapted to the size and working practices of each organization instead of copied wholesale from a framework designed for a different environment.

    AI VALUE, AGENTS AND A PRACTICAL PATH FORWARD
    Mirko and Paul also discuss how organizations can assess the value and cost of AI, how agents may increasingly work alongside employees, and why administrators need ways to discover and manage agents in their environments. Paul shares his Focus Week concept in Portugal, where teams spend dedicated time working on Microsoft 365, SharePoint, governance or Copilot challenges away from their usual workplace interruptions. The central message for IT leaders is that Copilot readiness starts with understanding the Microsoft 365 tenant: who can access what, how information is organized, which content should be retained or surfaced, and how employees will learn to use AI in their work. Review sharing settings, improve information governance and connect adoption to real business needs before treating Copilot as simply another license to deploy.

    Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.
    続きを読む 一部表示
    55 分
  • When Microsoft Messaging Looks Secure but Isn’t — Exchange Server, Hybrid and Microsoft 365 Security with Thomas Stensitzki [MVP]

    When Microsoft Messaging Looks Secure but Isn’t — Exchange Server, Hybrid and Microsoft 365 Security with Thomas Stensitzki [MVP]
    2026/09/24
    Microsoft Exchange and Microsoft 365 make it possible to run powerful messaging environments, but moving email to the cloud does not automatically make it secure. In this episode of the M365 Show, host Mirko Peters [MVP] talks with Thomas Stensitzki [MVP] about the security gaps that can hide in Exchange Server, Exchange Online, and hybrid deployments. Drawing on more than 25 years of messaging experience, Thomas explains how identity protection, careful configuration, secure mail flow, and operational discipline work together to protect an organization’s email.FROM EXCHANGE SERVER TO HYBRID AND EXCHANGE ONLINEThomas shares how he built his career around Exchange and why email remains essential to business. He explains how a hybrid setup connects on-premises Exchange Server with Exchange Online, and why that connection needs careful planning across messaging, networking, and security teams. Microsoft 365 provides a working service with default settings, but organizations still need to configure protections such as anti-spam, anti-malware, and anti-phishing to fit their needs.IDENTITY, ADMINISTRATOR ACCESS, AND BREAK-GLASS ACCOUNTSIdentity security comes first, including for service accounts and other non-human identities. Thomas discusses sensitive Exchange administrator roles, privileged access management, and why administrators should avoid using highly privileged accounts for everyday work. He also explains how to protect emergency or “break-glass” accounts, including the role of FIDO security keys and the need to plan how administrators can regain access during an outage.LEGACY SMTP, PHISHING, AND COMPROMISED ACCOUNTSOlder applications and devices may still depend on basic authentication or legacy SMTP. Thomas recommends avoiding those methods where possible and describes how an on-premises relay can help route messages from systems that cannot use modern authentication. The conversation also follows a potential attack path from a malicious email to stolen credentials and unauthorized access, highlighting the value of email filtering, separate administrative accounts, and monitoring sign-in activity.MAIL FLOW, SPF, DKIM, AND DMARCUnderstanding the full route an email takes is essential, especially in complex environments that combine gateways, Exchange Server, Exchange Online Protection, and Microsoft Defender. Thomas explains the roles of SPF, DKIM, and DMARC in authenticating messages sent from an organization’s domain. He also recommends using dedicated subdomains for third-party services such as marketing platforms and CRM systems, and using DMARC reports to identify legitimate and suspicious senders.MICROSOFT DEFENDER AND SECURITY MONITORINGThomas discusses Microsoft Defender for Office 365 Safe Links and how link protection can help assess a URL when a user clicks it. He also covers Entra sign-in logs, suspicious sign-ins, and impossible-travel alerts. Security tools and scores can guide decisions, but administrators still need to understand what they measure, what their licenses include, and which protections their organization actually needs.CONFIGURATION, GOVERNANCE, AND OPERATIONAL DISCIPLINEThe discussion moves beyond individual security settings to configuration management, least-privilege access for programmatic tools, and the risks of exposing Microsoft 365 content through APIs or agents. Thomas explains how configuration exports can help teams track changes. He also discusses Microsoft Purview sensitivity labels and data loss prevention (DLP), recommending that organizations plan their rollout carefully because these controls can be difficult to change once they are in production.BUSINESS CONTINUITY, AI, AND KEEPING EXCHANGE SECUREBackups alone may not be enough if an organization loses access to its Microsoft 365 tenant, domains, or configuration. Thomas stresses the importance of planning for business continuity before an incident occurs. He also considers how AI may help both defenders and attackers, and describes his consulting work helping organizations update Exchange Server environments and move to Exchange Online or hybrid configurations.RAPID-FIRE QUESTIONS AND FINAL SECURITY ADVICEIn the rapid-fire round, Thomas chooses Exchange Server, a long-term hybrid architecture, and PowerShell. He also discusses Exchange Server certificate management and recommends Manfred Huber as a future guest. His closing advice is straightforward: keep Exchange environments up to date, follow the Exchange Product Group blog, apply patches, watch for default configuration changes, and prepare for the deprecation of Exchange Web Services in Exchange Online.Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.
    続きを読む 一部表示
    1 時間 9 分
  • Content Understanding & Document AI - Simply Explained

    Content Understanding & Document AI - Simply Explained
    2026/09/18
    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.
    続きを読む 一部表示
    18 分
  • IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

    IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem
    2026/09/18
    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 LEARNIn 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 TIMETelemetry 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 RESPONSEAn 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 DOWNSending 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 DOESAzure IoT Hub provides the ...
    続きを読む 一部表示
    1 時間 50 分
  • The 5 Pillars of Data Transformation - Simply Explained

    The 5 Pillars of Data Transformation - Simply Explained
    2026/09/18
    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 LEARNIn 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 AUTOMATIONData 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 DECISIONMany 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.
    続きを読む 一部表示
    18 分
  • Your Factory Cloud Bill Is Much Higher Than You Think

    Your Factory Cloud Bill Is Much Higher Than You Think
    2026/09/17
    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 Learn
    • Why cloud egress costs can become more important than storage costs
    • How MQTT and IoT telemetry can create multiple downstream data flows
    • Why device count is a poor way to estimate factory data volume
    • How vibration monitoring can generate gigabytes or terabytes of data
    • Why cross-region and cross-zone traffic matters
    • How NAT gateways and network routing can increase cloud costs
    • Why replication, backups, exports, and dashboards create additional data movement
    • How to identify duplicate factory data pipelines
    • When raw manufacturing data should remain at the edge
    • How event filtering and aggregation reduce unnecessary cloud traffic
    • Why edge computing should be a processing layer rather than a miniature cloud
    • How to design an edge-to-cloud manufacturing architecture around business decisions rather than raw data volume
    Edge 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.
    続きを読む 一部表示
    2 時間 3 分
  • From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

    From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]
    2026/09/16
    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 AIRishi 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 AIOne 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 ONTOLOGIESThe 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 AIMicrosoft 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 BRAINRishi 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...
    続きを読む 一部表示
    1 時間 6 分
  • Why Your ERP Can't Build an Optimal Production Schedule

    Why Your ERP Can't Build an Optimal Production Schedule
    2026/09/16
    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 PROBLEMTraditional 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 HOURSReal 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 MATTERSProduction 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 PACEWhen 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 RUNMRP 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 CAPACITYA 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 SURVIVINGThis 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 CHANGESFinite 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 OPTIMISATIONOnce 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. APSERP 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 EPISODEYou’ll learn why ERP schedules become overloaded, what infinite capacity really means, why bottlenecks...
    続きを読む 一部表示
    1 時間 44 分