Post go-live support

Mike Pereira is Sunrise’s Vice President of Global Customer Support and one of Sunrise’s longest-serving employees. Mike has over twenty years of experience and a deep background in apparel and textile management as well as manufacturing supply chain management.

You did it! Breathe a sigh of relief — you made it through go-live, and your new ERP system is up and running. Now it’s time to tackle what to do after go-live. Even though you may want to call this project “done” and move on, the work isn’t over. The first few weeks after going live, it’s critical that you stay vigilant and nip any issues in the bud. Let’s walk through the hyper care process and document some things you should expect…

Data migration: the first wave

Special cases

Helping new users

Avoid the Valley of Despair

Frequently asked questions

Data migration issues — the first wave

People are surprised at how quiet the first week after go-live can be. If you did all your testing and gave yourself plenty of time and CRPs, transactions should be flowing through your system without a hitch. The first thing you might encounter are data migration errors. These usually happen because business users have only interacted with the old, migrated data before, and any issues that existed could throw errors in the new system. It’s important to clear out these data migration errors first, before too many pile up.

Special cases

It’s impossible to test every possible scenario prior to go-live. The second wave of issues you might encounter are the outliers — one-off scenarios you didn’t have time to test. These are to be expected (after all, you have to go-live at some point, right?) As users start adding new master and transactional data, these corner cases become obvious. The intersection of data and business processes can create unique, unexpected situations. If your project team handles these cases as they appear, you should be fine.

Helping new users

You’ve conquered any migration problems and taken care of the corner cases. The last thing to look out for are user errors. We consider these issues the most dangerous because if they aren’t dealt with swiftly, user errors can snowball into an avalanche of problems that affect the whole organization. For example, an employee from merchandising might forget to associate the cost for a new product. The warehouse then receives the product at zero cost, and now the fix requires several financial transactions and lots of time. During this time, speed of resolution is key. If errors are being created faster than resolutions, that’s a problem. Your project team and your organization’s power users should work on clearing out these errors and reinforcing best practices among the rest of the organization.

Avoid the “Valley of Despair”

The Valley of Despair is when your ERP’s performance drops dramatically, shortly after going live. Users might get frustrated, disappointed, and wonder if the project was even worth it. Guiding users around this metaphorical valley of despair is why your project team should stick around a little longer. The real benchmark people should focus on is closing the first financial period in the new system.

Frequently asked questions

What are the most common problems users might experience after go-live?

Data migration errors, followed by special cases regarding business processes, and user errors are most common.

What’s a good benchmark for measuring success post go-live?

Closing the first financial period in your new ERP system is a common benchmark to use.

We don’t have time to test every scenario in time for our scheduled go-live, is this bad?

Assessing go-live readiness is an art and a science. Businesses are complex—and it’s impossible to test every single scenario and stay on schedule. It’s to be expected that some special cases will reveal themselves in the first few weeks after go-live.

Start Your Journey with Sunrise Today!

Whether you’re exploring your options for new business platforms, or ready to get started, we are trusted business partners for some of the world’s most well-known brands. With over 25 years of experience with the Microsoft stack, we can help you understand all the capabilities Microsoft has to offer.

To customize, or not to customize?

Implementing a cloud-based ERP system like Microsoft Dynamics 365 is essential for organizations seeking to stay competitive. However, one topic that often causes hesitation during ERP projects is customizations. While ERP customizations have historically been a source of frustration, particularly when they lead to long-term maintenance issues or system instability, a “no customization” policy isn’t always the best approach. The key is knowing when customizations add value versus when they create unnecessary complexity.

Understanding When to Customize Your ERP System

Not all customizations are created equal. The decision to customize should never be taken lightly, but avoiding all customizations across the board can leave your organization struggling to maintain a competitive edge. A better approach is to evaluate whether a customization serves a clear business purpose. Customizations should align with your company’s goals and long-term strategy, enabling your teams to perform at their best while enhancing overall efficiency.

Gap-Fit Analysis: Identifying When Customizations Are Necessary

During the early stages of an ERP project, your team will engage in a gap-fit analysis to document current business processes and compare them with the new system’s out-of-the-box functionality. This is where the decision to customize or change your processes often comes into play. Should the software be customized to fit your current business processes, or should your processes adapt to fit the software?

There are pros and cons to each approach. Customizing the software may seem like a faster, easier option in the short term, especially when users resist change. But using customizations as a shortcut can result in significant long-term costs, from ongoing maintenance to system updates that break existing custom code. On the other hand, asking your team to change ingrained business processes can be time-consuming and may lead to friction during implementation.

