AI Shipment365 is available on Microsoft Marketplace today! Setup is fast. We designed it to deploy in hours, not weeks. But getting every customer account structure, service type preference, and delivery flag configured correctly from day one is where the detail matters. That’s where Ascent’s experience changes the outcome. We built AI Shipment365. We’ve implemented it across manufacturers in steel, bedding, food, pharma, and chemicals. When we configure it, you go live the same day. Here’s exactly what that looks like… Before You Start: What You Need in Place The one to two hour deployment timeline holds when everything on this list is ready before configuration begins. Most setups that run long don’t hit technical problems. They hit preparation gaps. D365 F&O environment. AI Shipment365 runs on D365 Finance and Operations cloud deployments using standard data entities via Power Automate. No X++ code, no custom extensions. Confirm your environment is on a current supported version. Power Automate needs to reach it. Power Automate licensing. Many D365 F&O customers already have Power Automate capacity in their existing licensing they’ve never activated. Check before purchasing a separate plan. A per-flow or per-user plan covers what the integration needs. Azure subscription. The integration uses an Azure SQL database as the intermediary between D365 and WorldShip. If you already run Azure workloads, provision it there. If not, a standalone subscription works. At mid-market shipment volumes, the database cost is minimal. UPS WorldShip version. This one matters more than people expect. WorldShip import and export mapping is version-specific. Older versions use different backend database table structures than current ones. A manufacturer who ran setup assuming a current schema on a two-year-old WorldShip installation spent two hours troubleshooting mapping failures that were version mismatches the whole time. Check your version before starting. Customer shipping data. This step determines how well the integration performs from day one. Before configuration starts, compile the following for every customer: UPS account numbers. Identify whether each customer ships on your account, their own corporate account, or a branch-level collect account. A distributor with three regional offices might have three different collect numbers depending on which location is receiving the order. Document all of them and the logic for when each applies. Service type defaults. Flag any customer who requires Next Day Air or Second Day Air by default, or under specific order conditions like production-critical flags. Delivery flags. Saturday delivery, residential delivery, signature required, adult signature required. These are the flags most commonly missed in manual processes. One manufacturer lost a production line for a Monday morning because a Saturday delivery flag wasn’t stored and didn’t make it to the shipping team on Friday. Address accuracy. Review your D365 customer address records before go-live. Inaccurate addresses that were being caught and corrected manually during WorldShip entry will flow directly to labels once the integration is live. Thirty minutes of address review before go-live is worth more than any amount of fixing afterward. The Configuration Sequence Step 1: Provision the Azure SQL database. Create the database in your Azure subscription. The AI Shipment365 schema includes specific tables for inbound shipment records from D365 and outbound tracking records from WorldShip. Configure a SQL Server login scoped only to those tables. This login is used by both Power Automate and the WorldShip ODBC connection and doesn’t need broad database access. Step 2: Deploy the Power Automate flows. AI Shipment365 ships as Power Automate solution packages. Import them into your Power Automate environment and configure the D365 and Azure SQL connection references. The D365 connector runs under a service account scoped to sales orders, packing slips, customer records, and the tracking fields the integration writes back. Nothing broader. The tracking update flow runs on a schedule. Every 30 minutes covers most manufacturers. If you have customers who expect near-real-time visibility, every 15 minutes is the practical floor. Running it more frequently adds API call volume without meaningful improvement. Step 3: Configure the WorldShip ODBC connection. On each WorldShip workstation, set up an ODBC data source pointing to the Azure SQL database using the login from Step 1. Before moving to mapping configuration, test the connection explicitly. Most corporate firewalls allow outbound connections to Azure SQL on port 1433, but if your environment has egress filtering, confirm that port is open first. Discovering a firewall block after spending an hour on WorldShip mapping configuration is avoidable. Step 4: Configure WorldShip import and export mapping. Import mapping defines which Azure database fields populate which WorldShip fields when the barcode is scanned. At minimum: ship-to name, all address lines, city, state, zip, country, UPS account number, service type, and delivery flags. Export mapping defines what WorldShip writes back after label generation: tracking number, published rate, billed rate, service type used, and packing slip ID as the key field linking the return record back to the original D365 order. The packing slip ID is the link in both directions. Confirm barcode format compatibility between D365 and WorldShip before completing this step. Step 5: Enter customer data in D365. Using the data compiled during preparation, enter account numbers, service type defaults, and delivery flags into D365 customer records. For customers with multiple UPS accounts depending on order type or destination, configure the selection logic at the sales order level and validate each variation explicitly during UAT. A customer with a corporate account for orders over a certain value and a branch collect account below that threshold needs both paths tested, not just the default. The UAT Process: What to Test Before Go-Live Standard shipment on your account. Post a test packing slip, scan the barcode in WorldShip, and confirm ship-to address, account number, and service type populate correctly. Generate a label. Confirm the tracking number appears in the D365 sales order within the next flow run interval. Customer collect account. Test at least one customer shipping on their own UPS account. Confirm the correct collect number populates. This is the scenario that causes the most freight disputes in manual … Read more

