Warehouse and Intralogistics Optimization With Azure and Dynamics 365

iFAKT GmbH - Warehouse and Intralogistics Optimization With Azure and Dynamics 365 00:00:00 Speaker: Imagine a warehouse with full racks and pickers working through a busy shift across the same site. An assembly line waits for a tote of parts that's already in stock, while completed warehouse tasks keep climbing. Everyone's working, but production still misses its delivery. I want to follow that delay from where material gets stored through the warehouse work to the moment. Production can actually use it, because having parts on site and having parts at the line are two different things. Let's follow one tote through a hypothetical plant. The warehouse supplies several assembly cells and also picks customer orders for dispatch, so the same people and storage area support demands with different deadlines. Our tote holds a small component used during assembly. A supplier delivery brings those components into receiving, where a worker checks the delivery and puts the material into a container that can move through the plant. At this point, production doesn't need the tote beside the line. It moves into storage with other stock ready for later use, and the receiving team turns its attention to the next delivery waiting to be unloaded. That first move seems straightforward, but the tote now sits in a location chosen when it arrived, and every later request has to work with the distance and handling steps that choice creates. By the next shift, assembly needs more of this component. There's still some stock beside the cell, but the planned work will use it. So a request starts the journey from warehouse storage to production. The tote doesn't travel straight from its storage location to the cell. In this example, reserve stock first moves to a picking area where workers collect smaller quantities for the requests they're handling during the shift. That replenishment move hasn't happened yet. The components exist in reserve storage, but the worker handling the production request reaches the picking location and finds too few parts to complete it. Meanwhile, dispatch faces a customer shipment that needs to leave soon. A worker who could help bring down the reserve stock instead helps finish that shipment, because missing the collection would create another problem for the plant. Neither request looks unreasonable on its own. The dispatch team needs the goods ready for collection, while the assembly team needs enough components to keep people working on the production order already underway. Eventually, the reserve stock reaches the picking area. A picker collects the required quantity, checks the tote and moves it to staging, where it waits with other containers that also need transport for the picker, that piece of work is finished for the assembly cell. Nothing has arrived yet, and the remaining parts beside the line continue to disappear. As workers build the next units. The tote waits while another load moves first, then someone collects it for the trip through the plant, but arrival near the cell still leaves an unloading and hand-off step. Before assembly can use the parts, a worker needs to receive the tote and put it within reach. If it lands at a nearby holding point instead, the transport trip may end while the production team still needs someone to bring the material over. Now consider what the assembly supervisor faces during that wait, people stand ready at the cell, work remains on the order, and the missing component prevents them from completing the next assembly. Despite stock elsewhere on site, the supervisor may switch the team to another job that keeps some work moving, but it also changes the sequence for later orders and leaves the original job waiting for both parts and another opening. Someone may leave their normal work to chase the tote. They walk to staging. Ask whether it's already been collected and perhaps arrange a rushed move while other requests continue waiting for the same people. After enough deliveries like this, extra stock beside the line starts looking sensible. Production asks for more than the immediate need, because a spare tote feels safer than relying on a journey whose completion nobody can confidently promise. That response creates more material to store and handle near assembly. It's understandable, though, because the production team carries the cost of waiting even when each warehouse team can point to work completed during the shift. I wouldn't start by asking who needs to work faster. I'd ask whether the next tote reaches the right assembly cell before its parts run out, because a busy warehouse can still leave that delivery unfinished. Before changing that journey, we need to choose what we're improving. Intralogistics means the movement and storage of material within your site, including the places where material sits between one operation and the next physical move. The word covers more than transport. If a change shifts material from a warehouse rack into a production buffer, you've changed the intralogistics flow. Even if the route between those places stays exactly the same. I'd define the goal as a delivery promise. Production needs an agreed quantity at an agreed point, in usable condition within a time window that supports the work without filling the area too early. Each part of that promise needs a plain definition at the cell might mean a marked receiving position, while ready for use, might require a different position where the operator can safely reach the container. Quantity needs the same care. Enough material to finish the next job might suit one operation, while another needs a fixed container quantity. Because splitting the load creates extra handling and storage problems. Condition belongs in the promise two. A delivery that reaches the correct place on time still fails if the packaging no longer protects the parts or the container can't be handled safely. Their timing also works in both directions. Material arriving well before production needs. It can occupy space reserved for another delivery, so an earlier arrival isn't always a better result for the site. That gives us something firmer than reduce warehouse travel. Shorter travel can help, but I judge it against the delivery promise and the work it creates elsewhere. Rather than treating distance as the final objective, consider a choice between small, frequent deliveries and larger loads. Smaller loads reduce the stock beside production, but they can also require more trips, more handling and more shared space along the route during the shift. Larger loads change that balance. You may spend less labor on repeated trips while committing more stock and floor space to material that production won't consume for some time after it arrives. Neither choice wins by default. The sensible choice depends on how much room you have, how demand changes, and how reliably people can complete the moves without disrupting other work around them. Labor creates another trade off, a plan that saves walking for one worker may require another worker to spend longer receiving or arranging material, so the comparison needs to include both ends of the move. Safe movement sets limits on those choices. If a proposed delivery pattern leaves too little room for people to pass or handle a container safely, lower travel time doesn't make that pattern acceptable. So I'd choose a narrow boundary for the first improvement. For this flow, we'll start when the warehouse releases the production supply request for execution and finish when production confirms receipt at the agreed line. Side point release needs one shared meaning. Here it means the request has entered executable warehouse work rather than remaining a future requirement that nobody is yet expected to act on during the current operation. Receipt needs an equally clear meaning. We'll count it when the required material reaches the agreed receiving point, and production confirms that the quantity and condition meet the delivery promise for that request. This boundary keeps the first question manageable. We're asking how reliably a released request becomes an accepted delivery, while recognizing that earlier decisions and conditions outside this boundary can still affect the result. We also need to state what this boundary leaves out. If a request waits before release, that delay still affects production, but it won't appear in the elapsed time we've chosen for this first improvement. That's a deliberate limit, not a reason to ignore it. Keeping the boundary explicit prevents a faster result inside the warehouse from being mistaken for a faster response to the original production need across the whole site. Now we can ask how long that defined journey takes. The clock starts at release and stops at confirmed receipt, giving us one elapsed interval. That includes everything the material experiences between those agreed points. Within that elapsed interval. The tote experiences two different kinds of time. During some periods, someone picks the parts, checks the quantity, loads the container, moves it through the plant, or unloads it at the receiving point. We'll call those periods touch time or active handling time. The definition includes physical movement even when nobody touches the tote during the trip, because we are measuring activity on the materials journey rather than hands on labor alone, waiting time fills the gaps between those activities. A tote can sit ready in staging while transport remains unavailable, or a picking task can pause because replenishment hasn't brought enough stock to the pick face, those pauses need separate labels. Waiting for reserve stock tells us something different from waiting for collection, even though both appear as minutes when no activity advances the requested material toward receipt. Unreleased work needs care here. A request waiting before our agreed release point sits outside this measurement, while a downstream task awaiting release after that point can create waiting inside the measured journey. That distinction affects the calculation flow efficiency. Using this definition equals the active time within the journey divided by its total elapsed time, with both measured between the same start and finish. Take an illustrative request that reaches receipt after an hour. If picking, checking, loading, movement, and unloading occupy fifteen minutes within that hour, the measured flow efficiency comes to twenty five percent for that particular journey. The remaining forty five minutes need investigation, not an automatic verdict. They represent time outside our defined activity periods, which might include avoidable queues, required holes or gaps that the available records don't yet explain well enough. A higher percentage doesn't automatically mean a better delivery. If workers spend longer handling a tote without reducing its waiting time, the active share can rise even though production receives the material later than before. I'd keep the elapsed time beside the percentage that lets you distinguish a journey that improves because queues shrink from one whose ratio changes because the material requires more handling than it did previously. There's also a difference between material time and labor time. If two workers load the same tote together for five minutes, the tote experiences five minutes of loading. Even though the task consumes ten worker minutes of labor. Overlapping activities create the same counting risk when checking and loading happen together. Adding their full durations can count part of the same interval twice and overstate how long the tote remains active. For this measure, count each active interval only once. You can still record labor efforts separately, but adding labor effort to travel duration won't produce a sound measure of the material's active share of elapsed time. A confirmed pick followed by a confirmed delivery doesn't tell you exactly when loading started, how long transport took, or whether the tote sat waiting before someone unloaded it. You get the bookends, but not the middle. Missing evidence isn't proof of waiting. When a starter finishes unknown, I'd label that interval as uncertain, rather than quietly assigning every unexplained minute to a cue and presenting the result as measured fact. Let the gaps stay visible. Material awaiting a quality decision may correctly remain untouched, Moving it toward consumption before approval would defeat the purpose of the hold, regardless of the delivery deadline. Keep that hold visible within the elapsed journey. If you also calculate a version that excludes approved quality holds, name it clearly and retain the unadjusted result. People need to understand the difference between them, otherwise, one team counts checking as active work while another excludes it, and you're comparing percentages that describe different activities despite sharing the same name. That's where the totals stop being enough to explain. One hour from release to receipt, you need records that place the pick loading movement, unloading checks and pauses in their actual sequence. The next question concerns what those records actually prove. Each recorded step needs to tell us which part of the total journey occurred, rather than leaving us to infer physical activity from a completed task total, start by asking which system owns each operational fact in our hypothetical plant. The answer changes as the request passes from a production requirement into warehouse work and then into a physical transport mission. A production order creates a requirement for components while planning functions. Consider demand, supply and timing to work out what material the business expects to need. The ERP also records inventory transactions and applies business rules. Those rules can govern which stock counts as available, how material issues affect an order, and whether a transaction can proceed under the current business conditions. Its inventory view has a defined purpose. A posted material issue supports stock accounting and order processing, but its physical meaning depends on when your process posts that issue and what information triggers it. Planning provides an expected requirement rather than direct knowledge of every movement. If production changes pace during a shift, the original requirement can remain a sound planning record. While no longer describing the cells immediate supply situation, it turns demand into warehouse work, applies configured location rules, and directs workers through picking and stock movements within the processes you've set up. Location rules help determine where warehouse work should happen depending on the process and configuration. They guide where workers pick stock or place material subject to the stock and location conditions the system knows about. Warehouse records describe completed transactions within those workflows. Their meaning depends on the required confirmation. A worker might confirm placement at staging, for example, without the WMS taking responsibility for the later delivery to assembly, ERP and WMS may share one application suite. Even then, separate their responsibilities in your design. One product can contain both business planning and warehouse execution without making every record interchangeable across those functions. It tracks execution at the operational cell, providing context about what production is working on and how material consumption relates to that work during the shift. That context helps interpret the need for our component. A planned order might call for a certain quantity across the shift, while current production progress indicates whether the next supply request needs attention sooner or later, consumption records need a clear meaning as well. Some processes record consumption from a workers confirmation, while others calculated from reported production. You need to know what evidence supports the quantity before acting on it. A fleet manager assigns and tracks vehicle missions while local automation coordinates movements and equipment interactions, such as transferring a load through a controlled pickup station. Their authority needs a firm boundary. A warehouse system can request a delivery, but the fleet system still needs to determine whether a suitable vehicle can accept and execute that mission under current operating conditions. Equipment coordination sits closer to the machinery where a vehicle exchanges material with a conveyor or another automated station. Local controls manage the required sequence and permissions before either piece of equipment completes its part. Safety stays within the engineered local control arrangements. Business urgency can change a requested priority, but it can't grant permission to bypass protective controls or require a vehicle to proceed through an unsafe condition. For each action name, the system allowed to request it, the system allowed to change it, and the system whose confirmation counts as completion changes need the same care as new requests. If production asks to cancel a delivery after collection, the warehouse and fleet systems need an agreed response that respects the Load's current position and execution state, I'd settle disputed authority with the process owners first. When the ERP w M, S, m e s and fleet system each have a clear job, an accepted request means someone owns execution and a completion confirmation carries an agreed operational meaning. Are those systems naming the same things? Our tote might carry a container label that the warehouse recognizes, while the transport system refers to a load and production recognizes only the component inside, those names need a dependable connection. You don't have to force every application to use identical codes, but you do need maintained mappings that let each system identify the same physical container without guesswork. Item identity needs more than a matching description. Two records, called assembly bracket, might describe different revisions, so the shared reference must preserve whichever distinctions determine whether production can actually use that material for the intended job. Locations need their own shared references a warehouse location, a vehicle destination, and a production receiving point may refer to related places, but your model must state whether they represent the same position or separate positions. If work is empty, a reusable tote and refill it with another component. The tote remains the same physical object, while its item, quantity and batch associations change. Keep the production order connected to the transport request two one order can require several deliveries, and one delivery may support several requirements. Those relationships need explicit records rather than assumptions based on similar names. If the warehouse counts individual parts while a transport request specifies containers, the receiving system needs a defined conversion that matches the actual pack arrangement for that item. A container isn't a fixed quantity by itself. In our hypothetical flow, a full tote might hold several packs, while a partial tote holds fewer container count alone can't establish how many usable parts will arrive. Pack size and container capacity describe different limits. Pack size tells you how parts arrive or get handled together, while container capacity constrains what fits safely by weight, dimensions or the approved packing arrangement. Conversions also need a controlled source. When a supplier changes the number of parts in a pack, someone must update the relevant item and packaging records before old assumptions start producing incorrect delivery quantities. The shared model should preserve whether material remains under inspection, carries a block, or belongs to a batch that the requested production order isn't allowed to consume. Batch rules must travel with the material reference. If an order requires a particular batch or forbids mixing batches, a matching item code, and sufficient quantity still leave the proposed container unsuitable for that request. Recording a rack address tells you where material sits, but choosing a workable move requires knowing which aisle reaches it and which handling equipment can enter that aisle. A permitted route depends on the load and equipment. A package suitable for a worker with a small cart may exclude a loaded vehicle, even though both destinations appear close together in the location. Records transfer points need specific connections. Record which storage areas can feed each point, which transport types can collect there, and which destination buffers can accept the resulting load without another unrecorded handling step line side buffers need physical limits in the model that includes usable container positions and access restrictions. An apparently empty floor area may still need to remain clear for workers handling material at the cell. Assign named owners for item packaging, location definitions, and permitted routes with a clear way for warehouse and production teams to report changes that affect those records. A moved rack needs more than a new floor label before its new position enters normal use. Check the location reference, access relationships and affected destinations, then agree when the revised records become valid across systems. Renaming a location shouldn't erase its history. Keep a stable identity behind the displayed name and control route revisions, so a temporary closure doesn't silently become a permanent assumption. After the aisle reopens, you can ask where an item should live using its handling needs. Actual quantities and reachable destinations. Rather than choosing a convenient address that the physical operation can't support, that placement decision has a name slotting. 00:17:27 Speaker: You choose where an item belongs by weighing demand. The work needed to handle it, and the storage positions that can actually accommodate it during normal operation. I'd start with the destinations the item serves and address that works well for customer dispatch may create repeated long trips for assembly, especially when production draws small quantities throughout the shift. Rather than collecting one large load, an item can generate frequent picks without moving much physical volume, while another leaves storage less often but requires a large load every time someone handles it. Those patterns call for different placement choices. A small component picked repeatedly may justify a position with easy access, because each extra stretch of walking repeats across many visits during the working day. A bulky item creates a different kind of space problem than you'd expect. Even if you don't pick it that often, it still needs a large storage position and a clear path for whatever equipment moves it, which immediately rules out a lot of otherwise convenient locations. Count visits and volume as separate things. If you rank items only by how many units move through, thousands of small washers can look more demanding than a few large housings, even when those housings take up way more handling space replenishment volume belongs in that calculation to a compact picking position might work fine for frequent small withdrawals, but the amount of material passing through that spot creates repeated incoming moves that also need room and access of their own. Available storage puts a hard limit on your choices. You're assigning real positions with fixed dimensions and load limits, so the nearest empty spot might still be the wrong place for the next container of parts. No matter how convenient it looks on paper, weight can rule out a position immediately. A heavy component needs the right rack and handling method, and repeated manual picks from an awkward height can turn what looks like a short route into physically difficult work that slows everyone down. Reach changes the effort within the pick itself for an item you handle, often a position that lets workers grasp and withdraw the part comfortably may matter more than shaving a few feet off the walking route. Compatibility narrows the options further. Materials that need separation because of contamination or chemical risks can't share a convenient storage area just because both appear frequently in the same warehouse workload. Temperature requirements can fix an item's storage zone. Within that permitted zone, you can still choose a more useful position, but demand doesn't override the conditions needed to keep the material fit for use. Lot rules affect physical arrangement to where your process requires a particular sequence of lot selection. Placement should let workers reach the permitted stock without moving other containers aside just to complete the pick. Access depends on how the item gets handled. A position can work fine for a person collecting a small pack, yet prove awkward for the truck, bringing in the larger load so both movements belong in the placement decision. Let's go back to our hypothetical assembly component. Suppose it's picking position sits close to dispatch because the warehouse originally used it mainly for customer orders before assembly became its largest source of repeated requests. The item hasn't changed, but its demand pattern has. Workers now collect small quantities for production throughout the shift, carrying those requests away from dispatch and toward a consumer on the other side of the warehouse. Its current address still looks convenient from the shipping doors from the assembly supply route, though that same address adds distance to each collection and those repeated journeys deserve more weight than the items old dispatch role. I'd compare feasible positions against that current demand. The question is which address best supports the actual mix of production and dispatch work while meeting the items, handling constraints, and fitting the storage space available, but nearby positions share their access space. Moving several frequently picked items closer to their consumers can draw more workers into the same aisle, so shorter planned travel can still leave people waiting to reach the stock. That changes what closer actually means. In practice, a location saves travel only if workers can approach it and complete the pick, which means storage placement also has to account for everyone else using that aisle. Suppose we move several popular components into one short aisle during the morning rush. Workers supplying assembly and workers preparing dispatch orders reach those positions together, each expecting the shorter route to help them finish sooner. The route calculation can still be correct. Each worker walks less, but now waits behind someone, checking a quantity, positioning a cart, or reaching a neighboring location that shares the same approach space. Those visits don't spread evenly through the shift. When several requests arrive together, an aisle that copes comfortably with average demand can become a queue. Precisely when production needs its next delivery most urgently, I'd compare travel savings with access delays. A placement candidate needs to account for when workers visit each location, not just how many visits appear in the total demand for the whole day. Related items create another placement choice if workers often collect two components on the same trip, placing them near each other can remove a repeated walk between separate storage areas during those requests. But check what picked together actually means in your records. Two items used on the same production order might leave the warehouse hours apart, so their shared order reference doesn't necessarily justify neighboring picking positions. Actual collection patterns give you a stronger basis, where requests repeatedly combine the same components. Nearby positions may help, provided several workers can reach those positions without blocking each other's carts, or access to stock replenishment adds traffic to those same positions, while one worker collects parts, another may need space to bring in replacement stock, and the resulting conflict can erase the time saved by placing related items together, a slightly wider spread might work better. You could keep commonly paired items within a short walk while distributing their pick faces across approaches that LED collection and incoming stock movement happen without constant interference. Then there's the cost of changing the arrangement. Moving stock takes people and equipment away from normal work. While the relocation itself may occupy the very aisles you're trying to make easier to use. Labels need to match the changed arrangement. Workers also need clear instructions about which positions remain active during the move, especially if some stock still occupies the old address while other stock reaches the new one. Learning takes time after the move ends. A worker who previously knew where to turn may pause to check each instruction, and that temporary slowdown belongs in the assessment. Rather than being dismissed as resistance, I'd ask how long the expected benefit should last. Moving an item for a brief demand surge may consume more effort than it saves, particularly if another move follows when the current production mix changes. Again. Historical demand helps separate a lasting pattern from a passing peak. Compare candidate positions using representative requests, including periods when production, supply, and dispatch compete for access, rather than selecting only a quiet shift that makes every arrangement look workable. Route assumptions need a physical check. If the comparison assumes cards can pass, workers can approach from either end or replenishment, never interrupts picking. Walk those routes and confirm those assumptions before trusting the estimated. Saving a controlled trial gives you evidence beyond the estimate. Change a limited set of positions. Keep a record of the relocation effort and compare the resulting travel and access delays against work with a similar demand mix. Keep the trial understandable to the people doing the work. Ask workers where they wait and which moves become awkward because a total task duration alone won't tell you whether the new arrangement creates repeated interference at one position, the trial may justify keeping only part of the change if paired items save walking, but one crowded location delays several other requests retain the useful pairing and reconsider that location. Rather than accepting the whole arrangement as one package. One more check belongs before calling the placement successful a pick face. The location workers collect material from must hold enough usable stock to support the visits that the new arrangement directs toward it during normal demand and easy to reach empty position still stops the request. The placement decision now depends on whether replacement stock can reach that position in time, without turning its convenient access into another recurring conflict between picking and replenishment. Replenishment needs to start before the shortage becomes visible. By the time a picker reports an empty position. The remaining work includes finding reserve stock, assigning the move, collecting it and bringing it into the picking area. Reserve storage and picking positions carry different workloads. Reserve storage holds larger quantities between receipts and withdrawals, while the pick face holds the smaller working quantity that workers need to reach repeatedly during current requests, their stock records need to stay connected through actual work. Creating a replenishment task doesn't put parts within reach, so the operation needs to distinguish stock requested for movement from stock physically available for picking. That distinction affects the next replenishment decision. If a move already covers the expected shortage, creating another task can send excess material toward a position that lacks enough room to receive both loads. A trigger sets the point for starting that work. You might use a stock threshold, demand from upcoming requests, or a combination that checks whether the remaining quantity can cover withdrawals. Until replacement stock arrives, the threshold needs to cover replenishment lead time. That means allowing for the time between triggering the task and making the stock available, including the waits that regularly occur before anyone collects the reserve load. Use an achievable lead time, not just the driving time, a move that takes little time once a worker starts can still require a much earlier trigger. When that worker normally finishes other assigned work, first demand changes what that protection needs to cover. If assembly requests several containers close together, a threshold based on evenly spread withdrawals may trigger too late, even though the total shift demand hasn't increased. Pack sizes then shape the quantity you can replenish where workers move sealed packs round the proposed quantity to a permitted pack amount, and check that the resulting load fits the available picking position. Too much replenishment creates its own obstruction. A rule that always sends a full reserve load may leave workers handling surplus stock beside the pig face, because the location only has room for part of it. Triggering earlier also changes competition for workers and access. The person assigned to replenish may already be collecting material elsewhere, while the destination isle may remain occupied by workers. Completing picks against other requests give replenishment a workable place in that shared workload. Waiting until every active pick finishes can leave replenishment permanently behind, but stopping all picking whenever stock needs moving can delay requests that already have material available. Consider a later request in our hypothetical plant. The pick face still contains enough parts for ordinary withdrawals, but an upcoming assembly requirement will consume more before the usual replenishment move can finish. The reserve quantity is sufficient, so purchasing isn't the immediate issue. Yet. The replenishment task waits behind current picking work, and the next production request reaches the pick face after the remaining usable stock has already left, the worker now faces an empty location and a pending request. Sending the worker back later doesn't remove the shortage. It adds another visit while the reserve moves still needs someone and somewhere to execute it. This is the failure the trigger should help prevent. If the upcoming requirement becomes visible early enough, the replenishment rule can bring the task forward while access and labor still allow completion before the larger withdrawal. When several pig faces approach shortage at the same time, the team needs to weigh which pending withdrawals depend on each move, rather than treating every low stock position as equally urgent. I judge the rule by usable stock at collection time. A task created early but completed after the picker arrives hasn't protected that request. Even if the system correctly recognized the falling quantity well before the shortage actually hit with replenishment working, the picking method has a fair starting point. From there, we can ask how to organize collection across requests, because comparing picking routes only makes sense when the required stock is actually there to collect. You can keep each order separate, combine several orders into one trip, or divide collection across warehouse areas. Each choice changes the work needed after picking discrete picking keeps one order together from the start. A worker collects its required items into the assigned container, completes the checks and passes that order onward without first separating its contents from material for other orders. That gives you clear ownership and fairly simple handling. If an item is missing or a quantity needs checking, the worker can relate the problem directly to the order. Rather than untangling several requests. Sharing one collection, the cost can be repeated. Travel when several small orders require items from the same locations, separate trips, and workers along much of the same path, even though each order contains relatively little material. Batch picking combines those collection trips a worker picks for several orders during one route, reducing repeated visits where the orders overlap, then ensures each collected quantity reaches the container assigned to its destination. The sorting work still needs time and space. You might separate orders into marked cart compartments during collection, or collect a combined quantity and divide it afterward, depending on the process and equipment available. Either method needs dependable identity checks. A correct total quantity across the batch doesn't prove that each order contains the right parts, especially when similar components belong to different destinations or carry different traceability requirements. Our assembly toad could share a trip with other requests. If those requests need the same component. One collection may reduce walking, but the worker still needs to separate and confirm the quantity intended for each receiving cell. Batch size changes that balance. Adding orders can increase the travel saved while also increasing the number of containers, checks and sorting decisions the worker must manage before those orders can move onward. Zone picking divides responsibility by warehouse area. Instead, workers collect the parts held in their own zone, while an order either passes between zones or brings it separately picked portions together at a consolidation point. Local knowledge can help. Within each zone, workers cover a smaller area and become familiar with its locations, but an order requiring several zones now depends on several people completing their portions and handing them onward. Consolidation becomes part of the delivery work. Someone or something needs to match those portions to the correct order, verify completeness and keep incomplete orders separate from orders that can proceed to their destination. Uneven workloads can leave one portion waiting for another. If most current orders need many items from one zone and few from the others, shorter local routes won't prevent that busy zone from delaying complete orders. I choose by order family rather than warehouse wide preference. An order with many items may justify its own collection trip, while repeated small orders with overlapping items may suit batching if separation remains manageable afterward, the item mix can settle some choices quickly. Large or awkward parts may consume the cart capacity that a batch needs, while small, similar looking parts can place more demand on identification and separation than their physical size suggests. Traceability can also narrow the workable methods. Where an order requires recorded batch or serial identities, the picking process must preserve those associations through collection and sorting, rather than trying to reconstruct them from the final containers. Separate orders don't automatically guarantee correct traceability, either. Each method needs checks at the points where material changes container or order association, so the comparison should include the actual confirmation work that each method requires. Downstream capacity belongs in the choice. If batch picking sends material to a sorting bench faster than that bench can separate and check it. The saved walking time creates a queue of unfinished orders. Zone picking can create a similar problem at consolidation. Measure how long complete orders take to emerge, including the wait for their final portion, rather than judging each zone only by how quickly workers finish local picks. A mixed approach may fit the demand better. You could keep awkward orders discrete and batch suitable small requests, provided workers can distinguish the methods and the receiving process can handle their different completion patterns. That leaves the amount of work entering each path. Even a suitable picking method can struggle when too many orders arrive together. Because sorting positions and consolidation space must absorb what the pickers send them next, you can have plenty of requests ready in the business plan without asking workers to start every request at once, particularly when the next handoff has limited room. A wave groups selected requests for release. Together, that grouping can help coordinate work around a departure time or a production supply window, giving the shift a defined set of requests to complete before that deadline. Smaller releases follow a different rhythm. Instead of admitting a large group at a scheduled point, you release smaller amounts as demand becomes actionable and the operation has room to carry them through. Neither approach removes the need for a capacity check. A wave needs a realistic size, while smaller releases need limits that stop frequent additions from quietly creating the same overload as one large release. Start that check with the stock needed for execution. If a request depends on replenishment, decide whether that move can finish before collection needs to begin, rather than releasing work that workers can only start by chasing missing material. Then check the people available during the relevant period. A release based on the full shift headcount can overstate capacity. When some workers are receiving deliveries, covering breaks or handling tasks that already have firm deadlines. Staging needs a check expressed in usable positions. Count the spaces suitable for the containers being released, allowing for material already there and loads expected to arrive before transport can clear those positions for re-use. Transport availability needs a time window to a vehicle available later doesn't necessarily support a release now, especially if the released work will reach staging. While the vehicles remain committed to other collections around the site, receiving capacity completes that check before adding work. Establish whether the destination can accept the expected delivery during its arrival window, including the people and space needed to receive it without holding up other loads. Picture a release surge in our hypothetical plant. Several production requests enter picking together the stock is ready, and workers complete the collections quickly enough that the shift initially appears to be running ahead of demand. Staging fills faster than the vehicles can clear it. Pickers bring the next containers forward, find their intended positions occupied, and spend time looking for somewhere permitted to put loads that nobody can collect. Yet the queue now interferes with further collections. A vehicle arriving for one container may need another load moved first, while pickers carrying completed work wait for staging space instead of starting their next assigned request. Releasing more work won't clear those positions. The useful response is to limit incoming work until transport creates enough room, while checking whether a smaller release can still protect the production deliveries approaching their deadlines. That limit should respond to changing conditions. If receiving pauses or vehicle availability falls, reduce the next release. When those constraints ease, admit more work without requiring the shift to wait for an arbitrary scheduled restart. 00:34:50 Speaker: Priority decides which requests use the available capacity. I base that choice on the delivery window and the consequence of delay. So an approaching production shortage can take precedence over material that won't be needed until later. Urgency alone can leave ordinary requests waiting indefinitely at an aging rule that increases a requests attention as it waits with a review point that forces someone to resolve repeatedly deferred work rather than leaving it behind every new, urgent arrival. That review needs authority to change the plan. If urgent demand consumes all available capacity. Someone must adjust delivery promises or resources, because moving every deadline forward in the queue doesn't create room for the work underneath. Keep priority changes deliberate rather than constant. Once workers start a feasible request, interrupting them for each new arrival can waste the capacity. The priority rule is supposed to protect and leave several requests. Partly finished. The release decision now has a concrete output. It names which requests can enter execution, their permitted sequence, and which requests remain held until a stock space, labor, transport or receiving condition changes enough to admit them. Those decisions have to become actual warehouse instructions. A release rule only controls the operation when the system creating and assigning warehouse work applies it, rather than leaving a supervisor to reconcile a separate priority list with whatever workers receive. For a site running dynamics three hundred sixty five supply Chain management. This becomes configuration work. Its warehouse management functions provide mechanisms for creating and directing warehouse work, but you still need to translate the operating rules into supported processes that workers can execute. Work templates define the structure of that work. For a supported process, a template can specify a sequence of pick and put steps with selection criteria. Determining which template applies to the transaction being processed. Location directives answer a different question where should those steps happen? They apply configured queries and actions to find suitable picking or placement locations using the conditions available to that process, rather than a worker choosing an address from memory. The distinction matters when you change a warehouse process if the intended steps remain correct but stock keeps reaching an unsuitable destination, investigate the applicable location directive before changing the work template that defines the steps. Consider our assembly component within a supported production supply workflow. You need to establish which work template applies and how the relevant location directives. Select stock and placement positions, then test the resulting instructions against the intended physical hand-off. You can have a template and a directive that each look perfectly reasonable on their own, but put them together and the combined result might send a worker through steps that don't match how the receiving position actually operates. That's the kind of thing you catch in testing, not in documentation. Wave templates and their configured processing methods determine how eligible demand gets processed, including the creation of warehouse work for whatever processes your implementation supports. But a wave isn't a complete capacity model by itself. If your release decision depends on conditions outside the standard workflow, you need to check how those conditions enter the process and what supported configuration or extension would enforce that decision. Dynamics three hundred sixty five supports approaches like minimum and maximum stock levels and replenishment connected to wave demand, but their suitability depends entirely on your warehouse setup and the scenario you're supporting. Test the resulting work, not just the trigger. Check which replenishment template applies, which locations qualify, and what happens when the requested quantity can't fit, or the preferred source doesn't contain eligible stock for that move? Configured mobile device menu items guide supported activities so the prompts and confirmations need to match the job someone can actually perform at that location. Each confirmation needs a precise operational meaning. If the app asks a worker to confirm placement, you need to establish whether that confirmation records a container entering staging, reaching your production input location, or completing another defined warehouse step. Its strength depends on what the workflow requires the worker to scan, which values the application validates, and whether the confirmation occurs where the material actually changes position. I test that with the device in a worker's hand. Follow the prompts and the exception paths a wrong location, an incomplete quantity, because the configured response determines what the resulting transaction can reliably prove. Confirm the deployed application version enabled functions, warehouse parameters, and mobile app setup. Then verify that the documented process covers your actual transaction type and operating conditions. Existing extensions need attention during that check. A familiar process name doesn't prove standard behavior because an extension may change work creation, validation, or confirmation in ways that affect both worker instructions and recorded results. Run it through the configured environment and inspect the work it creates. The mobile prompts it presents, and the inventory transactions it posts before treating the proposed design as supported. That gives dynamics three hundred sixty five a clear execution role. It applies configured warehouse rules and records the transactions completed through those workflows, while your process design establishes what each recorded confirmation means in the physical operation, a warehouse work record can establish that a configured step finished, but it doesn't automatically document every movement or pause between the workers confirmations along the toad's journey. That's the boundary I'd keep explicit before using those records to explain delivery time. Distinguish the business steps they confirm from the physical movement history. You would still need to establish separately for the same container before using it. To explain a delay, check which action sets that time and whether it records the workers confirmation or a later processing step. Those moments can differ. A device might submit a confirmation after the physical placement, and an integration might receive the resulting record later still. So each timestamp needs a documented meaning. Follow a completed transaction through its capture and processing. Then establish which recorded time supports the operational question you want the integration to answer. A work header may also hide several separate steps. If you need the time of placement at staging, a timestamp for the overall work completion may be too broad. When that work includes other actions. The warehouse confirmation establishes one handoff, but the container might remain at that position until someone collects it, leaving a gap that the warehouse transaction alone can't explain. Pick up closes that gap only if something records it without a collection confirmation from the transport process, you can't tell whether the toad spends most of that interval awaiting collection or already travelling toward assembly. A transport record might establish that the load reaches its assigned destination, while production acceptance follows later. Because someone still needs to receive and check the delivered material. Keep those milestones separate in the integration, warehouse completion, physical pickup, arrival, and acceptance. Each answer a different question and collapsing them into one delivery timestamp removes the evidence needed to locate the delay. First, decide whether you're reading a completed transaction, receiving notice of a change, or asking another system to perform an action because those exchanges need different handling. Then establish how quickly the information needs to arrive. A historical investigation may tolerate periodic extracts, while a process reacting to pending collection needs a shorter delay and a clear understanding of what the available interface can deliver. Reading occasional warehouse work updates creates a different load from collecting frequent movement observations, so assess expected traffic and supported limits before choosing one route for both kinds of information. Check the interfaces available for that specific process. Depending on the deployed environment, supported options can include APIs, data entities, or business events, but you need to verify their coverage rather than assume every record has an equivalent interface. An interface suitable for retrieving work history doesn't necessarily support changing that work, and its refresh behavior may be acceptable for analysis without meeting an operational response requirement. Business events can report supported business changes with dynamics three hundred sixty five provides an applicable event, a subscriber can receive a notification and use its documented contents to identify the change or retrieve the related detail. Confirm what causes the event which identify as it carries, and whether it contains the information you need or simply tells you that something warrants another supported read. Don't assume an event exists for every physical handoff. If the standard event coverage doesn't include your required occurrence, assess a supported extension or another capture path with the application owner responsible for maintaining that design. A warehouse business event won't automatically provide the Tote's departure from staging or its progress through the plant unless the relevant process explicitly captures and exposes those occurrences. Ask the transport system what it can actually report. It may expose collection and arrival confirmations, while other observations require equipment side capture, and the available detail depends on the installed system and its supported interfaces. If confirmed, pickup and arrival explain the transport interval adequately. Collecting continuous position updates may add data volume without improving your understanding of when production receives usable material. The connection now has a specific job. It links the warehouse confirmed handoff to evidence from the movement that follows, while preserving the difference between a business transaction and an observed physical occurrence. To explain the interval between warehouse confirmation and delivery. We need to examine what the transport system knows about that mission and which parts of its record correspond to the tote itself. The vehicle label tells you less than you might expect. Automated guided vehicles, agvs and autonomous mobile robots. Amrs describe broad equipment categories, while the installed navigation and control systems determine how each vehicle actually moves. Amrs commonly navigate from a map and can adjust their path around obstacles, but those labels alone don't establish how freely a particular vehicle can reroute. Ask what the installed system permits. A robot capable of choosing another path may still operate within tightly defined routes, and its reported status needs to reflect those operating limits rather than the equipment brochure. That record should let you distinguish a request waiting for a response from a job. The transport system has accepted responsibility for executing under its own rules. Requested doesn't necessarily mean accepted. The interface might acknowledge receipt of a message before the fleet application validates the destination, checks the request details, and creates an executable mission in its own records. A mission can enter the fleet's workload without a vehicle assignment, while dispatch can indicate that a particular vehicle has received instructions but hasn't yet reached the load, those distinctions explain apparently inactive periods if the tote weights while its mission remains accepted but unassigned. That's different from a dispatched vehicle traveling toward the pickup position, even though neither has collected it. Establish whether that state follows a confirmed transfer onto the vehicle, a station signal, or simply completion of a programmed step that assumes the transfer succeeded. Delivered needs the same examination. Depending on the vendor's definition, it might mean the vehicle reached a destination, completed unloading, or received a successful transfer signal from the destination equipment during that mission. Cancellation records and intentional termination while failure reports an unsuccessful execution condition. But either state still needs enough detail to establish whether the tote remains aboard the vehicle. A mission can fail after collection if the interface returns only failed. The record leaves an operational question unanswered. Where does the physical load remain, and does the mission retain its association with that load position can indicate that a dispatched vehicle hasn't progressed, but you need to know whether that position comes from a recent observation or an older update still presented as current load state adds a different kind of evidence. A vehicle reporting itself occupied may carry our tote, another container, or a load whose identity isn't exposed. So occupied status alone can't establish which request is progressing. A partly charged vehicle might comfortably complete its assigned work, while another with more charge may remain unavailable because the fleet's charging rules prevent it from accepting another mission. So the number alone doesn't tell you much. You need to know what the rules allow. Charging status describes activity, not merely remaining energy. You have to distinguish a vehicle traveling to charge from one already connected to a charger, because those states explain different intervals when the vehicle isn't carrying requested material, one is on its way, the other is actually plugged in. Blockage reports also need interpretation. A stop vehicle might be waiting behind another vehicle, detecting an obstruction or awaiting a station response, and the available reason codes determine how precisely you can explain that pause. Without good codes, you're guessing. I'd verify these meanings with the vendor's interface documentation For each timestamp, establish whether it represents the actual occurrence, the controller's processing time, or the moment the vendor's server publishes the update to an external subscriber. Those three can be hours apart. Check mission identity across retries and restarts. If the system replaces a failed mission with a new identifier, retain the relationship so one physical delivery doesn't appear as two unrelated journeys in your investigation. That's a common data trap. Then check coverage and update frequency. Some interfaces publish state changes immediately while reporting position periodically, and others expose only current status, so a brief blockage or intermediate mission state might never reach your records. You won't know what you're missing. Ask how silence should be interpreted and unchanged status might indicate normal operation with no new event, but it might also reflect a disconnected interface, so freshness needs an explicit check alongside the reported state. Don't assume no news is good news now vehicle status can inform a material decision awaiting RTO. It matters differently when its destination has ample stock than when production approaches a shortage. So the next question connects what the fleet can do with when those parts become necessary. I'd give dispatch a deadline tied to material use. The useful question is whether a feasible collection now can get the tote to assembly before the remaining usable stock runs out, allowing time for the receiving step. That's the real constraint. That shortage time is an estimate, not a fixed appointment. If the cell changes its production pace or switches jobs, the estimate needs updating before it continues to drive transport priorities that no longer match the work. Stale estimates cause bad decisions. Delivery windows add another boundary to the decision. A request can need attention before shortage becomes imminent because it's permitted. Receiving window closes soon, leaving no suitable opportunity to deliver during the next part of production. The window matters as much as the stock level request. Age should influence the choice without replacing those deadlines. An older request deserves review when newer work repeatedly passes it, particularly if its delivery still matters. But nobody has attached an immediate shortage warning to it. Age is a signal, not a rule. I'd compare the time remaining with the time still required. A request with a later shortage can need dispatch first if its collection and delivery take longer than another request that appears more urgent from the deadline alone. The math changes when you factor in travel time. Priority ranks the need assignment checks whether the move can happen before offering the mission to a vehicle. Establish whether its load capacity and transfer equipment suit the actual container, including its dimensions and how it gets loaded. A vehicle that can't carry the load is useless. A vehicle can be available yet unsuitable for this tote. A platform intended for a particular cart interface can't necessarily collect a pallet or another container type, even when the load's weight falls comfortably within its rated capacity, the interface matters more than the weight limit. Route access narrows the eligible vehicles further. The proposed assignment needs a permitted path that the vehicle can use with this load, rather than simply a destination that exists in the fleet systems map. A valid destination with no valid route is a dead end pick up readiness needs a physical answer if the tote still needs its final check or sits behind another container, sending a vehicle immediately can occupy the collection position without advancing the delivery production actually needs. You're just creating a traffic jam. The destination needs room. Before the mission starts, check whether a suitable drop off position will be available when the load arrives, and decide who must confirm that availability when another delivery already occupies the position. Sending a vehicle to a full dock wastes everyone's time. External priority requests should express the business need. They can supply the requested delivery window and shortage estimate. While the fleet manager retains responsibility for vehicle assignment and mission execution within its supported operating rules. Keep the roles clear. I'd avoid a second dispatcher outside the fleet system. If an external service keeps choosing individual vehicles or changing active assignments independently, the fleet manager loses a dependable view of the work it's expected to coordinate. Two dispatchers means no one's in charge. Agree on what a priority change can actually affect. The fleet might apply it only to waiting missions, for example. So the requesting system needs to understand whether an accepted update changes the queue or an assignment already underway. Set expectations upfront. consider an urgent delivery in our hypothetical plant assemblies. Remaining stock is falling, the tote is ready for collection and a suitable vehicle is idle, but the destination transfer point still holds a container from an earlier delivery. Everything looks good except the one thing that matters the missing capacity belongs to the transfer point. Dispatching the waiting tote would send the vehicle toward a position that can't receive it, potentially leaving both the urgent material and its assigned vehicle unable to complete their next step. That's a double failure. Adding another vehicle wouldn't clear that occupied position. The immediate response is to identify who can remove or receive the existing container. Establish when that can happen and check whether the urgent tote still has a workable delivery window. The bottleneck is human, not robotic. That answer changes the dispatch decision. The fleet could hold collection until the destination clears or use another approved drop off point, but only if that alternative preserves the required receiving process and production can actually access the material there. Not all alternatives are equal. An alternative destination needs explicit agreement. Otherwise, the system may report a successful urgent delivery while assembly continues searching for a tote that now sits somewhere convenient for transport but outside the expected receiving arrangement. You solved the wrong problem. Clearing one position can also depend on someone else's movement. A forklift may need access to remove the existing load. A worker may need to receive it, and a robot may already be approaching the same transfer area. Everyone's waiting on everyone else. Dispatch therefore depends on more than the robot queue. Once several transport types and people share the approach, the practical question becomes how their movements interact at the places every delivery must pass through to reach its destination. The intersection is the real constraint. Shared access deserves its own operating rules. At a pedestrian crossing, a forklift driver, a worker pushing a manual cart and a mobile robot can each need the same space for different reasons. One space, multiple users no clear priority. Their movements don't follow the same pattern. A robot may approach along a repeatable route, while a worker changes direction to collect packaging, and a forklift needs extra clearance to turn with its load predictable and unpredictable traffic mix in the same corridor. 00:52:25 Speaker: A clear passage can become occupied very quickly. Someone opening a card gate or stepping back to pull a container can enter a space that looked available when another movement started a few moments earlier. The window closes faster than any system can react. I'd examine the working area, not just the marked travel lane. Watch where people stand during loading, where card handles extend, and where drivers position equipment before turning. Because those actions determine how much room the task actually needs, the lane is only part of the story. A stopped robot doesn't necessarily indicate a fault if someone enters its protective field, stopping may be the correct response, while repeated stops at that location suggest the surrounding work arrangement needs a closer examination. The robot is working correctly and the layout isn't. The response belongs in the site's engineered safety arrangements. Protective devices and safety related controls need to act locally within their validated design without depending on a cloud connection or an analytical service interpreting the situation. Safety doesn't route through the cloud. Cloud analysis can help identify recurring interference. It can support a proposal to separate traffic or change a delivery period, but permission for equipment to move must remain with the appropriate local controls and operating procedures. Analytics inform safety hardware decides that distinction matters when someone proposes reducing stops changing a protective field, a speed limit or a crossing arrangement requires the proper safety review rather than a software adjustment justified only by shorter journey times. Speed isn't worth a safety violation. Doors deserve particular attention because they interrupt otherwise open routes. A vehicle may need to wait for an opening sequence, confirm clearance, and pass completely through before another movement can begin. From the opposite direction, doors create hidden bottlenecks. A lift introduces a different shared limit. Its doors usable load space and transfer sequence can restrict movement between floors even when every vehicle approaching it has a clear route and an available destination, the lift becomes the single point of failure. Intersections can lose capacity without anything breaking. A turning forklift may temporarily occupy both approaches, while a pedestrian crossing nearby prevents another movement from clearing the space needed for the next turn to begin. Nothing. Failed. The geometry just doesn't work. Loading stations have their own working envelope positioning a load, securing it, and withdrawing handling equipment can occupy the approach longer than the actual transfer, particularly when the worker needs access from more than one side. The setup time dominates. Narrow aisles limit how much work can happen together. If a cart blocks access while someone picks or unloads, the practical constraint may be the task taking place there rather than the distance anyone needs to travel. The aisle width is a capacity limit. I'd observe these places during their busiest overlap. A route check between deliveries can miss the forklift arriving during a shift change, or the manual cart waiting beside a loading station when another load needs to leave. Peak times reveal the real constraints. Any proposed change needs a worker access check. Ask whether people can still reach controls, remove packaging, inspect a load and handle exceptions without stepping into a vehicle route or squeezing between equipment and stored material. If workers can't do their jobs, the change fails. Evacuation routes need protection through the whole operating cycle, a position that stays clear during routine deliveries may still become obstructed. When a vehicle stops, a cart remains unattended or workers temporarily hold material during an exception. Emergency access can't be an afterthought. Ergonomics belongs in that review as well. Moving a station away from traffic might improve separation, yet force workers to pull loaded carts around a tight bend or repeatedly reach across an awkward transfer surface. One problem solved, another created. I'd involve the people who perform those tasks. They can explain where a plant movement requires an extra step, where a heavy cart becomes hard to control, and which access space disappears once normal work begins, the operators know the real constraints. The site risk assessment needs to reflect the revised operation. Review the interaction between people and equipment with the responsible safety specialists, and establish what training markings, controls or physical changes are required before introducing it. Don't skip the paperwork. Then we need evidence about the remaining delays for a crossing door or loading station. The investigation should distinguish the approach from the pause and the clearance with enough context to explain what occupied the shared space. Three different delays. Three different fixes. A position trace alone won't explain every stop to tell whether a vehicle waited for a pedestrian, a door response, or another load being handled. We need recorded occurrences tied to those physical handoffs and interruptions. The trace shows the symptom, not the cause. For our tote collection, completed records, a specific occurrence while currently in transit describes a status that could stay the same across many observations from the transport system. That difference determines what you can actually reconstruct later. Repeated snapshots showing in transit don't establish the exact collection time unless the source also provides a transition record or some other explicit indication of when collection happened. Give each event a defined meaning before you choose its fields. A collection event should specify what information qualifies as collection, so everyone interpreting that event understands what physical occurrence the source claims to have recorded. Start with the source and an event identity. The source identifies the application or equipment producing the record, while a unique identifier within an agreed scope lets you recognize that particular occurrence when its message arrives again. The event identity isn't the tote identity. A reusable tote can generate many collection events over its working life, and each occurrence needs its own reference without changing the identity of the container involved. Preserve event time and receipt time separately. Event Time describes when the source reports the occurrence while receipt time describes when you're receiving service obtains the record, making the communication delay visible rather than hiding it. Location should describe where that occurrence happened. If the event also carries the intended destination, label it separately, so a planned receiving position can't be mistaken for evidence that the tote already reached that position. Quantity needs a unit and a clear subject, a record reporting one container and a record reporting one part. Describe different quantities, so the event must state what was counted and which material association applied at that moment. Reasons should explain exceptions using agreed meanings. A cancellation reason like destination unavailable needs a defined interpretation, while an absent reason should remain unknown. Rather than being treated as evidence that no obstruction existed. These fields become useful when their references connect. Our collection event needs a dependable relationship to the container, the relevant warehouse work, the transport mission and the production demand that prompted the delivery in the first place. Those references won't always fit a single straight chain. If one transport mission carries containers for different requirements, preserve the individual associations so a mission completion doesn't automatically mark every production requirement as fully supplied. Partial quantities make that especially important when a request receives material through separate deliveries. Each event needs enough quantity and identity detail to establish which portion it concerns, without implying that the entire requirement moved together. Keep those associations valid for the occurrence being recorded. If a container gets reassigned later, joining an older event only to its current contents could incorrectly attribute yesterday's movement to the material it carries today. Message delivery will complicate this history, even with sound definitions, a sender can retry after losing an acknowledgment, leaving the receiver with another copy of an event that had already stored and processed successfully. Recognize the repeated event before counting another movement. Retain enough processing history to prevent the same occurrence from increasing delivered quantity twice, while distinguishing a duplicate message from a genuinely repeated action involving the same tote. Late arrival needs different treatment from duplication. A previously unseen collection event might arrive after the delivery event, so the receiver must accept that new evidence without assuming the order of receipt matches the physical sequence. History may need correction. When that evidence arrives, a previously unexplained interval can become measurable, but any revised duration should remain traceable to the late record rather than silently replacing an earlier result without explanation. Clock differences can also distort the apparent sequence if the warehouse clock runs ahead of the fleet clock. A valid pickup might appear to precede placement, producing a negative interval that describes clock disagreement rather than physical movement. Document clock synchronization and retain the original timestamps where timing remains uncertain, record that uncertainty and use source sequence information when available, rather than inventing precise ordering that the evidence can't actually support across systems. Receiving order alone won't resolve those conflicts. Your processing rules need to distinguish a new observation from an older event arriving late, so historical evidence doesn't overwrite a more recent known state merely because its message arrived last. That gives the connection to Azure a clear responsibility. It needs to carry the occurrence, its meaning, its references, and its timing evidence intact, including duplicates and late arrivals. Rather than turning each incoming message into unquestioned operational truth. A Supported dynamics three hundred sixty five interface supplies the relevant business information to an integration service, which handles its onward delivery without adding analytical processing to the warehouse transaction itself. That service needs somewhere to hold its progress. If it retrieves change records periodically, it should retain a reliable continuation point and handle interrupted retrieval without silently skipping the records between one successful run and the next. A notification based connection has a different responsibility when a supported business event prompts a further read, the integration service needs to manage that read explicitly, including temporary failures that prevent it from retrieving the related warehouse detail. The fleet connection enters through a separate adapter. That adapter translates the vendor's message format into the shared event contract, while keeping the original message available when someone needs to investigate a translation or source issue. Translation needs controlled rules rather than convenient substitutions. If the vendor supplies a state that your contract doesn't recognize, preserve it for investigation instead of forcing it into the nearest familiar state and changing its meaning. Contract versions need attention. As interfaces change, a vendor update that changes a field or introduces a new message type should trigger testing, rather than quietly changing what downstream consumers receive during an ordinary operating shift. For a busy observation stream, Azure event hubs can handle ingestion. Producers send events into a partitioned stream, and separate consumers can read that stream at their own pace, without each producer maintaining a separate connection to every downstream service. Partitions affect how consumers process the stream. Ordering applies within a partition, so the partitioning choice should support the relationships you need to process together without assuming that event hubs establishes one sequence across every source event. Hubs retains events for a configured period. That retention lets consumers recover from interruptions or reread available history, but it doesn't replace a deliberate long term storage plan for records you need beyond that period. Azure Service Bus fits a different messaging need. Its queues and topics. Support application messaging where a receiving service accepts responsibility for processing a message with mechanisms such as message locks and dead letter handling for unsuccessful processing that can suit a request moving through a business workflow. The receiving application still determines what successful processing means, because accepting a message from Service Bus doesn't itself establish that the requested warehouse action has physically occurred. I'd keep observations and commands on clearly separated paths. An observation reports evidence for consumers to interpret while a command requests work from a named owner, so their processing and recovery rules need different outcomes. Replay makes that separation very practical. Rereading yesterday's transport observations should rebuild analytical history without sending yesterday's movement requests back into execution, simply because both message types passed through the same ingestion process. Durable storage gives the observations a longer working life. You can retain incoming records in Azure storage through a capture mechanism or a dedicated consumer, with access and retention settings matched to the history the operation needs. Keep an original copy alongside the processed representation. When a translation rule changes, that original record lets you reprocess the evidence rather than trying to reconstruct a vendor message from fields that an earlier transformation discarded. Consumers also need checkpoints that match completed. Processing a checkpoint records how far a consumer has progressed, and advancing it before the corresponding output is safely committed can leave a gap after that, consumer restarts. Advancing it later creates a different recovery case. The consumer may read some events again after a restart, so its rights need to tolerate repeated processing without creating another stored movement for the same occurrence. Independent consumers should maintain independent progress. A service building historical records shouldn't lose its place because another service pauses for maintenance, and one consumer's successful read shouldn't imply that every downstream destination received the information. Replay needs an explicit operating procedure to define the period being reread and the output being rebuilt. So a correction to historical processing doesn't mix old and new results without anyone knowing which rules produced them. The next step connects that stored history to warehouse records. Use the preserved references to associate movement events with the relevant work and demand, while retaining enough historical detail to interpret those associations as they applied during the journey. Then, analysis has something specific to work with. It can follow a released request through recorded handoffs and compare that sequence with the warehouse's business history without treating a successfully delivered message as proof of successfully delivered material. The analytical question now gets more specific which warehouse conditions accompanied the delay, and did those conditions affect every request or only material serving a particular production area during that part of the shift? Microsoft Fabric is one option for bringing that evidence together. It's analytical storage and processing capabilities can combine movement history with replicated or extracted orders, inventory information, and warehouse work using supported connections appropriate to each source. I'd organize that information around questions the operation needs answered. For example, an investigator should be able to select a delayed supply request and retrieve the relevant demand, warehouse activity and material status without manually searching several applications. The timing of those records still matters. If your inventory extract represents the end of the shift, it can't establish what stock was available when an earlier request entered execution, unless you also retain the relevant changes. Make that limit explicit in the analytical model. Distinguish current inventory from historical inventory evidence and identify when an order or work record was last refreshed so people know which conclusions its contents can support. Here's where fabric real time intelligence actually helps. If you've got the right connections and deployment in place, an event house can hold event data for queries that examine recent activity, while new records keep arriving through the ingestion path. That makes investigating recent delays much more straightforward, an operational query could identify requests whose recorded progress has stopped, then link those requests to the relevant warehouse area and production destination using whatever business context you've got available. You're not guessing. You're tracing the actual path. Recent information and historical analysis need different working arrangements, though you might query recent events frequently while keeping a longer history in a lake, house, or warehouse where broader comparisons don't compete with every incoming update for the same resources that separation matters, choose that arrangement against the actual response requirement. If a supervisor reviews supply performance once per shift, maintaining a complex, low latency analytical path might add support work without changing any decision the supervisor can actually take. Don't build what you don't need before you publish a release to receipt duration. Agree on which release occurrence starts the interval, which acceptance ends it, and how the calculation handles requests with more than one qualifying record. Get that nailed down first. Incomplete requests need deliberate treatment to a measure based only on completed journeys can improve while unfinished requests accumulate, so identify whether the result covers completed deliveries or requests that enter the process during the selected period. Those are different populations, not interchangeable time filters. Filtering by receipt data answers what finished during a shift while filtering by release date follows the work admitted during that shift, including requests whose receipt may occur later. Keep that distinction clear. Exclusions should remain visible to the person interpreting the result. If cancelled requests or approved holds receive different treatment, name the measure accordingly and make the excluded population available rather than burying that choice inside a calculation. Transparency saves confusion. Later shift calendars deserve the same care. When a shift crosses midnight or a site changes its clocks, calendar dates alone can split related work incorrectly, so the analytical model needs the agreed operational calendar and time zone. Get that right from the start. I test the measures against individual requests with process owners. Pick examples with an ordinary completion and an exception, then confirm that the calculated result matches the documented definition before comparing areas or drawing conclusions about their performance. Trust but verify historical joins. Broad queries and report refreshes should run against analytical copies with extraction loads managed so an investigation doesn't slow the application workers rely on to finish their tasks. Don't let analysis become the bottleneck. Fleet control needs the same separation. A report refresh, an analytical capacity limit or an unavailable query service shouldn't become a prerequisite for a vehicle completing the mission. Its local execution system already owns. Production comes first. Data freshness belongs beside the interpretation, not in a footnote. If warehouse records refresh less frequently than transport events, an apparent mismatch may reflect different update schedules rather than material moving without the required warehouse confirmation. Know what you're looking at. A lengthy delay on material required to morrow deserves a different response from a shorter delay on a component needed now, even if the first interval dominates the warehouses time totals. Context is everything. I'd bring that distinction into the analytical result itself. Associate delayed requests with their required supply windows and affected production needs while labeling any missing context. Rather than assigning urgency from duration alone, that changes which delay deserves attention. First, the request worth investigating first may be neither the oldest nor the slowest, but the one whose remaining delivery margin threatens the next production operation, waiting for its material prioritized by impact, not by age. You need measures that connect the delivery result to the work involved, so an improvement in one part of the journey doesn't conceal a deterioration elsewhere. Keep elapsed time as the main duration for the released request beside it. Record active time and confirmed queue time, leaving uncertain intervals visible rather than forcing them into whichever category makes the result easier to explain. 01:09:57 Speaker: Then add first pass completion to that same journey. Count whether the delivery reaches acceptance without a correction, such as replacing an incorrect container, collecting missing parts or returning material that the destination can't use for the request. A corrected delivery can still meet its deadline, but if that success requires another trip and repeated checks, the on time result hides extra work that consumes capacity needed by other requests during the shift. First, pass completion makes that extra work harder to overlook. Define what counts as a correction consistently, and distinguish a planned split delivery from an incomplete delivery that requires an unplanned follow up to meet the original requirement. On time line side delivery should reflect accepted material at the required point, with the denominator covering the requests due in that period, including those still missing when their window closes. That gives you a service result, but production needs another measure. Record shortage incidents, where required, usable material isn't available for the intended operation. Whether or not the warehouse request itself carries a late status in its records. A shortage doesn't always stop production immediately, though the cell might use its remaining buffer or switch work, so record material related production waiting separately from the occurrence of the shortage that prompted that response. Be precise about whose time you're counting. A cell waiting for parts for ten minutes represents a different measure from the combined waiting time of everyone assigned there, and both need their own labels if you use them. Avoid attributing every production pause to a nearby late delivery. Confirm that unavailable material prevented the intended work because an equipment fault occurring at the same time could otherwise inflate the waiting attributed to warehouse supply. The relationship between these measures tells you where to question the result if delivery reliability improves, but shortage incidents persist. Check whether the delivery promise actually matches production need rather than assuming the warehouse result settles the matter. A route that usually performs well but occasionally leaves production waiting can require more protection than a slightly slower route, whose deliveries remain within a predictable range. Use a middle of the pack duration to describe the ordinary journey, then examine the slow end separately, asking how long the delayed deliveries take and how often those extended waits occur during otherwise normal operations. Don't bury those waits inside one site. Wide average separate routes, shifts and demand types because regular production replenishment and urgent replacement requests may experience different delays even when they share some warehouse locations and transport resources. Keep the comparisons fair as you split them a shift. Handling more awkward loads or urgent requests shouldn't appear less effective simply because its demand mix differs from the shift, receiving easier, more predictable work. Small groups need caution, too. If a route handles few deliveries, one difficult request can dominate its result. So retain the request count and inspect the underlying journeys before treating the pattern as established. Suppose a hypothetical shift raises its pick rate while completed containers accumulate in staging, leaving more released requests unfinished at the end of the same operating period. The pick rate gain is real, but the delivery gain isn't established. Review that gain alongside staging occupancy, Q age accepted deliveries and production waiting so faster collection doesn't earn credit for merely shifting unfinished work downstream. I'd keep those consequences attached to any productivity claim. A change deserves support when it improves the delivery promise without unacceptable extra handling or waiting, rather than when one team can report more completed tasks. The remaining question concerns each missed promise for every late delivery, identify which condition prevented its next required handoff at the relevant time, rather than stopping at a duration or assigning responsibility to whichever team confirmed completion last. The last recorded delay can point you toward the wrong cause. A transport mission can finish late because the fleet lacks capacity, but it can also finish late because earlier decisions leave too little time for an otherwise ordinary trip. Read the sequence backward from the missed acceptance. Establish when the tote became ready for collection. Then ask which earlier occurrence determined that readiness, and whether the transport system could reasonably have completed delivery within the remaining time its replenishment task starts waiting before the pick begins and two changes in warehouse priority. Push that task behind other work while assembly continues consuming its remaining components. The first change protects an approaching dispatch deadline. The second favors a newly urgent production request, leaving our replenishment task unfinished even though its original delivery requirements still stands and its available margin keeps shrinking. Eventually, someone completes replenishment and the picker prepares the tote. The transport mission then enters the fleet queue with almost no margin, so a routine wait for assignment carries it beyond the required delivery time. The mission record accurately reports a late delivery, but speeding up transport wouldnt address the repeated deferral that consumed the delivery margin before the tote became available, and the next similar request could fail the same way I'd reconstruct what each priority change actually displaced. Compare the task sequence before and after each change, using the recorded readiness and completion times to establish whether the affected replenishment could have finished earlier with the resources, then available sequence alone doesn't prove causation, though a priority change occurring before a delay deserves investigation, but you still need evidence that it postponed executable work rather than changing a task already blocked for another reason. That distinction keeps the diagnosis grounded. If reserve stock couldn't be accessed during the disputed interval, reversing the priority decision might not have advanced replenishment at all, despite its apparently suspicious position in the history. For the same operating interval. Count requests entering the relevant queue requests leaving it, and the usable resource time available to complete that particular kind of work. Matching periods matter more than convenient totals. Comparing a morning queue peak with full shift throughput can hide a temporary shortage of capacity because quieter hours later compensate numerically without rescuing the deliveries due earlier resource availability needs the same time boundary. A worker assigned elsewhere during that peak doesn't provide replenishment capacity. Then, even if the staffing record lists that worker as present for the entire shift, match the resources to the moment they're actually needed. Watch how the queue changes during those intervals. If ready, work keeps piling up while completions stay flat and the required resources stay busy. You've got evidence of a capacity constraint during that period. Idle resources point to a different question. You need to check whether queued tasks actually qualify for execution. Missing stock or inaccessible pickup positions can leave a long task list without enough ready work for the available resource. Little's law gives us a useful consistency. Check here for a clearly bounded flow and a reasonably stable conditions. Average work in process equals average throughput multiplied by average elapsed time through that same flow. Put simply, unfinished work connects completion rate to time spent inside. In a stable flow, completing ten requests per hour, an average of twenty requests inside the boundary means an average elapsed time of two hours. Make sure you're using matching units and populations if throughput counts. Containers while unfinished work counts production orders containing several containers, the calculation mixes different subjects and won't describe a meaningful elapsed time for either one. Stability also limits what you can interpret a queue growing throughout the observation period. A short disruption or requests crossing inconsistent boundaries can make a simple average misleading, so don't treat this relationship as a minute by minute dispatch rule. The relationship doesn't identify the cause by itself. It helps test whether reported queue sizes, completion rates, and elapsed times make sense together, while the event sequence explains which conditions might account for that result. Now turn the diagnosis into a testable change if repeated priority changes look like the culprit, limit those interruptions for a defined trial and track replenishment readiness. Transport weighting and accepted deliveries during comparable operating periods. Keep the displaced requests in that assessment. Protecting our towed only counts as an improvement if the change doesn't create worse missed deliveries elsewhere, so the experiment must follow consequences beyond the task whose delay first caught your attention. Following those consequences requires a way to connect affected resources and requirements. The useful model lets you move from a constrained location to the materials it holds, then to the production needs that depend on those materials. A digital twin can provide that maintained representation for this warehouse. It might represent selected storage areas, transfer stations and lineside buffers, together with the operational state needed to answer a specific supply question. The word maintained carries most of the work here. A transfer station, represented as available yesterday, tells you little about its usefulness. Now, unless the model receives updates and preserves enough timing information to qualify that state. Its scope can stay quite small. You might represent a receiving buffer's occupied positions, and accepted container types without modeling it's paint, color, manufacturer or every physical detail someone could collect about it. Choose those details around the decision. If the question concerns whether a destination can receive another tote, its usable capacity and current occupancy deserve attention before details that never change the answer to that question. A knowledge graph puts connected facts at the center. It describes how a material relates to permitted locations, how those locations connect through routes, which resources can use, those routes, and which production needs depend on that material. Those connections support a different kind of question. Instead of asking only where a tote sits, you can ask which production requirements become exposed when the resource serving its location can no longer perform the required movement. Consider a lift serving storage on an upper floor. A connected model could link that lift to the routes passing through it, those routes to the storage locations they serve, and the stored materials to their production requirements. That lets an application follow the dependency outward, starting with an unavailable lift, it can identify potentially affected requirements, then use the connected facts to distinguish them from requirements supplied through locations with another permitted route. A graph can express alternatives as well as dependencies. One location might have access through another lift, while a particular container type remains excluded from that alternative because the transfer arrangement doesn't support its handling method. Digital twins and knowledge graphs can overlap. Here. The twin represents relevant physical assets and their maintained state, while the graph organizes connected facts that let an application follow relationships across those assets and the wider operation. Azure Digital Twins is one possible relationship layer. You can define models for relevant entities, create digital twins from those models, and connect them through relationships that applications can query within the services supported capabilities. The surrounding services still have jobs to perform. Source integrations must update the represented state. Analytical services must calculate broader performance results, and an optimization service must evaluate choices against its own objectives and constraints. The relationship layer supplies context to those services. It doesn't automatically infer every operational dependency from your warehouse records, and it doesn't turn a connected representation into a production ready optimization engine without additional logic and integration. Before choosing a graph, test the actual questions. If most queries retrieve a request, its assigned container and one destination. A relational database with clear tables and joins may support the work with less maintenance effort. Repeated dependency traversal makes a graph more interesting when applications frequently follow, changing chains from resources through routes and locations to materials and production needs explicitly represented. Relationships can make that navigation easier to express and maintain. Relational models can handle connected data to compare both approaches against representative questions, expected update rates, access controls, and the skills of the team that will support the model. After the initial project ends, I'd ask for a worked decision before approving the modeling effort. Show which relationships the application follows, which state it reads, and how the resulting context changes an answer that the existing records couldn't support conveniently. Then assign responsibility for keeping that answer dependable. Someone must own each relationship type, define when it becomes valid, and decide what happens when its supporting information grows stale or no longer matches the operation. That responsibility includes retiring facts, not just adding them. When a temporary root permission ends or a buffer changes purpose. The model needs a controlled update, so applications stop treating an old connection as a current option. Stop modeling when the decision has enough context. Every extra relationship creates another fact someone must maintain, and an abandoned connection to a permitted root can keep sending applications toward an option the warehouse no longer has. Before moving racks, I test the proposed operation in a simulation that gives us a way to explore how a different arrangement behaves under load, without first disrupting the warehouse to discover whether its assumptions hold. Discrete event simulation follows changes in a modeled operation over time. A request arrives, a task enters a queue, a resource becomes available, and the model calculates when the next activity can start. Under its operating rules, the model needs more than a map. It needs task durations, travel paths, resource availability, and rules for deciding which waiting task proceeds. When several tasks compete for the same worker, Vehicle or transfer station. A resource stays occupied for the duration of its task. Other work waits until that resource becomes available, so the simulation can expose interactions that a comparison of average travel distances would leave out of the assessment. Take our hypothetical plant and build a baseline case first before testing changes. Reproduce its current operation closely enough that the model generates recognizable completion patterns and queues under the demand and staffing conditions you've actually observed. Then change one part of that modelled operation for revised slotting. Move selected items to candidate positions while preserving their handling requirements, and calculate how the changed routes affect both collection and replenishment over the simulated shift. Smaller releases provide another comparison without changing the physical layout. Run the same demand through a release rule that admits less work at once than. Examine whether accepted deliveries improve or requests simply wait longer before entering execution. Transfer capacity deserves a separate experiment. Add a usable receiving position or change the model transfer arrangement, including the handling work it requires, and test whether that change allows existing transport resources to complete more deliveries. Fleet size can then vary against those same conditions. Compare the current fleet with a larger or smaller fleet, keeping other assumptions consistent so you can distinguish the effect of vehicle count from the effect of change. Demand more vehicles might reduce assignment weights, but increase route interference. The result depends on whether the model represents shared access and transfer occupancy credibly, rather than allowing every vehicle to travel independently through space that only one can use. Calibration checks whether those modelled behaviours resemble the real operation. Use observed routes and handling times to adjust the baseline, then compare its results with a separate operating period that you didn't use to tune its inputs. Travel needs realistic distances, and operating conditions include the paths vehicles actually take and the time they spend turning approaching stations and completing transfers, rather than calculating every journey from distance divided by a nominal travel. Speed handling times need variation rather than one fixed value. Collect observations across relevant load types and working conditions. Because a model in which every collection takes exactly the same duration can hide the queues created by uneven work downtime needs its own representation as well. Include interruptions that remove resources from service, with durations and timing grounded in available records, while distinguishing scheduled unavailability from failures whose occurrence changes between simulated runs. Demand should preserve the patterns that stress the operation test busy overlaps and changes in request mix, not just a smooth arrival rate that spreads the day's work evenly and gives every resource time to recover. Some behavior will remain uncertain. Despite careful calibration, workers may combine tasks informally, recover from an exception differently, or choose a route the model doesn't include, so the simulated result carries assumptions about those responses. Sensitivity tests show how much those assumptions influence the recommendation. Increase handling times, vary equipment availability, or introduce a stronger demand peak than check whether the preferred arrangement still performs acceptably across that range of conditions. Repeat runs when the model includes random variation. One run might favor a candidate simply because its interruptions occur at convenient moments, so compare the spread of outcomes rather than presenting a single simulated shift as a forecast. A slotting arrangement tested against today's order mix may perform poorly when production changes its product mix. That means the assumptions need a review date as well. As an owner, you can't just set it and forget it. Simulation can test choices, but someone still has to propose them. Once the model behaves credibly within stated limits, the next step is searching for workable combinations of placement, release rules, transfer capacity, and fleet size within those tested constraints. Searching those combinations calls for explicit decision rules. An optimization engine evaluates candidate choices against a stated objective, while respecting constraints that define which choices the warehouse can actually carry out under the conditions supplied. The objective determines what the engine rewards. You might minimize expected late supply with penalties that reflect production consequences, while limiting extra handling rather than letting the engine improve delivery timing at any labor cost constraints define the permitted choices for a slotting decision. Those could include location, capacity and material compatibility for release quantities. They could restrict how much work enters a process during the period being evaluated. Some limits must remain absolute if a container exceeds a location's permitted load, the engine should reject that assignment rather than accept it, because a sufficiently large travel saving outweighs a penalty in its score. Other preferences can involve a trade off. Moving an item might reduce collection effort, but increase replenishment effort, so the objective needs to account for both. Using weights, the operation can explain and defend a solver searches within that defined problem depending on its method and available computing time. It may return a feasible improvement without proving that no better answer exists. So describe the result with that limit intact. A prediction model could estimate demand for a component over the next operating period, helping the decision process evaluate how much material a candidate arrangement must support. Travel estimates can vary with operating conditions. Rather than assigning one duration to a route, a model might use departure time, load type and observe traffic conditions to estimate the journey likely for that particular request. Task duration needs the same attention to context. Picking a sealed pack and counting loose parts require different effort, so useful estimates should distinguish the work characteristics that the available records can actually describe reliably. 01:27:22 Speaker: Shortage risk combines several uncertain inputs. A model might estimate the chance that usable stock runs out before another delivery arrives, using expected consumption and supply timing, rather than treating either estimate as a guaranteed occurrence. The uncertainty should reach the decision engine if a recommendation works only when every journey matches its expected duration. Test it against slower estimates, too, so the selected choice doesn't depend on unusually favorable conditions. Prediction quality needs an operational test. Compare estimates with later observations for the relevant request types, and check whether the errors change which option the engine selects, rather than judging accuracy only across the entire data set. It can help you investigate a recommendation in plain language, retrieving the relevant records and explaining how the supplied evidence relates to the decision. Under discussion, you could ask why one release option ranks above another. The answer should refer to the recorded requirements, estimated durations and solver result available for those options with references that let you inspect the supporting evidence. An explanation must preserve the distinction between evidence and inference. If the solver returns only an objective score. A language model shouldn't invent a precise account of which constraint determined the result, or claim certainty about unrecorded events. Useful explanations require useful solver output. Retain the selected choices, objective contributions, binding limits where available, and stated assumptions so the language model can explain an actual decision record rather than compose a plausible story. Microsoft AI services can support parts of this design. Azure Machine Learning, for example, can support developing and deploying prediction models, while Azure OpenAI can provide language models for an application grounded in retrieved operational records. The warehouse logic still needs separate implementation. A specialist solver must receive a correctly formulated problem, and manufacturing rules must translate business requirements into constraints and objectives, rather than relying on a language model to infer them. Hosting these components together doesn't merge their responsibilities. Your application must connect the estimates, decision inputs, solver outputs, and retrieved evidence deliberately, including how it handles missing information that prevents a dependable recommendation from being produced. Even a feasible well-explained choice remains a proposal until the organization grants a defined person or service authority to change the warehouse work. Concerned permission needs to become a controlled transaction between detecting a supply risk and changing warehouse work. The application needs a defined path that establishes what should change, who can approve it, and whether the change still makes sense. Begin with the risk and its supporting context for a proposed replenishment priority change. Collect the affected requirement. The current task state, the remaining delivery margin and the other work that would lose its place. Turn that context into a specific proposal. Instead of asking someone to fix the shortage, identify the task to reprioritize the requested priority and the conditions under which that change would still help the affected delivery. Check those conditions before requesting approval. The application should establish whether the task still awaits execution, whether its proposed position is permitted, and whether the resulting displacement remains within the approvers agreed authority approval should attach to that proposal, not a general intention record which action the person approved and the evidence they reviewed. So a later change in the task or circumstances doesn't silently inherit permission intended for an earlier situation. The owning application must perform the change for dynamics three sixty five warehouse work. Use a supported operation available for that specific process or a governed extension where needed, rather than editing underlying records directly, direct database edits bypass the application's transaction rules. They can leave related records inconsistent or omit required processing, even when the changed field appears to contain exactly the priority value. The integration intended to set keep one instruction path for the affected task. A separate message telling a worker to ignore their assigned sequence would create competing instructions, so the approved change needs to reach the system that actually presents and manages that work. Give the command its own identity. Associate that identity with the approved proposal and retain it through retries, allowing the receiver or integration layer to recognize another delivery of the same request. Rather than execute a second change, an acknowledgment needs a precise meaning. Distinguish receipt of the command from acceptance by the application, and distinguish acceptance from a confirmed state change. Because each response supports a different claim about execution, a timeout leaves the outcome uncertain. The application might apply the priority change, but lose its response on the return journey. So immediately sending a new command could repeat an action that already succeeded. Retry with the original identity where the interface supports that behavior, where it doesn't. The integration needs a supported way to check the result and prevent repetition before attempting the operation again with an unresolved outcome. Commands also need an expiry condition. A priority change intended to protect the next delivery window shouldn't remain executable indefinitely, waiting to emerge from a delayed integration after the task or production need has changed. Consider our hypothetical replenishment recommendation awaiting approval while the supervisor handles another exception. A warehouse worker completes the move and the parts become available before the proposed priority change reaches the execution service. The earlier recommendation has expired. In practical terms, even if its time limit hasn't elapsed, its stated condition no longer holds, so the service should check the current task state and reject the obsolete action. Approval doesn't remove that final check. Ask the owning application to validate the relevant state when applying the change where supported. Because conditions can change between an external check and the actual transaction. Partial failure needs reconciliation rather than guesswork if approval is recorded, but the application response is missing. Retain the command as unresolved until a supported read or execution record establishes whether the requested change took effect. Resolve uncertainty before proposing another action for that task. Otherwise, the recommendation service could calculate a replacement from an assumed failure while the warehouse application already operates under the first approved change, leaving both sides acting on different histories, someone needs responsibility for unresolved commands. Define who reviews them, what evidence settles their status, and when automated attempts stop. So a persistent interface problem doesn't generate an endless series of uncertain warehouse changes. The warehouse needs a clear way to continue its work. When that approval path integration, or cloud service becomes unavailable without leaving workers dependent on commands whose outcome nobody can establish, a failure procedure needs to tell the shift what remains usable. Losing the connection to Azure may leave warehouse transactions and local fleet execution available, while losing the warehouse network can remove the instructions and confirmations workers normally depend on. Define those operating modes separately for each failure. Specify which work can continue, which new requests must wait, and who can authorize a temporary manual process without creating movements. The owning systems can't later reconcile. Stale telemetry calls for a different response from a disconnected application. If position or occupancy updates stop, mark the affected information as unverified and prevent automated decisions that depend on it, rather than continuing to treat the last observation as current unavailable analytics shouldn't erase the shifts. Operating instructions supervisors need access to an agreed fallback sequence, an exception procedure with a named person responsible for resolving priorities until the Analytical Service returns and its information is current. Again, delayed messages require an explicit degraded mode. Two when updates arrive too slowly to support timely decisions, suspend the affected automation and tell the shift which confirmations now require checking through the source application or an approved physical check. Buffered events can restore missing history, but the receiving services need enough storage and processing capacity to absorb that backlog. You also need to make sure old updates don't masquerade, as current conditions keep recovery traffic from overwhelming current work. Set limits on backlog processing. Monitor how far each connection remains behind, and announce recovery only when the information needed for operational decisions has caught up enough. Duplicate commands need a recovery check, not a bulk resend. Before releasing held requests. Compare their recorded outcomes with the owning application's current state. Separate actions already applied from actions still unresolved or no longer permitted to execute unfinished missions. Need inspection through the fleets supported recovery procedure. A vehicle may have collected a load before communication failed, so establish its actual load and mission state before creating replacement work or asking someone to move the container manually. Conflicting stock records need a controlled reconciliation point if manual handling occurred during the outage, hold the affected stock from further automatic allocation until an authorized person checks the physical quantity and records corrections through the approved transaction process. Every temporary movement needs a recoverable record. The fallback method should capture the container quantity, origin, destination and responsible person clearly enough that recovery doesn't depend on who ever remembers where a load disappeared during the interruption, I. Teams may restore connectivity and application services while OT teams verify equipment, side communications and execution status. Warehouse operations decides whether the physical process can safely resume. Network boundaries should stay intact during troubleshooting. Use documented connections between approved endpoints and require controlled remote access, rather than opening broad access between enterprise services and equipment networks because the shift needs a quick repair. Give each connection and recovery decision a named owner. Service identities should receive only the access their tasks require, while temporary support permissions need an expiry and an audit record that survives the incident being closed. Scanner activity and mission handoffs can reveal individual work patterns. Collect and expose personal identifiers only where a defined operational purpose requires them, rather than retaining every available detail by default. Keep routine analysis focused on tasks and queues. Restrict identifiable records to authorized roles and avoid interpreting a worker's recorded pause as poor performance. When the record does not establish whether access equipment or another task prevented progress. Explain the use before collecting the data, workers should know what gets recorded, who can inspect it, how long identifiable records remain, and whether the information can enter employment related decisions under the site's applicable rules. Retention needs to cover copies as well as primary records set. Deletion or de-identification rules for analytical data sets. Exports and recovery stores with documented exceptions where an investigation or legal obligation requires particular records to remain available. Longer run recovery drills with warehouse operators. IT, OT and support teams include a lost connection during collection and a backlog containing obsolete requests, then verify that stock and mission states reconcile. A restored connection isn't the end of the drill. Finish only when the shift can identify every affected load, explain unresolved records, and confirm that no duplicate instruction remains waiting to move material a second time. Once those drills pass, I'd keep the first live pilot narrow, choose one supply route and a defined set of materials, then name the shifts included so everyone knows which deliveries belong to the trial and which remain outside it. Give that route a delivery promise the receiving team accepts. Record the quantity and receiving position for each request, along with its permitted arrival window. So the pilot has a result to test rather than a general ambition to improve performance. Choose a route with enough activity to reveal recurring problems. A rarely used route might look easy to manage, but it won't tell you much about whether the proposed changes survive the ordinary pressure of competing requests during a working shift. Collect enough history to include the demand patterns the route normally handles, rather than choosing a fixed period that happens to contain only quiet days or an unusual production campaign. Record what the shift actually faces during that baseline. Include the mix of materials and container types, the people available for the work, and whether stock starts in a condition that allows the planned collections to proceed. Known disruptions need their own record if a supplier delay or plan staffing change affects the comparison. Retain that context so nobody attributes its effects to a pilot rule that couldn't reasonably have prevented them. A fair comparison won't always mean matching calendar weeks. You may need to compare similar demand periods within those weeks, because a lighter workload can make an unchanged process appear faster without any improvement in how it operates. Let it propose changes without sending them into execution. Then compare its proposals with what the shift actually did. Ask operators whether those alternatives were practical at that moment. Disagreement is useful evidence, not an obstacle to deployment. If the service repeatedly proposes moves that operators reject, record their reasons and check whether the problem comes from missing context, an unsuitable objective or a rule that doesn't fit the work. Move to approved live changes only after reviewing those disagreements, keep the initial permissions limited to the pilot route and agreed actions, so a useful recommendation elsewhere doesn't quietly expand the trial beyond what the team has prepared to manage. Set roll back criteria before the first approved change. Agree with deterioration in delivery performance, extra handling or operator workload requires a pause and identify who can restore the previous operating rule without waiting for a project meeting. Ask what changed during specific deliveries, including extra checking or walking that the recorded durations may not explain. Give the team a clear response to each recurring concern, then put a cost against the work that changes. Count labor spent moving material across the full pilot flow, including additional receiving or sorting effort, rather than claiming a saving from reduced warehouse walking while another team absorbs more work. Treat production weighting carefully in the economic assessment. Recovered production time may support more output when demand and other capacity permitted, but avoided weighting doesn't automatically become a cash saving equal to every minute recorded against the line fleet and inventory costs need the same discipline. Check whether the pilot changes vehicle hours, charging, maintenance or leased capacity, and whether its delivery pattern requires more containers or stock committed to the route throughout normal operation include the effort needed to keep the change working. Integration, development, testing, configuration, upkeep and support all consume resources even when existing. Azure or Dynamics three hundred sixty five capacity means the pilot doesn't immediately produce another software purchase. Separate one time spending from recurring costs. A pilot can justify its setup effort over a longer period, but frequent intervention by engineers can erase the benefit. If that intervention becomes part of normal shift support, I'd want a repeatable delivery improvement across the included shifts. Accepted operator workload and a cost assessment that still holds when temporary project support steps away from the root. Then specify where that evidence applies. A result from small container supply doesn't yet justify the same rules for bulky loads or a different receiving arrangement, so the next route needs its own check against the pilot's actual operating conditions. We can now revisit the tote with a tested operating model. The pilot should leave enough evidence to judge its next delivery as part of a repeatable process, rather than a successful exception that depended on the project team standing nearby. This time, the request connects to the usable reserve stock, the quantity available at the pick face, the warehouse tasks already waiting, and the transport mission serving that cell. The connection exposes a problem. Before release. The Pigface can cover smaller withdrawals already committed, but it can't also cover this request before the cells remaining supply is expected to run out. Stock availability now leads to a specific decision. Instead of releasing the request into a predictable shortage, the supervisor receives a proposed replenishment move linked to the production requirement and the available time for completing delivery. The proposal needs a workable opening in the current workload. A suitable worker can complete replenishment before the production pick must begin, provided another replenishment task moves slightly later without threatening the requests that depend on it. Transport offers two possible collection windows. The earlier window requires the toad to reach staging sooner than the warehouse can reasonably prepare it, while the later window still leaves time for delivery and acceptance, I'd select the later feasible window, not the earlier hopeful one. That choice gives the warehouse an achievable readiness target and avoids occupying a vehicle while somebody finishes work that the proposed collection time assumed would already be complete. The destination check supports that choice. Assembly confirms that it's receiving position. Will accept the container during the proposed window, with no earlier delivery expected to occupy the space when this tote arrives through supported operations in the configured dynamics three hundred sixty five, process replenishment receives its approved place in the workload. The production supply request remains held until the required stock becomes available. Approval now produces evidence rather than another message to chase the warehouse. Application confirms the change. The assigned worker completes replenishment, and the resulting confirmation establishes that the Pigface can support the quantity needed for this request. The request can now enter picking dynamics three hundred sixty five creates the applicable warehouse work, and the worker completes the collection and placement confirmations that associate the prepared container with its designated staging position. The transport request reaches the fleet system. With that readiness established, its acceptance confirms responsibility for the mission, and the subsequent pickup confirmation connects the physical tote leaving staging to the production request. Still awaiting receipt for this hypothetical request. Acceptance falls inside the agreed window. The cell continues its intended work without chasing the container or switching jobs to cover a gap, which gives us a production result to examine alongside the warehouse activity, I'd still inspect what happened to the displaced replenishment task. Its later completion must remain compatible with the requests it supports. Otherwise, protecting this delivery has merely transferred the shortage risk to another part of the shift queue. Movement tells us whether the change held together. Check whether staging cleared as expected, and whether requests behind our tote continued progressing, rather than assuming one accepted delivery proves that the shared flow improved. Exceptions need their place in that assessment, too. If a worker needed an unplanned container correction or a vehicle required assistance at pickup, retain that intervention even when acceptance still occurred within the promised window. The successful handoff doesn't erase the effort behind it. Comparing the planned sequence with the confirmed sequence tells us whether the result followed the approved operating choice or depended on someone quietly rescuing it along the way. Production continuity also needs confirmation from the receiving operation. Ask whether the accepted quantity actually sustained the intended work until the next planned supply, rather than treating an on time receipt as sufficient evidence by itself. That leaves the supervisor with a concrete follow up. Keep the choice if the delivery affected queues and dependent requests behave acceptably, reconsider it. If the same action repeatedly creates exceptions or consume someone else's delivery margin. The response still needs an owner on the shift. The connected records can expose the approaching shortage, but someone with authority must commit the replenishment capacity, resolve the competing demand, and ensure the accepted decision reaches execution. Warehouse productivity should answer to the receiving operations. Need faster picking beside a growing queue at the same transfer point still leaves production waiting, even when the warehouse records more completed work during that shift. Where does that gap appear in your operation? I'd like to compare where you record warehouse work completion with where production confirms line. Side receipt.