The trick is finding the right balance. Customizations should be reserved for areas that truly impact your company’s uniqueness or provide a competitive advantage.

Strategic Factors to Consider Before Customizing

Adding Value to the Organization

Customizations should deliver measurable value. Will the customization improve efficiency, enhance the customer experience, or contribute to higher revenue streams? If the answer is yes, it may be worth considering. However, any customization should align with your organization’s broader strategic goals and business objectives.

One good rule of thumb is to ask: Will this customization make my business more competitive in the marketplace? If the answer is no, it might be better to explore standard functionality or process changes.

Streamlining Processes

A well-planned customization can help streamline workflows by automating repetitive tasks, simplifying processes, or integrating disparate systems. For instance, if your business relies heavily on manual processes, a customization could significantly reduce time and labor costs.

However, remember that customizing software to match inefficient processes isn’t the answer. Consider whether changing your business processes could deliver similar efficiency gains without the need for custom code.

Exploring Low-Code Alternatives

Before diving into full-blown customizations, consider low-code solutions, such as Microsoft’s Power Platform. Low-code platforms allow you to build custom applications with minimal development effort, providing needed functionality without heavy investments in development or future maintenance.

The Power Platform integrates seamlessly with Dynamics 365, giving users the flexibility to extend the ERP system without feeling like they’re interacting with a completely different solution. This approach can reduce complexity and help you avoid the maintenance issues that customizations can introduce, all while enhancing user satisfaction.

Evaluating the Long-Term Feasibility of Customizations

It’s easy to overlook the long-term implications of customizations, but it’s critical to assess their feasibility over time. Customizations require ongoing updates, especially as cloud platforms evolve. You’ll need to ensure that your customizations remain compatible with future upgrades and don’t become a burden on your IT team.

When evaluating whether a customization is sustainable, consider:

The resources required to maintain and update the customization over time.
The potential impact on future upgrades or new system features.
Whether the customization aligns with the long-term goals of your business.

By thinking ahead, you can ensure that customizations don’t become obstacles but rather sustainable enhancements that support your growth.

Everything You Need For A

SUCCESSFUL IMPLEMENTATION

Cloud-based ERPs have changed implementation best practices and methodologies. Based on over 30 years of experience, we’ve identified seven critical factors that influence whether a project succeeds or fails.

Ready for your tailored ERP solution?

Schedule a call with one of our ERP experts today to implement Dynamics 365 with less cost and fewer customizations.

Don’t underestimate data migration

As a Director of Consulting for Sunrise Technologies, Jason Wolf has over 15 years of experience implementing Dynamics ERP solutions for apparel, footwear, retail, and consumer goods companies.

ERP implementations are tough

Over the years, implementation partners have created methodologies, project management and planning tools to account for every aspect of an ERP implementation. Yet it’s still common to see data migration get left behind during project planning. We believe this is backwards, since without the data, your new ERP system can’t go live. Data migration should be considered at the beginning of an ERP project, while other important design decisions are being made. By taking the time upfront to plan your migration strategy, you can avoid unexpected delays during your project.

Why migration planning is so important
Data migration strategies
Data cleansing
Validation and testing
Frequently asked questions

Data migration can make or break your implementation

Migration planning should happen early in the project. Getting a jumpstart on the challenges for each data structure can save tons of time, and safeguard against unexpected hiccups during the project. It also gives the project team a better idea on timelines and resources needed to get from the old system to the new one. The bigger the change to a data structure (especially master data structures like product, customer, vendor, etc.,) the more challenging it will be to move to the new system. Without a plan in place, budgets can run over, timelines run long, or an issue stalls the process late in the project.

Selecting a strategy for data migration

The key to a smooth migration is picking the right strategy. One size does NOT fit all, which is why it’s important to spend time early in the project deciding on the best method. Some examples are:

Bill of Materials data might be complex, with significant changes to the data structure. However, the volume might be small enough that it’s easier to enter it manually. For very complex data structures, it doesn’t make sense to write a migration script that you’ll only use once, when in the same amount of time you could just enter the data.
Sales orders (or other types of transactional data), might be thousands or even hundreds of thousands of lines long. In that case, it might be better to create an automated script to move and map the data.

Cleaning the data

One of the unsung benefits of an implementation is getting a fresh start with clean, well-organized data. You can’t realize all the benefits of a new ERP system if your data is riddled with errors. Take this opportunity to remove redundancies, append missing information, fix typos and errors, and archive what you won’t need going forward. The key is to clean the data before migrating to the new system. Source data should be audited, issues resolved quickly, and controls set up for maintaining data quality and governance in the new ERP system. Much of this data cleansing work is manual, but it’s worth it to get the full value out of your implementation.

