Select Page
3 Things to Consider When Upgrading From Epicor 905 to E10

3 Things to Consider When Upgrading From Epicor 905 to E10

People, Infrastructure, and Scope in an Epicor 905 Migration

A customer on the front end of an upgrade from Epicor 905 to E10 asked me for advice on ERP upgrade planning. I’ve long reflected on some of the keys to a successful Epicor 905 upgrade to E10—the lessons learned by decades of experience, and collected across countless end-of-project reviews. In light of wins and losses of the past, I’ve put together some thoughts on successfully upgrading an ERP system.

Working with consultants often helps in transitioning from a legacy ERP and gaining traction with the new version. This is especially the case if your business intends to leverage the upgrade as an opportunity to perform process changes, implement additional modules, or take advantage of new functionality. All of these things involve risk, largely due to the complexity of data amassed in the process. But if you consider your people, your infrastructure, and your scope, then an upgrade will be the best decision you can make for your future.

Cloud Consulting

Your People & Your Partners

Upgrading your ERP system is all about the people.

  • The people your upgrade will support
  • The people who will help make your application meet your goals

The Philosophy Behind Your People

Methodology: You want to work with folks who have a process for taking your company through the steps, so ’tis not a hodgepodge of random activity.

 

Expertise: I’d recommend you work with a consultancy rather than an independent “jack of all trades” — generalists are good for what they do, but I find the overall solution is superior when delivered by a coordinated team of folks. Look for specialization: Operations, Finance, Tools, Installation, etc.

 

Knowledge: This is where you want some good generalist know-how accessible to you when needed. For example, if you’re upgrading Epicor from 905 to E10, you’ll want someone around who has knowledge about 905 and expertise about upgrading to E10. This is especially helpful for tools considerations and code conversion, but not really important otherwise. The data from 905 to 10 is generally the same, and the functionality is also quite similar. If you have ABL code that you need to convert, you’ll want to partner with a team that has these skills.

 

Experience: This is key. In an Epicor upgrade, for example, you need folks who are strong in E10 and can recommend how the system will best run in 10, so that your transition is smooth and effective.

The Technical Nature of an ERP Upgrade

These considerations apply to any ERP, but I’m going to walk you through this with my Epicor consulting experience coloring the waters. In general, the move from Epicor 905 to 10 is technical in nature, with the change of the database and business logic layers from Progress to .net & SQL Server. Here’s a quick summary of some of the major changes and their implications:

 

Core Modules: These are very similar from 905 to 10 with some new sub-modules and lots of new bells and whistles. You’ll find many opportunities for changes in configuration, and some of these can create unexpected behaviors, so test carefully.

 

Updatable BAQs & Dashboards: These generally come over uneventfully, with a few tweaks. If they contain ABL code, some rewrites are required.

 

Embedded Customizations: These also generally come over uneventfully, with a few tweaks.

 

BPMs: Anything with Progress 4GL ABL code will need to be rewritten.

 

Configurators: Similar to BPMs, anything with Progress 4GL ABL code will need to be rewritten.

 

SSRS / Crystal Reports: 905 primarily uses Crystal Reports. In 10, these have all been converted to SSRS. If you have a lot of custom Crystal Reports, you’ll want to consider whether to rebuild these in 10 or deploy Crystal in the E10 environment.

At all levels, you have to assess the ERP system and the technology that supports it. When you’re upgrading a legacy ERP, should you also upgrade your servers? Will your system require new data management solutions like cloud-based disaster and recovery services? Are you facing new cybersecurity and compliance decisions?

 

Technical Considerations

Upgrading an ERP system demands skillful handling of data. This includes both the mind and soul of the ERP: the strength and spirit of the application. With on-premise, hosted, and SaaS solutions now available as ERP infrastructure options, your upgrade should include technology assessments both in and out of the software.

Upgrade vs. Reimplementation

