Microsoft Dynamics 365 and SAP ERP Together: A Strong Business Case for Hub-and-Spoke ERP

Businesses can deploy two of today’s leading ERP solutions together to meet specific requirements without needlessly complicating their technology environments or abandoning standardization. Hub-and-spoke ERP is a sound, well-tested architecture that takes advantage of each solution’s strengths and drives better outcomes from ERP investments.

Many standard arguments for a complete, unified business management solution from a single vendor hold true when it comes to ERP. It makes sense for companies to keep technical complexities and administrative workloads at a minimum and deal with just one accountable technology vendor. Running all business processes on the same platform can enable a free flow of information to the people who need to consider it in their thinking and decision-making. If all business data live in a single repository, reporting and business insight can be more accurate and include all information that matters. Once users are trained and comfortable, they can more easily change assignments and perform new tasks in a harmonious, connected software environment.

Even Powerful ERP has Capabilities Gaps

Practically, the life of many companies is not such that it can be managed on a simple foundation. For instance, growth and acquisition may result in special requirements of user groups or business entities. Or, specialized systems used, for example, in logistics or product design, offer essential functionality that is not part of ERP, although it might be integrated with it. Today’s leading ERP systems cover more functionality than ever, and phased deployments in the cloud are far more efficient and predictable than the challenging, lengthy implementations that were common in the past. Even so, it doesn’t make practical or economic sense for software providers to try to meet every imaginable need, which would result in overly complicated, feature-bloated products. Businesses are served much better by standard solutions that fit most of the typical functionality requirements in a given industry.

That means ERP systems will, for good reasons, come with a capabilities gap. Companies can integrate them with targeted software products and, if no viable solution is available, they may need to customize and write code, or have a vendor do it for them. Or, if they want to leave their ERP infrastructure unmodified but still need to enable productive operations for a business group or a set of processes and workloads, they can deploy a second ERP solution and put integrations in place to ensure that users’ productivity is not jeopardized by data starvation. In such multi-tier ERP architectures, most often, one ERP system is considered the system of record and the first tier, with the second one supporting discrete workloads or meeting essential business requirements that are not common across the entire organization.

Two Tiers Functioning as One System of Record and Engagement

Hub-and-spoke architecture is a widely used model for multi-tier ERP environments. A complex, global enterprise may use SAP to manage its activities in a highly standardized, streamlined manner. But, when the company acquires another business or enters a new market, it needs to meet compliance standards or support business processes that only matter for that new division or market. It’s just as unproductive and wasteful to enforce these requirements across the enterprise as it would be not meeting them at all. The company implements a second ERP solution, like Microsoft Dynamics 365, to support the operations of that business group or in that market. Similarly, when a company wants to sell or spin-off a part of the process, it could deploy an ERP system just for that segment. Doing so would prepare the path for a relatively smooth transition and enable the new entity to be fully functional from day one.

While many matches between ERP systems in a hub-and-spoke architecture are possible, practically a small handful of them are more manageable, predictable, and effective than others. That can happen when two software companies follow complementary goals, standards, and approaches for creating robust, scalable, usable, secure technology to support demanding workloads. SAP and Microsoft Dynamics together present a strong business case for successful hub-and-spoke deployments. Companies have been using the two ERP systems in conjunction long before Dynamics became a cloud-enabled solution on Azure as Microsoft Dynamics 365.

How to Run Standard Core Operations and Meet Specialized, Local Requirements

To explain why Microsoft Dynamics 365 works so well in hub-and-spoke ERP environments, many ERP industry observers and analysts emphasize specific strong points of the technology. At Sikich, we rely on these characteristics of Dynamics 365 in many implementation and upgrade projects we perform for our clients. For one thing, Dynamics 365 is a category leader when it comes to providing comprehensive, powerful functionality for a wide span of businesses. Flexible configurations make it possible to adjust Dynamics 365 for industry-specific requirements, and thousands of ISVs offer proven, extensively vetted solutions to meet more specialized needs. The software has been localized for more than 40 languages and country-specific conditions, and the comfortable, intuitive user interfaces incorporate best standards for usability.

Across industries, we have observed and supported many use cases for hub-and-spoke ERP architecture with SAP and Dynamics 365. Some companies running SAP on-premises may deploy Dynamics 365 on Azure when the advantages of the cloud are compelling. Often, that is the case when a business experiences sudden variation in transaction processing, and quickly scaling resources up or down is best accomplished in the cloud. For some companies, that may also be their first experience of Azure success, foreshadowing what could happen once they move their SAP ERP solution to the cloud as well.

It also happens that business groups or recently acquired companies use several highly specialized or customized applications, and it’s easier to consolidate and streamline them within the confines of the second-tier Dynamics 365 ERP solution, not SAP. Another, relatively frequent scenario takes place when a company opens a subsidiary or acquires a business in a different language environment and decides to use Dynamics 365 because it can comfortably accommodate the right language along with regulatory mandates and unique business processes.

It’s Realistic to Expect an Efficient, Predictable Implementation

Given the advanced state-of-the-art and the availability of documented, best practices and the experiences of various companies and their ERP partners, implementing Dynamics 365 in a hub-and-spoke architecture with SAP can be a controlled, low-risk effort. The layered structure of the technology—including database, persistent, application, service, business logic, and presentation layers—enables a high level of flexibility. Layers inter-operate but function independently of one another, and multiple layers of one type can interact with others. That is a great advantage when an implementer needs to support the kind of common scenario where users or devices run the same software in a variety of processes, all of which connect to a centralized database.
Sikich has helped many companies deploy and benefit from Microsoft Dynamics 365.

Get in touch with us if you want to learn more about low-risk, fast implementations that help you achieve predictable business results.

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author