Data validation

The only way to know for sure that the data migrated successfully is to check. The basic process is to start with a small amount of data, load it into the new ERP system, test, add more, and repeat. Once the migration is complete, you can validate it by checking against the source system. For example, say you want to check your open sales orders. You could check the line counts, quantity, and amount against the original source and if the numbers match, you’re good to go.

Frequently asked questions

When should we start thinking about data migration strategy?

As early as possible! A data migration strategy should be considered early in the project, while other key design decisions are being made.

How do we decide which strategy to use for data migration?

There isn’t a one-size-fits-all approach for data migration. Your implementation partner should offer guidance based on their experience. In general, for lower volumes, it might be more efficient to manually enter the data rather than spend time creating an automated script. For very large sets of data that contain complex mapping and business logic, automation may be the way to go.

How should we handle data cleansing?

Clean your data in the source system prior to the migration.

How do we validate that the migration was successful?

Create a checklist to test what’s in your new system against the legacy data source.

Start Your Journey with Sunrise Today!

What kills an ERP project?

As a Project Manager for Sunrise Technologies, Kristin Pehilj brings over 20 years of industry experience to the table and serves as a trusted advisor for apparel, footwear, and consumer goods companies that are in the midst of an ERP replacement.

No one wants to think about it, but your ERP project might fail. And while there’s a wealth of analysis on why ERP implementations fail, we consider one factor to be the difference between an implementation’s success or failure. Executive involvement is key — without it, an ERP project will struggle from the beginning and may not recover.

Change management

The executive’s role

Steering committee meetings

Frequently asked questions

More than just an ERP project

An ERP implementation is really a change management initiative. Just with more software involved. Asking people to change is never easy. It’s up to your company’s leaders to champion the project and guide your employees throughout the process.

Once a project is underway (and starts to get tough), the new system should be the catalyst for business transformation, something people can reference as the driving force behind positive change. You can have the best consultants, but even skilled, friendly, hard-working people face resistance when they’re the outsiders. Members of groups follow their leaders. And this is a good thing! Huge projects only get accomplished when people work together as a team, which is why executives should be prepared make tough decisions, foster consensus, and drive the project forward.

How executives can play a crucial role

Of the thousands of decisions that need to be made during a project, many are going to be controversial. An ERP system touches almost every department in a company. Each department has its own set of processes and distinct personalities. Something like sales order management — which crosses paths with sales, credit, customer service, planning, logistics, accounts receivable — could require days or weeks of meetings. And when people can’t come to an agreement? The process stalls. This is the death knell of your project. This type of deadlock is why executive support is crucial. They can smooth the path and make the tough decisions needed to drive the project forward.

Why meetings are so important

We recommend you form a project steering committee and meet at least once a month. The meetings don’t have to be long, but they should focus on specific asks for executives, rather than just listing project updates. It’s amazing what you can accomplish in a one-hour meeting. The key is to keep requests concise, limit needless updates, and be clear on who is responsible for what. By bringing a list of short, actionable items to the executive team, you can respect everyone’s time and keep them engaged and involved.

Frequently asked questions

Why is this more important than budgets, applications, platforms, or other resources?

Certainly those factors are important, but we consider executive involvement the backbone of a successful ERP implementation. These projects involve change management, which is never easy and relies on a company’s leaders to see it through.

How can I ensure my executive team’s involvement?

The most basic thing you can do is establish a steering committee and ask key members of the executive team to participate. Getting executives to attend regular meetings might be tough, but a well thought out meeting with an agenda, decisions and next steps will go a long way to keeping them involved. And it will be worth it in the end.

Ultimately, who is responsible for what?

It’s the implementation team’s job to decide who is responsible for what activities, which problems need an executive decision, and which can be solved on their own.

Fitting in another monthly meeting is hard, how do we use the time effectively?

The key to a successful steering committee meeting isn’t just project updates (people can get that information on their own time), it’s bringing up the issues that need executive input. Get in, follow the agenda, assign next steps, and move on.

Start Your Journey with Sunrise Today!

Season codes: what are you really tracking?

As the SVP of Global Business Development for Sunrise Technologies, Cem Item serves as a trusted advisor to C-level executives running large global enterprises. He conducts corporate business strategy engagements and digital transformation workshops around the world. With over 20 years of consulting experience, Cem specializes in the textile, apparel, footwear, home furnishings, consumer goods manufacturing, and retail industries.

