M365.FM - Modern work, security, and productivity with Microsoft 365

Эпизоды

• 
  Why Your ERP Can't Build an Optimal Production Schedule 16.09.2026 1ч 44мин

  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...
• 
  Production Planning Software: When Does a Manufacturer Actually Need It? 16.09.2026 1ч 47мин

  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 WORKSNot 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 WATCHWe 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 SOFTWAREERP 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 DOA 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 SIMULATIONThese 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...
• 
  Can You Simulate Your Factory Before Changing It? 16.09.2026 1ч 56мин

  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 PREDICTMore 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 MEANSFactory 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 SIMULATIONERP 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 TWINData 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 CAPACITYBefore 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 CAPACITYTen 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...
• 
  APS Software vs. ERP: What's the Difference? 15.09.2026 1ч 33мин

  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 QUESTIONSAn 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 SCHEDULEA 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 ADDSAdvanced 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 OPTIMIZATIONA 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....
• 
  Constraint-Based Scheduling: The Architecture That Makes Production Plans Real 15.09.2026 1ч 51мин

  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 FACTORYProduction 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 SCHEDULEProduction 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 CAPACITYThis 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...
• 
  A Machine Goes Down. How Should Your Production Plan React? 15.09.2026 1ч 41мин

  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 REPLANNINGModern 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 HOURSOne 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...
• 
  Can Value Stream Mapping Become a Live Data Model? 15.09.2026 1ч 48мин

  Value Stream Mapping has been one of the most useful tools in Lean Manufacturing for understanding how material, information, and decisions move through a production system.But traditional Value Stream Mapping has a fundamental limitation.The factory keeps changing. The map does not.You can bring production, planning, quality, maintenance, supply chain, and operations into the same workshop. You can map cycle times, queues, batch sizes, handoffs, waiting times, information flows, and bottlenecks. At the end of the workshop, everyone may finally share the same picture of how the production system works.Then reality changes.A supplier shipment arrives late. A customer places an urgent order. A machine goes down. Quality blocks a batch. Maintenance removes a resource from production. A setup takes longer than expected. Material waits in the wrong location.The Value Stream Map hanging on the wall still describes yesterday's factory.So what if a Value Stream Map could become something more?In this episode, we explore how Value Stream Mapping could evolve from a static Lean Manufacturing document into a live manufacturing data model connected to ERP, MES, quality, maintenance, machine, and shop-floor data.The goal is not simply to digitize a Value Stream Map.The goal is to create a model that continuously reflects how production actually behaves.THE PROBLEM WITH STATIC VALUE STREAM MAPPINGTraditional Value Stream Mapping captures an important snapshot of a production system.It helps teams understand the sequence of processes required to produce a product, but its real value goes much further than drawing boxes and arrows.A Value Stream Map can describe processing times, waiting times, queues, inventory, batch sizes, changeovers, information flows, replenishment signals, production control rules, and handoffs between different parts of the organization.That makes Value Stream Mapping extremely useful for understanding flow.But production is dynamic.The conditions captured during a workshop may already be different several days later.Demand changes.Resources become unavailable.Orders receive different priorities.Quality issues create rework.Material arrives late.Production schedules change.Actual cycle times differ from planning assumptions.These changes affect the real flow of production, but they are usually not reflected automatically in the Value Stream Map.This creates an interesting question for modern manufacturing:Can Value Stream Mapping become a continuously updated model of the factory?FROM VALUE STREAM MAP TO LIVE DATA MODELA live Value Stream Model would be fundamentally different from simply putting a traditional Value Stream Map on a screen.Digitizing a diagram is relatively easy.Creating a model that understands the relationships between orders, operations, resources, materials, constraints, events, and production states is much harder.A live manufacturing model needs to understand questions such as:Where is an order right now?Which operation was completed last?What should happen next?Which resource is required?Is that resource actually available?Is material waiting?Is quality blocking production?Has maintenance reduced available capacity?Is the order waiting because of a physical constraint or because of an information delay?And most importantly:What evidence proves the current state of production?This moves Value Stream Mapping from documentation toward operational intelligence.ONE ORDER, MANY MANUFACTURING SYSTEMSConsider a make-to-order manufacturing environment.A customer order enters the business with a required delivery date.ERP creates the sales order, generates production requirements, checks material availability, and provides routing information describing the expected sequence of operations.But ERP only provides part of the picture.On the factory floor, the Manufacturing Execution System may dispatch work, record operator confirmations, track...