We work with mid-market manufacturers every day. Steel buildings, contract bedding, food production, chemicals, pharma. Different industries, different operations, different challenges. But one problem shows up almost everywhere. Dynamics 365 is live. Inventory is tracked. Production is visible. Finance is closing on time. And then we walk to the shipping floor and someone is typing order details into UPS WorldShip by hand. The data is already in D365. The customer’s account number, the service type, the delivery preferences. All of it sitting in the system. None of it reaching the floor automatically. We kept seeing this. Across implementations, across industries, across team sizes. So we built something to fix it. This blog explains the gap, what it does to your operation, and how closing it changes the way your shipping floor runs. Where the Gap Comes From D365 Finance and Operations doesn’t have a native, out-of-the-box integration with UPS WorldShip or FedEx ShipManager that works the way manufacturers need it to. The connection that existed in older versions of Dynamics AX relied on an ODBC setup that no longer holds up in the modern D365 cloud environment. The result: your sales order lives in D365. Your packing slip is posted in D365. But when the order reaches the shipping floor, none of that data flows automatically to the carrier system. Someone bridges the gap manually, every order, every day. For a company shipping 20 orders a day that’s manageable. For a company shipping 50, 100, or 200 orders a day it becomes one of the biggest operational drains nobody is measuring. What It Does to Your Throughput Throughput is the metric most operations leaders focus on for production. How many units through the line per shift. Where are we bottlenecked. The same question applies to shipping and the answer is almost always the manual entry step. A shipping team processing 60 orders a day at 8 minutes of manual entry per order is spending 480 minutes on data transfer before they’ve done anything else. That’s not slack time. That’s your shipping floor’s entire productive capacity absorbed by a task the system should be handling automatically. What gets cut to make room? Address verification before the truck leaves. Exception handling. Proactive communication when something is running behind. The work that actually requires human judgment gets compressed into whatever time is left after the data entry is done. When data flows automatically from D365 to WorldShip, that capacity comes back. Not as cost savings on paper. As real time your team can redirect to work that matters. The Data Your Shipping Floor Needs But Can’t Access Here’s specifically what lives in D365 that your shipping team needs every day but currently can’t access automatically. Customer UPS account numbers. Some customers ship on your account. Some on a corporate UPS account. Some on a branch-level collect account that differs by location. In a manual process the shipping team either knows this from experience, asks customer service, or guesses. All three approaches introduce error. Service type preferences. A customer might default to Ground for standard orders but require Next Day Air for anything production-critical. That preference is in the sales order. It doesn’t reach the floor unless someone communicates it manually. Delivery flags. Saturday delivery. Residential delivery. Signature required. Each of these affects the label, the carrier charge, and whether the shipment is delivered successfully on the first attempt. Missing any of them means a failed delivery or a billing discrepancy. Address accuracy. Corporate billing addresses, regional distribution centers, receiving docks with specific delivery window requirements. These details should be stored in the customer record and flow to the label automatically. In a manual process they depend on the shipping team knowing them or catching the discrepancy before the truck leaves. When none of this flows automatically, your floor is operating on partial information. The team fills the gaps with memory, verbal handoffs, and personal spreadsheets. That’s not a process. That’s controlled improvisation under time pressure. The Accountability Gap When a shipment goes out wrong in a manual process, tracing the error is genuinely difficult. Was the wrong collect number entered because customer service didn’t communicate it? Because the shipping team selected from memory and got it wrong? Because the spreadsheet of account numbers hadn’t been updated when the customer switched accounts last quarter? The answer is usually unclear. The error happened somewhere in the chain of people, spreadsheets, and verbal communications between the sales order and the floor. You can retrain the team, update the spreadsheet, add a checklist. But the next error will come from a slightly different gap in the same informal chain. When shipping data flows from D365 to WorldShip through a defined integration, every step is traceable. If a customer’s account number is wrong, the fix is in D365 at the customer record level. The next order ships correctly automatically. One fix applied system-wide. That’s the difference between managing errors and eliminating their source. What Happens When Your Operation Grows Manual shipping processes don’t scale. They absorb each new layer of complexity as additional tribal knowledge somebody has to carry. New customer with three different UPS accounts depending on order type? Someone learns that and adds it to their personal spreadsheet. New national retailer with specific labeling and EDI requirements? Someone builds a workaround outside the system. Second warehouse? Now two teams are managing the same informal process independently. We worked with a contract manufacturer shipping to national retailers across multiple facilities. Each retailer had specific labeling standards, documentation requirements, and EDI needs. Managing those manually across multiple shipping locations wasn’t sustainable. Peak season had become its own operational project requiring dedicated oversight just to keep the manual process from breaking down. The solution wasn’t more documentation or more oversight. It was moving the retailer-specific requirements into D365 where they could be stored at the customer level, triggered automatically at shipment, and applied consistently across every facility. When your shipping requirements live in D365, adding a new customer … Read more