The importance of seasonal products for brands

Some brands live or die by seasons. We work with a lot of apparel and fashion brands, and seasonal inventory is very common for these companies. Winter coats, summer dresses, that sort of thing. While other types of businesses certainly have a seasonal element, there is tremendous pressure for brands to stay on top of the latest trends (or create trends themselves).

Optimize inventory with season codes

Season codes give you the ability to report on a product’s sales performance by season. This is a good thing. Especially for apparel and fashion brands, the styles of products change from year to year. A style may have one season to prove itself, and if it doesn’t sell well, it’s gone next year. Often, we find companies add the season code to a product’s style number — for example, say you make a dress and call it DressF20.

Embedded season codes in style numbers cause problems

At first glance, combining season codes and style numbers seems fine. It makes logical sense. But over time, keeping these two attributes together causes problems. Let’s examine a few:

Problem 1: If you decide to sell across seasons, you need to create new style numbers for the same product

The dress from Fall 2020 was a big hit. You want to carry it next year. Great! However, you’ll now have to make a DressF21 style and move the 2020 inventory to the new 2021 style number.

Problem 2: Carried-over styles need new color and size product variants

The original dress you sold that was so popular — you also have to make new color and size variants for the carried-over style.

Problem 3: You must complete inventory transfers for the new SKUs.

You’ve got your new style number, your new variants — now it’s time to transfer the leftover inventory from the old SKU to the new SKU. Now imagine doing all this work for 10, 20, 30 styles every season. Think about all the time and effort wasted — all because you’re tracking styles and the season code together.

Last season doesn’t really mean last season (for styles)

Ask yourself: what data are you really trying to capture with the season code? Are you trying to document:

When the product was designed?

When the product was manufactured?

The selling season for the product?

A better way to manage seasonal inventory

You may find a more logical attribute than season, or that there are actually multiple “seasons” that have nothing to do with whether it’s snowing outside or not. Maybe design seasons are the way to go. Another way to think about it is in terms of color. Colors lend themselves to seasonality more than style, so you could link a season code with a color rather than a product. The best way to generate season codes will differ for your business, but being thoughtful about what you really need that data for, and setting it up right the first time, can save time and money down the road (no more frantically keying in new product numbers and inventory transfers).

Start Your Journey with Sunrise Today!

What should your product numbers mean?

As a Senior Supply Chain Consultant for Sunrise Technologies, Melissa Welhelmi brings over 20 years of industry experience to the table and serves as a trusted advisor for apparel, footwear, and consumer goods companies that are in the midst of an ERP replacement.

Intelligent product numbers

Like we’ve discussed before, product is the heart of your brand. And since product structure is such an integral part of your business, how you number (or don’t number) those products matter. A lot.

Intelligent numbering is very common in the industries we work with. This is when a product’s number or ID contains meaningful information. For example, a fashion brand might have a jacket label WJF20S123-BLK-S. In the style name, “W” means Women, “J” means Jacket, F20 means Fall 2020 season, S123 means the sequential style number. “BLK” is the color black and “S” stands for small size. The style numbers can get really detailed.

At first, intelligent numbering makes a lot of sense, especially for quick analysis. At a glance, users can see the most important attributes. Especially with companies using legacy inventory management systems, users may rely on those product numbers packed with meaning for reporting and analytics.

Why smart numbering is no longer a best practice

Businesses change. Employees leave and take their institutional knowledge with them. New staff members have to learn and maintain the product numbering schema. Because humans maintain these numbers, mistakes happen. Eventually, you may find that no one understands what your company’s product numbers mean anymore, but you have to maintain it for the sake of not having a better alternative.

In many ways, intelligent numbering is an outdated practice that should be left behind with legacy systems. There are many downsides:

Someone needs to be well-trained and well-versed in the product numbering schema so they can correctly configure products. Mistakes cost time and money to fix.
Heavy reliance on insider knowledge — new staff members don’t know the meaning behind the intelligent numbers.
Hard to maintain — adding new product categories means you might have to rethink the whole data structure and add new, complicated logic.
Adding new products can be time-consuming, with a higher likelihood of manual entry and errors.

Intelligent numbering isn’t just a human problem, it’s a systems problem. Especially for consumer brands, once they start adding new product categories, additional information must be added to the product master data setup. The extra business logic that comes with this work adds another layer of complexity to something as simple as numbering products.

Trade smart numbers for a smarter system

We’ve discussed this in detail in some of our other blogs — there’s a better way!