• 
  How Finite Capacity Scheduling Actually Works in Manufacturing 14.09.2026 1ч 54мин

  Your ERP says the production order should finish next Thursday. The routing looks correct. Material is planned. Everything appears under control. Then you walk onto the shop floor and discover the machine is already overloaded, the required operator is booked elsewhere, the fixture is in use, or the material exists in ERP but has not actually been inspected and released. That is the gap between planning demand and scheduling reality. In this deep dive, we break down how finite capacity scheduling actually works in manufacturing — from ERP and MRP planning to a schedule that accounts for the physical constraints of machines, people, tools, materials, quality gates, maintenance and time.INFINITE VS. FINITE CAPACITY PLANNINGInfinite capacity planning has an important purpose. ERP and MRP systems can quickly calculate demand, material requirements, planned orders and dates across thousands of products and long planning horizons. But a planned date does not prove that the factory has enough usable capacity to execute the work. Finite scheduling asks the harder question: Can this operation actually run at this time, on this resource, with everything required to execute it? That means looking beyond calendar hours to usable capacity and considering machines, qualified people, tooling, fixtures, released material and process conditions.FROM PRODUCTION ORDER TO SCHEDULED OPERATIONSA production order cannot simply be treated as one block between a start and finish date. A finite scheduler breaks the order into individual operations and calculates setup time, runtime, waiting and transfer time before searching for eligible resources and available slots. Once an operation occupies a slot, that capacity is no longer available to another order. Delays can therefore propagate through subsequent operations and expose a late order before it reaches the shop floor.FORWARD VS. BACKWARD SCHEDULINGWe examine the two fundamental scheduling perspectives. Forward scheduling asks: Given what is ready now and the capacity we actually have, when can this order realistically finish? Backward scheduling starts with the requested delivery date and asks: When must every preceding operation happen for us to keep this promise? Comparing the two can expose the critical decision gap between the customer promise and what current production conditions can actually deliver.SEQUENCING, BOTTLENECKS AND CHANGEOVERSHaving enough capacity somewhere in the calendar does not automatically tell you which order should run next. We explore competing sequencing strategies including due-date priority, customer priority, shortest processing time, critical ratio and campaign-based sequencing. Changeovers are especially important. Switching fixtures, tools, programs, materials or product families consumes real bottleneck capacity. A schedule that ignores sequence-dependent setup time can look feasible while being impossible to execute.MATERIAL, PEOPLE, TOOLS AND QUALITY ARE CAPACITY TOOA free machine does not necessarily mean an operation can start. Material may still be awaiting inspection. The qualified operator may work another shift. A fixture may be installed on another machine. A gauge may require calibration. Quality may need to approve the first piece. Finite scheduling therefore becomes a model of relationships between products, operations, resources, skills, tooling, materials and process rules, rather than simply a machine calendar.WHAT HAPPENS WHEN THE PLAN BREAKS?Machines fail. Materials arrive late. Operators become unavailable. Quality holds appear. Priorities change. A useful finite schedule should respond without constantly reshuffling the entire factory. We discuss rescheduling, protected or “freeze” zones, schedule nervousness and how planners can evaluate alternative scenarios instead of blindly accepting a completely regenerated schedule. The...
• 
  Why Your Critical Path Changes When Production Changes 14.09.2026 1ч 51мин

  A production plan can look perfectly reasonable — until production actually starts.One machine runs late. A material release slips. A qualified operator becomes unavailable. A quality inspection takes longer than expected. A batch misses its furnace window. Suddenly, a delay of only a few hours can put an entire customer delivery at risk.In this deep dive, we explore how the Critical Path Method (CPM) can be adapted from traditional project management to modern manufacturing and production planning.The central idea is simple: the critical path in manufacturing should not be treated as a fixed sequence created when the production order was released.Instead, manufacturers need to understand the live chain of dependencies that currently determines the earliest possible completion and shipment date.That chain can change throughout the production day.A machine breakdown may initially be the problem. Once the machine recovers, however, the critical dependency could move to a furnace slot, a qualified operator, an inspection queue, a missing fixture, a quality release, or even the carrier cutoff at the end of the process.This episode examines how manufacturers can connect production orders, machines, materials, people, quality states, ERP, MES, IoT, and shop-floor events into a dependency model capable of supporting more dynamic production scheduling.WHY CRITICAL PATH METHOD MATTERS IN MANUFACTURINGCritical Path Method is normally associated with project management.A project contains tasks with durations and dependencies. Some activities can run in parallel, while others cannot begin until previous work has finished.The critical path represents the sequence of dependent activities that determines the earliest possible project completion date.Manufacturing has many of the same characteristics.A released production order contains operations that need to happen in a particular sequence. Those operations can depend on:Machine availabilityMaterial availabilityQualified operatorsFixtures and toolingInspection resultsQuality releasesBatch windowsMaintenance schedulesShift calendarsProcess approvalsDownstream capacityPacking and dispatch requirementsThat effectively turns the production order into a dependency network.But manufacturing introduces an additional challenge: production orders don't operate independently.They compete for shared machines, people, tools, test equipment, forklifts, inspection resources, heat-treatment capacity, and sometimes even physical space.The result is a continuously changing network of dependencies across many orders.WHEN ONE LATE OPERATION CHANGES THE DELIVERY DATEConsider a machine assembly that must ship by the end of the week.Its route could include:MachiningHeat treatmentSurface finishingFinal inspectionPackingDispatchPlanning initially places every operation into an appropriate time window.Then the machining center stops.Perhaps a spindle alarm requires maintenance and the remaining quantity cannot be completed for several hours.At first, this appears to be a simple machine delay.But the actual impact depends on what happens next.If machining misses the next scheduled furnace load, the order may have to wait until the following batch. That later heat-treatment completion could then miss the finishing shift.Inspection moves later. Packing moves later. Eventually, the order could miss the carrier collection.A few hours of machine downtime can therefore create a full day of delivery risk.This is why production planning cannot look only at the operation that originally became late.The more important question is:Which remaining dependency now controls whether the order can ship on time?THE CRITICAL PATH IS NOT STATICIn manufacturing, the...
