Select Page
Custom Cloud: Public Cloud Choices, SaaS Challenges

Custom Cloud: Public Cloud Choices, SaaS Challenges

What to Do When ERP Turns SaaS

I once sat in at a sales conference for an ERP vendor and listened as the CEO explained sales strategy as it related to their ongoing movement to the cloud. He described the situation as one of configurability vs. customizability. There were some customers who could live with and work within the configurable features and capabilities of the base application as they existed “out-of-the-box.” These customers would be targets for the vendors single-tenant and multi-tenant cloud (or SaaS) offerings. For the subset of customers whose needs extended beyond the system’s base configuration, and were in need of custom functionality and integrations, the vendor would still offer the traditional perpetual license. This would allow customers with more complex needs to deploy their applications on-premise or in a private cloud.

ERP Public Cloud Software as a Service

That was the CEO’s perspective. Customers have their own perspective. 

Configuration & Customization to Order

I recently talked with a customer who was struggling to implement the cloud version of an ERP to the vendor’s public cloud. The customer had purchased the software based on a set of assumptions, assumptions that were not instantiated by the vendor’s public cloud (or SaaS) platform. For one, the customer had come from a highly customized in-house suite of applications, and had a highly developer-centric approach to application implementation: if the app didn’t do what you need, customize it so that it would do what you need.

This approach is anathema to ERP implementations in general, and as a customer implementing on a public cloud SaaS platform, the shock was only intensified. The customization toolset to which they believed themselves to be privy to was less than advertised. And the documentation that explained just what was and was not possible was all but nonexistent. As the customer put it, his team’s vast C# skillset went largely underutilized.

Frustrations abounded on all fronts. Creating the necessary reports and labels, whether through Bartender or SSRS had been a disaster, as both the licensing and underlying architecture made for an untenable situation. Development and deployment of new solutions was cumbersome and time-consuming, as it required the vendor to perform the deployment every time a change was made. Similarly, the approved third-party applications that they had purchased in conjunction with the base package didn’t integrate as well as advertised, and they turned out to be even less configurable than the base ERP system.

Worse still, the customer was a user of the ERP’s product configurator module. This mode was itself a mini-development platform, but its features were largely server-side and thus greatly hampered in the vendor’s SaaS platform. The ability to use the module to look up and retrieve data, for instance, was greatly limited on the SaaS architecture, and the customer struggled to construct configurators to handle their complex product needs. Beyond functionality, the overall performance of the application was a drag. For many customers, the move from whip-fast, green-screen legacy platform to a contemporary ERP brings an unfortunate surprise when it comes to basic performance at a user interaction level. But in this case, it was magnified by the performance of the underlying cloud platform.

It was a disheartening conversation and I struggled to offer suggestions, outside of a reimplementation under a perpetual license model. The strange thing was that the customer did not really even come to me looking for help. He was really just venting his frustrations. He had learned enough of the application, its architecture, and the Service-as-a-Software (SaaS) deployment model to know that whatever help he might receive, he was constrained by the architecture to which he had bound himself. The cloud, whose name implies boundless opportunity and possibility, had become a crippling constraint.  

Different ERP systems provide different levels of configurability and customizability. Some systems offer a basic platform with robust tools to use to build custom functionality with which to tailor the base platform. Others provide extensive configurability, as to avoid the need for additional tailoring. The systems that best combine configurability and customizability capabilities stand the best chance of supporting the needs of complex organizations. Even still, the unbridled requirements of a given company can often exceed the combined abilities of an ERP system to handle it.

This may necessitate the need for third-party integrations, to atone for liabilities in the base system. It may require integration to a pre-existing home-grown system, to address the specific needs of the organization. In the most extreme of cases, customers may look to modify the system’s source code to make the system do what it needs. At some point, it should be considered whether such extreme measures justify the investment in ERP at all. Sometimes it is simply a cultural conundrum: if an organization is unable to bend some of its needs to the will of the application, they may truly be better off with a homegrown system, and live with the liabilities that come with such a decision. 

DRaaS for SaaS: When the Public Cloud Vendor Needs to Adapt

Beyond configurability and customizability, the questions of functionality and integration as they relate to an ERP system’s deployment model complicate matters further. The textbook cases regarding ERP customization nightmares from the 1990s all occurred within an on-premise context. The evolution of cloud computing had not yet thrown this new variable into the mix. But with the improvement of server processing power, the expansion of data centers, and the ability to pass larger and larger amounts of data over networks, ERP vendors were able to construct ERP applications that conformed to the public cloud software-as-a-service (SaaS) deployment model.

