Brad Feakes, Author at EstesGroup

Dark Web Protection: Assessment, Awareness & Actualization

by Brad Feakes | Jul 1, 2020 | Managed IT Services, Network Security, Security

Business owners, especially those who have been through the challenges involved in a data breach, often hope the dark web goes completely dark — as in nonexistent. Wouldn’t it be nice if trending IT services, like advanced web scans and security audits, go out with the times? For now, the illegal realm of the dark web makes history every day, so companies must work nonstop to predict cyber threats and stay a step ahead of the hackers.

Dark Exposure

The dark web is an encrypted network of criminal intent. The deep web, conversely, provides a safe haven for your private information. By law, you need to keep most of your business data hidden from public view. You don’t want your financial information or your employees’ social security numbers exposed, and neither does the government. Whether you’re a manufacturing company in the heart of Denver, Colorado, or a distribution business with hubs across the country, you need hidden security — call it “dark web” protection — for massive amounts of corporate data. This means you’ll need to keep your real-time data and your backups in the deep web and out of the dark web.

The deep web is essential to privacy, compliance, safety and security. Like the illegal areas of the web, it’s built from non-indexed pages. Your company’s network is not revealed to random viewers because it’s kept hidden in the deep web — unless you suffer a data breach that exposes your information to malcontents.

To Breach Their Own

People feel vulnerable online and are somewhat aware that cyber danger is lurking. However, data breaches often originate in too much trust or in lack of communication surrounding network trust issues. Your users trust an email and get phished, or they trust “12345” as a solid password. Could the problem be that your users trust the company to protect them? Does your team assume that strong security solutions are already in place? Here are some of the common reasons, stemming from the trust factor, that your business could suffer cyber attacks:

spam email
weak passwords
unprotected mobile devices
delayed software updates

Mix these with user oblivion (or trust) and flimsy (or outdated) policies, and your company is at high risk for a cyber attack.

“A” for Security

Let’s now look at 3 “Easy A” ways you can create safe deep web data:

Assessment: A security audit is an excellent way to surface your network’s weak points. You can immediately see vulnerabilities and close openings that could bring in hacker traffic.
Awareness: Users often trust the system. Cybersecurity awareness training, such as a fire drill phishing attack, can educate users about current cyber risks and prepare them for real-time attacks.
Actualization: Enriching and enforcing security policies, updating hardware and software, advancing network protection measures — there are hundreds of ways to make advanced security a reality for your company.

When was the last time you had a security audit? Have you ever clicked on a suspicious link because of mental fatigue or, the opposite, heightened curiosity? When did you last test your backups? Install updates? Scan the dark web for your private data? Did you ever turn off multi-factor authentication because it was annoying? If you assess your system and close obvious gaps, train the users accessing your corporate network, and actualize things like security in the cloud and advanced endpoint security, you can leave the hacker chapter out of your company’s history books.

Are you ready to protect your business from the hackers?

Our team can help you with assessment, awareness and actualization.

Epicor BAQ: Returning Too Much of a Good Thing

by Brad Feakes | Jun 17, 2020 | Epicor, Epicor 10, Epicor Administration

The Epicor BAQ (Business Activity Query) toolset allows you to leverage the mounds of data that your system generates. But the problem with mounds of data is its volume—when we say mounds, we mean… mounds. As such, Epicor has built in a feature to its BAQ designer to limit the number of rows returned.

This feature prevents a “runaway query” from tanking a company’s performance. This functionality was especially helpful when I first delved into queries, as it prevented me from needlessly tanking my environment. Looking back at some of my early queries, they certainly were tank-worthy.

But for experienced Epicor users working with large datasets, this limitation can be… well, limiting. When a query generates a dataset that is more than 10,000 rows, the following warning message displays:

Severity: Warning, Table: , Field: , RowID: , Text: Test results are forcibly limited to 10000 rows to prevent the application server memory overload:

This can be immensely frustrating to Epicor super-users, for there are cases when the entire dataset needs to be returned, to gauge the efficacy of a given BAQ. In the past, the workaround to this limitation was to embed the BAQ in a dashboard, as the 10K row limitation disappeared when the BAQ was part of a dashboard.

But such an additional step seemed like an unnecessary contrivance—scaling the fire escape when all you needed was a step ladder.

Fortunately, Epicor modified the BAQ designer to allow the person creating the BAQ to modify the Execution setting that limited the number of returned rows. The steps to make this possible are below.

From the Actions menu, select “Execution Settings”:

Click the new icon to create the new execution setting.

This creates a new execution setting that needs to be defined. Then you can perform the following additional steps:

For the “Setting Name” select “RemoveTestRowLimit”
Set the Setting Value to “True”
Check “Persist In Query”
Click OK:

Thereafter, the BAQ will return all the available rows:

The execution setting needs to be defined for each query for which you wish to return more than the default number of rows. Make sure to save the query after the execution setting has been defined.

Ready for a quintessential query?

Successfully navigating the Epicor application is rarely a matter of taking one great leap forward. More often than not, it is a series of small, incremental steps. With Epicor BAQ, your goal is to take your data and turn it into information—without getting lost in the volume.

To learn more about Epicor management and administration, please watch our video on cloud ERP by clicking here.

Part Master Best Practices? Ask Brad

by Brad Feakes | Jun 9, 2020 | Epicor, Epicor 10, ERP

Epicor Part Master Q&A

Q: What are some of the first things that someone should consider when setting up parts in Epicor?

A: We could have a long, harrowing conversation about part naming conventions, but arguments over part naming philosophies have ruined more friendships than heated discussions over the latest Star Wars movies—so I’m going to leave that one alone. In terms of Epicor part master setup, probably the first and most important consideration is the Non-Stock checkbox. The Non-Stock Flag is one of those “big-little” checkboxes that drive a ton of downstream behavior. This one flag will affect how a part will be handled on a sales order, a purchase order, and a job, whether as the top-level assembly or as a component material, and basically determines whether the related transaction will be processed through the system’s inventory module or processed directly in a “to-order” manner. This flag is fundamental for companies looking to operate in mixed-mode manufacturing. Most companies, even companies working in highly-engineered environments, rarely intend to manufacture all components “to-order.” Often there are economies of scale to consider, and components can be used on a broad array of higher-level assemblies. As such, some parts will be handled in a “to-order” manner, while others will follow a traditional inventory-based approach. For that reason, we have to place special consideration on the setting of the Non-Stock flag.

Q: Phantom BOMs are a topic of disagreement—do you have any recommendations on the use of Phantoms?

A: In general, a phantom is a part that carries a method of manufacture, but is not itself manufactured discretely. Rather, the part “explodes” when it belongs in a work order—the top level part disappears and is replaced by its components. Phantoms really are system-specific, for the rules for handling phantoms differ by ERP system. Within Epicor, a few general rules could be suggested when deciding if a part will be flagged Phantom BOM. Firstly, if a part is stocked, it should not and cannot be flagged Phantom BOM, as it is assumed that a phantom part not be stocked. Also, if a part is made independently from its parent, in a different place and at a different time, it should not be flagged Phantom BOM—it should be either a material or a subassembly, so its manufacture can be managed independently from its parent. When component parts are made at the same time and place as their parents, I’ve seen customers use phantoms to manage the components, to simplify production, while retaining the basic product structure defined by engineering.

Q: More specific to Epicor, the Pull-as-Assembly flag is a source of confusion and disagreement—do you have any recommendations on the use of the Pull-as-Assembly flag?

A: A Method-of-Manufacturing defined for a Part Revision can differ significantly when you pull the revision into a Job and get details. These differences are largely due to the Pull-as-Assembly flag. This flag essentially defines whether a component part will be manufactured independently from its parent part, or as part of the same Job as its parent, as a subassembly. One can suggest a few principles when choosing to flag a part as Pull-as-Assembly. If the part is stocked, do not flag the part Pull-as-Assembly, as you will be supplying the material from your on-hand inventory. If the component part in question is Non-Stock, and the intent is to supply the materials through a separate Job, uncheck the Pull-As-Assembly flag. But if you wish to supply the Non-Stock part with a subassembly, allow the Pull-as-Assembly flag to remain checked.

Q: Can you explain how the settings on the part master flow through to a bill of materials and ultimately to a work order?

A: It’s easier to explain this with a visual…

Are you looking for answers to your Epicor questions? Part Master or otherwise? Follow these links, and our ERP consultants will help you find answers:

Please fill out the form below to get a white paper on Epicor Part Setup and Best Practices sent right to your inbox!

Get an Epicor ERP Part Setup & Manufacturing Best Practices Whitepaper Today

Epicor Engineer-to-Order at Your Service

by Brad Feakes | Jun 4, 2020 | Epicor, Epicor 10, ERP

The Role of Order Entry in ETO and CTO Environments

Epicor Engineer-to-Order environments are their own special breed. Based on an almost infinite notion of product variability, their business models are hard to shoehorn into an ERP system. I once had a job shop employee describe his product variability with ultimate pliancy: “If they want us to wrap it in toilet paper, we’ll wrap it in toilet paper.” That would be a costly proposition these days. In light of this, I often get requests from my customers for “best practices” in handling various Epicor ETO environments.

The If-Then-This-That of E10