• 
  How AI Changed Software Development Forever — Building the Agentic Future with Andre Baltieri [MVP] 03.09.2026 1ч 11мин

  Artificial intelligence is changing software development at a speed we have rarely seen before.Developers have already moved from writing every line of code themselves to working with AI assistants that can generate code, explain unfamiliar systems, create tests, debug applications, and automate repetitive work.But according to Microsoft MVP Andre Baltieri, that is only the beginning.In this episode of M365.FM, Mirko Peters sits down with Andre for a deep dive into the transition from traditional software development to AI-assisted development, coding agents, agentic architectures, Microsoft Agent Framework, .NET, RAG, context engineering, security, and the economics of generative AI.FROM .NET IN 2003 TO THE AI ERAAndre takes us back to the early days of .NET and C#, when learning a new Microsoft technology often meant purchasing official training and traveling to another city.Since then, software development has moved through desktop, web, mobile, cloud, containers, microservices, and serverless computing.Andre argues that the transition to AI feels fundamentally different. Instead of simply introducing another platform or framework, AI introduces a new way for humans to interact with software.AI ASSISTANTS VS. AI CODING AGENTSThere is an important difference between having an AI assistant inside your IDE and delegating work to an agent.An assistant can explain code, suggest refactoring, answer questions, and help developers understand their applications.An agent can receive a goal, create a plan, divide the work into smaller tasks, use tools, coordinate additional agents, and implement significant parts of the solution.Andre explains how this is already changing his own development workflow, with AI now generating much of the code he previously would have written manually.SPEC-DRIVEN SOFTWARE DEVELOPMENTAs agents become more capable, specifications become increasingly important.Instead of describing every implementation detail, developers can define requirements, architecture, constraints, and expected behavior and allow agents to determine how parts of the implementation should be completed.This shifts developer attention from simply producing code toward defining what should be built and why.MICROSOFT AGENT FRAMEWORKThe conversation moves into Microsoft Agent Framework and its role in bringing AI capabilities into existing applications.Andre explains how the framework brings together capabilities associated with Semantic Kernel and AutoGen and provides developers with tools for connecting models, orchestrating workflows, using MCP, implementing RAG, handling data ingestion, and exposing application functionality to AI.For .NET developers in particular, this can significantly reduce the amount of integration code required.WHY .NET STILL MATTERS IN THE AI ERAPython remains one of the dominant languages in AI development, but Andre argues strongly that .NET and C# are extremely well positioned for enterprise AI applications..NET continues to evolve rapidly, while Microsoft's AI tooling increasingly gives C# developers native access to modern AI capabilities.Organizations with years of business logic already implemented in .NET may therefore have a major advantage: they do not necessarily need to rebuild everything before introducing AI.Existing functionality can instead be selectively exposed to agents and AI-powered applications.FROM DETERMINISTIC SOFTWARE TO AGENTIC SYSTEMSTraditional applications are largely deterministic:If X happens, execute Y.Agentic systems introduce another model:Here is the goal. Determine which actions are required to accomplish it.That represents a significant architectural shift.Instead of explicitly defining every possible path, developers increasingly define goals, tools, context, permissions, constraints, and boundaries within which AI can operate.DESIGN PATTERNS ARE NOT...
• 
  Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP] 02.09.2026 1ч 1мин

  Microsoft Power Platform is often described as a low-code platform. But what happens when the applications you build become business-critical, highly integrated, and too complex for a simple maker-first approach?In this episode of M365 FM, Mirko Peters talks with Power Platform Solution Architect Ian Tweedie about what happens when Power Platform moves beyond simple low-code applications and becomes part of a serious enterprise architecture.LOW-CODE DOESN’T MEAN LOW ARCHITECTUREPower Platform can deliver a large percentage of business value quickly, but enterprise solutions almost always contain requirements that go beyond standard low-code capabilities.Ian explains why low-code should never be confused with no-code — and why traditional software architecture principles still matter when building with Power Apps, Power Automate, Dataverse, custom connectors, APIs, and Azure services.WHEN POWER PLATFORM BECOMES ENTERPRISE SOFTWAREThere isn’t necessarily a clean line between “low-code” and “enterprise.”Complexity starts increasing when applications involve multiple user journeys, development teams, integrations, security requirements, business-critical processes, and interconnected services.At that point, architecture becomes essential.Ian explains why solutions should be divided into clearly defined features and modules with clean interfaces instead of becoming one large interconnected application.ESCAPING THE WHACK-A-MOLE DEVELOPMENT PROBLEMFix one bug and another appears somewhere else.That familiar development problem is often a symptom of tightly coupled architecture.Ian discusses how modular design can isolate functionality and reduce unintended dependencies. Using email delivery as an example, he explains how separating business processes from delivery mechanisms can make applications easier to test, maintain, replace, and scale.LOW-CODE + PRO-CODE = HYBRID ARCHITECTUREPower Platform doesn’t have to compete with traditional software development.A Power Apps frontend might represent only a small part of a much larger application using Azure, AWS, GCP, APIs, or custom services.The important architectural question isn’t whether something is “low-code” or “pro-code.”It’s which technology is best suited to each feature.CITIZEN DEVELOPERS, MAKERS AND ARCHITECTURECitizen developers bring something extremely valuable: deep knowledge of the business processes they work with every day.But business expertise doesn’t automatically translate into good application architecture.Ian discusses the balance between empowering makers and introducing enough architecture, governance, normalization, and technical review to prevent solutions from becoming difficult to maintain.GOVERNANCE WITHOUT KILLING INNOVATIONToo little governance creates chaos.Too much governance creates friction — and can drive employees toward unsupported workarounds, spreadsheets, VBA, and shadow IT.The challenge is finding the right level of governance based on organizational risk, application criticality, users, and business impact.POWER PLATFORM, APIs AND AZUREWhere should business logic live?Should secrets be stored inside Power Platform? When should Azure Key Vault, Azure Functions, or API Management become part of the architecture?Ian explains why architecture should always begin with the problem being solved rather than adding Azure services simply because they are available.GIT, SOURCE CONTROL AND CI/CDAs Power Platform development becomes more collaborative, traditional development practices become increasingly relevant.The conversation explores Git, repositories, development environments, pipelines, source control, feature isolation, cross-dependencies, and CI/CD.There may not always be a perfect approach to source control in Power Platform — sometimes the goal is choosing the “least worst option” for the...
