Meta

With grateful thanks for sparkling input from former Oracle colleagues Cindy Sayers, Mark Nix, and Leanne Harper. This is an answer I provided in an Executive Forum discussion recently at ExecRank.com, as a follow-up to their Software and Internet Advisory Council meeting.

In short, it’s no different from on-premise software – the customer owns the integration problem. Software from different vendors do not usually share the same “Lego” blocks of integration, even when they have “open API’s” and “web services” enabled. Only when those services and API’s use the same infrastructure do you have a chance that the vendor has made a successful integration, and then, you need to consider whether that integration solves your particular needs.

In an integrated Cloud ERP suite, all the applications from that one vendor should be talking to each other, the same as with on-premise applications such as ERP. If you want to change those integrations, the vendor should offer integration tools and services you can use. If this is a Cloud suite, then you’ll like need a Platform as a Service (PaaS) platform that contains those tools. Recently I’ve begun hearing about “Integration as a Service” offerings that are intended to connect a vendor’s Cloud and on-premise applications, and even 3rd party applications that use the same integration technologies.

In the end, it will probably come down the customer who owns the integration. Simple or point-to-point integrations offered by vendors are usually not complete (that is, covering all the required integration points), or don’t move all the data a customer requires between the applications (only a subset of the data has been integrated), or it simply doesn’t work the way the customer wants it to work. So the customer will do it themselves, or hire consultants to write the integration.

Anytime you have multiple vendors, such as a Cloud situation where different applications come from different vendors, (or the same in an on-premise situation), vendor supplied integrations might work in a perfect world. But you still have the issues of different update schedules from different vendors and whether one vendor’s update is validated against every other vendor’s then current releases (and there are often several current releases that need to be maintained on integration from every vendor). The multi-to-multi puzzle is simply not going to be cost effective for any one vendor to maintain. Recently I noticed that my Quicken was no longer accepting certain types of downloads from banks, or importing certain file types.

And, if you did get the integration to work, you’d find you have a master data management problem: who owns the ‘real’ customer, vendor, item, or employee master file when multiple cloud (or on-premise) software products all contain their own version of one or more of those files? Again, more integration work, this time likely requiring “MDM” tools as well.

And beyond that, customizations and configurations in any of the cloud (or on-premise) solutions makes the integrations that much more challenging. Is one system’s “sales order” the same as another’s? After decades of EDI (electronic data interchange) it’s still a challenging world when one dominant vendor or company imposes their view of the world on everyone else, such as Wal-Mart did some years back, or the top tier automotive companies did on their entire supply chain.

In the end, if everyone is satisifed with one-size-fits-all “best practices” built into Cloud software, how does one company use technology to differentiate itself from another company? If the race to best practice is shortened and made easier, where is the competitive advantage? And how do you implement transformational technology into a Cloud delivery model that gives everyone the same software?

Many software implementations take nine months or longer, resulting in higher internal efforts and costs, a delay of return on of your investment, the risk of obsolescence of what eventually gets implemented, and even a competitive disadvantage by falling behind faster moving competitors.

Much has been written about the processes required to execute the selection, how to manage and deal with vendors, required internal staffing, and proper communications.
Today we will learn about reaching towards the expectations of your executives.

Managing the scope of the selectin and implementation with regard to what will help your business is key to an effective system selection. You must identify the executive expectations for the system’s ROI. Is your system selection directly related to that ROI? Are the project plans and tasks targeted to achieve that ROI? Are your accomplishments being measured against that same ROI?

Make sure that your project is being driven against the expectations of your executives. For example, those could be

Whatever they are, make sure that your system selection evaluation is focused only on accomplishing those objectives.

Begin by articulating what those goals in more detail:

How do the executives plan to accomplish the corporate mission? By gaining market share? Being first to market? Becoming a global competitor? Having the best customer satisfaction?

How do the executives envision driving up revenue and maximizing profits? By developing new sales channels? Lowering COGS and/or S&GA?

What are the techniques they plan to use to minimize risk to shareholders and capital? Through better regulatory compliance? By extending asset life cycles?

The answers to these questions will must be expressed in measurable terms, or else you won’t know if the implementation was successful. Discover the right measurable quantitative or qualitative terms, whether they be in dollars or ratio‘s, survey results, or perhaps the executive compensation metrics in the 10K report.