Think about whether you want your ERP upgrade to be a straight, utility-driven upgrade from the legacy to the current version or a reimplementation. We’ve worked with customers who have gone either way.  We’ve found that reimplementation efforts tend to take longer and cost more, but leave you with a much cleaner data foundation.

A Data-Driven Epicor 905 Upgrade

If you’re trying to pull off some configuration/business process changes as part of the upgrade, this is easier to do as part of a reimplementation. If running Epicor and you’re looking to do the straight, utility-driven upgrade, I would recommend partnering with Epicor specifically to do the database conversion/upgrade. They have proprietary tool (“Cirrus”) that performs this upgrade, and it’s really the best way to do this. In the past, with early versions of 10, the upgrade toolset was part of the Admin Console, and partners like us performed the upgrade. Prior to the upgrade, we also had to request data scrubbing programs to run in 905 prior to the actual upgrade. These helped prepare the data for the 905 > 10 conversion.

Over the course of the last few years, Epicor developed the Cirrus toolset that performs the database uplift. This incorporates all that scrubbing and referential integrity stuff to successfully migrate the DB. These capabilities are not built into the admin console upgrade capabilities, so my understanding is that a better-quality uplift is achieved by working though Cirrus. As a customer, I would be working through Epicor to get the DB upgrading it, and not relying on the admin console. In reviewing the feedback from the Epicor user community, I think that the general consensus would be to leverage Cirrus when possible.

The Project Scope: Budgets & Ongoing Planning

Begin with your history. How to handle your historical data is unique to your project, and you might want to bring in a consultant to help you make decisions around the complexities. There are a number of additional budgetary/planning considerations that should be made at the onset of an upgrade project. Here are several that we normally work though with our customers:

  • Project Management: Do you have an on-site PM who will handle more of the PM duties, or do you want the partner to assume those?
  • Server Install/Configuration/Tuning: Who do you have for technical staff to assist with server-side activities, or do you want the partner to assume those?
  • ABL Code Conversion: Who do you have for development staff that can assist with code conversion, or do you want the partner to assume those?
  • Cirrus Upgrade: Are we working through Epicor to do the Cirrus upgrade? If doing a Cirrus upgrade, you should plan for that cost.
  • Delta Education: Do you want to self-educate or have your partner provide ERP training and support?
  • On-site Consultation: Do you want to have consultants on-site to assist, or do you want to have the partner working remotely and on-site on an as-needed basis?
  • Milestone Prep: Do you have resources that can perform the prep activities, or do you want the partner to assist?
  • Milestone Verification Events: Do you want to conduct CRP and UAT events on your own?
  • Gap Closure: Do you want assistance with gap closure, or do you want to spearhead this?
  • Customization/Tools: Do you have an internal resource to perform any new tools work (customizations, BPMs, reports, etc) that would be part up the upgrade project?
  • Data Conversion/DMT Assistance: Do you have a data-savvy resource who can own DMT & data questions and query the data out of the existing system, manipulate it to load into Epicor, and run the DMT tool to load?
  • On-site Support at Cutover: Do you want on-site support at cutover?
  • First Month-End: Do you need on-site finance support for the first month-end after cutting over, or do you have strong Epicor-savvy internal financial resources?

Upgrading an ERP system can be challenging. It’s a highly rewarding endeavor, and the outcome justifies the move. Good luck on your journey, and reach out to our experts with any questions you have along the way! 

 

Epicor Part & MOM Settings: Learning By Example

Epicor Part & MOM Settings: Learning By Example

Epicor Cover: Lessons From the Trenches

Sometimes the best way to understand the inner workings of an ERP system is to review examples of its activities and to trace them back to the underlying setup that generated the activities themselves. In the Epicor ERP context, I’ve encountered challenges in helping users understand the impact of some core part settings. Like many ERP systems, Epicor’s part master file is fundamental in governing how these parts flow through the ERP application. There are a handful of “big little checkboxes” that radically change the system’s behavior, and understanding these system settings is a core building block to successfully configuring your Epicor ERP system.

