Select Page
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 Multi-Site Migration:  A Moving Guide

Epicor Multi-Site Migration: A Moving Guide

Out of Epicor Multi-Site, Out of Mind

 

An Epicor multi-site implementation, whether moving from a single site to multiple sites, or vice versa, is a common phenomenon in the manufacturing and distribution world.  Companies and sites in Epicor are rarely in a “set it and forget it” proposition.  As companies evolve, the need to further break out or combine business units can become necessary.  As your business grows, you might wonder if your satellite facility should be considered part of your main site or if it should be a site of its own.  Or, in a similar Epicor multi-site configuration puzzle, you might wonder how to map out the consolidation of a two-company environment into a single-company installation.

 

Assume, for example, that a company has four sites (A, B, C, D) split across two companies (1 and 2) in the following manner:

  • Company 1:  Sites A, B, C
  • Company 2:  Site D

And the company desires to combine operations under a single operating unit, such that the lone site under company 2 would be absorbed under the operations of company 1:

  • Company 1:  Site A, B, C, D

Such a change may seem like simply a matter of converting existing data—of pointing all records from the old company and site to the new company and sites.  Alas, systems are often less than accommodating in allowing for historical transactions to be modified in this manner.

 

Epicor Multi-Site Implementation Recommended

 

Epicor offers no toolsets to “move” a site across companies.  No toolset currently exists that provides the ability to change the company context of all records in a single instance, as to point them to another company context.  Historical transactions don’t like having their keys modified, and such revisionist history is fraught with potential challenges, and thus not recommended.

 

The recommended best practice in such an Epicor multi-site implementation scenario is to reimplement site 2-D in Company 1.  This would involve the setup and configuration of the site and the transfer of setup, master file, and open transaction data into the new site, and the continuance of business operations from within this new site.  This would not include the loading of historical transactions—it would essentially be an act of starting fresh in the new company, as if the site were converted from a legacy system and not from Epicor.

 

To achieve Epicor site consolidation, as described above, a four-stage process can create the desired infrastructure:

  • Plan:  The planning stage finalizes scope and organization through assessment, planning, resource organization, scheduling, etc.  The resolution of conflicts in data, customization, or configuration will occur as part of the testing phase.  Scripts will be developed for the movement of data and customizations.
  • Architect:  The architect stage involves the setup and testing of an environment that would represent the future state deployment, and the elicitation and resolution of any gaps, issues, or conflicts that would come from the planned deployment.  Key activities are the development of the test environment, testing of new site deployment, and gap/issue resolution.
  • Validate:  The validate stage is used to verify that we can successfully execute a cutover and run the business as intended, as if we were in a live environment.
  • Stabilize:  This is the final, successful deployment of a new site at cutover.

 

To address the scenario described above, the following environment map would be recommended:

  • Test Environment:  The initial environment used to model the construction of the new site.
  • Pilot Environment:  The environment in which conference room pilot (CRP) validation occurs.
  • Live Environment:  The existing Live environment, which will be updated at the cutover of the new site.

 

In a traditional Epicor implementation, we go through a five-stage process:  Plan, Educate, Architect, Validate, Stabilize.  This conventional waterfall approach to implementing an ERP application does not adequately address a scenario where training is not required, and prototyping is centered less on the use of the system than it is on properly implementing and integrating an existing Epicor process into a different Epicor company.  As such, the methodology is somewhat simplified, considering the team is already well-versed in the application.

 

The environmental build, relative to the four-stage model described above, would be as follows:

 

Architect:

Initial Live Environment Setup:

  • Extract Setup information from 2-D.
  • Create New Site D in company 1.
  • Update Site configuration in 1-D.
  • Update Company configuration in company 1, as needed.

Test Environment Setup:

  • Build Test environment from copy of production.
  • Extract master file records from Company 2 (Live) and load into Company 1 (Test) and reconcile Conflicts as needed.
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Test) and reconcile conflicts as needed.
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Pilot).
  • Perform user testing to verify functionality in Site 1-D and the effect of adding 1-D on sites 1-A, 1-B, and 1-C.

Verify:

Pilot Environment:

  • Build Pilot environment from copy of production.
  • Extract master file records from Company 2 (Live) and load into Company 1 (Pilot).
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Pilot).
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Pilot).
  • Perform conference room pilot (CRP) event to verify functionality in Site 1-D and the effect of adding 1-D on sites 1-A, 1-B, and 1-C.

Stabilize:

