“So long as a man’s eyes are open in the light, the act of seeing is involuntary.” – Herman Melville.
The idea of vision is a pregnant metaphor, full of intimations and implications. In its verbal sense, vision refers to the act of seeing, of perceiving the world around us. As a noun, one’s vision has more to do with a sight into the future, to a place where one wishes, eventually, to reside.
The idea of vision, in both senses, tends to suffuse the jargon of everyday business. When customers come to us, they are not just in search of the domain knowledge related to a given enterprise system. They come to us looking to understand how to best integrate the use of a system with their particular business climate, such that they can best achieve their strategic goals, their vision. Customers tend to be strong in understanding the opportunities available to them. That is, they are able to formulate a vision for the future. Customers often struggle to put into place the processes, practices and procedures that allow them to achieve the vision that they’ve formulated.
After a losing year, the CEO of a company for whom I once worked, remarked (only half-sarcastically) that our company was “perfectly structured to achieve the results we’ve achieved.” That is, our company had a strategic vision, but our actions failed to achieve it. Our actions had achieved a different (and less profitable) vision. And I would offer that the reason for our failure to achieve our vision was in our inability to remove the paradigmatic lenses that colored everything we perceived, and ultimately drove our actions.
Einstein famously described insanity as the expectation that the repetition of same behavior will yield different results. In that light, I have worked for and worked with a few companies over the years that have gone insane at one point or another, seeking to achieve new strategic goals using the old methods that had worked in previous generations. The logic behind such an approach has some justification – if it ain’t broke, don’t fix it, right? Such a an approach seems fine until a losing year leaves the CEO glowering down at you, over his horn-rimmed spectacles. The problem here is not one of vision, but of lenses. A company’s lenses serve as the paradigms that cement the company’s habits, culture and means of solving problems. As time goes by, and circumstances change, these lenses may begin to skew reality. In the most dysfunctional of environments, these lenses may even warp perceptions as to encourage the most maladaptive of business behaviors.
As ERP implementation consultants, it is of necessity that we come into a business from the outside, unaware and unaccustomed to the perspectives that shape the business in question. As consultants, we also have the good fortune of being exposed to many companies, in different industries, working with various products, catering to disparate markets. The expectation here is that our ERP implementation strategies across such environments gives us a cadre of different perspectives to use, and that we should be able to use these to the benefit of our client when they develop a vision and strategy. Because of the natural ignorance to a customer’s cultural worldview, and the access to alternative perspectives, the goal of a consultation effort has less to do with the use of an enterprise system than it does with the opportunities for a fresh perspective. The implementation of a new system becomes a means of surfacing and understanding the customer’s existing lenses and the consulting effort becomes an opportunity to try out new lenses, lenses that can be leveraged to formulate new processes and practices, that address changing business landscapes, and help companies achieve their respective strategic visions, in so doing.
So what is your vision? Come talk to us at the Estes Group, and see if we can help develop a vision and strategy to make them into a reality.
Epicor ERP is a powerful platform with thousands of manufacturers using it to run their businesses. With power often comes complexity, and that’s been the case with earlier versions of the system. There is no perfect ERP system, and the ever-changing balance between functionality and usability is a constant series of trade-offs. Epicor ERP Version 9 often required multiple servers, performance tuning was critical, it had a Progress data base layer, even when running on SQL, and the user experience was challenging. A personalized Epicor ERP demo is the perfect beginning to your Epicor consulting journey.
Epicor invested $25M in Epicor ERP Version 10, developing a completely new platform. The system was written and optimized for Microsoft .NET Framework and the Microsoft Data Platform, including Microsoft SQL Server. Users will experience a big increase in performance (over Epicor 9) and find the system easier to manage.
What you’ll see in your Epicor ERP demo
According to Epicor, here are the Top 5 user ERP system experience enhancements for Epicor ERP 10.
Responsiveness – Performance has doubled and scalability has quadrupled across virtually all aspects of the system. ERP 10 is much more hardware efficient, which dramatically lowers hardware costs.
Simplicity – ERP 10 services are hosted purely using Microsoft Windows® components, including Internet Information Services (IIS) and Microsoft .NET. An all new management architecture makes deployment and migration much easier.
Mobility – Touch-enabled devices are now supported for a new navigation system and a re-architected Epicor Web Access (EWA) browser client.
Collaboration – Epicor Social Enterprise is included with ERP 10 and is a new way for ERP users to interact with each other and with ERP data.
Choice – ERP 10 can be deployed on premise, hosted, or access via subscription. It is also much easier to create a high-performing virtualized infrastructure.
The current version, Epicor 10.2, introduces some really exciting capabilities that you’ll see in your ERP demo, including Active Home Page and Epicor Data Discovery (EDD). Here are some highlights:
Developed using the latest web standard, which makes the system mobile-friendly and responsive.
Manufacturing role-based KPIs, examples: Percentage of Jobs without Scrap or Non Conformance, Manufacturing Hours and Indirect Hours.
Finance and Supply Chain role-based KPIs, including: Price Variance, Open PO Count and Amount, and Negative Inventory Items/Out of Stock.
Customization capabilities to modify out-of-the-box KPIs or create entirely new ones based on existing or newly created BAQs.
Epicor Consulting: How can we help?
What do you want to see? Our Epicor consultants will show it to you. The best way to get an in-depth look at the new Epicor 10.2 functionality is to experience it firsthand! Our Epicor consulting team can give you a demo of the full system, or one of our ERP specialists can walk you through a specific module. We can help you with project planning, including Epicor budgeting so you experience increased revenue at every step of your ERP upgrade. Your personalized Epicor ERP demo can even show you the newest managed ERP hosting capabilities.
During the rush to select, acquire, and implement an ERP application, companies often license modules that they do not end up utilizing by the time cutover rolls around. Once the booming, buzzing confusion of going live has diminished, companies frequently review their suite of modules to determine whether some second phase enhancements can be implemented, both to benefit their organizations and to make use of the money spent on licensure. Epicor’s Service Connect application often falls into this second-phase category. It is not uncommon for Epicor customers, fresh off an implementation, to come to us and ask, “So we own Service Connect—now what is it good for?”
Service Connect is a multi-purpose tool in which a user can automate business processes and create application integrations to aid a business in its day-to-day processing. By using documents as its primary interface, Service Connect can convert data from one application into a form another application (or internal process) can understand. It uses industry-wide technologies to exchange information between applications or business processes based on data mappings and data manipulation.
A business may benefit from the use of Service Connect for many reasons. Some reasons include:
To automate an internal process by removing the human interaction from a process. For example, a company might use Service Connect to automate the entry of a Sales Order, based on an external trigger, or have the lines of a Sales Order automatically ship when the Sales Order has been closed.
To have one application pass information to another application, in order for the second application to process the data. An example of this would be billing information from a project tracking application to an accounting application. This would allow Accounting to bill for services rendered on the project.
To respond back to an application with updated data after a business process has been completed. This would keep two unrelated applications in sync. For example, if an item were to be requested to be shipped in an inventory application, the data would be passed to a shipping application to be shipped, then once shipped the tracking number would be returned to the inventory application.
To send emails requesting tasks be executed before another step of a business process can be completed. An example of this would be sending an email to a Purchase Order manager to approve a Purchase Order over a specific amount.
To assign tasks to be completed to users, to help manage the flow of a business process. By using Service Connect Task Monitor, instead of emails, a task can be assigned to a specific user and the business process halted until the user completes the task. This could be used for setting up project service billings approvals or Personal Time Off requests.
The automation and orchestration capabilities of Service Connect improve processes within the Epicor application and improve interactions between the Epicor application and other applications. Customers in need of such capabilities find that by dusting off their Service Connect license and connecting with some skilled partners, they can extend the scope of their enterprise application and yield tangible business benefits in so doing. The Estes Group has a wide breadth and depth of experience in Service Connect, and has been helping customers to get the most out of their investment. Looking to take your enterprise application to the next level? Come check us out—we’d love to talk with you and see what’s possible.
“Jumping the shark” has come to take on a broad meaning, extending beyond popular culture. Wikipedia defines the term jumping the shark to refer to the moment when a brand, design, franchise, or creative effort’s evolution declines, or when it changes notably in style into something unwelcome. Jumping the shark is the moment where an entity has reached its proverbial apogee and thereafter inevitably and irrevocably begins its downward slope. This happens with TV shows, with athletes, and, unfortunately, with ERP applications when you don’t get an ERP software upgrade. So why update your software?
I once worked for a company that implemented a hip and snazzy Tier 1 ERP system in 1999. Over the next ten years, the package implemented was resold, re-branded, and reworked multiple times; to such an extent that it no longer resembled its antecedent. Moreover, the company had done little to keep up with these changes, and after ten years, the system it implemented had essentially jumped the shark. In 2009, the company moved to an equally hip and snazzy ERP system, but with upgrades—now it had a Microsoft .Net user interface and a SQL Server database. There was this iffy Progress OpenEdge middle layer, but even still, the overall package seemed bright and beaming, compared to the dim hue of the application it replaced. The application implemented in 2009 was Epicor’s Vantage 8.03 ERP system.
Now, as we near 2018, companies continue to question the systems implemented in the first decade of our new millennium. No longer the strategic advantage that it was at cut-over, companies’ enterprise systems have slowly morphed into liabilities when trying to reconcile ERP structure vs. company structure. And as digital transformation increasingly becomes the norm, companies can greatly benefit from understanding whether its ERP system has outlived its usefulness to the organization. Below are a number of ways to know whether your ERP system has jumped the shark, and the reasons why you need an ERP system upgrade:
You’ve lost track of the number of major releases between the current software version and the version you are currently on; or the number of service packs outnumber your fingers and toes. Does your current application have a suffix in the range of 6.0 or 8.0, while the vendor is peddling products with a moniker broaching double digits? That might be a problem.
The ERP vendor from whom you purchased the software has since been acquired by another ERP vendor. When vendors merge, application consolidation often follows. Typically this involves the sun-setting of certain applications in favor of others, which means that customers of discontinued applications may find themselves tied to a dwindling thread of support. When mergers or acquisitions happen, understand the implications to your enterprise application—it may involve new investments.
The ERP product being used has since been re-branded. Epicor’s Vantage 803 has been re-branded twice—first to the Epicor 904/905 series, and now to the ERP 10 platform. Vendors generally offer migration paths for existing customers when re-branding products. Often, this is because application re-branding generally coincides with significant infrastructural and functional changes to the application itself. Explore the migration path options—perhaps it will take you somewhere.
Is your current application written in a propriety language that is no longer supported? Or was it built on a server platform that you no longer want to support? Or does it use a database that you are no longer comfortable with? Perhaps it’s time to find a better fit.
Your company’s direction relating to application, database, or operating system architecture has changed dramatically since the original implementation. Sometimes the software has kept up but the business has changed. In these cases, a re-implementation might be in order.
To customers of Epicor’s legacy 803 and 905 platforms, the answer is clear: the shark has been jumped—it’s time to change the channel and upgrade. Are you ready to upgrade? Talk to us today!
With the festive season charging forward like a white-tailed deer dodging a hunter’s shot, I began to reflect on some of the holiday gifts I had received as a child. I remember finding my brightly colored box named for me, ripping through the wrapping paper with glee, anxious to find just what was bottled up inside the cardboard box of the year—normally some elaborate plastic play-thing, composed of more components than angels on a pin. Pulling open the cardboard gates, I routinely discovered that the contents of a box never quite resembled the shiny images on its outer face. That is, there was one pivotal phrase that stood between the receipt of a gift and its actual usage: “Some assembly required.”
That single phrase was as impassible and looming as the Sphinx. Upon reading this riddle, I would rush to my father and beg him to figure it out for me, and in typical holiday spirits, he would lay his eggnog aside and curse his way through the necessary assembly. The lessons learned through these experiences stayed with me into adulthood. Now, as I’ve perused the aisles of the local box shop, looking for a suitable gift for my own, I’ve quickly learned to spot the familiar warning—and move on. I’ve become known as the parent who has bequeathed gifts like modeling clay for the holidays. It encourages the imagination, I’ve claimed. Moreover, there is no way for a parent to botch its assembly!
With Epicor’s version 10.2 similarly cresting the horizon like a jolly old man in a flying toboggan, I’ve come to notice how customers utilizing Epicor’s legacy Product Configurator react to the idea of an upgrade in much the same way I’ve reacted to a 600-piece dollhouse—they duck into the next aisle. In any version, Epicor’s Product Configurator is a complex module—it is part functional setup, part development toolkit. And companies spend a lot of work in developing the configurators that will support their business requirements. That is, there is a lot of assemblies required, once this gift is unwrapped. And the idea of reimplementing Epicor 10 configurator for a new version feels, to some customers, like their dollhouse just got smashed, and they are required to reassemble it again, only now with a new set of assembly instructions.
In spite of these understandable concerns, I believe Epicor’s 10.X configurator platformis a tremendous improvement to its previous iterations: it is more scalable, more flexible, and allows for better-designed solutions that yield a better end-user experiences. And try as I might, I can find no CPQ solutions made of modeling clay…
While there are no easy instructions when it comes to upgrading Epicor 10 configurators, I have found, in working with customers, that there are a few lessons that we’ve learned, lessons that could be thought of as “reassembly instructions.”
A few might include the following:
I have found that it benefits customers to run an early initial trial upgrade of their existing Epicor database, strictly for purposes of reviewing the upgraded configurators. With each new version of 10.X.XXX, the upgrade process gets tweaked and improved, so issues upgrading configurators in one version may be resolved in another, and the upgraded configurators may be sufficiently intact, as to constitute a decent starting point from which to begin their efforts.
In terms of business logic, companies benefit when they look for opportunities to utilize UD methods in lieu of the on-leave event handlers in legacy versions. These can be a helpful way of centralizing code, and even a nice way just to pull it out and give it a clear and distinct definition, which allows for more logical designs and greater maintainability. In terms of Method Rules, companies should look to consolidate the many individual rules from legacy versions into single statements in 10. In the Epicor 10 configurator rule designer, the option to “execute specified expression” allows for great freedom in developing blocks of code to update multiple fields at once. This allows customers to consolidate all of their efforts into a single place, which usually makes for better maintainability.
In most cases, the development of a solid C# skillset is a must for working in configurator 10.X, in much the same way that Progress ABL/4GL skills were central to Epicor’s legacy configurators, particularly if the configurator being upgraded has a lot of custom code to manage its business logic.
Converting code need not require a .net savant. There is the web page for converting 4GL to C#–that can get you in the ballpark, one block at a time. But for the absolute novice to C#, it helps to have someone available who has worked in C# and Progress-based configurator environments.
C# has a few particularities that are critical to handle right away, as they will prevent a block of code from passing syntax check. These include:
The use of a semicolon: all statements end with a semicolon.
Braces: multi-line blocks of code (such as if-then blocks, switch statements, or for each blocks) are wrapped in braces (“{}”).
Case Sensitivity: C# is a case-sensitive language. That is, the .net compiler will interpret “cmbPartNum” to be something other than “cmbpartnum.” This is an infuriating peculiarity for someone coming from a Progress environment, where the case did not matter.
Object Orientation: in the .net platform, interaction with any program involves the use of object properties and methods. This involves commands that differ somewhat from the legacy design. For instance, a command to update a field in 10.X, you might look like ‘Inputs.chrPartDesc.Value = “lalala”’ whereas the same command in the progress-based configurator would look like “chrPartDesc = ‘lalala’”. Understanding these small differences can go a long way in making steady progress in configurator conversion.
I find it a good approach to have a customer review their existing configurator code base prior to the upgrade, and identify each unique king of logical activity they perform. This might include, but is not limited to the following:
For each loops
Switch Statements
If then else logic
Reading UD tables
Writing to UD Tables
From there, the customer can develop a solution catalogue for addressing each unique code construct—how the each unique activities performed in Progress 4GL would be performed in C#. The idea here is to document each code conversion best practice, so you don’t have to reinvent the wheel the next time you encounter the same construct in another configurator.
So, with the festive season approaching, consider giving yourself the gift of an Epicor upgrade. Yes, there is some assembly required, but not as much as you might think, and once assembled, it will keep the kids busy for the next ten years. Moreover, have you ever tried to pick modeling clay out of your carpet?
In some ways, enterprise applications are like professional athletes.
There is a period of promise. There is a period of inconsistent, but incremental growth, which culminates in a period of eminence and excellence. Then, there is the period of slow decline, of lowered expectations, and eventually, the time for a replacement. For every Joe Montana, there is a Steve Young, for every Brett Favre, an Aaron Rogers. But ERP vendors have one advantage that us mere mortals lack. While it’s terribly difficult to reprogram a creaky knee or a sore arch, it is possible to reprogram an enterprise system.
To paraphrase Marcellus Wallace,
Some athletes think their bodies will age like wine. If you mean it turns to vinegar, it does. If you mean it gets better with age, it doesn’t.
As an Epicor ERP implementation consultant, I’ve stepped into many organizations whose business systems, to keep with the culinary motif, have more gristle on them than a bucket of secret recipe chicken. Their basic structure is like a freezer-burnt fry hen. And since it takes more spice to make an old bird taste good, their aged systems have become harder to maintain, harder to support, harder to extend or reconfigure.
The secret recipe I recommend to these Epicor ERP implementation clients is to begin with a new bird. It is possible to take an aging platform and replace it with a more current, more robust platform, one fit for future endeavors.
It is also possible to do all of this while still retaining the original flavor—competencies, and capabilities of the application that have differentiated it from its competitors. Epicor spent the last few years doing just that—replacing its aged legacy architecture with its version 10 application: a full-stack Microsoft platform, a platform that makes it more scalable, maintainable, and versatile than it ever was. For Epicor customers who haven’t made an ERP software upgrade and are living on its legacy versions, a migration path has provided them with the programmatic equivalent to a Canterbury spring—the fountain of youth.
Still, many Epicor customers are hesitant to make the jump from their legacy 803 or 905 version of the software to its new version 10 manifestation. In working with customers, I’ve found that companies often have a few distinct challenges preventing them from making the jump:
Epicor ERP Customizations:
Companies that have significantly customized the application in its legacy version fear that it will be impossible to bring them up to version 10 without chaos. They fear that Humpty Dumpty will not come together in 10, as he had in the legacy version.
Epicor ERP Product Configurators:
Epicor’s Product Configurator module is a challenging and complex module to master, in any version. With the advent of version 10, the architecture of Epicor’s Product Configurator module changed dramatically. Companies that have dialed in their legacy configurators may shirk from the effort to redesign the wheel in a new version.
Epicor ERP Crystal Reports:
With the move to a Microsoft-centric stack, Epicor moved from the Crystal Reports to SQL Server Reporting Services (SSRS) as its reporting platform. Customers comfortable with Crystal may be hesitant to go through the effort to replace their suite of custom Crystal reports with their SSRS concomitant.
But the challenges in moving to version 10 are not insurmountable. In a recent webinar, we discussed some of the methods that one could employ to overcome these challenges. In subsequent posts, I will further discuss these methods. Our goal at the Estes Group is to make it such that the benefits of moving to Epicor’s version 10 platform outweigh the risks and the costs.
So if you’re on a legacy version of the application, and if you’re tired of running on an old set of drummies, come check us out—we’d love to talk with you, and help get your company running again.