To that end, I’ve put together a few examples that help demonstrate Epicor part and Epicor MOM setup, and their ramifications on Epicor job structure. In fact, Epicor job MOMs are highly dependent on the upstream settings, and without this understanding, the structure of an Epicor job MOM can be confusing. Such principles as Epicor job materials, make-direct materials, and job subassemblies are all traced back to a few small settings. Let’s look at some examples and see how they play out.

The Difference is in the Settings

  • Fundamental decisions create a stable core
  • Successful configurations come from experience
  • Subtle variations significantly alter outcomes
Enterprise Resource Planning Project Team Meeting

In my examples, I utilize Epicor’s training database.

I begin with a few existing parts, and make small modifications to demonstrate the different scenarios.

Let’s begin with part DSS-1000.

This part came directly from the Epicor training database. The key material, part DSS-1010, was also pre-defined. Part DSS-1000 occupied material sequence 10 of parent part DSS-1000. This serves as the baseline for subsequent scenarios.

From here, I copied parts DSS-1000 and DSS-1010 multiple times and made subtle variations.

The following component materials are used in the subsequent scenarios:

  • DSS-1010: Directly from the training database. Stocked MFG Part (i.e: not Non-Stock).
  • DSS-1010NS: MFG, Non-Stock: Used for Make-Direct and Subassembly examples.
  • DSS-1010NSPB: MFG, Non-Stock Phantom BOM Part. 

The following higher-level assemblies are used in the subsequent scenarios:

  • DSS-1000: Mtl Seq 10 (DSS-1010) is a stocked material.
  • DSS-1000MDM: Mtl Seq 10 (DSS-1010NS) is a Make-Direct material.
  • DSS-1000SUB: Mtl Seq 10 (DSS-1010NS) is a Job Subassembly.
  • DSS-1000PBOM: Mtl Seq 10 (DSS-1010NSPB) is a Phantom Assembly.

Interaction between Part Master, the Engineering Workbench, and the Epicor Job

It is fundamental to understand that the part master settings affect the default settings in the Epicor Engineering Workbench and that both the Engineering Workbench and the part master affect the final job MOM. The default behavior can be described as follows:

  • Non-Stock > Pull as Assembly > Job Subassembly
  • Not Non-Stock > Not Pull as Assembly > Job Material (Issued from Stock)

Default Behavior: Stocked Part from Part Master to Job MOM

Let’s explore Epicor’s default behavior in handling a Stocked Material. In this example, the following parameters exist:

  • Part DSS-1010 is a stocked part.
  • Part DSS-1010 is a not flagged Pull as assembly material on Part DSS-1000, material sequence 10.

The outcome: Material sequence 10, part DSS-1010, shows up on the job as a material that is issued from stock (not Make-Direct).

Epicor Material Sequence

Default Behavior: Non-Stocked Part from Part Master to Job MOM

Let’s explore Epicor’s default behavior in handling a Non-Stocked material. In this example, the following parameters exist:

  • Part DSS-1010NS is a Non-Stocked part.
  • By default, Part DSS-1010NS is flagged Pull as Assembly on Part DSS-1000, material sequence 10.

The outcome: Part DSS-1010NS shows up on the Job as a Subassembly. Material Sequence 10 no longer exists on the Epicor job bill of materials.

Epicor Job Bill of Materials

Override: Processing Non-Stock Part as a Make-Direct Job Material

By default, a Non-Stock Material would be processed as a Subassembly (Pull as Assembly). But this behavior can be overridden, in the Epicor Engineering Workbench, resulting in different downstream behaviors. Unchecking the Pull as Assembly flag for a Non-Stock material will cause the material on the job to be supplied in a Make-Direct manner: Non-Stock > Not Pull as Assembly > Make-Direct Material