• 
  Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP] 01.09.2026 1ч 5мин

  Microsoft 365 Copilot doesn’t arrive in a clean Microsoft 365 tenant. It arrives in an environment that organizations have been building for years — full of SharePoint sites, Teams, OneDrive content, duplicate documents, historic migrations, guest accounts, inconsistent permissions, forgotten workspaces, broken ownership models, and content nobody has reviewed in years.For traditional Microsoft 365 management, much of this technical debt could remain relatively hidden. AI changes that.In this episode of M365.FM, Mirko Peters talks with Richard Harbridge, Microsoft MVP and industry advisor at ShareGate, about why AI readiness is fundamentally connected to Microsoft 365 modernization and governance.The conversation moves beyond the question of how to deploy Copilot and focuses instead on a more important question: What kind of Microsoft 365 environment are we actually giving AI access to?COPILOT DOESN’T CREATE THE MESS — IT AMPLIFIES ITOne of the central ideas in this conversation is that Microsoft Copilot is not necessarily creating entirely new governance problems. Instead, AI makes existing problems significantly more visible and consequential.Organizations have accumulated years of decisions around permissions, sharing, workspace creation, ownership, migrations, external access, inactive content and collaboration.Richard describes this accumulation using the concept of “sprawl.”Sprawl itself is not automatically bad. A growing number of Teams, SharePoint sites and other resources can be evidence that people are successfully adopting Microsoft 365.The problem begins when that growth happens faster than the organization’s ability to manage it.Temporary permissions become permanent. Old collaboration spaces remain accessible. Ownership changes. Business structures evolve. Content stays online long after its original purpose has disappeared.Copilot then operates on top of that existing environment.MICROSOFT 365 SPRAWL IS BIGGER THAN TEAMS AND SHAREPOINTWhen people hear “Microsoft 365 sprawl,” they often immediately think about too many Teams or SharePoint sites.But Richard argues that sprawl is multidimensional.Organizations can experience workspace sprawl, permission and access sprawl, ownership problems, inactive resources, lifecycle problems, administrative complexity, conditional access sprawl and increasingly integration and connector sprawl.The rise of AI adds another dimension.Microsoft 365 environments increasingly connect data, applications, AI systems and agents. That means organizations need to think beyond individual workloads and start looking at Microsoft 365 as an interconnected ecosystem.Governance can no longer be treated purely as “SharePoint governance” or “Teams governance.”THE CONFIDENCE GAP IN MICROSOFT 365 GOVERNANCERichard shares an especially interesting finding from ShareGate’s research.A very large percentage of IT leaders report being highly confident in their Microsoft 365 governance. Yet a significant portion of those same organizations report that Copilot has surfaced content that users arguably should not have been able to discover — or they suspect this may have happened but do not know how to verify it.That creates an important distinction between having governance controls available and actually having a continuously governed environment.Policies, configuration options and administrative controls alone do not guarantee that an organization understands its current Microsoft 365 state.AI can expose that gap very quickly.DID MICROSOFT MAKE COLLABORATION TOO EASY?Microsoft Teams, SharePoint and OneDrive are successful partly because Microsoft has made collaboration extremely easy.But easy collaboration also makes it easy to create more resources.One response organizations have traditionally used is restricting workspace creation. Richard explains why that alone does not solve the problem.A workspace created today may serve...
• 
  Microsoft 365 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP] 30.08.2026 1ч 4мин

  Does Microsoft 365 Copilot really make people more productive?In this episode of the M365 FM podcast, Mirko Peters speaks with Microsoft MVP Adrian Espes about what Copilot actually delivers in everyday work—not in a polished demo, but during a normal working day filled with meetings, emails, documents, Teams messages, deadlines, and constant interruptions.Adrian brings a practical perspective shaped by his experience in training, business analytics, modern workplace consulting, and Microsoft 365 adoption. Together, Mirko and Adrian look beyond the marketing and explore where Copilot is genuinely useful, where expectations are still unrealistic, and what organizations need to consider before rolling it out.MICROSOFT 365 COPILOT IN THE REAL WORLDAdrian explains why Microsoft 365 Copilot’s biggest advantage is its position inside the Microsoft ecosystem. Unlike standalone AI tools, Copilot can work directly with the applications people already use every day, including Outlook, Teams, Word, PowerPoint, Excel, and Edge.The conversation explores how Copilot can help users summarize meetings, catch up on conversations, identify follow-up tasks, work with documents, and create useful outputs without constantly moving information between different tools.PROMPTING WITHOUT BECOMING A PROMPT ENGINEERDo employees really need to become prompt engineers?Adrian shares a realistic approach to prompting. Users do not need to learn complicated formulas or memorize a perfect prompt structure. Instead, they should practice explaining their goal clearly, provide relevant context, describe the desired outcome, and refine their requests over time.The discussion also covers why different departments and roles may need different prompting approaches. A financial analyst, a marketing professional, a manager, and a frontline worker will all use Copilot differently because their goals and daily tasks are different.PRODUCTIVITY, EFFICIENCY, AND THE HUMAN FACTOROne of the central themes of this episode is the difference between productivity and efficiency.Adrian explains why the word “productivity” can create anxiety among employees. When companies talk about productivity, many workers may fear that AI is being introduced to measure performance or replace jobs.Instead, Adrian suggests focusing on efficiency, better work quality, reduced friction, and making AI a natural part of everyday work. The real question is not simply whether someone completes more tasks, but whether Copilot helps them work with less effort, better information, and more time for meaningful activities.DATA QUALITY, GOVERNANCE, AND SECURITYCopilot can only be as useful as the information available to it. That makes data quality, permissions, governance, and information architecture essential parts of any Microsoft 365 Copilot project.Mirko and Adrian discuss the importance of reviewing the Microsoft 365 environment before implementation. This includes checking permissions, overshared information, tenant configuration, data protection, sensitivity labels, and the way users store and access content.Adrian also explains the importance of using enterprise accounts and understanding how enterprise data protection works when employees use Microsoft Copilot in a business environment.MICROSOFT 365 COPILOT AND AI MODELSThe conversation also looks at the growing number of AI tools and models available today, including Microsoft Copilot, ChatGPT, Claude, Gemini, Perplexity, and different models available through GitHub and Microsoft platforms.Rather than asking which AI tool is universally the best, Adrian recommends choosing the right tool for the task. Some tools may be stronger for coding, reasoning, image creation, or creative work, while Microsoft 365 Copilot’s major strength is its integration with business data and workplace applications.A PRACTICAL COPILOT IMPLEMENTATION ROADMAP