Live Environment-Cutover:

  • Extract master file records from Company 2 (Live) and load into Company 1 (Live).
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Live).
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Live).
  • Perform any ancillary cutover activities as required.
  • Resume operation in new environment.

 

Considerations

 

As with any project, there are a number of considerations that should be clarified at the onset of an Epicor multi-site migration.  The following assumptions have been made:

  • There are always minor data transformations needed when loading data into a new Company and Site, such as the new Company and Site IDs.  You should give consideration to any transformations above and beyond these basic adjustments:
    • Are there data transformations that will need to occur beyond the necessary changes to allow the data to function correctly and without conflict in the new company?
    • Are there changes to setup tables that will need to be mapped when loading master files and open transactions?
  • There is a necessity to identify who will be building test case scripts and who will be performing the necessary testing and validation—and this validation is twofold:
    • Validate the functionality of the new site within the existing company.
    • Confirm that the addition of the new site does not introduce any processing issues with any of the existing sites.
  • It is critical to identify a process for resolving conflicts—the addition of a new site may introduce conflicts with the existing Epicor implementation, and a resolution strategy should be devised at the project’s onset.

 

Conflicts and Conflict Resolution

 

Potential conflicts may exist between Company 1 and Company 2, and these may surface as a function of the “move” of Site 2-D into Company 1.  These may include the following:

  • Company configurations in Company 1 may not be in agreement with those of Company 2.
  • Security and menu settings in Company 1 may not be in agreement with those of Company 2.
  • Conflicts between customizations and/or reports may exist between Companies 1 and 2.
  • System Agent configuration conflicts may exist between Companies 1 and 2.
  • Setup Table conflicts may exist between Companies 1 and 2.
  • GL structure conflicts may exist between Companies 1 and 2.
  • Master File conflicts may exist between Companies 1 and 2.

 

Historical Data Access and Epicor Multi-Site Design

 

With any such migration, questions exist as to how historical data will be accessed.  As noted above, our recommended approach does not include the loading of historical transactional data.  In the current situation, the historical data from site D in Company 2 will continue to reside in the database, but the ability to modify the data will be removed at cutover.  Read-only access and report access could still be permitted, to provide access to historical data.  Additionally, the utilization of cross-company BAQs could be applied for reporting from Company 1 and consolidating datasets between the legacy site 2-D and the new site 1-D.

 

As companies expand, it’s common for new physical facilities to be spun up and incorporated into the existing Epicor application in some form or fashion.  In other cases, companies manage parallel business within the same space, and may decide they need to better break these out, as to keep their operating interests independent of one another.  In all possible scenarios, Epicor multi-site implementation can be tricky, demanding a thorough migration plan.

 

 

Looking to tweak your company/site configuration as part of an Epicor upgrade?  Learn more about multi-company and multi-site upgrades here.

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.  

Remote Epicor CRP: A Skeleton Key

Remote Epicor CRP: A Skeleton Key

When Your E10 Conference Room Pilot Feels Like Space Exploration

 

Conducting a successful Epicor CRP remotely is a lot like doing one in person—except that nobody’s in the same room.  Customers suddenly working remotely in the midst of an Epicor implementation may feel like their project happened long, long ago in a galaxy far, far away.  As such, many have asked us for guidance on whether to proceed with their project or to put it on hold until their team returns to on-site infrastructure.  With a little adjustment, companies can proceed with their Epicor implementation and keep their team’s momentum.  As much as I like to get in the customer’s on-site orbit, a few little changes when orchestrating a remote Epicor CRP will go a long way since the fundamental implementation principles do not change.

 

 

 

Here are 5 recommendations for conducting a remote Epicor CRP event:

 

1)  Place extra effort on the preparation stage.

 

A number of planning steps can be performed before the event.  This may include level-setting expectations of the core team and end users.   For many of the attendees, this might be the first time they have gone through a systematic verification event such as a CRP.  Provide them with an understanding of the logic behind such an event and an idea of how the event will be conducted.

 

Consider which roles will be required and who will be performing them: Who will be the facilitator?  Who will be keeping score against the test script to confirm which steps have or have not passed testing?  Who will document discoveries, issues, gaps, decisions, or general notes that extend beyond the test script?  Having these roles defined will help build traction early.

 

Also, make sure that team members and users have access to the necessary documents (test scripts, agenda, end user procedures) prior to the event.  Make sure that technical steps have been validated, and work with the IT department as necessary to ensure web conferencing software is working as expected, and that team members will be able to access the application remotely.  Consider performing a quick dry run with a subset of the team to ensure the event can be conducted as intended.

 

2)  Start with a well-defined set of scenarios and a detailed testing script.

 