Let’s explore Epicor’s behavior in handling a Non-Stocked material. In this example, the following parameters exist:

  • Part DSS-1010NS is a Non-Stocked part.
  • Part DSS-1010NS is not flagged Pull as assembly material on Part DSS-1000MDM, material sequence 10. We have overridden the default and unchecked the flagged Pull as assembly flag.

Outcome: Part DSS-1010NS shows up on the Job as a Make-Direct Material on the Job.

Epicor Parameters

 

As you can see, the decisions you make when handling Epicor’s part settings can significantly impact the Epicor jobs created to manufacture them. Hopefully these examples have assisted in your understanding of the factors that affect Epicor’s job bill of materials.

Watch a video from one of our ERP events for more tips from Epicor consulting experts.

SQL Server: Turning Tips and Playing Tricks

SQL Server: Turning Tips and Playing Tricks

SQL Server Configuration, Tuning & Optimization

The perspectivism of an ERP system shifts based on one’s point of reference. To an end user, an ERP system might simply be a series of screens from which one enters and extracts data. But to an ERP administrator, the view from behind the curtain might be quite different.

For an Epicor admin, the Epicor ERP application’s curtain call generally includes a number of actors: the application server, the database server, and the end user client install among them. Each of these layers requires different tricks and techniques to keep them running smoothly.

Learn about SQL Server by watching an Epicor consulting video presentation:

SQL Server Training

Server-side wisdom is not attained simply by paying for the next round. Much of this kind of information is acquired by doing. There are guide books and training materials, of course, but these cover what we tend to call the “happy path” — and anything that veers off that path is uncharted. Also, there is a certain truism about software vendors keeping their cards close. I once had an instructor shut down one of my end-of-class questions simply: “I could tell you, but I’d have to bill you for it.”

Common Epicor Admin Tasks

In that light, we thought that it would be helpful to openly discuss some of the SQL Server tools and tricks of the trade, as to assist Epicor admins and members of the user community in solving common SQL server tasks. In the above video, recorded at a past EstesGroup User Summit, Daryl Sirota, EstesGroup’s Director of Technical Services, goes over some key SQL Server considerations that cover the range of challenges that a system administrator may encounter in managing the Epicor ecosystem, including the following:

Licensing

SQL Server licensing models vary, often by the number of users vs. the number of cores. An important consideration with licensing is scalability. The more you look to scale an environment, the more licenses you may require. Moreover, how you deploy SSRS vis-à-vis also adds potential licensing complications. We would recommend that you explore the options in constructing your SQL server environments to manage these licensing concerns.

Security

Database security begins with understanding who has admin access to a given database (be it a user with physical access, a database owner, or a local SQL admin or Windows administrator). Beyond basic access, a border concern has to do with understanding how data is leaving the database — whether through replication, application access, an external API or a basic user download. Understanding how your data may leave the server is a good starting point to understanding how to safeguard it through cybersecurity or endpoint security.

Backups

Backing up your data for future disaster recovery scenarios introduces a number of challenges. Firstly, it should be clear that backing up your data is not enough. You need to test your backups to make sure they are complete and can be restored properly. Moreover, RTO and RPO considerations extend beyond an individual DB. Backing up an individual database is one thing. Another equally important element is being able to back up and restore your entire SQL server. Disasters can happen to an individual DB or to your entire server, and different strategies will be required, depending on the kind of failure.

Performance

There are a number of simple steps that can be taken to optimize performance. First, confirm that you’ve formatted drives to a 64K cluster size, to optimize efficiencies. Another step might be as simple as separating the database and transactional log volumes, due to their different IO patterns. Additional decisions, such as how you choose to allocate data, or how to separate the SQL engine from SSRS, can also impact performance.

Redundancy & Availability

Redundancy is less about backup and disaster recovery than it is about constructing a server environment that is sufficiently resilient, such that the overall system can operate even when one of its components fails. This might involve virtual machine replication, in order to provide redundant database servers. In our ECHO managed hosting environment, for instance, our SQL servers are replicated such that if SQL server were to go down, a redundant VM steps in and takes its place.