• 
  How Microsoft 365 & Copilot Are Redesigning the Way We Work with Tracy van der Schyff [MVP] 29.08.2026 1ч 3мин

  Microsoft 365 has given organizations more tools than ever to communicate, collaborate, automate, and manage information. Now Microsoft 365 Copilot adds an entirely new layer of AI capability. But behind all the discussion about productivity, automation, agents, and AI, there is a much bigger question: are these technologies simply helping us work faster, or are they fundamentally changing the way we think, learn, communicate, collaborate, and work?In this episode of m365.fm, Mirko Peters sits down with Tracy van der Schyff to explore the human side of Microsoft 365 and Copilot. Tracy has spent years working at the intersection of technology, productivity, digital literacy, training, adoption, and organizational change. Her focus is not simply on teaching people which buttons to click. It is about helping people understand technology, use it with purpose, and become more capable because of it.The conversation goes far beyond Copilot features. Mirko and Tracy discuss digital fluency, Microsoft 365 adoption, information management, AI readiness, change management, responsible AI, the broken digital workplace, and a powerful idea that runs throughout the episode: we design technology, but the technology we create and use also shapes us.FROM DIGITAL LITERACY TO DIGITAL FLUENCYFor many years, organizations talked about PC literacy and later digital literacy. But Tracy believes those terms no longer fully describe the skills people need in a modern workplace.Knowing how to operate a computer is not enough. Knowing where a button is inside Microsoft Teams or how to upload a document to SharePoint does not necessarily mean somebody understands how to work effectively in a digital environment.Digital fluency goes further. It means understanding the purpose of a technology, knowing when it should be used, understanding how your actions affect other people, and using technology responsibly and intentionally.This becomes even more important as AI enters everyday work. Tracy explains how her original model of eight pillars of digital literacy has evolved into eleven pillars of digital fluency, now incorporating responsible AI use and the additional skills people need when working alongside AI systems.The important distinction is that these are not simply Microsoft 365 skills. They are becoming life skills.AI is also creating unexpected opportunities to develop human skills. Communicating effectively with Copilot requires people to explain what they actually want. Better questions can produce better answers, and those answers can help people formulate better questions the next time. In that sense, working with AI can improve communication, creativity, critical thinking, and the ability to express intent clearly.THE MICROSOFT 365 TOOL OVERLOAD PROBLEMTeams, Outlook, SharePoint, OneDrive, Loop, Planner, Lists, Power Platform, Copilot and countless other applications give employees enormous capabilities. But providing access to tools does not automatically teach people how those tools should fit together.Organizations often deploy technology and expect employees to figure out the rest.That can result in departmental information being shared from personal OneDrive accounts, Teams being created simply for individual meetings, documents being stored in inappropriate locations, and employees constantly switching between tools without understanding where work actually belongs.When that happens, Tracy argues that blaming users is the wrong response.If an employee was never taught the intent behind Teams, SharePoint, OneDrive, Outlook, or another application, they will naturally choose whatever tool helps them complete the immediate task. The underlying problem is often not the employee. It is the absence of a clear digital strategy.ME, WE, US: SIMPLIFYING THE DIGITAL WORKPLACEOne framework Tracy uses to make the Microsoft 365 environment easier to understand is ME, WE, US.The ME space...
• 
  Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP] 28.08.2026 1ч 3мин

  Modern SharePoint development does not mean building every component from scratch. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Siddharth Vaghasia about building production-ready SharePoint Framework (SPFx) solutions by combining the right Microsoft 365 technologies with reusable community components.Siddharth brings nearly 18 years of experience across the Microsoft technology stack, from .NET and the early days of SharePoint Server to SharePoint Online, Microsoft 365, Power Platform, Azure, and modern SPFx development.WHEN SHOULD YOU ACTUALLY USE SPFx?Not every SharePoint requirement needs custom development. Siddharth explains a simple principle: first determine whether Microsoft already provides the functionality. If the requirement can reasonably be solved with standard SharePoint capabilities, avoid unnecessary customization.SPFx becomes valuable when organizations need experiences, integrations, or interfaces that cannot be delivered effectively with out-of-the-box functionality.SPFx VS POWER PLATFORMShould you build the solution with SPFx or Power Apps?The discussion explores where each approach fits. Power Apps can be effective for relatively straightforward forms, conditional fields, business rules, and scenarios where citizen development and low-code maintainability matter.SPFx becomes particularly powerful when developers need greater control over the user interface, complex data handling, reusable components, APIs, or sophisticated application experiences directly inside SharePoint. Siddharth also argues that generative AI coding tools are changing the traditional assumption that pro-code development necessarily takes longer than low-code development.THE MODERN SPFx TECHNOLOGY STACKA modern SPFx project brings together several technologies rather than relying on one framework.Siddharth breaks down the roles of TypeScript, React, Fluent UI, PnPjs, and PnP React Controls. TypeScript provides stronger typing and compile-time checks, while Fluent UI helps custom solutions retain the familiar Microsoft user experience.PnPjs simplifies interaction with SharePoint, Microsoft Graph, and other Microsoft 365 services by replacing repetitive REST request code with reusable abstractions.STOP REBUILDING CONTROLS THAT ALREADY EXISTOne of the central lessons of the episode is simple: professional development does not mean writing everything yourself.PnP React Controls provide SharePoint-aware and Microsoft 365-aware components for common development requirements. Instead of repeatedly creating the UI, API calls, data binding, and associated logic for components such as file pickers, developers can use established community controls.Siddharth's preferred approach is to check existing capabilities first: use Microsoft functionality when available, then Fluent UI or PnP React Controls where they satisfy the requirement, and create a custom component only when the required functionality does not already exist.THE FIVE PnP REACT CONTROLS DEVELOPERS SHOULD KNOWIf Siddharth had to choose only five controls, his selection would be People Picker, Taxonomy Picker, List View, File Picker, and Live Persona.These components cover several recurring requirements in enterprise SharePoint applications, including selecting users, working with managed metadata, presenting SharePoint data, selecting or uploading files, and displaying Microsoft 365 user information.BUILDING REAL APPLICATIONS INSIDE SHAREPOINTThe conversation moves from individual controls to application architecture with the example of a sophisticated project management solution.SharePoint lists can provide the underlying data layer for projects, customers, resources, and tasks, while SPFx can deliver a unified application experience containing dashboards, project views, charts, CRUD operations, role-specific interfaces, task management,...