If you’re using Dynamics 365 and still manually entering shipping data into UPS WorldShip or FedEx ShipManager every day, this is for you. Most manufacturers go live on D365 and assume shipping will get easier. It doesn’t. The order is in the system. The customer data is in the system. But when it’s time to ship, someone is still typing it all in by hand. That’s the gap AI Shipment365 closes. Why Does Shipping Stay Manual After a D365 Implementation? D365 Finance and Operations, even when well-configured, doesn’t have a native integration with UPS WorldShip or FedEx ShipManager that works the way manufacturers need it to work. The connection that existed in older versions of Dynamics AX relied on an ODBC setup that no longer holds up in the modern D365 cloud environment. So the sales order lives in D365. The packing slip is posted in D365. All the customer data, account numbers, service preferences, and delivery flags are in D365. But shipping execution happens in a separate system and the two don’t talk to each other. Someone bridges that gap manually, every time. For a company shipping 20 orders a day, that’s manageable. For a company shipping 50, 100, or 200 orders a day, it becomes one of the most expensive problems nobody is tracking. What This Actually Looks Like Every Day Richard couldn’t even tell us how long it took him. Two minutes per order on a good day. Fifteen on a bad one. If he was tired, distracted, or made a small mistake somewhere in the entry, he’d have to go back, figure out where it went wrong, and start over. The time was impossible to predict because the process demanded his full attention every single time. It wasn’t just slow. It was the kind of task that’s always hanging over you. How long will this one take? Did I get that account number right? Is that the correct service type? One small error and the whole thing unravels. Now you’re not just fixing the entry. You’re figuring out what went wrong, when, and what it’s going to cost to correct it. Before we connected the system, shipping felt like something that was always up in the air. The time, the accuracy, the rework. All of it unpredictable. Now add a peak shipping period. Black Friday, end of quarter, a major product push. A process that was already fragile becomes a crisis. Delays aren’t an option. Volume spikes. Manual entry doesn’t scale. Where Errors Go After They Leave the Dock Shipping errors don’t stay in the shipping department. They move downstream fast. Wrong collect number. A customer ships on their own UPS collect account. The wrong number gets entered. UPS charges your account. Your A/R team catches it in reconciliation. Someone spends two to four hours resolving it. Calls to UPS, calls to the customer, back and forth. That’s if it gets caught quickly. Wrong service type. A customer needed Next Day Air. Ground was selected. The shipment arrives two days late. The customer calls. Your team apologizes and investigates. The relationship takes a hit that a discount won’t fully repair. Missed Saturday delivery flag. A production-critical component needed to arrive Saturday. It didn’t, because the flag wasn’t stored anywhere accessible and didn’t get communicated to the dock. The customer’s line stops Monday morning. None of these happen because your shipping team isn’t doing their job. They happen because the information they need isn’t connected to where they work. The Knowledge That Lives in One Person’s Head Here’s the risk most COOs don’t see coming until it’s too late. Your best shipping person knows that Customer A ships on a corporate UPS account for large orders but switches to a branch collect number under a certain threshold. He knows Customer B always needs Saturday delivery. He knows Customer C’s main address sends packages to a receiving dock that’s closed Fridays. None of that is in D365. It’s in his head and maybe a spreadsheet on his desktop. The day he’s out sick, the day he resigns, the day you’re onboarding someone new, that knowledge doesn’t transfer automatically. The errors start immediately. Not because anyone failed, but because the system was never given the information it needed. When that institutional knowledge moves into D365, tied to the customer record and accessible to anyone, the operation stops depending on one person being present and attentive. This Is Also an AI Problem Here’s the honest version of AI readiness that nobody talks about. You can’t put AI on top of a broken process. It doesn’t work that way. Before AI can help you, your basic operational problems have to be solved first. Shipping is one of those foundational problems. When your team is re-entering data manually, making corrections, and tracking things outside the system, AI has nothing to work with. It can’t see what happened. It can’t learn from it. It can’t help you get better. Fix the operational problem first. Get the data clean and inside the system. Then AI becomes possible. That’s the right order, and AI Shipment365 is one of the steps that gets you there. What a Connected Shipping Workflow Actually Looks Like AI Shipment365 connects D365 directly to UPS WorldShip and FedEx ShipManager using Microsoft Power Automate. No custom development. No third-party middleware. Customer-specific UPS account numbers, service types, delivery flags, and address preferences are stored in D365 at the customer record level. When the packing slip is posted, all of that information flows automatically into WorldShip. The shipping team scans the packing slip barcode. WorldShip populates everything. They enter the box weights, generate the label, and submit. The tracking number flows back into D365 automatically. The sales order updates without manual entry. Customer service can see the tracking number the moment the label prints. If the estimated delivery date changes due to a delay, a weather event, or a routing issue, the system picks it up and alerts the shipping manager. Proactive communication instead … Read more

