Your System – Not Guilty As Charged

Just another weblog

Archive for the ‘How to improve’ Category

Integration Challenges among Cloud Applications

Posted by Joel Schipper on January 29, 2016

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, 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?



Posted in How to improve | Leave a Comment »

Keys to Successful Software Selection and Implementation

Posted by Joel Schipper on January 29, 2016

Aiming to Achieve Your Executive’s Expectations

I discuss the best way to select and implement software to achieve the expectations of your top executives below, and you may also follow it with these slides in PDF  Keys for a Successful Selection and Implementation – Leading to a Great Reference v3 C16

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

1 – Accomplish Corporate Mission
2 – Drive Revenue and Make Profits
3 – Minimize Risk to Shareholders and Capital

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:

  1. Software Usability.
  2. Software Architecture.
  3. 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.

  1. 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.
  2. 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.
  3. 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.

  • The same rules – usability and viability – still are in play
  • Add extra weight to integration approaches, service level / availability, and security.
  • Can you customize, and how?
  • How can you add third party software?
  • What are the reporting tools and business intelligence offerings?
  • How is auditing and SOX requirements handled?
  • How/when do you upgrade?
  • Will older versions be allowed?

Once you’ve made your selection (and purchase), it’s time to build a project plan to implement that software in light of your goals.  Be sure to:

  • Measure progress against original expectations
  • Make sure your implementation plans correspond to your original selection goals.
  • Determine what and where to implement to accomplish each goal.
  • Balance the effort to achieve with the level of reward and risk of failure (or probability of success)

Link the goals into project plans and closely monitor them.  Include user training, user acceptance testing, and stress testing in your plans.

Remember to measure your results.

  • Each goal has been linked to software features
  • The measurements of success for each goal were defined in the beginning, so use that as a baseline
  • Publish the new measurements to everyone, being very public about the results
  • Feature the measurements in the Steering Committee meetings and reports.

Remember:  “What is measured is what will be achieved.”

  • Publish your successes and explain your failures.
  • Publish corrective actions
  • Use incentives to drive achievement
  • Reward both achievement and the time to achieve
  • Use competitions and gamifications as appropriate.

And finally, if the project is having trouble or is delayed, consider:

  • Reviewing which goals are at risk, and attack problems starting with the value of the delayed goal
  • Using proven, team problem solving techniques
  • Revising project plans to reflect realities “on the ground” and move timelines rather than goals
  • Keep measuring and publishing results and reasons

And have some fun along the way!

Posted in How to improve, Not Guilty as Charged | 2 Comments »

ERP Skills needed to help solve looming global workforce shortage

Posted by Joel Schipper on January 11, 2015

I intend to post this same comment on the blog of, 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!

or get the TED app for iOS at

Posted in general comments, How to improve | Leave a Comment »

“The Big Lie about ERP Training”

Posted by Joel Schipper on January 7, 2015

This is from a comment I made on Andy Klee’s JDETips Blog in response to his April 21, 2014 posting about “the big lie in ERP training.”

I think this “big lie” also stems from a tectonic, generational shift towards “Apps” – the younger people who are coming of age in using corporate information systems today (e.g., ERP) have been schooled to believe that the “app” already encapsulates everything they need, and that the “app’s” are intended to be intuitive – at least to someone who uses app’s all the time and has learned their paradigms.  This mindset lends itself to not understanding or believing why a person would require lots of formal education and training …. if the “app” is intuitive, if it does a specific purpose, and if you understand the usual paradigms in the UI, then why would there be a need for training.

This ignores the “real world” of business applications that are not set up that way, that allow for a rich variety of approaches towards solving a business problem, and of course, configuring the software to match and improve on the business practices already in place outside of the software or “app.”

The training that’s needed is both in the software, and in remembering the power of how to think for ourselves.

I can only expect more and more “Cloud” software solutions to essentially “dumb down” their solutions to better fit the “app” mindset expectation.  That’s what the new generation of buyers will be looking for.  But at a cost of giving your company software that does exactly what the next company’s software gives them, and slowly eliminating “process improvement” as a way to differentiate yourself.

If that happens, the key to getting your company ahead will be to innovate in business processes, and to write your own software – or get agile, adaptable ERP software – to support those transformational processes.  Being “best in class” will not be enough because everyone by definition will be “BIC” if everyone uses the same (or similar) Cloud applications.  Best to leave those “app’s” for commodity processes such as self service HCM processing, self service purchase requisitioning.  And then to drive your user community to remove all non-value activities, focus on using those commodity “ERP” app’s in a standard manner across all divisions and regions, and eventually consolidate those functions into shared service centers that (sigh) eliminate the human moving parts.

All the more reason to learn “how to think” again.

Posted in Expanded Tweets, How to improve | Leave a Comment »

The Radical Viewpoint – Aiming at the Right Target

Posted by Joel Schipper on December 13, 2010

The first step in getting to a system that will not be “guilty as charged” is to aim at the right target opportunity.

That target will become clear only when you’ve done these four radical steps:

  • Simplify
    • Reviewed what is happening in your business processes, and simplified the number of steps in each process that will be handled by the new system.
    • For example, are you doing extra steps?  Steps without a “value-add?”  Steps that are overly complex or difficult to accomplish?
  • Standardize
    • Review how a particular  business function is being handled, e.g, Accounts Payable, in different divisions, regions, or lines of business (before you implement ‘shared services’).
    • Have each group handle this function with as much commonality and common standard procedure as possible.
    • Minimize the exceptions.
  • Centralize
    • Are you doing a function in different regions, regions, or lines of business with separate business groups?  If so, what is the compelling reason (perhaps a legal issue with joint ventures or governments)?
    • If there is no compelling reason, start to plan on using technology to consolidate those functions in what are commonly called “shared service” organizations.  Why have multiple A/P departments if not absolutely necessary?
  • Automate
    • Now that you’ve simplified the business process, you’ve standardized it, and you’ve centralized it, you’re ready to apply state of the art information technology to it.

With this new understanding of how you’re about to utilize the new system, you still need to have a clear and understandable Return on Investment (ROI) from that system, an ROI that you can not only calculate, but about which you can answer these questions:

  • Who exactly is getting this ROI?
    • What organizations and/or persons will experience this ROI?
  • How are they getting it?
    • What will change?
    • How will this be done and measured?
  • When should they expect it?
    • You need to know dates when the ROI will appear so that you can be ready to measure and record it’s arrival

Finally, get ready to measure your progress during and after implementation.  You know what you’re automating, and who’s getting the benefit – now be ready to hold those persons and that organization accountable for achieving the ROI.

More about each of these points in coming posts….

Posted in How to improve | Leave a Comment »