Have you ever told a customer that you had product in stock – only to find that you couldn’t fulfill the order because the inventory was sold or used in production before you got to it? Or have you ever expedited-in material for an important customer or job, only to have that material used to fulfill a different order or produce a different job? Or maybe you resorted to hiding parts in your desk so that it doesn’t get used to “Rob Peter to Pay Paul”. Frustrating, isn’t it? That’s why Epicor ERP’s Fulfillment Workbench is a critical application for many of my clients.
It’s a common occurrence, in both the retail and manufacturing world, having too much demand for a limited supply and seemingly no way to manage the available inventory. Wouldn’t it be nice to “set-aside” material so that it’s available when it comes time to ship or produce the product?
Fortunately, Epicor’s Fulfillment Workbench has a great way to manage those times when demand exceeds supply. Using the concept of Reserve, Allocation, and Cross-Docking, the Fulfillment Workbench allows management to decide how to best utilize limited supplies in the face of current and future demand. The Fulfillment Workbench has the option to do “soft” and “hard” allocation. In Epicor Parlance, Reserve equates to “Soft Reserve”, and Allocate is equivalent to “Hard Reserve”. Cross-Docking in essence “Hard Reserves” material that is not yet received into inventory and keeps it from being used to satisfy demand other than what it is specifically allocated to.
The “Reserve” function places a “soft-hold” on available material and keeps it from being used to satisfy other demand. However, this “reserve” status is easily removed if that material is needed to satisfy other demand. Whereas material that is “Hard Allocated” needs management permission to be remove that status so it can satisfy a different demand.
Using the Fulfillment Workbench, you can manage inventory for all three sources of demand: Sales Orders, Jobs, and Transfer Orders (inventory coming from another inter-company location). The Fulfillment Workbench provides additional functionality, like Cross-Docking, sorting by priorities, allocation templates, and many more. By utilizing this incredibly useful tool, managing your inventory supply becomes a much less complicated task, and helps make for satisfied customers and efficient manufacturing personnel.
Do you have more questions on Epicor’s Fulfillment Workbench or want to learn more about the product?
What is Electronic Data Interchange (EDI)? In a much simpler five words or less definition, it means “data in, data out”. EDI is a toolset that interacts with an Enterprise Resource Planning (ERP) business software system that takes data coming into the EDI system, processes that data in the ERP, and sends that data back out to the originator (like a customer). You would think that a process which can be explained in only four words would be pretty simple, right? And it can be, if the proper care and attention is given to the EDI’s initial setup and further EDI strategy.
If a customer’s purchase order sent via EDI is being processed and has an incorrect date, or is completely missing a cell’s data, a simple mapping adjustment can be made to correct these sorts of issues. How can you ensure that your customer’s purchase orders are processed into your system correctly, if that attention to detail is not done? How can you be sure the pricing on your sales orders and the invoices that are generated are correct if your price lists are not correctly setup in your ERP system?
The EDI strategy and process is a digital mirror of how your system is currently setup and will reflect your strengths and faults back to your customers and suppliers. Think of EDI as a linked chain and your business is a boat being pulled along by a truck, which represents your customers or suppliers. If all the links are solid, that truck will pull that boat forever always getting to the desired destination, but if there is a broken link, the chain will start to fail and eventually break, allowing that truck to continue driving but it leaves the boat behind stranded in the middle of nowhere. To avoid being stranded and left behind, make sure that your chain is strong and durable by taking time setting up the ERP data properly, the EDI mapping, and running many tests before going live with customers. With the proper care and attention to your EDI solution it will not matter how large that boat or truck gets. Your chain will not break, it can handle it. Now ask yourself this, is your chain strong and durable enough? Or could there be some broken links you may or may not even know about?
Still not clear on the question “what is electronic data interchange?” Ask us anything, we would love to chat.
“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.
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.
Fans of 1970’s sitcoms and syndicated late-night television know the scene too well. The show was the long-running strip of analog nostalgia known as “Happy Days.” The episode was the Season 5 premiere. The setting was new: after four seasons of teenage angst centered around Arnold’s Drive-in, the show briefly moved its location to the beaches of California. The plot was abysmal: on some silly pretext, its standout character, Arthur “Fonzie” Fonzarelli, clad in a leather jacket and Bermuda shorts, water-ski-jumps a tiger shark, proving his tropical machismo for all to see. In retrospect, results were understandable; the show went on for many seasons, but never with the same pop and sizzle of the greasy diner days. The narrative had broached the limits of its own heuristic, and the damage was irreparable—the show had “jumped the shark.”
“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.