Select Page
Part Master Best Practices? Ask Brad

Part Master Best Practices? Ask Brad

Part Master Questions

 

Q: What are some of the first things that someone should consider when setting up parts in Epicor?

 

A: We could have a long, harrowing conversation about part naming conventions, but arguments over part naming philosophies have ruined more friendships than heated discussions over the latest Star Wars movies—so I’m going to leave that one alone. In terms of Epicor part master setup, probably the first and most important consideration is the Non-Stock checkbox. The Non-Stock Flag is one of those “big-little” checkboxes that drive a ton of downstream behavior. This one flag will affect how a part will be handled on a sales order, a purchase order, and a job, whether as the top-level assembly or as a component material, and basically determines whether the related transaction will be processed through the system’s inventory module or processed directly in a “to-order” manner. This flag is fundamental for companies looking to operate in mixed-mode manufacturing. Most companies, even companies working in highly-engineered environments, rarely intend to manufacture all components “to-order.” Often there are economies of scale to consider, and components can be used on a broad array of higher-level assemblies. As such, some parts will be handled in a “to-order” manner, while others will follow a traditional inventory-based approach. For that reason, we have to place special consideration on the setting of the Non-Stock flag.

 

 

Q: Phantom BOMs are a topic of disagreement—do you have any recommendations on the use of Phantoms?

 

A: In general, a phantom is a part that carries a method of manufacture, but is not itself manufactured discretely. Rather, the part “explodes” when it belongs in a work order—the top level part disappears and is replaced by its components. Phantoms really are system-specific, for the rules for handling phantoms differ by ERP system. Within Epicor, a few general rules could be suggested when deciding if a part will be flagged Phantom BOM. Firstly, if a part is stocked, it should not and cannot be flagged Phantom BOM, as it is assumed that a phantom part not be stocked. Also, if a part is made independently from its parent, in a different place and at a different time, it should not be flagged Phantom BOM—it should be either a material or a subassembly, so its manufacture can be managed independently from its parent. When component parts are made at the same time and place as their parents, I’ve seen customers use phantoms to manage the components, to simplify production, while retaining the basic product structure defined by engineering.

 

 

Q: More specific to Epicor, the Pull-as-Assembly flag is a source of confusion and disagreement—do you have any recommendations on the use of the Pull-as-Assembly flag?

 

A: A Method-of-Manufacturing defined for a Part Revision can differ significantly when you pull the revision into a Job and get details. These differences are largely due to the Pull-as-Assembly flag. This flag essentially defines whether a component part will be manufactured independently from its parent part, or as part of the same Job as its parent, as a subassembly. One can suggest a few principles when choosing to flag a part as Pull-as-Assembly. If the part is stocked, do not flag the part Pull-as-Assembly, as you will be supplying the material from your on-hand inventory. If the component part in question is Non-Stock, and the intent is to supply the materials through a separate Job, uncheck the Pull-As-Assembly flag. But if you wish to supply the Non-Stock part with a subassembly, allow the Pull-as-Assembly flag to remain checked.

 

 

Q: Can you explain how the settings on the part master flow through to a bill of materials and ultimately to a work order?

 

A: It’s easier to explain this with a visual…

 

Part Master Flow
Epicor Engineer-to-Order at Your Service

Epicor Engineer-to-Order at Your Service

The Role of Order Entry in ETO and CTO Environments

 

Epicor Engineer-to-Order environments are their own special breed. Based on an almost infinite notion of product variability, their business models are hard to shoehorn into an ERP system. I once had a job shop employee describe his product variability with ultimate pliancy: “If they want us to wrap it in toilet paper, we’ll wrap it in toilet paper.” That would be a costly proposition these days. In light of this, I often get requests from my customers for “best practices” in handling various Epicor ETO environments.

 

Epicor Engineer-To-Order

 

The If-Then-This-That of E10

 

When it comes to questions regarding Epicor Engineer-to-Order, I always preface my answers with a de facto “it depends” before diving deeper into all the variables at play. Best practice for one company might not be the same for another. Ironically enough, it is almost as if I need to configure an answer for my customer, and discussions tend to take on the following format: “If this and that and/or this or that, then do this…”

 