For example, a goal could be to reduce inventory by 5% or by $50MM year over year. Or improve Quality by lower Product “A” rework incidents by 10%. Or raising average annual customer quality survey scores to 7.5 (out of 10) and then by 0.2 annually. Or by increasing product upsells by 20% or taking orders in 2 minutes or less, or with fewer clicks.

Know what you’re going to need to measure, and understand how the new system will support these measurable goals.

Examine software features that are critical to achieve the executive expectations. For example, what will help

Reduce inventory levels?

Improve quality results?

Examine features critical to process improvement or transformation?

Be specific about what is required so you can link the executive expectations to the software selection.

Finally, rank the executive expectations. Some are most important … some will be easier to accomplish … some will be a stretch. Agree on an achievable set of expectations to balance the

Effort to achieve

Level of reward

Risk of failure (or probability of success)

Beware that a common pitfall is to only focus only upon easiest, fastest goals; that is a danger you must avoid as the easy returns are not usually the ones that make a real difference.

So, the net result at this point is that you have the list of “must-have” or “required” features. The list is defined deep enough to reveal critical features for executive expectations and for business improvement or transformation. Vertical indusry requirements should be the baseline. References and conference room pilots will ensure the software does what you want and expect it to do.

All other features are simply “foundational.” “Foundation” and Nice-to-have features are not your focus. Please do not spend your time in the selection analysis checking on features that all of your software candidates should be able to do, such as making balanced G/L entries, supporting at least 12 G/L periods, providing 3-way match of PO’s to AP Vouchers, etc. None of these will drive your results or “move the needle” unless you are converting from Quick Books or a manual system – and then, likely all the systems under consideration will perform all of these ‘foundational’ functions.

You should, of course, use a “usability” review or demo, and reference calls, to confirm that all the “foundational” functions work as advertised. You likely have a new generation of executives who have grown up under ERP and are looking towards the differentiating features.

This means you can “ditch” those lengthy RFP’s (requests for proposal) that are chock full of “expected features.” This is simply not a helpful exercise, but rather is a clear waste of time and money for you and the software vendors. “Foundation” features are just that – part of every quality modern system foundation. Focus only on the critical features for your industry, your business goals, and your future growth and expansion. This will let you stop making software decisions based on long demo’s or lengthy “scorings”.

Recognize that partner products will usually complete the solution, and must involve proven integration with strong, well-known and supported integration tools. Also, be sure there is a clear source of support and trouble resolution between the various vendors. You don’t want to be the clearing house for support issues!

Now that we’ve agreed to focus on the critical functions that will differentiate the software vendors from one another, there are three keys to making the right selection for you:

Software Usability.

Software Architecture.

Corporate Technological and Financial Viability.

Be sure to include all the partner solutions that make up the total “stack” in this analysis. One weak link can ruin the entire party!

To verify software usability you dig into actual experiences through customer references. At least one reference visit must be on-site with the reference customer. As far as demo’s go, you should love a demo, or else the software vendor is failing miserably at a core component of their sales process. Rather than do long demo’s, you are better off with a paid proof of concept as a more valid test of the required software features.

To pick the right software architecture, determine which of these three business environments fits you best, and only pick software from a vendor that matches your environment.

IF your business processes are fixed or change very slowly, the consider a “mostly there” base point system that is easy to customize. You should expect to live with this adjusted base system for a long time. In my opinion, MicroSoft Dynamics is a classic example.

IF your business processes are very complex, but won’t change much over time, then consider a system with vast features and configuration options, and expect to live with this adjusted base system for a long time. In my opinion, SAP is a classic example.

IF your business undergoes constant change, or is growing rapidly beyond your ability to accurately forecast future requirements, then you should only consider a system clearly capable of on-going growth and change. Plan on staying “current” with vendor releases by using with modern upgrade practices. Take advantage of application modules not in your initial implementation. And, take advantage of technologies not needed today, such as the “Internet of Things.” In my opinion, Oracle’s JD Edwards EnterpriseOne software is a classic example.

To confirm corporate viability, both the corporate and software roadmaps are critical. This area requires extra digging and confirmation, since “talk is cheap.” The future system life expectancy SHOULD be 5, 10, 15, or even 20 years unless you plan to exit your business sooner. The underlying software technologies should point to a long future. Find out through references what will be the required human and technology resources to maintain the system. And be skeptical of closed, proprietary technologies; so many have become dinosaurs in the past.

A long corporate viability roadmap is an absolute must-have condition. If your vendor is a public company, dig into the 10K SEC reports. Consult your CFO to discover if there are financial viability issues. Understand “exit strategies” for vendors funded through Private Equity. And beware of Wall Street and analyst reports that are paid for explicitly by vendors, or where the vendor has a cozy relationship with the analyst. Corporate viability analysis may be the #1 mistake in software selection.