• 
  SharePoint Isn't Boring Anymore: How Copilot Is Reinventing the Modern Workplace with Marcin Siewnicki [MVP] 27.08.2026 57мин

  For years, SharePoint has carried a reputation for complicated document libraries, outdated intranets, confusing navigation, too many sites, and information that employees simply cannot find. But Microsoft 365 is changing, and Copilot is making SharePoint more important than it has been in a long time.In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Marcin Siewnicki about how SharePoint is evolving from a traditional document and intranet platform into a central information and knowledge layer for the modern workplace. Marcin has worked with SharePoint since the SharePoint 2003 era, giving him more than two decades of perspective on how the platform has changed.WHY SHAREPOINT GOT A BAD REPUTATIONMuch of SharePoint’s reputation was created by the way organizations implemented it. Intranets were often designed by IT, heavily customized, difficult to use, and disconnected from what employees actually needed.Instead of continuously gathering feedback and improving the experience, many companies delivered an intranet and expected employees to adapt to it. The result was complex navigation, outdated content, overloaded pages, and systems people avoided whenever possible.INFORMATION ARCHITECTURE BEFORE TECHNOLOGYOne of the biggest problems is not SharePoint itself but how information is organized inside it. Without a clear information architecture, SharePoint can quickly become a huge shared folder filled with duplicated files, outdated information, unclear ownership, and multiple versions of the same document.Marcin explains why organizations should start with a simple structure, understand their data, remove unnecessary content, and introduce basic metadata. Information architecture does not have to be complicated to make SharePoint significantly easier to use.BUILDING A MODERN SHAREPOINT WORKPLACEA modern SharePoint homepage should not become an endless collection of web parts, corporate announcements, applications, and links. It should be simple, personalized, visually clear, and focused on what employees actually need.Communication sites can provide departments and organizations with modern, mobile-friendly publishing experiences without requiring the enormous custom intranet projects that were common in the past. The focus should be on useful information, important applications, relevant documents, straightforward navigation, and strong search capabilities.SOLVING THE SHAREPOINT NAVIGATION PROBLEMNavigation remains one of SharePoint’s biggest challenges. Organizations frequently attempt to expose every department, application, resource, and internal page through a single navigation structure.Marcin explains why simpler navigation usually works better. Global navigation should focus on the most important destinations, while detailed navigation can be provided closer to individual departments, sites, and business areas. Otherwise, navigation itself becomes another information problem.SHAREPOINT AND TEAMS SPRAWLMicrosoft Teams and SharePoint are deeply connected. Every new Team and many Teams channels can introduce additional SharePoint resources, which means uncontrolled Teams creation can quickly become uncontrolled SharePoint growth.Organizations therefore need simple creation processes, templates, basic metadata, lifecycle management, and user education. Employees should understand when they need a Team, when a SharePoint site is sufficient, and what happens behind the scenes when these collaboration environments are created.One useful way of looking at the relationship is to think of Microsoft Teams as the collaboration interface while SharePoint provides much of the document and information layer underneath it.GOVERNANCE WITHOUT KILLING INNOVATIONGovernance does not need to mean preventing employees from using new technology. The goal is to provide enough freedom for people to work...