A SQL Server Maintenance Plan

Beyond the above, a number of PowerShell and SQL scripts can be put to use to complete a number of common tasks, such as copying a production environment to a test instance, truncating transaction logs, updating the task agent settings or recreating SQL replication in support of e-commerce solutions.

Epicor Process Set Maintenance: Bundle Up

Epicor Process Set Maintenance: Bundle Up

Scheduling ERP Processes

Batch processes have been with us since the inception of business computing. You can complete a batch of tasks as a single process for sake of efficiency. The benefits of such processes are clearly time-saving for an Epicor administrator. Batch processing allows for the automation of many tasks that would take an actual user an immense amount of time and effort to perform in order to accomplish the required manual tasks and calculations. In ERP software, the Materials Requirements Planning (or MRP) process is probably the most well known of such processes. As ERP systems have become more advanced, the need to group multiple processes to operate in harmony has become increasingly important.

Female using cloud technology on a mobile workstation

Epicor Process Bundling

In an Epicor context, there are many processes that you might want to sequentially bundle, such as following up an MRP regeneration by running the production planning and the shop schedule load graph processes, such that you can see the implication of the MRP run on material shortages and shop load respectively.

Sounds simple enough, but the problem with this scenario comes with the fact that such processes often run in the wee hours of the night, and only the most zealous members of the ERP fandom would wish to set their alarms for 3:00 AM so they can manually kick off a few ancillary processes once the MRP regen completes.

Enter Epicor’s Process Set Maintenance. Epicor process sets allow Epicor admins to bundle process runs into a single event. This allows you to sequentially run a suite of Epicor processes automatically, without human intervention. Process sets can include various differences:

  • processes
  • reports
  • executive queries

Once a process set is defined, and then attached to a system agent schedule, the related tasks are automatically processed according to the timing defined by the system agent.

Let’s look at a common issue, one that surfaces frequently for an Epicor admin. At times, you may wish to run processes in a manner that filters the actual processing. For instance, you may wish to run MRP by site, or PO suggestions according to a handful of part classes. Confusion is commonplace in handling process sets when the processes involved possess filtered activities. I’ll give you an example of the problem and an explanation of the actual behavior an Epicor admin can expect to experience when setting up and executing a process set.

Epicor Process Set Maintenance With Process Filters Enabled

Creating a process set occurs through the Process Set Maintenance screen. Once a process set is defined, individual processes can be assigned to a process set. In the example below, I created a process set:

Epicor Process Set Maintenance Screen

Next, I opened the PO Suggestion screen and configured its process parameters. Of those parameters, I set a site-specific filter:

Epicor Generating Purchase Suggestions Screenshot

Then I clicked the icon below to save the PO Suggestion process to the process set I previously created:

Save Epicor Process Set Screen

Returning to my original process set, I now see that the PO Suggestions process has been attached to the process set. Were I to go through the same actions with other processes, I could add multiple processes to this process set, and then use the “Move Up” and “Move Down” buttons to order them appropriately. But one point of confusion exists here. If I were to double-click on the process that I just added, to review its properties, the filter that I previous defined is no longer visible:

Epicor PO Suggestions

As we will see, this cosmetic issue is not detrimental to the actual execution of the processes themselves. To complete the setup of a process set, you need to assign it to a System Agent Schedule. This is accomplished through the Schedule Process Set screen. From this screen, you can select the Process Set:

Schedule ERP Process

Allowing the System Agent schedule to run according to its next run time, I can see in the Epicor System Monitor that the underlying process ran successfully:

Epicor System Monitor

Looking at the Log File related to the PO Suggestions run, I can see that the PO Suggestions process ran according to the filter that I had initially set. As you can see, the log file indicates the Epicor site that I had defined:

Epicor Process Log File

Epicor Admin Automation