Why Is Dynamics 365 Finance and Operations Not Delivering ROI… And What to Do About It Most mid-market manufacturers go live on Dynamics 365 Finance and Operations and never realize the full ROI. Here is why Dynamics 365 Finance and Operations underdelivers after go-live, what it costs your operation, and how Ascent Innovations helps manufacturers fix it. You invested in Dynamics 365 Finance and Operations. The system is live. Transactions are processing. The project is closed. But the business is not running on Dynamics 365 Finance and Operations. Planners are in spreadsheets. Reports are exported and manually adjusted before anyone trusts them. Critical workflows are still happening over email and phone calls. And the ROI that justified the Dynamics 365 Finance and Operations investment has not materialized. This is one of the most common problems in mid-market manufacturing today. Organizations spend significant capital implementing Dynamics 365 Finance and Operations and find themselves a year or two past go-live with a system they are paying for but not fully using. The reason is almost always the same. And it is fixable. Why Is Dynamics 365 Finance and Operations Not Delivering ROI? The Root Cause When Dynamics 365 Finance and Operations is not trusted, the business works around it. Every workaround, every spreadsheet, every manual process, every decision made outside Dynamics 365 Finance and Operations reduces the value the system delivers and keeps the organization in a legacy state of operations. The system cannot improve because critical thinking never moves into it. Data stays incomplete. Reporting stays unreliable. And the business keeps running the way it always has, just with a more expensive platform underneath it. The organizations that get full value from Dynamics 365 Finance and Operations are not the ones that implemented the most modules. They are the ones that established sound financial and operational fundamentals that made the system trustworthy enough to actually run the business on. That distinction — between a system that is live and a system that is trusted — is where most of the Dynamics 365 Finance and Operations ROI gap lives. Why Dynamics 365 Finance and Operations ROI Problems Happen Most Often After Acquisitions This problem becomes significantly more pronounced in companies that have grown through acquisitions. Each acquired entity brings its own systems, processes, and ways of working. What should become a unified operation instead becomes a patchwork of disconnected tools, inconsistent data, and fragmented workflows. Leadership expects consolidation. What they get instead is: Multiple versions of the truth across entities Manual reporting just to understand performance Operations that never fully align Even after implementing Dynamics 365 Finance and Operations, the underlying fragmentation often remains, just inside a new platform. Without addressing these foundational differences, Dynamics 365 Finance and Operations becomes another layer on top of the problem rather than the system that resolves it. That is why many post-acquisition organizations feel the Dynamics 365 Finance and Operations ROI gap more acutely than others. Five Questions That Reveal Whether Dynamics 365 Finance and Operations Is Delivering Value If the answer to any of these is no, Dynamics 365 Finance and Operations is not delivering its full value. 1. Is Dynamics 365 Finance and Operations the primary system for daily execution? Or is your team still relying on spreadsheets and workarounds to get work done? If execution happens outside Dynamics 365 Finance and Operations, the system is not driving the business. The cost is not just inefficiency. Every manual process is a decision the system did not capture and cannot learn from. 2. Was the Dynamics 365 Finance and Operations implementation scoped to deliver real business impact at go-live? A well-designed Dynamics 365 Finance and Operations implementation changes how the business operates from day one, not just which platform it runs on. If the go-live did not improve workflows, visibility, or decision-making, the scope was not designed correctly. That gap compounds over time as teams build more workarounds around an incomplete foundation. 3. Has Dynamics 365 Finance and Operations changed how your business actually works? Workflows, cross-functional coordination, decision-making, accountability. Has any of that meaningfully changed since go-live? Or is the business running the same way it did before, just on a different platform? A $150M manufacturer running the same manual coordination processes it ran before Dynamics 365 Finance and Operations is absorbing the cost of the system without receiving the benefit. 4. Do your systems work together end-to-end inside Dynamics 365 Finance and Operations? If execution breaks down at handoffs between systems, such as sales to operations, warehouse to finance, or purchasing to production, integration gaps are costing you every day. Manual rekey steps, missed handoffs, and data that does not flow through Dynamics 365 Finance and Operations create delays and errors that accumulate across every transaction the business processes. 5. Do you trust your Dynamics 365 Finance and Operations reporting enough to run the business from it? If your finance team exports data before they trust it, rebuilds reports in Excel, or maintains parallel spreadsheets alongside Dynamics 365 Finance and Operations reports, your reporting foundation was not built correctly. If your CFO cannot close the books directly from Dynamics 365 Finance and Operations without a manual verification step, that is a cost the business absorbs every single month. These are not edge cases. They are the most common Dynamics 365 Finance and Operations implementation problems, and each one represents a specific, diagnosable gap that can be addressed without starting over. What Dynamics 365 Finance and Operations ROI Problems Look Like Across Manufacturing Industries The pattern of where Dynamics 365 Finance and Operations value gets lost is consistent. The operational details differ by industry. Metals and Steel Fabrication In one PE-backed metals group, three acquired companies were running separate ERP systems with different platforms for operations and accounting, no consolidated inventory view, and financial reporting that was manually assembled every close cycle. Planners had no confidence in on-hand inventory figures, which created downstream problems in procurement, production scheduling, and access to operating capital. Lenders required accurate inventory valuations that the business could not produce reliably from the system. Once the group consolidated onto Dynamics 365 Finance and Operations with proper intercompany configuration, inventory costing methodology aligned to commodity price fluctuations, and integrated project accounting, the financial picture … Read more