This shift toward a SaaS model allowed for highly available and highly scalable ERP solutions, whose subscription-based model provided ERP services for a monthly rate. But in doing so, the features and capabilities that these vendors offered were often scaled back significantly, when compared to their on-premise, perpetual license predecessors. Similarly, the integration capabilities of such platforms were drastically reduced to the web APIs that the ERP SaaS platform supported. This made the extension of the application’s capabilities much more difficult to achieve. For customers needing robust and expansive ERP functionality, as was the case with my customer above, the results of a mismatch between business requirements, customization tendencies, and deployment models can lead to a perfect storm of failure and disillusion. 

How does one avoid such a problematic situation? To begin with, there are some key questions to answer at the time of software selection before you’ve signed the dotted line:

  • Firstly, you need to understand the background of your own organization. Are you coming from a standard system or from a highly-tailored home-grown system? Are your business requirements of the variety that are commonly managed by a packaged system? Is the shift from your current system to the future system a small shuffle or a quantum leap?
  • You also need to understand your own expectations for the new system: are you trying to fit your organization into the system, or are you trying to tailor the system to fit your business? Do you see an ERP system as a packaged application or a custom development platform? Companies differ in this approach, and this greatly affects how they intend to use the system, so you need to be explicit about your expectations.
  • Finally, it should be noted that in many cases, a software’s public cloud version will differ markedly in functionality from its cloud cousin. As such, be careful to understand the version from which the Sales Engineers are basing their demonstrations. If you’re looking at a cloud deployment, ensure that the sales team demonstrates the application, as you will experience it as a customer, and not the products more robust, on-premise version.

Cloud services are as unique as business processes, and SaaS companies / SaaS, or public cloud, applications aren’t always as “internet connection, web browser, go” like they’re often advertised to be.

If your corporate office is mandating some form of “cloud” solution, understand that not all clouds are created equal. A system’s deployment mode is not as simple as choosing between an on-premise dinosaur and a public cloud popsicle. One significant alternative to the SaaS vs on-premise dichotomy is a private cloud deployment. Private cloud allows an ERP customer to install an on-premise, perpetual license version of the software, but in a virtual cloud environment. This allows customers to leverage the full set of capabilities, functionality, and integration opportunities that the software offers. For customers bent on heavy tailoring and customization, this allows them to leverage the full set of tools tailor the application to the customer’s specific needs. Further still, this model makes integrations much easier, as it provides access to the application and database server layers, as needed, which can greatly simplify integration architectures. 

Cloud Customs of Custom Code

A company’s implementation story should be neither a laughable comedy nor a disheartening tragedy. With planning and discretion, companies can formulate a successful narrative. Are you in search of an ERP story with a happy ending? Talk to us, and we’ll spin you a yarn.

You can consolidate everything from software licensing and updates to hardware inventory management with EstesCloud Managed Application Hosting. We offer custom solutions for web-based transactions. We might not be famous like Amazon web services, but our private cloud, hybrid cloud, IaaS, and PaaS solutions offer you the personal attention of world-class IT and ERP consultants.

ERP Deployment Options & Cloud Services

Infrastructure as a Service

Platform as a Service

Software as a Service

IT Management Models

In pure form, a public cloud deployment limits your control and troubles cybersecurity and compliance management efforts. Know your enterprise resource planning options before you deploy. The cloud should be one of your most powerful tools as you move your company forward. But cloud computing terminology is hazy, and cloud migration can be a step backward if the deployment model isn’t a good fit. Do you understand your cloud options? Our cloud ERP experts can walk you through the cloud spectrum and help you find the best platform for your business. When a complex ERP like Epicor’s Prophet 21 is going through client-server architecture changes, EstesGroup consultants are here to answer questions so that you can focus on your business, rather than on its supporting software.

Feeling the pressure to upgrade your ERP system to a new SaaS version? Know your options before you commit to the public cloud. Get a free demo and consultation with our cloud experts today.

Prophet 21 Event: Servers, Financials & Supply Chains

Prophet 21 Event: Servers, Financials & Supply Chains