Business applications today are built to handle multidimensional products without complex naming schemes. Data entities like dimensions, hierarchies, attributes, categories, and assortments can be used to create a new master data model for a company that is easy to maintain, without intelligent number schemes.

Legacy systems often lack this capability, so we understand why organizations struggle with intelligent product numbering.

Why you should ditch smart numbering in your product data management

Easier than intelligent numbering

Adding new products is quick and easy.

Users don’t have to remember extra information about meaning behind product numbers

They can use other dimensions in the ERP system for search and reporting.

No single point of failure (or bottlenecks)

Multiple users can work with products in the system, and they don’t have to ask someone what the numbers mean.

Easy to maintain

Has your brand expanded into dog beds, home furnishings, or hair products? No problem. Configuring new dimensions is easier and faster than rethinking your numbering schema for your entire product catalog.

Improve part or product lifecycle management

If product information changes, the number doesn’t have to.

Easier to merge new product catalogs

Product catalogs from different companies or acquisitions can be merged without losing information.

Ease of reporting

Advanced reporting like data mining, automated queries, and business analytics is easier to do with simple product IDs.

Other considerations for intelligent numbering and ERP systems

A new systems implementation is a complete paradigm shift for your business. Like we discuss in product attributes, an ERP project is an opportunity for you to cleanse your data and setup a new master data structure that works for you. Changing these data entities is a big deal and requires a solid change management strategy.

Virtual Warehouse

Warehouse data tells a story

Data tells a story about how a company runs its business. The warehouse table in particular — this core entity reveals so much about how a company manages its inventory. We’re fascinated by the creativity we see and how customers utilize their inventory data in so many ways.

A common setup: virtual warehouses

One way customers can manage inventory is by setting up virtual warehouses. This is when a warehouse that doesn’t exist in physical space is created in their inventory management system, and inventory is added. Virtual warehouses are a technique used to segment inventory. Think of it as “setting aside” a portion of your product for VIP customers or certain channels. Virtual warehouses aren’t necessarily a bad thing – if an important customer, region, or channel made an early commitment to your product, you definitely want to make sure that product is available to them. For single-channel brands or businesses with simple supply chains, virtual warehousing is a perfectly fine way to manage inventory, and a good business practice. But for omni-channel brands, or global organizations selling product in multiple countries, using virtual warehouses to segment inventory can cause problems.

How virtual warehouses cause problems in the supply chain

Problems start to happen when you set up dozens of virtual warehouses in the system to serve different channels, regions, and retail stores. Even though the warehouses are virtual, you still must deal with the same inventory management issues that crop up just like in a physical warehouse. There are overages and shortages. Demand fluctuates. Product that you “set aside” for your customers and channels changes, constantly, and now you must keep up with every warehouse you created. Different operational segments of the business may hide inventory from another, so they can ensure their fulfillment requests are met. It’s not uncommon for us to see a single warehouse storing product, yet the ERP system has four separate virtual locations. How can you fulfill orders from warehouses that don’t exist?

Fixes for virtual warehouses – that actually cause more problems

When businesses start to have these problems with virtual warehouses, they come up with a brilliant solution – virtual transfers! These cause their own sets of problems, though. When this happens, you’re moving too far away from the accurate, real-life understanding of your inventory. To fix this, companies ask their IT departments to write specific algorithms to automate these virtual transfers, which eats up more time and money. And all the while, the brand still must keep fulfilling orders and allocating product. What started out as a simple way to make every channel happy becomes a twisted nightmare of complex rules and business logic. There are also third-party solutions you can buy and implement to make virtual warehouse management easier. But at the end of the day, these solutions don’t fix the core problem: your virtual house inventory doesn’t match your physical inventory, and it’s hard for the business to make good decisions regarding fulfillment, allocation, and how to manage the supply chain.

The solution? Get rid of virtual warehouses

There is a solution for this virtual warehouse madness and prioritizing where inventory gets allocated. An intelligent soft allocation system can dramatically improve omni-channel inventory management. Soft allocation does this by pegging inventory to segments based on demand and supply from a single inventory point (aka a single warehouse). Instead of automating virtual transfers just to balance out inventory inaccuracies, soft allocation is configurable as demands change, with no complex rewriting or rules or algorithms. Users can prioritize inventory, while pulling from a single pool and maintaining global visibility across the entire system.

Frequently asked virtual warehouse questions

What's better, hard or soft allocation?