Attending the Greater Chicago Design-2-Part Show in Schaumburg? If you’re at the conference looking to improve your contract manufacturing operations, this is a common challenge across the industry. Paper, whiteboards, and spreadsheets. It works… until it doesn’t. Then growth happens More orders. More customers. More complexity. The team steps up. For a while, it still works. But it depends on heroic effort. Success becomes a double-edged sword The business is growing. But the way it’s being run doesn’t scale. So you invest in a modern ERP like Microsoft Dynamics 365. But this is where most teams get stuck The system goes live… and the business still runs outside of it. Planning stays in spreadsheets. Execution stays on whiteboards. You’ve upgraded the system. But not the way the business runs. Last year at the Chicago Design-2-Part Show, this came up at a lunch table. My Microsoft Certified Partner shirt sparked questions, and it’s something I talk about with manufacturers all the time. What this really means The system shows one version of reality. The floor is running another. That gap is where profitability gets lost: Overtime Expediting Inefficient runs Too much or too little inventory Missed commitments This isn’t an ERP problem But it often gets blamed on the technology. The real issue is a lack of attention to the details that make the system trustworthy. So people don’t rely on it. They fall back to spreadsheets, whiteboards, and manual tracking. And the gap remains. This is a visibility problem A lack of trust becomes a visibility problem. You can’t clearly see: what’s actually happening what’s about to go wrong what decisions to make early So everything becomes reactive. And that’s where profitability gets hit Not in one big event. In small, constant ways. You still get the work done. It just costs more than it should. The shift It’s not about having a system. It’s about running the business in it. Gut check Are spreadsheets required to run planning? Are whiteboards driving production decisions? Are costly mistakes being made? If yes: You have an opportunity to improve your bottom line— and drive growth through a more consistent, trusted customer experience. Spreadsheets, paper, whiteboards, and recurring problems are a signal for change. If this sounds familiar, let’s talk If this sounds like your operation, Ascent Innovations can help. We meet you where you are and focus on what will have the biggest impact first. Every recommendation is backed by a real business case—based on an ROI model grounded in your business, not a marketing pitch. Text me at 630-887-7251 and let’s meet up. About the Author John Bruhnke is Managing Director at Ascent Innovations with 25 years of experience in enterprise systems and analytics. He is the creator of the Trusted Facts Method, a framework for establishing Operational Truth by defining and governing the performance drivers of revenue, operating income, and cash flow. He works with CEOs and CFOs to align sales, operations, and finance so organizations can move from fragmented reporting to proactive management of business performance.