One such question came to me recently from an Epicor customer, with regard to the role of Order Entry/Customer Service employees in an Engineer-to-Order organization. The company was debating the benefits and liabilities of having their inside sales staff perform rudimentary engineering activities as part of the entry of a sales order. In such companies, product details tend to arrive comparatively late in the quote-to-cash cycle, and the folks responsible for pounding in the orders often find themselves as the purveyors of this information, as received from the customer. These changes often require tweaks to manufacturing methods for a given product, and companies struggle in determining who should own these changes.

 

 

The In-the-Know of ETO

 

Who do you know on your team who could best own these changes? As I’ve noted above, “It depends.” But what does it depend on? I can think of a few of the variables that you would consider when deciding whether Order Entry should handle Engineering tasks:

  • Technical efficacy and product knowledge of the Order Entry team: The higher the efficacy, the more liberties you can give someone to alter MOMs when quoting. In some environments, where the estimators are highly technical, Engineering is strictly focused on new product development, and Sales owns what is sometimes called “project engineering.” In other environments, this role is staffed by folks in the engineering department.
  • Complexity of the product: The higher the complexity, the less you’d want Order Entry muddling with the engineering of the product. In low-complexity job shops, I’ve seen order entry or customer service staff handle the engineering implications of order changes.
  • The implementation of Epicor: There are a number of ways in Epicor to get from a Quote to a Job, and few companies in the CTO/ETO world do it exactly the same. Depending on the overall architecture, the MOMs in question might be modified through the quote module, the part master, or in the jobs themselves. This architecture will affect the processes needed to make changes: do you need to modify MOMs through the quote, or will you perform modifications to the Part Revision through the engineering workbench? Quote MOMs are much more apt to be modified by sales staff than are part master records.

In general, I have found that in most environments, Order Entry is focused on specifying product characteristics, features and options and that Engineering is responsible for defining the engineered product to satisfy these requirements. I often recommend that Engineering be the party responsible for what we normally understand to be the engineering function.

 

This model works well as companies sufficiently standardize their product offerings to support Epicor Configure-to-Order business models, as the delineation between features and options vs. product design are more pronounced in these environments. But there are certainly cases in which the composition of the entire sales staff, the nature of the product, and the system architecture determines that Sales is the optimal department to make these changes.

 

 

Are you a company in an Epicor Engineer-to-Order or Configure-to-Order environment? For help with your Epicor implementation or upgrade, please join us on June 17th for our virtual EstesGroup Epicor User Summit.

 

EstesGroup Epicor Summit: Click here to register via our website

June 17th, 2020, 10 am to 3 pm (Central Time)

  • 10:00-11:00 – Epicor Security: Make It or Break It (Daryl Sirota)
  • 11:00-12:00 – Leveraging Epicor Data Through Business Intelligence (Mark Herman)
  • 12:00-1:00 – Manufactured Parts Setup: Best Practices (Brad Feakes)
  • 1:00-2:00 – Embedded Customization: Custom Pop-ups and Other Tricks (Joe Trent)
  • 2:00-3:00 – Ask a Consultant: Professional Services Round Table

 

 

An End User’s ERP History – from Baan IV to E10

An End User’s ERP History – from Baan IV to E10

ERP

Back when I still worked for a manufacturing company, in a magnificent sprawl of factory and office buildings, I had a reputation for being a fast walker.  I’d bustle through the labyrinthine hallways of the office and scale the grand aisles of the factory.  With my head down in a shoegazer’s stride, I’d often come into near collisions with whiteboards or drill presses.  At the time, I was shaped roughly like a college linebacker, and my coworkers would clear the path when they saw me coming.  “Slow mind, fast feet,” one of my supervisors once remarked.  When people asked why I walked so fast, I replied, “It’s hard to hit a moving target.”  In a company that had a reputation for random layoffs, this was a sufficient answer — an insider’s aphorism.

 