In summary, while it may appear that an Epicor process loses its configured filters when added to a process set, in actuality, these parameters are retained, allowing the Epicor Admin great flexibility in automating a variety of ERP system activities.

Epicor Consulting? Epicor Managed Hosting?

Get advice from an ERP consultant or managed IT specialist. Chat with us to get a free ERP consultation or technology assessment.

Epicor Server File Download: Serving the Process Server

Epicor Server File Download: Serving the Process Server

The Pandora’s Box of ERP

Epicor processes can be a Pandora’s box of complexity. Rumbling under the surface, these processes perform innumerable tasks that allow an ERP system to function effectively. But when these processes fail to deliver the expected functionality, understanding the logic of these subaltern beasts can be problematic.

Happy distribution warehouse manager holding a cloud-enabled mobile tablet
  • Was it a problem with network connectivity?
  • With master file setup?
  • With company configuration?
  • Was it a bug?

Accessing Log Files Through Epicor Server File Download

One can spend an immense amount of time trying to troubleshoot these processes, especially given the timing required to perform trial-and-error with back-end processes. Such repetition gives ERP wheel-spinning a new meaning.

Fortunately, Epicor has a means of slowing the wheel, if not breaking it altogether. It is a general best practice when designing and developing complex programs and processes to include some form of logging. This provides the end user, or Epicor admin in this case, an opportunity to divine the logic of the program in question. This can help you troubleshoot process issues quickly.

In the past, gaining access to these logs to anyone but an Epicor administrator has been problematic. But in recent versions, Epicor added functionality to allow an end user to access server-side log files: Server File Download.

Epicor Server File Download provides the ability for a given user to look up various types of log files and save them to a local location. This allows you to retrieve and review log files. It does not require access to the server locations where they are stored.

Let’s assume that I kicked off a PO Suggestions process and enabled logging, specifying both the logging level and the log file name:

Epicor Server Download Generate Purchasing

As the process runs, it writes a log file to the server. The log file can be retrieved using the following method:

  • Open the “Server File Download” screen, which has the following menu location: System Management/Schedule Processes/Server File Download.
  • Choose the Directory Type. User: These logs normally refer to the user-specific logs. Company: Company type files are the most common logging methods and logs for processes such as MRP or PO Suggestions normally land here. Reports: This area holds XML files related to Crystal Reports.
  • Use the “Select File…” button to identify the file you wish to retrieve.
  • Use the “Client Path…” button to define the location to which you want the file saved.
Epicor Server File Download

Clicking the “Select File…” button allows you to search for and select the file in question. In the example below, I located the file that I had named previously, when I kicked off PO Suggestions:

Epicor PO Suggestions

Clicking the “Client Path…” button allows you to specify the location to which you intend to download the file:

Epicor Server File Download Browse For Folder Screen

Once the source file and the destination location have been defined, select the OK button. This will kick off the download activity:

Epicor Source File

Once the download has completed, the system will raise a download status message:

E10 Server Download Complete

Once downloaded, you can navigate to the specified path and access and review the log file to better understand the details of the process itself:

ERP Process Server Log File

ERP system troubles? Check the log…

Navigating the workings of an ERP system’s back-end server processes can feel at first like an exploration into the Eleusinian Mysteries. Fortunately, Epicor’s Server File Download toolset allows you to unearth the hermetic actions of Epicor’s darker processes, hiding in the process server’s chthonic cave, bringing them into the platonic light of your client folder and making them visible for all to see.

Never miss an ERP step. Learn about our private cloud hosting solutions.

ERP Implementation Best Practices: Closing the Gaps

ERP Implementation Best Practices: Closing the Gaps

ERP Implementation Challenges

Bridging functionality gaps in ERP is one of the great challenges in an Epicor implementation, or of any enterprise resource planning project. There are often visible gaps between a company’s business requirements and the system’s ability to address them. In a perfect world, the needs of the company perfectly match the capabilities of the system they are implementing. In practice, the gaps between an organization and its ERP application can be significant, and closing these gaps can take significant effort. The inability to successfully close these gaps is a leading cause of project failure. This guide will help you understand a few ERP implementation best practices to help address the great challenge of closing the gaps.

