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?

EstesGroup and Alliance Machine Interview (Video)

EstesGroup and Alliance Machine Interview (Video)

Bryan Provo, President

Alliance Machine, Inc.

Bruce Grant, President & CEO

EstesGroup

 

Bryan Provo explains why working with EstesGroup is critical to his success

 

Alliance Machine’s Bryan Provo is President of his family’s 2nd generation manufacturing business based in Elk River, MN, north of the Twin Cities. For 30 years, his company has delivered high-value solutions to the aerospace, defense, medical and technology industries. 

 

When EstesGroup originally engaged with him over 5 years ago, Bryan’s mind was fixed on having hardware on-site (exactly where cybercriminals could access it). In conversation with Bruce Grant, Bryan explained his transition from wanting full access to his own hardware to wanting complete IT and security management from EstesGroup experts.

 

Bryan explained the challenging times that brought on his IT change: “I felt it was too difficult to manage the hardware portion.”

After a nasty ransomware experience two years ago, Bryan set out to find a managed IT service provider and, after many phone calls and after reaching out to multiple vendors, he partnered with EstesGroup. He realized, in his own words, “They had exactly what I was looking for.” 

 

Bryan summarized the success of bringing EstesGroup fully aboard for his IT needs: “It’s been an absolute heaven-sent.”

As you will hear in the interview, Bryan has experienced, and thoroughly knows, how difficult server crashes were before EstesGroup began managing his IT. Please listen to Bryan Provo explain various strengths of his partnership with EstesGroup in the following short videos, taken from the full interview with Bruce Grant:

Why EstesGroup Managed IT?

Why EstesGroup Cybersecurity?

Need help with your ERP or IT systems? Contact us today.

Epicor User Security – Allow Multiple Sessions (Video)

Epicor User Security – Allow Multiple Sessions (Video)

Your Epicor Application is In Session

 

Over the years, we’ve worked with a number of fledgling ERP administrators on resolving Epicor user security and user account maintenance issues.  One common quirk with Epicor user account maintenance relates to the flag that allows multiple concurrent sessions (in the database: UserFile.AllowMultipleSessions).  This is a powerful checkbox, significantly affecting a user’s experience of the application.  The best way to deal with Epicor user security troubles is to understand the functionality of the application, and our hope is that in this example, we can show you one way to avoid ERP administration headaches.

The multiple concurrent sessions flag itself is set via the Epicor User Account Maintenance screen:

 

The “Allow Multiple Sessions” checkbox defines whether a user can launch multiple sessions of the Epicor application.  This lets the user log in multiple times and interact with the environment and with the system from either session.  This can be helpful in performance-constrained environments, where a form might “hang” for a number of minutes and necessitate the use of a second session for subsequent parallel activities.  But none of this is possible if the checkbox is not set.  In practice, the setting of the “Allow Multiple Sessions” flag has two primary effects for a general user.

 

For customers working in multi-company or multi-site environments, when this flag is not set, a change to a user’s current company and/or site will force all open forms to be closed.  This does not occur when the flag is set:

 

 

 

If this checkbox is not selected, a user can only have one instance of the Epicor ERP application open at a time.  If they log into a new session while already logged into the system, the older session is deleted.

 

 

Once logged into the second session, the user will receive an error from the prior session, with a warning that the session has been cancelled:

 

 

Gaming the System

 

It’s surprising how significant the influence of enterprise systems is on manufacturing and distribution companies.  The configurations of these systems frequently determine the rules of the game that companies and their users have to follow.  Because of this, you have to choose your systems carefully and work to understand the rules by which they play.  

 

In an Epicor application context, dialing in the system to support the needs of your end user community is a key step in both the implementation and the ongoing maintenance of your Epicor installation.  In addition, it is important to understand how a company’s security involves more than just firewalls and endpoints.  Within a company’s domain, and within its core applications, it is important to understand what users should and shouldn’t be able to do.  In Epicor, many of these IT security permissions are defined through the User Account Maintenance screen.

 

Whatever your enterprise system of choice, make sure to leverage its security permissions to empower optimal user productivity, while also minimizing risk.  Beyond the bounds of Epicor user security, make sure to draw in all of your resources to create protective guidelines for your user community. 

 

Are you having issues with, or have questions about, your Epicor 10 ERP Application area? Contact us today.

IT Security Gone “WFH” – Now What?

IT Security Gone “WFH” – Now What?

 

Recent “Work From Home” (WFH) mandates have quickly pushed manufacturing and distribution employees out of the familiarity of their work offices and into a new realm of IT security needs.  Currently, statistics are saying that 70% of the workforce that can work from home is and, after this crisis is over, more than 40% will STAY at home.  With this transition, IT security principles become part of a critical conversation, especially for companies with remote workers supporting on-site manufacturing or distribution activities.

 

What is your WFH IT security policy?

 

Many distributed businesses have responded to the telecommute directive without many changes, especially those companies with data residing in the cloud.  These companies have already established work-at-home policies and invested in the remote access/remote desktop technology to enable telecommuting with IT security in place.  Folks who invested fully in the Office 365 space are feeling little pain, but businesses with legacy on-premise servers, workstations and printers are probably still scrambling.

 

Don’t be fooled—the hackers have followed you home!  The increase in suspicious emails, bad websites, and malicious advertisements has skyrocketed, and the cybercrime community is just waiting for your users to click on something to ransom your hard-earned data away.

 

Without a written and agreed upon IT security policy, you are at the mercy of your users’ good intentions.  Imagine a home PC with a saved password left on the VPN all day while the kids are stuck at home from school.  The amount of data that could be lost or compromised is staggering!  At a minimum, make sure you have a document that instructs your WFH users to lock the keyboard when they step away (or implement a screen saver with a password).  Ensure your users don’t download documents to their local hard drive or USB drives.  The list goes on, but the human element is the riskiest of all!

 