With summer in full swing, distributors are on the move, crossing docks, splitting shipments, and delivering goods by the truckload to a diverse array of customers. It is a time for expansion—of old trade routes of supply chains and of new opportunities as our reopening country rediscovers its possibilities.

Female Attending a Virtual Epicor Prophet 21 Event

Attend a 2021 Prophet 21 event in person or online

With user conferences back in the schedule for 2021, P21 users are highly anticipating the Prophet 21 user conference P21WWUG CONNECT in mid-August. This event serves as a focal point for the P21 user community and as a bookend for a busy summer. At the onset of the summer season, we thought it would be helpful to host our P21 summer summit as a prelude to the larger Prophet 21 community event. This also gives you the opportunity to open the summer with some new ideas for using your P21 application to its fullest capabilities.

Events like this are a great opportunity to review your application’s capabilities and find ways to improve internal processes, discover ways to reduce costs, and reveal methods to improve information flow and presentation. You’ll also surface steps you can take to better integrate Prophet 21 with suppliers and customers.

Our summer 2021 Prophet 21® event takes place on June 24, from 10:00 AM to 1:30 PM (Central Time). Three panelists will discuss topics pertinent to the P21® user community. The event is free, and all are welcome! This summit will also provide an insider’s view of the Epicor Prophet 21® solution for any distributor who is looking for growth opportunities that only a new software can provide.

Prophet 21 Event Itinerary

Server Best Practices for the Epicor P21 Environment

10 AM – 11 AM (CST)

Daryl Sirota, Executive Director of Technical Services at EstesGroup, will discuss server best practices for P21. Understanding the optimal means for deploying the Prophet 21 application has never been more important, especially with Epicor’s move to a new client-server architecture. Daryl will discuss some of the key considerations when deploying and maintaining your server stack. Daryl leverages 35+ years of IT experience to help customers develop server and cloud architectures that are robust, flexible and reliable. A veteran systems engineer and Microsoft expert, Daryl provides the stable technical foundations that allow customers to focus on their business. Attend this Prophet 21 event if you’d like to know how to create a private cloud for your ERP software.

Creating Financial Statements Using Financial Line Express

11 AM – Noon (CST)

Terri Gage, Senior Consultant at EstesGroup, will discuss the creation of Financial Statements. P21 customers express frustration in successfully creating financial statements, but the often forgotten Financial Line Express can bring ample help to your financial reporting needs. A longtime project manager, implementation consultant, and Prophet 21 specialist, Terri works with organizations to help them successfully implement and fully benefit from the P21 application, actualizing their goals of sustained profitability and business excellence.

Bridging the Gap Between Epicor and Suppliers for Distribution Companies

12:00 PM – 1:00 PM (CST)

Jim Frye, Enterprise Sales Director at SourceDay, will discuss how distribution companies bridge the gap between their Prophet 21 system and their supply chains. Distributors need to do many things to help secure their supply chains as the ground shifts beneath them, automating the mundane and improving collaboration, visibility, and accountability between them and their varied suppliers. Jim leverages 30+ years of experience working with Global Manufacturing Companies, big and small. His passion is to help organizations facilitate growth, reduce operating costs, and increase profitability through supply chain efficiency.

Our event concludes with an open Q&A session, allowing users to raise questions regarding the sessions themselves and the Prophet 21 application in general. Operations management strategies. Cloud server integration steps. Cloud hosting service risks. Prophet 21 cloud platform options. Global supply chain trends. Operation system updates. Dedicated servers, multiple servers, SaaS… from Prophet 21 consulting to server hosting, we have answers to your P21 ERP and IT questions.

Do you have questions you’ve been meaning to ask a consultant, but haven’t wanted to shell out the cash? 

Now is your chance to do it–on our time and our dime!

Epicor’s Prophet 21 user community is founded on collaboration.

Come collaborate with us on June 24.

This event can also help distributors who are considering a new enterprise resource planning (ERP) software.

Cyber Security

3 Ways to Spring your Epicor Installation Ahead

3 Ways to Spring your Epicor Installation Ahead

Spring Cleaning & New Growth for Epicor ERP

While individuals differ in their opinion of daylight savings time, the metaphor of “springing ahead” feels perfect for the enterprise resource planning (ERP) season. Spring is, after all, the time of growth and expansion. So how do companies make the most of this season? Successful Epicor customers often find ways to move their implementation forward, following through on the ERP resolutions made in winter. 