Soft allocation is the way to go. By keeping inventory transparent, you keep the supply chain moving quickly. Solutions can give you the flexibility to hard allocate once you’re ready to ship, but up until that point, you’ll want to be able to move orders around fast, without unnecessary data entry or manual processes.

If virtual warehouses are so problematic, is there still a case to use them?

We don’t consider virtual warehouses a best practice. For one thing, there is nothing fast about virtual warehouses. Once you start messing around with virtual transfers and virtual overages and shortages, you’ve moved too far away from reality, and your users are going to waste a lot of time trying to make your imaginary warehouse look right. At Sunrise, we advocate for having what’s in your system match your physical inventory, sticking as close to reality as possible.

Is this where negative inventory comes from?

Theoretically, yes, although it’s possible to put systems in place to prevent that. Even with extra business logic, though, solving one problem for virtual warehouses won’t fix everything that’s wrong with using them in the first place. Soft allocation prevents negative inventory from ever being an issue.

Why replace virtual warehouses with a soft allocation solution?

If your brand sells across multiple channels like retail, eCommerce, and wholesale, or they sell in multiple regions or countries, soft allocation is the way to go. The more complex an organization, the smarter it is to keep all the inventory in one big pool. It seems counterintuitive at first, but when done correctly, soft allocation ensures you can meet fulfillment demand and have an accurate, real-world view of your inventory across all your channels.

See how Dynamics 365 handles inventory management

Are you interested in learning more inventory best practices? Would you like to a see a modern, streamlined allocation solution that gives you both flexibility and accuracy? Contact Sunrise today!

Product attributes: best practices for product management in a new ERP deployment

So, you’re embarking on a new ERP implementation. It’s a new beginning, a chance to reevaluate, reorganize, and revitalize your business processes. And for consumer brands and retailers, product management is the most important piece of the ERP puzzle.

When starting a new ERP implementation, it’s absolutely critical that you think about how you’ll handle product attribution in your new system. For many companies, it’s a mistake to bring over the old product data structure.

Instead, take this as an opportunity to clean up messy, disorganized data and define a product hierarchy that frees your team from unnecessary and confusing product management.

Product attributes: the lifeblood of your brand

Product is the heart of a brand. Whether you sell jackets or handbags or table lamps (or all these things and more), you must define the type, colors, sizes, and many other dimensions for each product. A company’s product data structure is one of the most complex parts of an ERP system. Almost every area of your business will bring their own data and business logic to the product management party. It’s essential that you maintain clean and accurate data for your products to keep them moving through the system efficiently.

What are product attributes?

For those who don’t know: product attributes describe your brand’s, well, products. For those who are all too familiar: managing product attributes can be a pain, especially in a legacy system. Every time a brand debuts a new collection or starts selling a new category of goods, new attributes must be added to the ERP system.

What’s the best way to manage product attributes?

During a new ERP implementation, you have a rare opportunity to clean up your messy data and streamline your product management. Whatever data structure you decide on, you’ll have to live with for the next several years (or decades). Here’s the process we recommend for cleaning up your product hierarchy:

Step one: define your hard attributes

Hard attributes are characteristics that span your entire organization – examples are Brand, Gender, and Product Type. These are used by the business to sort and filter products. Hard attributes show up in the main forms and reports of a business. You will end up with a few of them.

Step two: define soft attributes

Soft attributes, on the other hand, are where you really slice and dice your product data. These are details that are specific to your product categories — think flammability for clothes, finish for furniture, material for handbags, etc.

Examples of hard attributes

Brand
Gender
Product type

…there will only be a few of these

Examples of soft attributes

Color
Finish
Flammability

…there will be a lot of these

The biggest mistake companies make in their product master data

We see this a lot with legacy systems: ALL the soft attributes, across every product category, are visible for every product. Business users then get confused — why is Finish showing up for a jacket? Why is Flammability listed in the Footwear section? Am I supposed to maintain the water-resistance attribute for my furnishings products? It gets confusing and messy, fast.

Product hierarchies: an opportunity to clean house

It’s usually not a company’s fault that their product masters get so jumbled. Legacy ERP systems don’t handle multiple product categories very well, and people develop customizations and workarounds to get the info they need. Plus, the retail and consumer brands landscape has changed so much – an apparel company that implemented an ERP system in 1999 couldn’t predict that someday, that same company would evolve into a lifestyle brand selling handbags, shoes, accessories, and home décor. Or that a company may acquire another brand that sells a completely different product, like furnishings, or cosmetics.

That’s where a modern, cloud-based ERP comes in: you need a system for handling many different categories, while minimizing confusion and extra work for product management. Adding a new product category should NOT require customizations to your ERP system.