Time and ERP Planning No Gaps

ERP Customization

  • Find creative ways to use the system’s standard configurations to address the needs of your business.
  • Adjust your business processes to conform to the system’s recommended best practices.
  • Tailor the software in one form or another to provide needed functionality.
  • Combine the above methods to achieve a hybrid solution.

So why do businesses feel the need to tailor the applications they implement? ERP software customization is a means of closing gaps. Sometimes, it is the preferred means of addressing challenges before they start. Often, gap closure will involve some form of customization. The overall level of ERP project complexity will expand with increasing challenges and risks. In general, the different types of obstacles encountered in an ERP project can be grouped under one of a few headings. Customizing an ERP application allows you to do a number of things and to circumvent a number of issues:

  • Automate tasks. The standard system is too transactional and user-intensive.
  • Prevent errors. The standard system allows for too many points of failure as a function of user entry.
  • Integrate with third-party systems. The standard system does not provide specific functionality, necessitating a tertiary application. Similarly, the standard system does not integrate with the third-party module in question.
  • Extract and display data. The standard system’s out-of-the-box reports do not present the necessary information needed by the business.
  • Add business logic. The standard system does not possess logic needed by the implementing company.

The Total Cost of Ownership of an ERP Solution

The rule of thumb that came out of the first generation of ERP systems was simple: avoid customizing the ERP system at all costs. Fit the business to the software, not the software to the business. Considering the comparatively rigid systems of the era, this recommendation seemed valid. Earlier-generation ERP systems contained limited toolsets for tailoring the application to meet the needs of the implementing organization. As such, customization essentially implied a source code modification, and such changes were detrimental to the long-term maintainability of the systems involved.

ERP Implementation Best Practices Evolving

Next-generation ERP systems contained improved toolsets to provide non-source-code customizations that were upgradable and maintainable, but the disruptive effects of customization on the implementation projects nevertheless continued unabated. Why do ERP customizations continue to create challenges to organizations?

 

Customizations are disruptive—they introduce logic to the application that is not native to the core system. They may also behave in ways that are unlike the rest of the system, and tend to be less comprehensive than the source code that they are layered upon.

 

As they are developed and refined, they often contain bugs. For example, the custom business logic may be invoked at times when it isn’t expected, or may not be invoked in all cases that require it. Working though these bugs can be challenging. Moreover, when customizations run into bugs or undocumented features of the core application, an abundance of unexpected behaviors can result.

 

 

ERP Toolsets & Project Success

Everything said, how do companies successfully leverage the customization toolsets available? How do they provide the necessary functionality to their organizations without compromising project success? Consider the following observations:

  • On one hand, we’ve seen companies significantly customize their application in an organized and methodical fashion. Therefore, the customizations produced a limited disruption to the implementation.
  • On the other hand, we’ve encountered other companies that only modestly customized their application. The modest number of customizations significantly disrupted the implementation. Why?

Organize to Optimize Your ERP Software

The level of customization and the level of organization of a project are closely tied. Therefore, companies that organize their customization efforts carefully are much less likely to experience problems caused by customizations. Conversely, poorly organized customization efforts will create additional issues that will add complexity and disruption to an implementation that is already, by its very nature, complicated.

 

Quantifying the impact of these two variables (customization and organization) can be difficult, but a simple mathematical model might help to model their interaction.

  • Assume that a project’s level of disorganization can be scored on a scale from 1 to 10, with 1 being highly organized and 10 being highly disorganized.
  • Similarly, assume that a project’s level of customization can be scored on a scale from 1 to 10, with 1 being lightly customized and 10 being highly customized.
  • Additionally, assume that a project’s success can be scored on a scale of 1 to 100, and anything over a score of 20 is a bad thing. For example, the project could be over budget, behind schedule, or low in scope or quality. In this context, a score of 30 might imply a project that went live late, or had to cut scope, or exceeded the budget, while a ruination score of 100 might represent a project that is years late, millions over budget, and so poorly designed that it will fail to go live.