When it comes to questions regarding Epicor Engineer-to-Order, I always preface my answers with a de facto “it depends” before diving deeper into all the variables at play. Best practice for one company might not be the same for another. Ironically enough, it is almost as if I need to configure an answer for my customer, and discussions tend to take on the following format: “If this and that and/or this or that, then do this…”

One such question came to me recently from an Epicor customer, with regard to the role of Order Entry/Customer Service employees in an Engineer-to-Order organization. The company was debating the benefits and liabilities of having their inside sales staff perform rudimentary engineering activities as part of the entry of a sales order. In such companies, product details tend to arrive comparatively late in the quote-to-cash cycle, and the folks responsible for pounding in the orders often find themselves as the purveyors of this information, as received from the customer. These changes often require tweaks to manufacturing methods for a given product, and companies struggle in determining who should own these changes.

The In-the-Know of ETO

Who do you know on your team who could best own these changes? As I’ve noted above, “It depends.” But what does it depend on? I can think of a few of the variables that you would consider when deciding whether Order Entry should handle Engineering tasks:

Technical efficacy and product knowledge of the Order Entry team: The higher the efficacy, the more liberties you can give someone to alter MOMs when quoting. In some environments, where the estimators are highly technical, Engineering is strictly focused on new product development, and Sales owns what is sometimes called “project engineering.” In other environments, this role is staffed by folks in the engineering department.
Complexity of the product: The higher the complexity, the less you’d want Order Entry muddling with the engineering of the product. In low-complexity job shops, I’ve seen order entry or customer service staff handle the engineering implications of order changes.
The implementation of Epicor: There are a number of ways in Epicor to get from a Quote to a Job, and few companies in the CTO/ETO world do it exactly the same. Depending on the overall architecture, the MOMs in question might be modified through the quote module, the part master, or in the jobs themselves. This architecture will affect the processes needed to make changes: do you need to modify MOMs through the quote, or will you perform modifications to the Part Revision through the engineering workbench? Quote MOMs are much more apt to be modified by sales staff than are part master records.

In general, I have found that in most environments, Order Entry is focused on specifying product characteristics, features and options and that Engineering is responsible for defining the engineered product to satisfy these requirements. I often recommend that Engineering be the party responsible for what we normally understand to be the engineering function.

This model works well as companies sufficiently standardize their product offerings to support Epicor Configure-to-Order business models, as the delineation between features and options vs. product design are more pronounced in these environments. But there are certainly cases in which the composition of the entire sales staff, the nature of the product, and the system architecture determines that Sales is the optimal department to make these changes.

Are you a company in an Epicor Engineer-to-Order or Configure-to-Order environment? For help with your Epicor implementation or upgrade, please reach out to our team.

Hidden Ransomware as a VM Valentine (Video)

by Brad Feakes | May 27, 2020 | Managed IT Services, Network Security, Security

Apparently ransomware is now installing a virtual machine inside the hacked computer in order to avoid detection. We’ve entered a new phase of devious behavior! How will your company avoid the new forms of ransomware hidden in your system’s shadows?

Hackers Exploit Your Pixie Dust Trust

Please make sure your users are safe! I think the only way to avoid all this malefic malware is to adopt a Zero Trust attitude, bringing in an IT expert with a Zero Trust philosophy if necessary. Think of it this way — do you let a technician into your home to work on the AC unit, just because they have the right shirt on? Did you call them? Are they “safe”? Do they take their shoes off and keep their N95 masks on? Some of us will allow them in, some will not. At this time, I have immune-compromised folks at home, and that technician isn’t coming in. I’ll live with a busted AC unit for now — it’s not worth the risk.

Is your PC worth the risk to allow untrusted software in and run whatever, wherever it wants, with whatever bugs it brings with it? I think not. When it comes to the technology that enables your business, it can be easy to trust your users because you see them as good people, as your helpful team. But the magical thinking of an IT fairy tale will not protect your team from hidden ransomware dangers, especially those that appear deceptively dressed in a VM. You can trust your team without trusting their machines or their software.

Made in the Shade

Are your systems safe from ransomware hidden in the shadow of a VM? Companies enabling remote connectivity for their teams may have put their data at significant risk by taking shortcuts to ensure business continuity. Rushed IT policy often creates vulnerabilities that hackers can easily exploit. Malware can get into your network by posing as something friendly to your system. Hidden ransomware, now lurking as an amicable virtual machine, creates troublesome tenements for remote teams.

Ghosting the Hackers

Hidden malware is only one challenge you have when connecting your teams to company data. Fortunately, remote access and remote control utilities, when done properly, are tools that allow companies to connect home users to corporate data securely and efficiently. You can keep your team safe from malicious valentines, even when they appear in the form of a friendly VM. With protective IT policies in place, including a Zero Trust approach to the machines that make your business run, you can ghost the bad guys trying to unlock your data and prevent their hidden ransomware from accessing your system.