Everyone needs to be part of this project, so don’t hide it off with a small team.

With the work you’ve done so far, it should be “easy” to find your final three vendors (if there are three) because they each will have:

Corporate viability

References for software usability

Budgetary limits from initial quotes

A successful “navigational” or “sizzle” demo in which you expect to be “wow’ed”

For your ‘real’ demo, use a scripted demo. Scripted demo’s put you in charge of what you want to see – or what the vendor can show. Realistic vendor data is fine; they don’t need to replicate your customers, items, bills of material, etc. You are concerned with the business process scenario; customer friendly data doesn’t change the functionality. Rather, the vendors must show every critical feature. Do not take simple “yes” answers when judging critical features.

A long time ago, Sun Tzu said “In war, then, let your great object be victory, not lengthy campaigns.” If you set up a process where three vendors each provide a 2-3 long day demo’s, the result will be exhaustion of your selection team. You will forget what you’ve seen, and it will all blur together. Remember that demo’s are only for the critical features necessary to achieve executive expectations.

Other good practices to avoid a lengthy process include having a fully budgeted and approved project before beginning the software selection; re-checking usability and viability for vendors that can show the critical features; and remembering that each day is one more day before beginning to achieve goals and benefits.

A four month time is possible. Developing the RFP could be done in 2 weeks if the executives are available, or certainly after you’ve digested their critical expectations. The vendor Response can be held to 3 weeks. Creating evaluation documents and finalizing demo scripts can be done during this time. RFP evaluation, customer visits, and follow-up can happen within 3 weeks. Vendor demo script preparation (and finishing customer reference visits) occurs during the next 3 weeks, and the scripted demos and detail follow-up happen in the subsequent 3 weeks. In the end, final Evaluation and Selection should take only 2 weeks.

You may need to look at some tie-breakers if there are too many good choices! These can include:

Support services that cover your time zones, global geographies, language skills, and the number of years before a release is “unsupported”

User groups and input to vendor “development” are important as you’ll want plenty of company, and a voice to the vendor

Implementation services, including a robust eco-system of implementation skill sets to avoid reliance on any one resource

Contracts that make clear just who is responsible for your system. Beware of ‘mixes’ of developers, partners, and resellers

Subjective evaluation of “Ease of Use” when all finalists are usable; just don’t let your lowest level workers drive the system selection, unless they are saying that the system is too clumsy or difficult to use.

Technical Viability of the Platform/Environment/Company

If your mix includes Software-as-a-Service (SaaS) Cloud vendors, then consider these additional factors, as these products generally provide best-of-breed practices, and are well suited when there is no mission-critical differentiation in critical features needed for you.

How Performance Management can Change Behavior

This is a subject that first came to me in 1983. I was faced with this problem in an electronics plant in Puerto Rico, when (as a younger man) I was to take over all production and material planning functions, hire new managers, and teach the staff how to utilize their “MRP” system. I knew that measuring performance could change behavior. It was a matter of

Identifying the behavior I wanted

Find out through performance reporting whether it was happening or not

Use the performance reports to highlight exceptions and identify “why not”

Gradually tighten the reporting tolerances to increase the successful behaviors.

This work was first published an “Auerbach Industry Applications Reference Publication, Volume 1, S32, 1985. I gave the talk a number of times, including at the International APICS conference in Las Vegas in 1982.

More recently, with the advent of easy to use, built-in operational performance reporting tools such as the Saved Query, the Watch-List, and the One View Reporting found in Oracle’s JD Edwards EnterpriseOne application, I was able to recreate the original performance metrics almost entirely out-of-the-box. With these modern tools, the cumbersome, manual data collection and report development is eliminated, and the software the planner is using to the tasks of their job is also tracking the metrics that need attention, thereby changing their behavior instantly and seamlessly.

I’ve given the full, updated talk a number of times at user group and other events. In this post, I want to link to a PDF version of the basic ideas behind “Do You Know What Your Planner Did Today?” and share them more broadly with the wider world. So here is the link. I hope you enjoy it! Do You Know What Your Planner Did Today – article format

These were my thoughts from a recent Executive Forum hosted by ExecRank, a web search firm for boards of directors.