ERP deployment considerations for product master data and attributes

The right ERP system can give you the correct product hierarchy to efficiently manage all your products. Microsoft Dynamics 365 makes it easy to define parent-child product relationships within categories. New soft attributes can be added quickly and attached to the relevant products in your hierarchy. Your users only see what they need to see, and their work is no longer crowded with irrelevant product data.

See how Dynamics 365 handles multidimensional inventory

Are you ready to simplify your product data structure? Want to learn more about how Dynamics 365 can efficiently manage your supply chain and revitalize your company? Get in touch with us today!

PLM integration

As a Senior Technical Architect and Project Manager with Sunrise, Mason Whitaker works closely with consumer brands and retailers organizations to ensure smooth Dynamics 365 implementations. Mason has experience working with global organizations in several industries, from e-commerce based mountain bike retail to high-end textiles and fashion.

The Need for Both Systems

Consumer brands and discrete manufacturers often need both PLM (Product Lifecycle Management) and ERP (Enterprise Resource Planning) software.

Since these consumer goods companies are designing and sourcing or manufacturing products, they require both solutions to handle their business operations.

And when shopping for a new ERP system, some companies hope to find them combined together in a single, all-in-one solution…but should you?

Here’s what we are going to dive into:

PLM vs ERP | Combining PLM and ERP | Boundaries between ERP and PLM | PLM and ERP Frequently Asked Questions | PLM Integration Framework

PLM vs ERP

Let’s start with a few definitions.

PLM: Flexible software that is used to manage the design process, configure and track design milestones, and facilitate team collaboration to plan and design new products to introduce to market.
ERP: Fully integrated financial and supply chain systems which handle high volumes of transactional, structured data, supporting the day-to-day business processes of sourcing and selling those products once introduced to market.

In the real world, the systems must pass product information back and forth…which can be done as an integration between two standalone systems or by adding PLM functionality to an ERP.

And while it is attractive to combine the two systems into a single solution, with a joint backend database, our recommendation may surprise you.

Should PLM and ERP be combined?

By trying to combine the two worlds into one product, companies often see a loss of features in either the PLM or the ERP. Attempts to combine the flexibility of PLM with the structure of ERP often fail — sacrificing unique characteristics of each that made them work in the hopes of finding a single solution.

Therefore, we recommend keeping PLM and ERP separate as a best practice.. In terms of application architecture, these two software solutions are complete opposites.

By allowing the two systems to operate separately from each other, both can function at their best to deliver the results you wanted from your investment in the first place. Product data for design, and product data for manufacture and sales transaction are very different.

The real need is for appropriate integration points so the two separate applications can pass product information back and forth, like attributes, variants, etc.

Where do you draw the boundaries between ERP and PLM?

Here are four general rules of thumb as you consider your product offerings across all channels and global regions.

Not all products need to live in the PLM. Only the ones that your consumer goods company designs in house need to start their product lifecycle in the PLM. The products that are designed by third parties can skip the PLM cycle and be entered straight into the ERP.
You must determine which system will provide the master for each product, and it should always be the master system going forward. This will help you avoid conflicts and duplications — which is critically important to avoid dual-sided, complex integrations.
Planning an interface between ERP and PLM needs to take into account more than just the product data. For example, you need to first plan the foundation for how product data will flow across the applications without friction, including reference data for units of measure, seasons, currencies, and vendors.
And finally, in addition to reference data and product data, more complex data integrations need to consider the flow of data for BOMs, POs, routes, etc.

If this sounds like a lot to consider when planning your PLM and ERP integration, or if you’re considering Microsoft Dynamics 365 for your ERP, then good news! We’ve already created a framework for you.

Frequently asked PLM and ERP questions

Where do we create a new style with multiple colors for our brand?

Create it in your PLM and push that product data to your ERP.

What happens when we need to change a color offering later?

If you are going to drop a color, extend a color across seasons, or introduce a new color, you should make those changes in your PLM first and then push the data to your ERP.

Should all product data be maintained in one system?

No, these rules of thumb don’t necessarily require that all product data like assortments, hierarchies, attributes, etc., need to be maintained in one system.

Does eCommerce product attribution need to be maintained in the PLM?

No, as a similar case to above. An intelligent integration design will keep a single system as the master application, while letting other third-party systems append additional data elements, such as attributes, as needed.

PLM Integration Framework for Microsoft Dynamics 365

Because thinking through intelligent PLM integration frameworks is complicated…and because we’ve done it a lot, we include this as part of our industry solution, so you don’t have to start from scratch.