• 
  Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP] 25.08.2026 59мин

  Microsoft Fabric brings data engineering, analytics, business intelligence, governance and increasingly AI together in one platform. But what does an end-to-end Fabric architecture actually look like when you move beyond individual features and start connecting everything?In this episode of the M365 FM Podcast, Mirko Peters is joined by Amit Chandak [Microsoft Data Platform MVP] for a practical journey through Microsoft Fabric — starting with raw organizational data and ending with trusted information that business users can use to make decisions.WHY MICROSOFT FABRIC?Before Fabric, organizations could already build sophisticated analytics architectures using Azure, Power BI and other platforms. The problem wasn't a lack of technology. In many cases, it was the opposite: organizations had too many choices, separate storage technologies, different compute models and multiple copies of essentially the same data.Amit explains how Microsoft Fabric attempts to simplify this architecture by bringing workloads together around shared foundations such as OneLake, common Fabric capacity and the Delta format. Lakehouses, warehouses, Power BI and other Fabric experiences can therefore operate as parts of a broader platform instead of completely isolated services.ONELAKE AS THE FOUNDATIONOneLake is one of the central concepts behind Fabric. Amit compares it conceptually to OneDrive: instead of every analytics workload creating completely independent storage environments, OneLake provides a virtualized storage foundation across the Fabric tenant.Organizations can still separate data through workspaces, Lakehouses, Warehouses and domains, but those resources exist within a common Fabric storage architecture. This becomes particularly important when organizations want to reduce unnecessary duplication while maintaining security and organizational boundaries.CENTRALIZED DATA OR DATA MESH?Fabric doesn't automatically mean putting everything into one giant centralized analytics environment.For smaller organizations, a centralized architecture may still work well. As organizations become larger, Amit sees increasing value in domain-oriented architectures where areas such as sales, finance and purchasing can have their own workspaces and responsibilities.IT can remain responsible for availability, governance and the technical foundation while business domains increasingly take ownership of how their data is analyzed and consumed.SHORTCUTS INSTEAD OF COPYING DATAOne of the recurring themes throughout the conversation is avoiding unnecessary copies of data.Fabric Shortcuts allow teams to reference data stored elsewhere rather than physically copying it into every environment that needs it. That can apply both inside Fabric and to supported external storage.Amit also explains an interesting architectural benefit of shortcuts: they can help separate workloads across capacities. This can become important when organizations want Power BI consumption workloads isolated from intensive data engineering workloads while still working with the same underlying information.LAKEHOUSE VS. WAREHOUSEOne of the biggest Fabric architecture questions remains: Should you use a Lakehouse or a Warehouse?A Lakehouse can work with structured and unstructured data and is naturally aligned with Spark. A Fabric Warehouse focuses on structured data and provides the familiar T-SQL experience.Both ultimately use Delta for structured data inside Fabric, which means the decision increasingly comes down to the type of data, preferred technologies and workloads.Organizations with strong SQL teams don't necessarily need to abandon their existing skills. Teams working with very large datasets, advanced engineering scenarios, unstructured information or extensive data science workloads may find the Lakehouse and Spark approach more attractive.GETTING DATA INTO FABRICOnce the...
• 
  Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT] 24.08.2026 1ч 3мин

  Enterprise AI is moving beyond chatbots that simply answer questions. The next generation of AI agents can understand business context, connect to enterprise systems, orchestrate workflows, and take action on behalf of users.But building an impressive AI agent demo is easy. Building an agent that works reliably across a global enterprise—with sensitive data, complex business processes, governance requirements, thousands of users, and measurable outcomes—is a very different challenge.In this episode of the M365 FM Podcast, Mirko Peters talks with Manpreet Singh [MVP/MCT] about what it actually takes to build production-ready enterprise AI agents with Microsoft Copilot Studio and the wider Microsoft AI ecosystem.Manpreet explains how organizations are evolving from individual departmental agents toward multi-agent architectures where specialized agents collaborate behind a single interface. The discussion explores when to use Microsoft 365 Copilot, Copilot Studio, and Azure AI Foundry—and how these technologies can work together rather than becoming isolated AI platforms.FROM ANSWERS TO ACTIONSThe real transformation begins when an AI agent can do more than retrieve information.Using practical examples, Manpreet explains how agents can connect with systems such as Workday, Salesforce, SAP, ServiceNow, Jira, Confluence, and PeopleSoft. Instead of navigating several applications manually, employees can interact with an agent through Microsoft Teams or another conversational interface.An employee requesting leave, for example, could have an agent check available leave, consult HR policies, initiate the request in the underlying HR system, ask the manager for approval, and return the final result—all without the employee opening the individual applications.KNOWLEDGE, TOOLS AND TRIGGERSA useful enterprise agent requires more than a good prompt.Manpreet breaks the architecture down into essential elements: knowledge sources that provide organizational context, tools and connectors that allow the agent to interact with enterprise systems, and triggers that determine when processes should begin.SharePoint can become an important knowledge layer, while Power Platform connectors and APIs enable agents to perform actions across business applications.WHY DATA QUALITY MATTERSConnecting an agent to twenty years of SharePoint content is not necessarily a good strategy.Manpreet strongly recommends cleaning and curating organizational knowledge before exposing it to AI. Thousands of outdated PDFs, duplicate documents, missing metadata, and obsolete policies can undermine the quality of agent responses.A smaller, carefully maintained knowledge base with current documents, useful metadata, tags, descriptions, and version management can produce significantly better results than simply indexing everything an organization owns.HUMAN-IN-THE-LOOP AIAutonomous does not have to mean uncontrolled.For low-risk transactions, organizations may allow an agent to complete an action automatically. Higher-value or sensitive decisions can introduce human approval.Manpreet discusses examples including financial claims, invoice processing, access requests, and infrastructure changes where humans remain part of the decision-making process while AI handles much of the repetitive work surrounding the decision.GOVERNANCE BEFORE SCALEAs agents gain access to multiple enterprise applications, governance becomes critical.The conversation explores Microsoft Purview, Data Loss Prevention policies, security controls, sensitivity labels, Microsoft Defender, identity, environment strategies, and the importance of establishing an AI Center of Excellence before allowing agent development to expand throughout an organization.Governance should protect enterprise information without creating policies so restrictive that agent performance and usability suffer.CONTROLLING AGENT...