The larger business process problems in outbound inventory management revolve around how to gracefully handle a customer’s request to ship product to a consignment location, then draw down that inventory, and eventually invoice the customer for the consumption. Usually there is an agreement in place that specifies which items are eligible for consignment, a target stocking level by location, a reorder point and reorder quantity, and a resupply and billing policy as it may be inefficient to resupply and invoice for each consumption transaction.

Once that agreement is in place, and the customer locations are identified, the next challenge is to accept these transactions seamlessly as just another part of sales order processing because the customer may be mixing normal shipments and consignment shipments in the same transaction or order transmittal; neither the customer’s people nor your customer service representatives want to parse out and separately handle the consignment transactions. So these consignments need to be taken in the same order flow process as normal orders. And, of course, there is the need to efficiently track what may be millions of closets, trunks, and shelf locations containing a very large number of SKU’s (stocking items). The problem set goes way beyond “Excel” spreadsheet” solutions!

A recent improvement in this area is a new software application just released by Oracle for the 9.2 JD Edwards ERP suite. With input from very large medical device companies, as well as consumer products and industrial supply firms, this new application specifically addresses each of the business problems above, beginning with a specific agreement, a method of identifying the consignment items as different types of order lines so that the sales order system can configure appropriate process flows, whether the customer is asking for a shipment, or is notifying the provider of a consumption. Replenishment and billing guidelines are contained in the agreement, and trigger the correct response for each customer and location.

By finding the right value-added steps in the process, and creating a configurable process that allows standardization of the business process flow while allowing for critical regional or divisional differences, this new piece of automation supports increasing the trust between partners while lowering their mutual cost of doing business together.

Your system can appear “guilty” when there are complex business requirements driven by metrics from arms length parent company ownership, e.g., private equity firms, or from personal interests, e.g., sales commission calculations; and that’s in addition to these considerations producing inefficient supply chain actions.

The root cause may be volatility in the underlying data, such as rapidly changing raw material prices, or fast moving foreign exchange rates. When combined with corporate metrics to reward (or punish) behavior, this can lead to counter-productive supply chain decisions, compounded elaborate attempts by IT to manipulate how the ERP system works in order to thwart those end user actions.

A far better, and much less complex solution is more likely to stop focusing on handling minute to minute changes, and to dampen out those effects by utilizing the ERP as designed, thereby restoring the system to “not guilty.”

For example, if raw material costs are extremely volatile, consider using a weekly purchase contract price, stored in a supplier-item price file with effectivity dates, that will be automatically applied to each PO released that week. This is more controlled than changing a price on a blanket PO, or a PO release, and contains the variation to a single week.

In another example, consider using a 5 day moving average exchange rate for the following week’s effective foreign exchange rate to accomplish a similar dampening effect. And at month end, use a spot rate, taking the exchange rate gain/loss only for the final days of the month happening during the closing week.

These are just examples of how to think “outside” the box to keep your system “Not Guilty As Charged!”

Here is another great example of how to keep your system “not guilty” that comes from the recent JDE Summit 15 in Broomfield, CO, a key gathering of roughly 700 business partners for Oracle’s JD Edwards product line.

Customers of Oracle’s JD Edwards EnterpriseOne product line can purchase a “technology foundation” that provides Oracle’s WebLogic applications server for JD Edwards, and also contains a limited use version of Oracle’s flagship data base, which was upgraded to the “12c” version in the past year. What many customers may not realize is how powerful the “in memory” feature (of the full “enterprise” version of the Oracle 12c data base) can be for a JD Edwards EnterpriseOne customer, both without making any change to their existing application, and even more so by taking advantage of some recent enhancements that are free of charge to a customer on maintenance and a current release. Let’s take a look.

I freely admit that until a week ago, I could not tell you in what an “in memory” data base did, or why it was important. At the JDE Summit, I sat in a session given by AJ Schifano and Keith Sholes that made it straightforward and crystal clear; this is a brief summary.

With Oracle’s 12c data base, the “regular” data base is still there and functioning as before, with it’s “row” structure, but now with another version (or copy) of the data base being maintained at the same time in memory in a “columnar” structure. Using a simple example, this means that every time a new sales order is added to the data base, the regular (row) structure adds the new sales order lines, and stores all the sales information such as customer ID, customer ship-to state, carrier, price, product, etc., in the columns (or cells) of that row of order line data. Now, at the same time, the “in memory” feature is resorting a copy of that data base according to each of those columns, so that the sales orders are automatically sorted by address, by state, by carrier, etc. This eliminates the need to “index” the row data to improve the speed of routine (planned and expected) queries and reports.