ERP systems are rarely a moving target.  A stationary target is usually either a soon-to-be-victim or a roadside misfortune.  When I first entered the business world, my company was replacing its mishmash of homegrown systems with Baan’s flagship ERP solution, Baan IV, well before the panic of Y2K.  New to the company, and still learning what I could do to get by, it was no big deal to me.  But to my wiser, more experienced coworkers, it was an all-out affront to their sensibilities.  These were folks accustomed to the keyword-laden world of green screens and shortcuts, for whom the art of the double-click was still a work in process.  So, the transition took a while, in spite of the new software being pretty solid.

old computer

Baan, as the company proper, went into a tailspin shortly thereafter, and its software was absorbed into countless versions of other applications.  I once sat down with a veteran consultant who had been with SSA Global and then with Infor during these transitions.  He gave me the entire evolutionary history of the Baan product over a burger and fries.  It was quite a mouthful coming from one of the application’s dedicants.

 

When it came time to replace our own ERP system, the manufacturing company I was with opted to move to Epicor’s Vantage ERP system.  Compared to Baan’s Unix-based architecture, Vantage’s look and feel seemed pretty modern and user-friendly, especially in the mid-to-late 2000s.  Now, Epicor’s manufacturing ERP product had its own special evolutionary history, and we happened to hitch a ride to its moving train while it was plowing forward at full speed, but still halfway from its destination.  Vantage had originally been architected using the Progress 4GL business language, both at an application and database level.  But as Microsoft became the dominant application platform, the company opted to begin a migration process to a fully Microsoft-centric stack.  And a long strange trip it’s been.

From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability. 

Brad Feakes

SVP, ERP & Professional Services, EstesGroup

 

Epicor’s Vantage 8.0 version was the first step in this evolution.  Being a client-server application, they replaced the Progress client with a Windows-based client, while retaining the Progress business logic layer on the server.  Better still, they now provided the option for a SQL Server database.  The initial results were… bumpy.  One can imagine why combining so many architectural layers would certainly be a veritable middleware nightmare.  Earnest effort went into remedying these issues, and the result was Vantage 8.03, a more stable version of 8.0.

 

A major functionality uplift had been teased for a number of years, under the guise of “Version 9.”  While still possessing the same basic backend architecture, the features and capabilities of the new version were to be a real advance from the current release.  The first installment of this promise was Epicor version 9.04, and the results were less than optimal.  Sure, the functionality was there, but the performance was abysmal.  At my own company, we never got so far as to implement 9.04, given that 9.05 was released on its tail in short order and addressed some of the issues that plagued its antecedent.  But at some point, it became known that 905 itself was going to be the last major release on the current architecture, that the next major release would be devoid of the Progress-based 4GL backend, and that in its place would reside an entirely Microsoft-centric server-side stack.

product management erp module

This finally came to fruition with Epicor’s version 10.  And the challenges experienced by the user community were similar to the previous versions.  In moving to E10, Epicor essentially rewrote much of the application’s backend, turning those in the end-user community on the bleeding edge essentially into beta testers.  The challenges of working through the kinks involved were significant.  Now a consultant and no longer a customer, I experienced the application from a new perspective as I tried to confirm just which of the legacy version’s features could and could not be supported by the new version.  Working in some of the more complex areas of the application, such as product configuration and MRP, I’ve encountered many show-stopping issues that put customer implementations in holding patterns.  As with 904, a relatively small subset of Epicor customers went live on 10.0, many opting to wait until 10.1’s more stable version was released.  Since 10.1, the version has been remarkably stable, with each new version offering more and more capabilities without undermining previous functionality.

 

My ERP journey over the past 20 years has been a long, strange trip indeed.  From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability.  Looking back, I’ve wondered if I’ve learned anything from my IT travels.  Though I won’t scribe any hard-and-fast rules into marble, there are a few things that are worth mentioning:

  • Software goes through cycles.  The stability, capabilities, and performance of an application all vary over time.  Understand this and plan accordingly.
  • A company’s success with an ERP implementation varies according the point in the cycle where they enter the fray.  Entering on a stable version might not give you all the bells and whistles you desire but will likely make for a more successful implementation.
  • Stability applies to an ERP vendor as much as it does to their software.  When you engage an ERP vendor, it’s good to understand the company’s stability.
  • An unstable vendor may quickly devolve into an unstable platform or, worse, into an unsupported platform.
  • When upgrading an application to a more recent version, be leery of the “bleeding edge” syndrome.  All other things being equal, it’s good to let the major version of an application settle down before taking it on.  Premature adoption can lead to catastrophic implementation.