If a home user gets infected on the VPN, their malware is the company’s malware!  Let me write that again:  If a home user gets infected on the VPN, their malware is the company’s malware.

 

How to connect securely to your enterprise data?

 

Many businesses have NOT invested in expensive VPN or Remote Desktop solutions, and now it might seem either too late or too expensive.  You need a low-cost, secure, and easy-to-deploy strategy to connect your home users with their corporate data:  desktops, servers, and printers at the office.  Many options exist, but without a budget and a vision, you’ll get lost in the storm.

 

 

Keeping your home PC safe!

 

Home computers are more vulnerable than corporate PCs.  Home PCs tend to fall behind on patches and updates.  Moreover, the computer might get repurposed for things like the kids’ Xbox.  Home firewalls never measure up to those provided by your IT department.  Most have no web filtering to speak of, and bad websites abound!  You’ll need that enterprise class security in a mobile-friendly package.

 

 

Productivity

 

Another blog could certainly be written about home offices, with a good webcam and a quiet space, but that’s for another page.  People are people, and the distractions from working from home are numerous and easy to fall prey to.  We recommend easy-to-deploy software to ensure that your users arrive to their home office on time and ready to work (even if it’s in their PJ’s), ensuring that they are productive and not on YouTube or getting the latest Amazon order completed.

 

 

 

Looking to provide IT security for your remote workers?  Deploy the EstesCloud PC Security Stack on your home users’ PCs and rest easily, knowing that your WFH users are protected and productive!

 

Private Cloud Owners Regress with Egress Expense

Private Cloud Owners Regress with Egress Expense

Private cloud deployment is changing the way manufacturing and distribution companies install applications and store information.  While this is an exciting move for any business, the step from on-premise to cloud infrastructure can come with unexpected costs.  Many companies expect, and easily budget for, typical costs associated with the move to private cloud, but hidden expenses often blur into the fine print of the original pricing model.  Thus, it’s important for a manufacturing or distribution business to budget wisely when moving from on-premise to private cloud infrastructure.

 

Cloud costs vary according to several different factors, and data comes into play at all levels.  A company is its historical data applied to its future, or potential, data.  Private cloud protects the data of a business while also utilizing it in real-time, and this cloud data normally exists in one of three states:

 

  • Data moving in.  This is data as it moves into the storage location or as it is being uploaded.  This process is also known as data ingress.
  • Data moving out.  This is data as it moves out of the storage location or as it is being downloaded.  This is sometimes referred to as data egress.
  • Data “at rest.”  This can be data residing in a static manner in the storage location and not in transit on the network.

 

 

Data In, Data Out

 

Not surprisingly, costs are tailored around these types of data.  Storage budgets are related to the costs of data that is physically being held at a location.  Normally, the storage of “at rest” data receives the most attention, as cloud providers offer various pricing structures based on how much data is stored, where the data is located, how often it needs a backup, how often it tends to be accessed, and how quickly it needs to be retrieved.

 

Many cloud providers do not charge customers for data upload or ingress, and the reasoning is obvious:  the more data you upload, the more you get charged for “data at rest.”  But one of the most significant hidden costs of the cloud relates to data egress charges—the charges leveled by your cloud provider for accessing your own data.

 

Think of your old phone bill before the cell phone revolution—each call outside the local area was billable, and the costs varied according to the duration of the call and the location to which the call was made.  Egress charges work similarly and are based primarily on the amount of data transferred.  Over time, this becomes a matter of dialing for dollars.  Should the data transfer increase, the charges will follow.

 

At its worst, this could become a situation of data rationing, where users are instructed to minimize their pulls from the data source, to minimize costs.  This is akin to a mother in the 1980s locking up her new push button phone, out of fear that her toddler, enamored with the button tones, might mistakenly dial Hawaii.

 

Data rationing is hardly the outcome that one would expect from a move to the cloud, yet egress pricing models put companies in a precarious position.  This poses a challenge for companies new to the cloud.  Customers accustomed to comprehensive local area networks do not always realize the amount of data that leaves one area of the network to be consumed by another, and thus may be unaware of their ultimate egress requirements.  Also, companies may have difficulty in predicting spikes in usage.  Without understanding when data use may increase, manufacturing and distribution companies will have trouble predicting expenses.

 

 

Data Grows on Trees

 

Companies using applications that operate in a client-server manner may be similarly challenged when they choose to host their server in the cloud.  The data requirements of private cloud can be as surprising as they are significant.  A client-server application like Epicor ERP, for instance, is a rather chatty application, as it frequently performs “get” calls to refresh data, in relation to other transactions.  In such a case, each “get” would entail a “give” in the form of cold hard cash.  For companies utilizing manufacturing execution systems in which users are routinely downloading work instructions and product schematics, in support of manufacturing operations, the costs would further compound.

 

The complexity involved in manufacturing and distribution requires the innovation of private cloud technology.  To transition from on-premise architecture, Epicor ERP customers looking to host their application in a private cloud need predictable costs and reliable budgets—a pricing model that does not involve surprise charges linked to the amount of data traveling into or out of the cloud hosting environment.  Egress can cause a budgetary mess, but you have the option to choose a pricing model that doesn’t watch your every download move.  Your company can have the reliability and innovation of private cloud without any of the hidden data egress costs that currently abound in the fine print of the cloud market.

 

 

 

 

 

Looking for help moving your business to the cloud?  Check out our private cloud environment:  EstesCloud Managed Hosting (ECHO).  We don’t have ingress or egress charges—your data is your data, and you are entitled to it!