In the case of Oracle’s JD Edwards EnterpriseOne, eliminating the time to maintain those indexes will improve the normal (that is, OLTP or on line transaction processing) speed of the data base by a factor of two (or 2X). That alone is huge benefit because it delays the need to buy more hardware (“iron”), and since the in memory portion of the data base is ‘compressed’ it also means only a modest additional (if any) investment in main memory. And with zero change to the JD Edwards applications, any customer on a supported release level (which goes back a number of years) can enjoy this improvement immediately and instantly with zero upgrade effort or any other change on the customer’s part. That’s a gigantic benefit from the JD Edwards commitment since the mid-1990’s to separate changes to the underlying technology from the business processing logic or “applications code.”

Second, with the data sorted in memory by column (“field”), open queries and ad hoc queries will run tremendously faster than over the “row” oriented (and on disk) data base. Tests by JD Edwards developers show these speed gains can be on the order of 1,000 times faster over tens of millions, even a hundred million or more, rows of data. What this means in practice is that if you have one hundred million rows of sales order data, and you have a particular delivery carrier that goes on strike, you can identify the affected sales orders in a split second from the in memory data base, while this could have taken ten to twenty minutes in the normal “row” oriented on-disk data base. While this situation may not have life and death consequences, it isn’t hard to imagine how a steady stream of such ad hoc, open ended inquiries could wind up consuming a “full time equivalent” (FTE) worker, whose cost would pay for the in memory feature of the data base “enterprise” license. And again, this is available immediately, without upgrade, to customers of many recent releases, of Oracle’s JD Edwards EnterpriseOne ERP software.

