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.