Interested in having us help your business?

Epicor ERP Upgrade Considerations for Data Dailies

Epicor ERP Upgrade Considerations for Data Dailies

The further away you get from the “new release” of a software, the more challenging an upgrade becomes, and this is especially true for Epicor ERP upgrade customers.  If you’re coming from a Progress 4GL business logic-based version, which would include anything earlier than version 10, such as Epicor’s 905 and 803 platforms, you might feel a little lost in all your options.  The need to move beyond Epicor’s legacy platform is obvious—the analog film of the old version is deteriorating on the reels.  But the move to Epicor’s E10 platform is more of an epic picture than it is an opening trailer.  Thus, it is important to storyboard the flow of the narrative from the old to the new, before the cameras roll, knowing that your plot armor will only take you through the first act of your Epicor ERP upgrade.

 

Two Epicor ERP Upgrade Paths

 

The hero’s journey in any good film starts with a call to action, with a road diverged in a wood where the protagonist must choose one of two paths.  In general, you can consider any move from a legacy version of a software to an updated version to be an upgrade.  But there are two distinct paths for moving from your legacy version to E10, and these greatly affect the nature of the final implementation.

 

Path 1.  A straight, utility-driven upgrade from the legacy to the current version:  In a straight upgrade, a utility converts the data from the legacy version, generating an E10 database that adheres to the structure of version 10 schema.

 

Path 2.  A reimplementation:  This is an alternative method for moving to E10 from the legacy version, but this method does not actually upgrade the legacy data to make the E10 database.  Rather, the upgrading company reimplements the application in E10, normally using the legacy data—filtered, scrubbed and reworked—as the starting point.

 

Data as the Villain… or the Hero?

 

Regardless of your opening scene, one of the most important considerations in any Epicor ERP upgrade is what to do with your data.  Companies can have one of many data challenges as they anticipate an Epicor upgrade.  It is not uncommon for a company’s current Epicor implementation, along with all its legacy data, to be handed down from a previous administration.  A lot of staff changes over ten years, for example, can leave a company with a system that has a setup and configuration at odds with their current orientation.  In such cases, a given company may wish to have another shot at configuring the application—to undo some of the decisions of the past.

 

Some companies unfortunately inherit a legacy system with data that has been carelessly maintained and is thus dirty beyond recognition.  In these cases, customers may look to either clean up the data or cut it entirely.  In other cases, significant changes to the business may have led to an inordinate number of part, customer, or supplier records that are obsolete.  While these might have historical value, they may also unduly clutter the database and place the company in a no-win situation.  In extreme cases, the company may even have a company and site structure that has evolved to be radically different from what is depicted in the Epicor application.

 

The data of an ERP system can be broken up into a number of classes:

  • Setup data:  This refers to the foundational data that underlies the setup of subsequent master file records.  Examples of setup data might include part classes, product groups, buyers, sales persons, etc.
  • Master file data:  This normally refers to the three core master files in any ERP system—the part master, the supplier master, and the customer master.  Subsequent master files may also need to be set up that relate to the extension or relation of these master file records, such as supplier or customer part price lists.
  • Live transactional data:  This refers to the open transactions in your system, such as purchase orders, sales orders, jobs, and invoices.  The decision as to whether to reimplement or upgrade greatly affects how these are to be handled, given that in an Epicor ERP upgrade they come along as part of the ride, whereas in a reimplementation they would need to be loaded in the style of a new install.
  • Historical data:  Historical data refers to all of the transactions that have been processed in the past and are no longer active, and would include purchase orders, sales orders, jobs, and invoices that have long since been closed.

From Classic to New Release

 

In a straight Epicor upgrade, the data from the legacy version is updated and fine-tuned to fit into the version 10 schema.  In such a situation, limited changes can be made to setup and master file data—you get what you had in the legacy version, only now it’s in version 10.  Tweaks can be made—new setup files can be defined and new parts, customers, and suppliers can be defined that replace or supplement their legacy analogues.  But any data that has been transacted against remains in the database.  It can be inactivated, but it’s still there, and some customers have a problem with this much clutter.  Depending on the degree of the issues noted above, this may or may not be a big deal.  Also, one of the upsides of a straight ERP upgrade is the ability to retain historical data with minimal effort.

 