Now, for customers who are on maintenance and able to upgrade to the latest releases – a program that by itself is the subject of a number of papers and presentations called the “100 day upgrade” (see http://www.learnjde.com) — Oracle’s JD Edwards EnterpriseOne software is offering an enhancement (at no charge) that transforms the multi-day, batch-orientation of the month end closing process into a nearly immediate, interactive process, supported by a “watch list” of accounting exceptions that pop up on the users screen, and lead the user directly to the problem areas that need attention. And this is all due to the in memory data base feature, which makes these new interactive versions of the older batch programs run in seconds over very large sets of general accounting records. In essence, you can simulate “closing” your accounting books every day of the month, meaning that senior management will have final results much faster after the actual end of the month, and will spend less time correcting the numbers and more time analyzing what appropriate actions to take. And, the saved effort in the accounting department, if redeployed to more productive tasks, would pay for the in memory option in even a fairly small company that has several general accounting clerks and analysts.

For the sake of full disclosure, these G/L closing programs are part of the latest G/L application, and are not dependent upon the in memory option; it’s just that no speed testing has been done (to my knowledge) of these new programs on the other data base platforms supported by JD Edwards, since they were written specifically to take advantage of the huge speed gains offered by the in memory option.

Just these few examples should be rocking the tables in every CIO’s office. In my opinion, any company that is already a JD Edwards customer, should be racing to find out what it will take to get bring on the memory option. If they are not a JD Edwards customer, they should be demanding that their ERP vendor provide them these same benefits without having to buy a new version of their ERP software, convert their existing ERP implementation, or having to buy a new hardware/software environment to support the in memory capabilities. The technology changes that used to take five years are now seemingly taking a year or less … the world is moving very fast! A failure to start using in memory data base capabilities will soon be enough to classify your system as “guilty as charged!”

A great example of how to keep your system “not guilty” comes from the recent JDE Summit 15 in Broomfield, CO, a key gathering of roughly 700 business partners for Oracle’s JD Edwards product line.

What’s at stake centers upon a fundamental change coming in the world of accounting and revenue recognition. The FASB and the IASB (accounting standard boards covering the USA and the world) have agreed that starting in January of 2017 there will be a dramatic change between how companies account for revenue that is related to an obligation to deliver on a promise. Today, this is called “deferred revenue” and in essence means that companies defer, or do not immediately recognize revenue – even if they have invoiced a customer and collected the cash – if they have a future obligation to deliver something, such as an unfinished (or promised) software release, or a piece of machinery subject to a final customer test and acceptance. In January of 2017, this will change to a different standard known as a ‘performance obligation’ meaning that the revenue will be recognized when the related contract obligation has been completed. A simple example is a company that makes and sells tractors and trailers. If the tractor can be used without the trailer, then shipping the tractor ahead of the trailer will be completion of the performance obligation, and hence revenue in January, 2017. If the tractor cannot be used without the trailer, then shipping the tractor ahead of the trailer will not complete the obligation, and therefore will not be revenue until the trailer is shipped and accepted by the customer, thereby completing the “set” and the obligation.

Where “your system” comes into this is through a major change in how contracted sales, and even sales without contracts but with implied ‘performance obligations’, are handled by your system. Some software companies will sell you a new “contracts management” module. If this is backwards compatible to your current release, then if you buy and implement it, your system will be keeping up with this fundamental change, and will “not be guilty.” If you fail to buy it, or if if requires an upgrade that you can’t undertake, then your system will become “guilty” but it will be your fault.

In the case of Oracle’s JD Edwards, both product lines (EnterpriseOne and World) will get the appropriate enhancements to handle the new accounting standards. And these will be at no charge for customers on maintenance support. The only rub will be that these enhancements will be made to a relatively current release of these systems. Since there is nothing to purchase, the JD Edwards systems will automatically be “not guilty as charged” … but a customer who can’t or won’t make an upgrade to reach those release levels will find themselves “guilty” and not their system.

I intend to post this same comment on the blog of JDE101.org, a new non-profit aimed at providing ERP skills anchored in Oracle’s JD Edwards EnterpriseOne to college students in business programs with a concentration in Information Technology.

I’ve just listened to a TED talk about a world-wide labor shortage that will develop in the next 15 years. The available workforce has already been born, and the students that JDE101 is trying to reach will be the emerging managers of that workforce.

We all know that technology has eliminated many routine level jobs, but the TED talk also points out that technology will create more jobs than it destroys in order to develop and manage that technology.

That said, being knowledgeable in a leading software tool such as JD Edwards EnterpriseOne, is one way for a college student today to position him or herself to help fill that looming labor shortage, and assure their self a good income for a long time to come. JDE E1 is not going away – I’ve written about that before on my own blog.

So check out an expert opinion on this subject with the following TED talk.

Rainer Strack: The workforce crisis of 2030 — and how to start solving it now!

This is just anecdotal evidence that bespoke code is more often “guilty” than packaged systems. It comes from a New York Times article on the original bike sharing company, PBSC Urban Solutions.

“While the cash problem was temporarily resolved with loans from the city, management’s attention was soon distracted by a pricing spat with 8D Technologies, the supplier that created the software for Bixi [the bike sharing software]. The city-owned company cut off its contract with 8D and developed new software on its own for future systems, including Citi Bike in New York.

That hurried software was a disaster, not just because it was full of problems, but also in terms of customer relations. Jon Orcutt, who championed Citi Bike during his time as director of policy at the New York City Transportation Department, said it picked PBSC’s technology based on the earlier software.

“That was not the system we got,” he said. Mr. Orcutt, who left the department last year, blames the software, in part, for the introduction delays and other problems with Citi Bike. At one point, he said, docking stations failed 10 percent of the time to release a bike.

Clearly, bespoke code requires a different set of quality assurance paradigms, both by developers and by requisitioners, to avoid the pitfalls of being “guilty as charged.”

A small division of larger company operates on 15 year old version of an ERP system running on a hardware platform that itself will soon to be obsolete. Company officials begin looking at new “Cloud” ERP solutions to get them out the mess.

Fortunately, the company complains to its outside software support consultant that the system is unable to help them manage a serious cash flow shortage situation; they use the system to select all the A/P checks to print, and then sit down and manually review the list to see what to remove to get down to the amount they have available to pay out. Consultant, once notified of the situation, immediately realizes that customer has not been trained in how to generate a selective A/P check run based upon the available dollars, and upon codes classifying various vendors as “must pay always” and other attributes. With the new training, the system does just what the company wants: Your system “not guilty as charged.”

At the same time, the G/L clerks are complaining that there is no easy way to upload transactions from Excel at month and year end into the ERP system for adjusting and other one time entries. While this aging ERP system did have a way to upload from spreadsheets, it was clumsy and unfriendly (“Guilty as charged”). However, this is a 15 year old release of that system; several years ago, the vendor released a series of updates making the system much more modern, one of which was a simple Excel upload/download feature. Since the system has not been modified in any substantial way, it would be straightforward to do an upgrade to the newer release, or even better, to the same vendor’s new technology platform that runs in “the Cloud”, can be owned or leased/rented (“SaaS”), and offers arguably the most modern user interface and reporting features available in any software package. The company is not taking advantage of this upgrade opportunity: Your system “not guilty as charged.”