Whether you’re heading toward a great spring-loaded leap forward or merely some spring cleaning, there are many things that you can do to help your Epicor application spring ahead in terms of functionality, capability and overall return on investment (ROI).

Epicor Installation Manufacturing Tool Sparks

Spring your Epicor Installation Ahead with a Master File Cleanup

Daily problems in business operations often have their source in the master file records. Master file records are the kind of data that gradually deteriorates over time, if not cared for with vigor. Cleaning up the customer, supplier, and part master tables allows companies to quickly resolve multiple ongoing issues. I’ve seen many companies perform annual intensive data cleanup efforts to rectify such ongoing issues, and this often results in a system that is more predictable and more scalable over time. With each master file, countless questions can be asked to verify the accuracy of this foundational data.

These might include some of the following:

  • Customer Master: Are customer contacts up to date? How about the terms? Are credit limits in need of a review?
  • Supplier Master: Is banking information correct? Are purchase points defined correctly? Are terms up to date?
  • Part Master: Is supply-side information correctly configured to handle demand? Are part costs in line? What about customer and supplier-based part pricing?

Spring your ERP Ahead with a User Security Review

Cleaning up security within the ERP application is a simple step that can improve the maintenance and maintainability of the application. One significant question would be to ask whether your company utilizes individual user security or group security. The use of group-based security tends to keep the management of security much cleaner than the individual method, as users inherit permissions from the security groups, which ensures consistent and predicable access, without the scramble of managing individual permissions on every user account. Has your individual user security gotten out of hand? It’s never too late to rationalize security groups and roll back some of the disarray. This is one simple way of keeping your Epicor installation from becoming risky business.

Within this general structure, attention should be take to a few key functions, as to ensure that they are adequately managed:

  • Part Maintenance: Who has the ability to create and maintain parts? In many organizations, too many individuals have this ability, and it can create a significant amount of disruption if they are not doing so in a consistent manner.
  • Quantity Adjustments: The ability to adjust inventory quantities on the fly is a powerful but dangerous capability. Often, quantity adjustments are made to cover other issues, such as incorrect quality practices or inaccurate material issuing tendencies. Limiting quantity adjustments to a few reliable individuals is key to preventing inventory problems from spinning out of control.
  • Job Entry: Who should be able to modify a job? There are several settings (backflush, make direct, purchase direct, etc.) that can radically affect the application. Tightening the screws on job entry is often a means of ensuring successful supply for the jobs in question.

Spring Ahead with Focused Education

In an ERP context, education should be distinguished from training. Training generally refers to basic instruction geared for general end users, to allow them to perform processes accurately and consistently. Education differs from simple training in that it focuses much more on the underlying mechanics of the ERP system than on performing specific pre-defined tasks. When a larger critical mass of super users understands the underlying mechanisms of the system, you are better able to make decisions and further refine your system, improving efficiency and handling new challenges as they arise. Also, as new employees enter the organization, providing them with a solid understanding of the system can prevent needless backtracking. This is especially true for an Epicor installation.

So, what areas of the application could use some additional deep dives? Here are a few:

  • Transaction types: What’s the different between MFG-STK and MFG-WIP? It’s an important distinction.
  • Non-Stock: Understanding the effects of the non-stock flag on Sales Order Entry, the Engineering Workbench, and Job Entry is fundamental to successfully managing parts through the system.
  • Phantom BOMs — phantoms may help simplify your job BOMs, consolidate engineering levels, and simplify transactions.
  • Labor Entry Method: How does backflushing differ from Quantity Only? These are subtle but important differences, and the ramifications are widespread.
  • Backflushing Materials: Backflushing is another opportunity to make the system more efficient, but it relies on a solid understanding of the related hierarchy.

A Clean Epicor Installation Enables Growth

Spring, after all, is the season of growth, so push to move your Epicor ERP application forward this season, and sew the seeds for a bountiful harvest in 2021. Ready for optimal growth? Get the Epicor consulting services or Prophet 21 services you need to get ahead of the season. Take a tour of Epicor in a future-proof environment with a free ECHO cloud hosting demo. ECHO supports all ERP systems, including cloud-ready P21cloud-ready SYSPRO.

 

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.

Join us at a virtual event to learn more

about ERP application deployment, management, and success.

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. Sign up to get industry news and commentary from our IT & ERP experts.