Given the potential issues with data that a company may face, reimplementation offers the ability to cleanly address these challenges.  It is common for businesses to transform significantly after their original implementations.  They may have a number of legacy companies, sites and warehouses that are no longer needed and may even burden the database and create confusion internally.  Customers may also wish to make radical changes to their company or site structures as a function of the upgrade.  In these cases, consideration should be made to performing a reimplementation in lieu of an E10 upgrade.

 

Typecasting your Data Forecasting

 

When you perform a straight Epicor upgrade, you are accepting that you will take all of your past performances with you, and this may create challenges that impede your future state aspirations.  Conversely, dumping your legacy database also involves leaving behind the historical data that amounts to the history of your business.  Epicor’s E10 ERP software is a big step up from its 905 and 803 antecedents, and with each point release, the gap between the new and legacy versions widens further.  Legacy Epicor customers looking to move their businesses forward will need to transition to a modern ERP platform, and Epicor’s E10 application provides a compelling case.  And when making this critical Epicor ERP upgrade rewrite, customers will do well to consider their data dailies.

 

 

 

Looking for a good storyline for your Epicor upgrade?  Learn more about E10 from our Epicor ERP team.  

Epicor Functionality in the Admin Console, Unwrapped

Epicor Functionality in the Admin Console, Unwrapped

New User Access, New E10 Functionality

 

Managing the Epicor functionality available to the user community is one key role of an Epicor Administrator.  In this light, it’s not uncommon for customers using the Epicor application to continue to add new modules.  An understanding of Epicor 10’s functionality develops over time, as administrators and users learn the full capabilities of E10 and how ERP can help run a business.  Once new E10 modules are licensed, and once the license is installed, users will need to have an administrator enable access through the Epicor Admin Console in order to allow users to make use of this new Epicor functionality.

 

Let’s walk through the steps you need to know to effectively manage newly installed Epicor modules.

 

In order to enable a new module, you will first need to be logged into the application server, which is the box where your Epicor application is installed.

 

Once on the application server, open the “Epicor Administration Console”:

 

 

Once the Epicor Admin Console is open, perform the following steps to enable the desired module:

  • Open the “Server Management” node in the left tree view and locate the Epicor instance in which you wish to enable the new module.  In the example below, it is the “Demo” instance.
  • Open up the E10 instance node and click on the “Licensing” node beneath it—this will display the license file in the panel to the right of the tree view.
  • Double-click the license file.  This will raise a little properties window.
  • Navigate to the “Modules” tab.  Sort by module name and locate the module you wish to enable.  Check the “Enabled” box to enable the module in question.
  • Click the “OK” button to commit the change:

Once that is accomplished, a user who has just logged into the Epicor application should see the new module available in the menu:

 

 

If your team is making suboptimal use of your Epicor application, you can easily enable some new functionality through the Epicor Admin Console, and they’ll be licensed to thrive.  There are several ancillary modules that can help extend the benefits of the Epicor application throughout your business.  Epicor has plenty of goodies in the basket.  The Epicor Admin Console is the tool for unwrapping these bonbons, enabling delectable Epicor functionality.  Bonbon appétit!

 

 

Not sure what specific Epicor functionality to enable?  EstesGroup specializes in Epicor ERP, and our consultants can help your users make the most of your Epicor License.

 

 

 

Are you interested in some more Epicor traps and taps?  Download our “12 Days of ECHO” guide for the Epicor Administrator here.

Epicor Optimization Success for Remote Teams

Epicor Optimization Success for Remote Teams

Rock the House by Refining Your Epicor Application

 

After completing an implementation, you can continue fine-tuning your processes to gain maximum return on investment through Epicor optimization.  If your team is working from home during the COVID-19 pandemic, the temptation might be to stall ERP optimization (Phase 2) steps.  Such delay has been the pattern among Epicor customers over the years.  But home can be the ideal environment for managing these Phase 2 actions.  Epicor optimization activities that improve the utility of your Epicor application can be accomplished via remote work.

 