In fact, most of our customers require a best-of-breed PLM system to manage the design of new products, and that’s why we include a PLM integration framework as part of our Sunrise 365^® Supply Chain extension for Microsoft Dynamics 365. It has everything you might need to configure, manage, and process the integration with your preferred PLM software – and has been built to be customized and extended to meet the needs of any implementation.

It utilizes a set of message entities to send and receive data to and from any third-party PLM system of your choice. The integration framework includes a set of out of the box entities for reference and product master data, and the solution can also be extended by creating additional entities or extending existing entities for your unique requirements (for example, add message entities for Bills of Materials).

In case you weren’t familiar, our supply chain solution extends Microsoft Dynamics 365 for Finance and Operations with a ton of advanced functionality that any consumer brand, apparel, footwear, or fashion company would need to make it a perfect fit. The PLM Integration framework is just one tiny piece of it, but you should also note, it also includes integration frameworks for your 3PLs and eCommerce platform too!

Start Your Journey with Sunrise Today!

TEC certification report

Review: Sunrise 365 Supply Chain and Retail Replenishment for Fashion and Retail Brands

Technology Evaluation Centers (TEC) is a leading software industry analyst firm. To achieve TEC certification, software solution providers must conduct a demo and submit a detailed functionality questionnaire. TEC analysts compare the solution against known benchmarks and provide a detailed review of the software’s features. The extensions in Sunrise 365 add support for essential fashion and apparel industry functionality, all seamlessly integrated into Dynamics 365.

Sunrise Customer Stories

Vera Bradley: Dynamics 365 at the Heart of Its Digital Transformation

Get Your Money's Worth

Save time and gain instant value when you deploy Microsoft Dynamics 365 with Sunrise industry extensions.

You Just Went Live...Now What?

Data migration issues — the first wave

Special cases

Helping new users

Avoid the “Valley of Despair”

Frequently asked questions

Further Reading

Start Your Journey with Sunrise Today!

To Customize, or Not to Customize?

Table of Contents

Understanding When to Customize Your ERP System

Gap-Fit Analysis: Identifying When Customizations Are Necessary

Strategic Factors to Consider Before Customizing

Adding Value to the Organization

Streamlining Processes

Exploring Low-Code Alternatives

Evaluating the Long-Term Feasibility of Customizations

Everything You Need For A

SUCCESSFUL IMPLEMENTATION

Ready for your tailored ERP solution?

Don't underestimate data migration

ERP implementations are tough

Data migration can make or break your implementation

Selecting a strategy for data migration

Cleaning the data

Data validation

Frequently asked questions

Further Reading

Start Your Journey with Sunrise Today!

What kills an ERP project?

More than just an ERP project

How executives can play a crucial role

Why meetings are so important

Frequently asked questions

Further Reading

Start Your Journey with Sunrise Today!

Remove season codes from style numbers for better inventory management

The importance of seasonal products for brands

Optimize inventory with season codes

Embedded season codes in style numbers cause problems

Problem 1: If you decide to sell across seasons, you need to create new style numbers for the same product

Problem 2: Carried-over styles need new color and size product variants

Problem 3: You must complete inventory transfers for the new SKUs.

Last season doesn’t really mean last season (for styles)

When the product was designed?

When the product was manufactured?

The selling season for the product?

A better way to manage seasonal inventory

Further Reading

Start Your Journey with Sunrise Today!

What should your product numbers mean?

Intelligent product numbers

Why smart numbering is no longer a best practice

Trade smart numbers for a smarter system

Why you should ditch smart numbering in your product data management

Other considerations for intelligent numbering and ERP systems

Virtual Warehouses Best Practices

Warehouse data tells a story

A common setup: virtual warehouses

How virtual warehouses cause problems in the supply chain

Fixes for virtual warehouses – that actually cause more problems

The solution? Get rid of virtual warehouses

Frequently asked virtual warehouse questions

Further Reading

See how Dynamics 365 handles inventory management

Product Attributes a Mess in Your Old ERP?

Product attributes: the lifeblood of your brand

What are product attributes?

What’s the best way to manage product attributes?

Step one: define your hard attributes

Step two: define soft attributes

Examples of hard attributes

Examples of soft attributes

The biggest mistake companies make in their product master data

Product hierarchies: an opportunity to clean house

ERP deployment considerations for product master data and attributes

Further Reading

See how Dynamics 365 handles multidimensional inventory

PLM Vs ERP

The Need for Both Systems

What should
your product numbers mean?