A CRP is only as successful as its completeness—in covering the key business scenarios that support the organization.  Companies implementing Epicor vary to the degree in which they document and define their scenarios prior to testing them in a milestone event such as a CRP.  A remote Epicor CRP requires a better-defined test script.  If you plan to bring in new users to try out the processes you’ve defined, you will want the test cases to be well-defined to avoid the ambiguity that can encumber a remote testing session.

 

In on-site situations, the assistance of the core team members, who have been living and breathing these scenarios on a daily basis, can help drive through the confusion that could be caused by a loosely defined testing script.  It becomes difficult in remote situations to provide this kind of guidance, so plan it out ahead of time.

 

3)  Organize your testing with a detailed agenda.

 

Once the scripts have been solidified, organize their execution within your remote Epicor CRP with a detailed day-by-day agenda.  This helps clarify expectations and becomes a tangible roadmap that everyone can follow for the week’s event.  For each day, identify scripts to be covered, the timeframe for which to cover them, and the necessary attendees.  This is especially important with end users that you will be bringing into the event, as their attendance will likely be for smaller and more-specific blocks of time.  Given that an individual’s availability may be compromised during this event, work with the project manager, the consultants, and the core team to logically arrange activities as to allow for a logical flow of events and an efficient use of team member and user resources.

 

4)  Make sure Epicor EUPs are well-defined and complete.

 

End User Procedures are often overlooked when entering a CRP, and we’ve seen companies conduct successful on-site Epicor Conference Room Pilot events where they successfully verify their processes in the absence of detailed click-by-click steps.  Consultant knowledge and team member capabilities often come into play here in guiding end users through processes.  Companies facing a remote CRP do not possess this luxury.  As such, Epicor EUPs need to be buttoned down in order to conduct a successful CRP.  It’s always good to introduce general users to a CRP event.  In a remote CRP, you will know with certainty whether you’ve given your user community sufficient instructions to do their jobs.

 

5)  Place extra emphasis on communication when conducting your event.

 

Due to the cross-functional nature of ERP systems, and the importance of confirming that a configured system operates properly across functional areas, communication is a pillar of any such event.  This is magnified when performing a remote Epicor CRP.  Open, transparent communication is essential.  Remember that in a remote Conference Room Pilot, it is hard to read non-verbal cues, and the team needs to be cognizant of such communication challenges.  Often it can be beneficial at the onset of the event to come to an agreement with the team on the ground rules to be followed, specifically when it comes to agreed-upon guidelines for things like clarifying a scenario before moving to the next, or deciding when to call “time-out” when a discussion is going down a bad path.

 

Engagement can also be an issue, so make sure your team stays engaged.  If you’ve been invited to a session, the assumption is that you will stay engaged in it.  Look to try out different techniques to retain engagement, such as taking frequent breaks, encouraging individual feedback, or leveraging the chat functionality or the digital whiteboard of your web conferencing software to keep people focused.  Also, if you are the facilitator, the project manager, or the consultant in a remote CRP, it is important to know your audience.  An understanding of team members’ general proclivities when it comes to working in situations with a greater degree of ambiguity can go a long way to heading off conflicts and frustration or preventing rabbit-hole adventures.

 

 

Epicor ERP implementations are more of a walk on the moon than a walk in the park.

 

These challenges may seem insurmountable in light of circumstances that mandate remote activity.  But it has been our experience thus far that a great deal of progress can continue, in spite of a decentralized team.  As it relates to successfully preparing for and conducting a remote Epicor Conference Room Pilot, we have found the same to be the case—with a little extra work in the areas of planning and preparation, and some adjusted expectations on how team members will interact with each other, an event as complex and rigorous as a remote Epicor CRP can be successfully conducted.

 

A successful remote E10 CRP relies on many of the same principles that underlie an on-site event, but these steps need to be conducted with even more diligence to ensure the success of remote implementation.  In on-site Conference Room Pilot events, it is far too easy for the consultant or the core team to “muscle” their way through the event.  Remote CRP events do not have this luxury, as the influence of any one individual is minimized due to the remote nature of the event.  Use this as a blessing: tighten up the organization and use your remote Epicor Conference Room Pilot as a launch pad to boldly go where no project has gone before.

 

 

 

Are you working through an Epicor ERP implementation?  Do you need some guidance on the setup of the part master?  Successful part master setup is critical for project success.  Download our white paper for some recommendations.

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.

COVID-19 Remote Consulting Strategies in Epicor ERP

COVID-19 Remote Consulting Strategies in Epicor ERP