“Let’s get into what happens when acquisitions outpace operational integration.” A manufacturing business acquires new facilities. Each one comes with its own ERP, its own workflows, its own costing methods, its own chart of accounts. Leadership focuses on integrating the revenue and the customer relationships, and the systems get pushed to “later.” Later turns into years. And somewhere along the way, the CEO, CFO, and COO realize they’re running a company where nobody can agree on the same set of numbers. If you’re leading a mid-market manufacturer with multiple facilities and that situation sounds familiar, this piece is written for you. Not to sell you a platform, but to walk through what unifying an operation like yours actually looks like, what the hard decisions are, and why most ERP projects fail to deliver the value the organization expected. The Hidden Cost of Growing Through Acquisitions The cost of running fragmented systems doesn’t always appear on a P&L. It shows up in every decision that takes longer than it should, every report that requires manual reconciliation before leadership trusts it, and every capacity commitment made without reliable data behind it. Delayed reporting isn’t just inefficient. It introduces compliance risk with lenders and credibility risk with stakeholders. When your CFO can’t close the books for three weeks because month-end requires manual consolidation and intercompany eliminations across disconnected systems, the business is operating on backward-looking financials. Decisions about pricing, capital allocation, and headcount are being made with numbers that are already stale by the time anyone sees them. When inventory data isn’t trusted, working capital decisions are compromised. Days inventory outstanding climbs because planning can’t see what’s actually on the floor across facilities. You carry excess safety stock at one site while another expedites the same item. You tie up cash in buffers that exist only because the system can’t give you a number you believe. Manual consolidation across platforms increases audit exposure and the likelihood of financial misstatement, not from negligence, but from the structural impossibility of maintaining accuracy when the same data is being entered, reconciled, and reported from three different systems with three different costing methodologies and three different period-close processes. This was the situation at the contract bedding manufacturer Ascent Innovations worked with. Multiple facilities across the United States, each on a different ERP, each operating independently. One of the project managers described it accurately: it felt like each location was running its own company. Most Companies Don’t Have a System Problem. They Have a Standardization Problem. Here’s where most conversations about ERP go wrong. The assumption is that the problem is the technology and the solution is better technology. Pick the right platform, implement it, go live, problem solved. Most ERP projects fail to deliver value because they digitize existing complexity instead of eliminating it. If every facility is running a different costing method, standard cost at one site, weighted average at another, FIFO at a third, and you implement a new system on top of that without aligning the methodology first, you end up with the same fragmentation on a more expensive platform. The data looks cleaner. But the underlying model is still incoherent, and leadership still can’t trust the consolidated output. The technology matters. Dynamics 365 Finance and Operations is a strong platform for manufacturing. It handles finance, procurement, production control, advanced warehousing, and transportation management in a single integrated environment. But the platform is not the hard part. The hard part is standardization. Deciding on one costing method across every legal entity. One chart of accounts. One set of financial reporting dimensions. One inventory structure. One set of business processes that every facility follows, regardless of how they did things before. That’s an organizational challenge, not a technical one. It requires leadership to make decisions that some facility managers won’t like, to retire processes that people have been using for years, and to hold the line when someone says “but our site is different.” Some sites are genuinely different: different product lines, different customer requirements, different shipping environments. The system has to accommodate that. But the underlying operational framework has to be consistent, or the implementation just relocates the chaos into a shinier system. Why a Phased ERP Rollout Starts with a Pilot A multi-facility ERP consolidation requires a phased rollout. The pilot facility isn’t just a test site. It’s where the implementation model gets built. We started with a single facility, not because the scope was unclear, but because a pilot isn’t just a test of the software. It’s a test of the standardized business processes underneath it. Before you can roll out a unified Dynamics 365 Finance and Operations platform across multiple sites, you need to clean and validate your master data, align the costing methodology, and confirm that the configured workflows actually match how work gets done on the floor. You can’t do that reliably for five facilities at once. You do it once, correctly, and then replicate. The pilot gave us a controlled environment to test integrations, run data migration validation, confirm cutover sequencing, and fine-tune training for the team members who would carry the rollout to every remaining site. By the time we moved to the second facility, we had a proven playbook. Conversations with site leadership were different because we could point to a live system that was already working. For mid-market manufacturers considering a Dynamics 365 implementation across multiple locations, the pilot phase is where the project either builds momentum or starts accumulating risk. Get it right, and every subsequent rollout is a replication exercise. Skip it, and every facility becomes its own implementation. Batch Tracking and Advanced Warehousing in Dynamics 365 We implemented the core Dynamics 365 Finance and Operations modules: finance, accounts payable, accounts receivable, procurement, sales and marketing. Those are the foundation. But for a contract manufacturer operating at this scale, the foundation alone doesn’t solve the problem. A contract manufacturer produces goods for other brands under private labels. The customer buying a mattress … Read more