• 
  From Copilot Rollout to AI Workplace: Adoption, Agents & Real Business Value with Christoffer Besler Hansen [MVP] 23.08.2026 57мин

  Microsoft 365 Copilot has moved beyond the question of “What can generative AI do?” The harder challenge is now turning AI into something thousands of employees actually use, trust, and derive measurable business value from. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Besler Hansen, Head of AI Workplace at Atea Group, about what it takes to move from a Copilot rollout to a genuine AI-powered workplace. Drawing on experience supporting AI adoption across more than 8,000 employees, Christoffer shares lessons on Microsoft 365 Copilot adoption, training, agents, Copilot Studio, Microsoft Foundry, governance, security, extensibility, FinOps, and measuring business value.WHAT IS AN AI WORKPLACE?An AI workplace is much broader than simply giving employees Microsoft 365 Copilot licenses. At Atea, the AI Workplace team is responsible for how more than 8,000 users incorporate AI into their daily work. Microsoft Copilot is a major component, but the strategy also includes Copilot Studio, agentic AI, Foundry, experimentation with other technologies, and—critically—continuous user adoption. The objective is not to deploy one AI product. It is to change how people work with information, applications, and business processes.TECHNOLOGY MOVES FAST. PEOPLE NEED TIME.New AI models and capabilities can appear every week. Human working habits don't change at the same speed. Christoffer explains why organizations need to spend substantial effort helping employees feel comfortable changing established workflows. At Atea, this includes training throughout the year, sometimes every other week, with sessions designed for different audiences such as managers, consultants, salespeople, beginners, and advanced users. AI adoption therefore isn't a launch event. It is an ongoing organizational capability.BUYING 5,000 COPILOT LICENSES ISN'T A STRATEGYWhat should happen after an organization purchases thousands of Microsoft 365 Copilot licenses? According to Christoffer, the organization first needs to determine why it purchased them. What is the objective? What should employees accomplish differently? How will the organization support adoption? How will success be measured? Simply assigning licenses and expecting employees to teach themselves isn't enough. Employees already have jobs to perform and cannot realistically follow every weekly change across rapidly evolving AI products.WHY EARLY COPILOT ADOPTION OFTEN DROPSAI naturally generates curiosity. When users initially received Copilot without structured adoption support, Christoffer observed strong engagement for approximately the first four weeks. Employees experimented with the technology. But when they struggled to turn those experiments into new working habits, usage declined. After structured training was introduced, users were more likely to continue using Copilot over time—and began asking for additional training as the products evolved. Initial excitement gets people through the door. Continuous education helps keep them there.HOW DO YOU MEASURE COPILOT ROI?One of the hardest enterprise AI questions is determining whether Copilot is actually creating value. Usage alone isn't enough. An employee opening Copilot 50 times doesn't necessarily mean the organization has become more productive. Christoffer argues that organizations need to identify what matters to their particular business and then measure whether AI improves those outcomes. That could include completing work faster, handling more customer cases, improving quality, or increasing business capacity.MEASURE OUTPUT, NOT JUST AI USAGEOne example discussed in the episode involves an employee who previously handled two cases simultaneously but could use AI to work across six while still receiving better customer feedback. That represents something more meaningful than a Copilot usage statistic. The...
• 
  Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP] 22.08.2026 1ч

  What happens when your cloud strategy cannot live entirely in the public cloud? Organizations are modernizing infrastructure with Azure, platform services, Infrastructure as Code, automated deployment pipelines, and Azure Landing Zones. At the same time, some workloads still need to remain close to factories, offices, regulated environments, existing infrastructure, or latency-sensitive systems. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Klarskov Jakobsen about how Azure Local can become part of a broader Azure architecture rather than another isolated on-premises platform. They explore Azure Local, Azure Landing Zones, Azure Arc, governance, Infrastructure as Code, Bicep, Azure DevOps, modernization, and the realities of building hybrid cloud environments.WHAT IS AZURE LOCAL?Azure Local combines familiar infrastructure technologies with Azure-based management, governance, and security capabilities. At its core, organizations can run workloads such as virtual machines locally while connecting the environment back to Azure. Christoffer explains that the major difference compared with a traditional Windows Server environment is the Azure experience surrounding the infrastructure. Organizations can keep workloads and data locally while using Azure capabilities to manage and govern the environment.IS AZURE LOCAL JUST AZURE IN YOUR DATA CENTER?Not exactly. Azure provides a significantly larger catalog of cloud services, but Azure Local can bring selected Azure experiences closer to local infrastructure. Christoffer discusses running virtual machines and Kubernetes on Azure Local as well as scenarios involving SQL Managed Instance and Azure Virtual Desktop. The result isn't a complete copy of Azure running inside your building. It's a hybrid platform combining local compute requirements with selected Azure services and management capabilities.WHEN DOES AZURE LOCAL MAKE SENSE?Several scenarios stand out. Organizations may have regulatory requirements requiring data to remain locally. Others need extremely low latency between applications, machines, factories, or other infrastructure. Some organizations simply have workloads that cannot yet move completely into the public cloud. Christoffer also sees increasing potential around local AI workloads, including scenarios where organizations need AI capabilities while maintaining local control over their data.AZURE LOCAL IS A LOCAL CLOUDOne of the important architectural lessons from the conversation is that Azure Local shouldn't be treated as simply another pair of servers. The environment includes multiple infrastructure and Azure-connected layers. Organizations therefore need people who understand the underlying hardware and operating technologies as well as Azure management. Christoffer describes Azure Local as effectively operating a local cloud rather than simply installing another traditional virtualization cluster.WHY AZURE LANDING ZONES MATTERMoving workloads into Azure doesn't automatically create a well-designed cloud environment. Organizations need structure, security boundaries, governance, permissions, networking, logging, and clear separation between workloads. Azure Landing Zones provide an architectural approach for establishing those foundations. Instead of placing unrelated applications, development environments, production systems, networking components, and shared services inside the same subscription, organizations establish clearer boundaries around workloads and responsibilities.THINK DIFFERENTLY ABOUT AZURE SUBSCRIPTIONSA subscription shouldn't simply become a container for everything an organization deploys. Christoffer recommends thinking about subscriptions as boundaries for specific environments and workloads. A development environment can have its own subscription. Testing can have another. Production can have...