ERP Optimization

 

 

Improve While in the Home Office Groove

 

By necessity, companies implement ERP with an initial push for the system’s essentials, as to go live in a timely manner with the intention of circling back and further elaborating on the ERP application as time allows.  When implementing Epicor as a customer, I once had a teammate bemoan this delay in the implementation of a certain element of functionality: “If we push it to Phase 2, it’ll never happen!”  The functionality was, to his dismay, postponed until after cutover.

 

His concern was not unfounded: Epicor ERP implementation Phase 2 activities frequently get set aside in lieu of the daily grind.

 

You might similarly worry that if you push tasks to Phase 2, they’ll never happen.  This is a good reason to be proactive in your Epicor optimization.  The remote organizational structures necessary to stop the spread of COVID-19 give you time to focus on process improvement, leading you toward improved on-site ERP functionality in the future.  Remote Epicor ERP optimization allows for time to be spent knocking off Phase 2 projects that will help you make better use of your application.

 

Let’s look at some of the optimization steps that your ERP team can do from home:

  • Data Cleansing: It’s not uncommon for a company to look back at its data and note the places where data discipline has been found wanting or where additional data could be updated to improve downstream processes.  Use remote ERP team time to query the data out of your system, massage it in Excel, and run updates through Epicor’s Data Management Tool (DMT).  DMT is a great tool when it comes to data cleansing—use it to your advantage.
  • Improving visibility across the enterprise: This is a great time to improve visibility to processes and data throughout the organization.  This is necessary in any organization, but even more so when the workforce is distributed.  Dashboards provide the simple kind of visibility that streamlines business processes and improves communication across your company.  But dashboards take a certain amount of quiet time to work through the underlying queries and predict how users might look to access the data.  Remote work gives your team those quiet hours.  Similarly, a well-done SSRS report can save time and effort, and remote work assignments to create these reports can help bridge communication gaps.
  • Enhancing existing modules: It’s not uncommon for customers to buy more functionality than they actually use at cutover.  Each functional area within an organization likely has some application capabilities that have gone underutilized, and Epicor optimization often begins with revisiting usage. You can also introduce or refine existing supplier and customer price lists, or even dust off the Buyer’s Workbench or the Fulfillment Workbench and put them to use in relating supply and demand.
  • Implementing new modules: Beyond utilizing existing licenses, some customers may take this time to implement new modules entirely.  Case Entry and Field Service are customer-facing modules that often get pushed to Phase 2 and are comparatively easy to do when implemented on top of an existing system configuration.  Project Entry is another module that can provide benefits when implemented on top of a live system.  Similarly, a customer looking to implement product configurator, to further enhance order entry and engineering processes, recently reached out to me, and remote consulting was a good way to address this Epicor optimization step.
  • Bullet-Proofing: Once a company is live, a number of places where processes can be tightened up always surface, such as missing steps or missing data that can create downstream troubles.  Optimization of your Epicor application can be remotely organized to help with tightening up or bullet-proofing existing processes.  Extended properties are a simple way to make fields mandatory or read-only, which may be of use in a given situation.  Similarly, a few well-placed BPMs can assist in providing extra validation or automation as needed. Cumulatively, these simple fixes go a long way in standardizing a given process.

Do More Than Float While Working Remote

 

Even if you’ve always used on-site consulting for your ERP implementation, you can, with a simple click into a web conferencing tool, have an expert consultant helping you with your Epicor optimization.  Sure, face-to-face meetings can be the ideal way for you to manage your team, and we’re all excited to eventually get our projects back in the office, but many Epicor ERP optimization project activities can be completed through remote consulting.

 

Looking for ways to use remote work time to improve your existing Epicor ERP implementation?  In addition to Managed IT, Epicor ERP, Prophet 21 and CyberSecurity services, EstesGroup also specializes in providing remote consulting assistance.  We’ve been working remotely with customers for years, providing the necessary assistance to knock off optimization tasks that help companies make better use of their Epicor application.

 

 

 

Learn a few more ways to use remote consulting to boost your team’s performance by checking out our blog on COVID-19 Remote Consulting Strategies in Epicor ERP.