For operations leaders managing supply chain, production, and planning on Dynamics 365 Finance & Operations. Spreadsheets are not a problem, but they are a signal the value an organization is benefitting from Dynamics 365 is far short of the potential. Microsoft Dynamics 365 implementations, and ERP projects, are delivered as MVPs. They establish core functionality, but many capabilities are pushed to post go-live. If you attempt to do too much for your go-live, the project struggles under its own weight, and capabilities must be cut from scope. Either way, some things must wait. So, you’re operating on Dynamics 365, but many departments continue to use the spreadsheets they have always used. Why Are Spreadsheets a Problem in Dynamics 365 Supply Chain Planning? The problem is not that spreadsheets exist, but the risk is that they remain forever. Spreadsheets have served businesses remarkably well for decades, but if the organization does not sunset their use, they become a performance bottleneck.   There are additional risks that emerge as spreadsheet reliance grows over time: Spreadsheets often rely on complex formulas that become increasingly difficult to understand and maintain They are not intuitive, creating challenges when ownership transitions or backup resources are required Data can be easily corrupted through manual errors, including formula fields being inadvertently deleted or overwritten, leading to incorrect calculations There is limited traceability, making it difficult to understand how decisions were made They are difficult to adapt quickly during unplanned or emergency situations These risks compound over time, increasing operational fragility, and reducing the organization’s ability to respond with speed and confidence.   Unlike system driven processes, manual spreadsheets can only operate as fast, accurately, and as frequently as the person doing it. Until the spreadsheets are retired, the expertise remains embedded in the spreadsheet and the planner’s head rather than in Microsoft Dynamics 365. The system does not improve because critical thinking is constantly reapplied in the spreadsheet. As a result, the system will never be trusted, and the business will continue to run on spreadsheets. Why Does Planning Rely on Spreadsheets? Most organizations will say planning happens in Dynamics 365. But the truth is, it happens in both Dynamics 365 and Excel. In many environments, Planning Optimization is not fully trusted to drive execution. Planners export data into spreadsheets and make manual changes to: Adjust demand Override supply recommendations Modify supplier and production lead times Account for conditions the system does not know The planner is overriding Dynamics 365 and making adjustments in Excel because they believe the inputs to Planning Optimization are incorrect. The Inputs are the Challenge of Leveraging Planning Optimization Planning Optimization in Dynamics 365 does not rely on reports or spreadsheets. It runs on: Demand (forecasts and orders) Supply (inventory, purchase, production) Planning parameters (lead times, safety stock, coverage) When these inputs are correct and aligned, the system produces reliable, executable recommendations. When they are not, the system produces an incorrect plan that requires a manual override. This is the root cause of why spreadsheets persist, the system is not trusted to operate independently. The key to success with Planning Optimization is evaluating and improving the completeness and accuracy of the inputs. Schedule a meeting with Ascent to discuss getting the inputs right. What does Planning Optimization in Dynamics 365 look like? D365 Planning Optimization is a supply orchestration engine that converts demand into executable supply decisions across procurement, production, and distribution. Every time Planning Optimization runs, it evaluates: Demand from sales orders, forecasts, and intercompany requirements Supply from on-hand inventory, purchase orders, production orders, and transfers Policies defined through coverage groups and planning parameters Constraints from lead times, bills of material, routes, and resource capacity It continuously evaluates changes in demand and supply and generates system-driven recommendations to keep the plan aligned with reality. The mechanism for operational impact is action messages. What are Dynamics 365 Planning Optimization Action Messages? Action messages are system-generated recommendations that tell you how to adjust your plan. When something changes, a sales order quantity increases, a delivery date shifts, supplier or production timing changes, the system recalculates and makes specific, actionable recommendations. Planning Optimization can automatically suggest: Advance: Move orders earlier to meet demand sooner Postpone: Delay orders to avoid excess inventory Increase: Add supply to prevent shortages Decrease: Reduce supply to avoid overstock These recommendations apply across purchase orders, production orders, and transfer orders, and they propagate across the supply chain. A change at the demand level can trigger coordinated updates across suppliers, production, and distribution. How Does Dynamics 365 Planning Optimization Make Strong Recommendations? Planning Optimization operates within established parameters: Minimum and maximum order quantities Order multiples Safety stock requirements Supplier calendars and availability Production constraints and BOM dependencies It will not reduce supply below safety stock levels. It will adjust quantities to match supplier order multiples. It will sequence actions across BOM levels to maintain feasibility. The business rules within Planning Optimization are owned and managed by the planner and can be adjusted as needed. Why This Matters for AI When all adjustments and decisions are recorded by Dynamics 365, it captures the conditions that led to a decision point and how the decision played out. Over time, this creates a rich dataset of how the business actually operates under changing conditions. Managing planning within D365 is what ultimately enables AI to identify patterns, detect emerging risks and opportunities earlier, and recommend better planning decisions over time. How Can Organizations Sunset Spreadsheets? Spreadsheets reveal Microsoft  D365 and reporting are not trusted, which is where focused projects yield significant business impact. To determine what to prioritize, organizations can do the following: Identify where planning occurs outside D365 Create an inventory of all the spreadsheets Stack rank the business value of systematizing each one Score each initiative for low, medium, and hard complexity Build a roadmap to retire spreadsheets Each spreadsheet is not just a workaround. It represents a specific gap in the system that, once addressed, improves both execution and trust. How Ascent Innovations Can Help Ascent helps organizations move from spreadsheet driven planning to system driven execution by: Identifying gaps in planning inputs Translating spreadsheet logic into D365 configuration Improving data accuracy and alignment Training teams to maintain trust in D365 Demand Planning If your planning process still depends on spreadsheets, the path forward is clear. Schedule a session with Ascent to identify … Read more