A score of 1 (very low customization, very low disorganization) represents a very low risk score and a score of 100 (very high customization, very high disorganization) represents immense and catastrophic risk to your ERP and to your business:

ERP Implementation Best Practices Grid

The simple lesson to be learned here is that an organization can perform reasonable amounts of customization to their ERP application without destroying an implementation. A company needs to take steps to utilize an organized approach to customizing their application.

 

ERP Risks

A challenge with this dilemma is the reality that most companies do not launch an ERP implementation project believing that they will customize the application significantly. As a result, when these change requests surface, they are normally ill-equipped to handle them, and things soon spin out of control. As such, many customers come to us asking the simple question: What does it mean when one’s customization methodology is highly organized?

 

ERP Project Risk Management

There are a number of characteristics that an organized implementation possesses. They include the following:

  • First and foremost, governance is in place, to control when customizations occur. Governance is the best way to keep the degree of customization from spinning out of control.
  • Solutions are tracked. The implementing company understands which modules have been customized and which reports have been altered. They have identified all truly custom entry screens, reports, and dashboards. This information is put to use whenever an ERP upgrade occurs or a new site goes live.
  • Business requirements and functional specifications are developed as solutions are developed, and these solutions are constructed using these specifications.
  • Guidelines are defined ahead of time. These are conventions that describe how custom solutions are to be constructed, organized, and named.
  • Solutions go through careful testing. They receive a unit test to ensure that the basic requirements have been met, and then a regression test, to ensure that they function appropriately within the overall application, and don’t break anything else.
  • Solutions go through careful deployments to the production environment. When old solutions replace new solutions, the old solutions are removed from the environment as part of the deployment, to prevent the environment from getting cluttered with old, inactive solutions.
  • When an ERP module is customized, the developers take into account the full suite of new and pre-existing customizations, as to ensure that new elements are optimized to efficiently work in concert with existing custom solutions.
  • Environments are constructed as to segment various activities such as functional design, custom solution development, and upgrade verification. When these activities overlap, conflicts invariably arise, and these can slow down the progress of a project and create needless confusion.

The Goal of an ERP Implementation is Twofold

How do you implement a system that satisfies the needs of your business? How do you stay scalable and maintainable and also support the future requirements of your organization?

 

The future of your business is always unknown, and often unpredictable. Therefore, cutover will surely present new unknowns. Heavy system customization often results in the achievement of the goals of business needs. Unfortunately, this can risk the long-term maintainability of your ERP system. An organized and methodical approach to system customization supports a more successful implementation. Moreover, it provides easier long-term maintenance of your application. Likewise, it holds the ability to support the business requirements of the future.

 

After the ERP Vendor, the Software

Are you trying to improve your manufacturing processes? Do you need user training to empower your ERP project team? Are you looking for the competitive advantage that cloud ERP offers? Do you need help with data migration to an ERP hosting environment for a complex enterprise resource planning software like Prophet 21, E10, or Sage? We have experts for everything ERP, whether you need Epicor consulting assistance or QuickBooks hosting guidance.

 

For 17 years, EstesGroup has served clients at every step of the ERP implementation process. We offer real-time support 24/7/365 for your implementation team. We optimize your technology, and we lighten the burden on the precious human resources that make your company unique. Your team can work according to their talents, while we do the routine work involved in managing your ERP software and the technology that supports it.

 

 

Learn More About ERP Implementation Best Practices for Cloud

A good ERP balances your budget, opens your resources to new possibilities and opportunities, and improves everything from customer relationship management to industry-specific compliance and cybersecurity. ERP cloud hosting provides an ideal platform for your work. Request an ECHO demo today to see how EstesCloud managed services can help your business.