Why Remote ERP Implementation is Essential

 

Remote ERP consulting in Epicor has become a necessary service for manufacturing and distribution industries during the COVID-19 pandemic.  Coronavirus quarantines and stay-at-home decrees have disbanded ERP project teams.  Separated from traditional onsite ERP consulting paradigms, office culture has shifted into remote consulting platforms in order to support the manufacturers and distributors critical to our nation.  With travel advisories in place, remote consulting has quickly become the new normal, and ERP consultants are empowering teams to meet the challenges of implementing ERP using remote technology and methodology.  Fortunately, remote ERP consulting strategies can be quickly and securely deployed to keep your Epicor ERP implementation projects successful throughout the COVID-19 crisis.

 

 

How to Effectively Enable Remote Work

 

Working with our customers over the past few weeks, we’ve used our team’s experience to come up with a few recommendations for remote ERP consulting and ERP project management:

 

  • Leverage Technology: Software providers have spent decades developing products that enable remote activities.  Go beyond basic connectivity and familiarize yourself with the ins and outs of your web conferencing tool of choice, such as Zoom, WebEx, or GoToMeeting.  Record sessions and look for ways to make file sharing and communication easier: SharePoint, Teams, OneNote, etc.  And if a remote engagement is on the horizon, work with your IT staff ahead of time to make sure everyone has requisite access.
  • Bring in remote expertise: As consultants, who by necessity have to connect to one of many types of projectors, screens, and presentation architectures, we naturally become quite adept at this process, bringing with us a toolbox of adaptors to connect to this or that technology.  In the remote world, we similarly need to master the skills of remote connectivity: VPN, Citrix, RDP, etc.  These communication modes work to bring clients and consultants effectively together, keeping an ERP implementation on schedule.
  • Modularize assistance: As COVID-19 disrupts traditional business culture across the manufacturing and distribution industries, moving key workers into home offices, Epicor ERP implementation projects demand adaptable technology and adaptable teamwork.  Remote consulting strategies that help to create ultimate flexibility for IT projects can bring success to your ERP implementations, even from your living room, by breaking up consulting into segments specific to particular individual needs.  Clients can optimize the increased flexibility of a consultant’s remote work schedule by using technology to enhance communication and productivity.
  • Master the help-homework-help cycle: Related to the above steps, look to leverage the modular approach by scheduling incremental sessions.  In this more intensive cycle, a consultant can provide instruction on a given topic with a customer, then allow a period of time between sessions for the customer team member to perform independent work before picking up with the next session.  The key here is getting to a good point at the end of a session such that homework can be assigned, with the customer not only responsible for the next steps, but also well-equipped with the knowledge necessary to be successful.
  • Keep your team connected: Communication becomes paramount during times of remote activity.  In these circumstances, consultants need to increasingly serve as the glue between team members.  Questions that don’t get asked are rarely answered, so this is a good time to get people asking questions.  In the absence of traditional project structures, individual team members might need more direction from their Epicor ERP consultants.  Customers working remotely are not only in need of consulting assistance but are also in need of increased project management.

 

When the Home Office Becomes Your Conference Room

 

Epicor ERP consultants are remotely managing teams to keep manufacturing and distribution projects successful throughout the COVID-19 outbreak.  With travel down and customers closing their doors to consultants who have been implementing ERP onsite, project teams might find themselves in an unfamiliar work architecture.  The shift to remote work environments brings challenges to ERP implementation teams and their consultants.  The coronavirus outlook for the upcoming weeks and months means the dependency on remote communication is only set to increase, making remote ERP consulting a necessity.  This will change the way that Epicor ERP consultants ply their trade for a while, but it won’t limit the success of ERP implementations.

 

Remote consulting strategies abound to assist customers in their remote business environments, and consultants more than ever need to be facilitators first and consultants second as we help manufacturing and distribution companies through the coronavirus disruption.  It’s a time for Epicor ERP project teams to be assertive, with consultants and team leaders providing direction, organization, communication and encouragement, not only though our application expertise, but also through the soft skills that we bring as part of our value proposition, keeping to our mission of Epicor ERP implementation success.

 

Looking for ways to enable remote work for your team?  Contact EstesGroup to learn more about our Managed IT, Epicor ERP, Prophet 21 and CyberSecurity services.  Stay well, be safe, and talk to us about the future of your business.

 

 

 

Looking for more information on Project Management to help keep your Epicor ERP Implementation moving forward? Check out our blog on: The Unique Family Dynamics of a Successful ERP Implementation.