Guilty for sure – not being able to ‘drill down and around’ – e.g., from G/L to A/P to underlying PO.

Amazingly enough these days, it is still possible to find systems that cannot “drill down and around” from one part of the system to another, even when it should be entirely natural to do so.

I recently came across a system aimed at manufacturing companies under $25M in annual revenues that could not drill back from a General Ledger posting to the underlying Accounts Payable posting to the underlying Purchase Order Receipt and in turn to the underlying Purchase Order.   This is simply not acceptable today, and a system lacking this kind of capability deserves the

“Is Your System Really Guilty” when you start blaming your ERP system for a lack of capabilities based upon what your system integrator of S.I. says, and without double checking with the software vendor?

In this situation, you are having trouble getting your ERP system to perform a business function; let’s look at a bit of complex, but real life, example.

An item is being made and a serial number is assigned to this sub-assembly.  But instead of completing the work order at this point, the sub-assembly is moved along to another set of operations that add more value and eventually consume this sub-assembly into a final assembly or finished goods item, which has the same serial number as the first sub-assembly.  This situation started creating duplicate serial numbers in inventory.  The original SI putting in the system thought this was the best solution available.  The company, feeling that inventory and production were getting out of control came to the software vendor and asked for a review of the process.  It didn’t take very long for the software vendor’s presales team, sent in on a health check, to realize that the proper procedure was to make a completion of the original sub-assembly to a stocking level (or even an intermediate level), and then to issue the serialized sub-assembly out to the next process where the system’s native lot track & trace features would link it to the serial number of the final or finished assembly.

This was an obvious solution to the vendor.  The fact that it hadn’t occurred to the original systems integrator was leading to a pronouncement of a “guilty” system, when there was no guilt at all, simply a system “not guilty as charged.”

 

 

The Radical Viewpoint – Aiming at the Right Target

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….

Bespoke – or Custom – Software

A long time ago, I was a software business analyst and programmer in a very large company.  I went to meetings with business users, and asked them what their software should do.  I went to plants, offices, and distribution centers, and talked to business users who were using very rudimentary “accounting” systems .  I wrote down what they said.

Then we had many long meetings with lots of people (and coffee and doughnuts) to better understand what we thought we heard, and to gain agreement on what was needed.  I wrote up what I thought they wanted.  We met again and again.  I laid out pictures of screens and reports to represent what I thought they were going to get.

As time went by, business requirements also changed.  Finally, we had “agreement.”  Then a budget was laid out for program development, and years later, programs were delivered.  Maybe they hit the mark, maybe not – after six years I had moved on.

The chance that these programs no longer were what was truly needed was reasonably high due to the time lag involved between request and delivery.  Perhaps these systems were then “guilty as charged.”

The issue of custom or bespoke code is big one.  We can discuss this at more length in the future.

For now, a few guiding principles are:

• Design becomes paramount
  • Is the system design truly representative of what the users want?
  • How do you know?
• User input and acceptance of design is key
  • They must be able to visualize the end system
  • Prototypes are critical – the old phrase “a picture is worth a thousand words” is so true in this case
  • Rapid development tools are essential in managing the time frame
• Constant communication and feedback is the secret
  • And if documentation and testing teams are involved at each stage, the chance of errors in the final product will be dramatically reduced – this is another topic for another day; I talked about this at a conference in the late 1980’s…

Good luck on your designs….

 

Guilty As Charged

In this section, we’ll look at a couple of instances where a system really is guilty because the underlying application program code was either harming the end users, not able to change and support important business initiatives, or simply programmed to do the tasks required.

 

Case #2010-0901 – Have You Paid for a New System Twice Over?

This example of “Your System – Not Guilty as Charged” stands in opposition to the previous one (#2010-0801) because in this case potential upgrades were bypassed for about ten years, until a crisis arose.

In this case, the CEO of the company discovered a hot new business opportunity that required a set of software functions that the existing enterprise system could not handle.  Complicating the situation, this  new opportunity was also not directly handled by any newer features available from any of the upgrade releases available since the original implementation release taken by this company.

The dilemma now was that (1) the “old” system can’t handle the newly desired processes, and (2) by itself, an upgrade wouldn’t solve the problem.  So, IT had a crisis decision on their hands.  They could (1) rush to buy a 3rd party bolt-on to the “old” system to handle the new requirements, or they could (2) delay the CEO’s request and perform an upgrade – covering ten years of releases – before adding on that 3rd party product, which had a “standards based” integration with the current (upgraded) release of the company’s enterprise software system.

The positive side of doing the delay and getting the upgrade would be that much newer technologies available at the upgrade release level would make the 3^rd party integration a much smoother, easier, and less costly process, while at the same time providing a stronger functional baseline across for future benefits in all areas of the business.  The downside of rushing the purchase of the 3^rd party system without doing the upgrade would not only be a more difficult and costlier set of integration programs, but that this work would add to the cost of any future upgrade.

The result was an unnecessary and very unpleasant dilemma for the chief IT officer.  The resolution, in my opinion, resembled a kind of “hari kari” when IT found an entirely different enterprise system that offered a pre-integrated “partner” solution for the new business process desired by the CEO.  The result was the purchase of an entirely different enterprise system, creating an entirely new set of training costs and learning curves for the business users and IT staff, and essentially “torching” ten years of support payments.

What’s your opinion on the guilt of the old system?

Case #2010-0801 – Upgrades without Benefits

In this example of “Your System – Not Guilty as Charged”, we look at one of most baffling of the cases I’ve come across – when a company performs an upgrade of their enterprise software without getting any obvious business benefit other than moving from an older technology baseline to a new technology.

Although I can’t think of any “good” reasons for this type of move, I have seen it happen because the software vendor as ending “support” for an old release and so the client company moved to the newer release simply to stay on support without making any changes to business processes and without taking advantage of any added or enhanced features in the new release.

The result?  All the prior problems, challenges, and frustrations faced by the business users remain.  Anyone looking at this situation would have to conclude that if the old system was “guilty” then the ‘new’ system is also surely “guilty.”  But is this situation the fault of the enterprise system?  I don’t think so.

What’s your opinion?

Case #2010-0701 – There’s Never Time to Move Forward

In this example of “Your System – Not Guilty as Charged”, we see what happens when it’s always the “busy” season, and there’s never enough time to do an upgrade or buy a new system.

So often I see that old problems and headaches persisting because of the lack of proper systems support for necessary and important business processes.  The old workarounds persist, and oftentimes become worse and more complicated by additional twists and turns necessary to keep transactions flowing and to report on that business because the business processes keep evolving with new market place demands, competitive situations, and management initiatives.

Key signs of this situation are hand-crafted system-to-system integrations, double entries to two or more systems, and lots of time spent double checking that entries in one system are reflected properly in the other system(s).  This data nightmare becomes a way of life for the poor souls caught between the two systems, and is a source of great frustration to them.

One user who had to keep up inventory and cost figures between a manufacturing execution system and the corporate ERP system told me that she spent much of her day simply checking that figures entered in the MES reached the ERP without distortion or error because the system ‘integration’ was old and often unreliable – yet either not ‘fixable’ or a significant source of distress to management to get it fixed.  She, in fact, was the ‘fix.’  We showed this company a fully integrated manufacturing/ERP system; the liked it; the users said they wanted it; but six months later, there’s either not a budget and now we’re approaching  the ‘busy season’ again.

I saw a quote one time that said, “The implementation time frame is directly proportional to the time it takes to make the decision.”  Perhaps that’s why companies that dither around making the upgrade decision are afraid to make it – they intuitively grasp that the longer they take to make the decision, the longer and more painful it’s going to be to make the implementation of that upgrade.

What do you say?

Take a look at the presentation on the “Presentations” page to see what you can do, and for some radical views on how to “get it right.”

Case #2010-0601 – “Letting Problems Persist”

In this example of “Your System – Not Guilty as Charged”, we see what happens when users are working on a very old version of their software system because IT and/or the user community has passed on the many version updates offered by the software vendor.

The almost certain result is that the older version of the software cannot address important business processes, usually because these processes arose, or became important, after the initial implementation.  If the software selection had been thorough, and if the software vendor has a good track record of staying current with both their customer base and with industry or market trends, then there is a very good chance that later releases of the software offers key features that address the new business process problem.  But either IT, or IT in combination with the user community, has elected not to take those upgrades.

Why has this happened?  IT decides that there is only a marginal improvement offered by the first release after the initial implementation level, and takes a “pass”.  This repeats with each subsequent release until the software is old and aged, and then the business faces a substantial upgrade, often leading to a complete re-implementation, and possibly even a re-evaluation and new selection.

What is the natural result?  The business users address their problem with a combination of procedural workarounds – which are often inefficient and prone to error – and with their own trusty software tools – Microsoft Excel and Access, plus fax, email, whiteboards, and redundant communications.  User satisfaction with the Enterprise System declines as it becomes more marginalized.  Senior management loses their initial view of the system as a valuable asset.

In addition, customer service levels tend to decline while related operating costs tend to rise.  For example, if the system is unable to handle assemble to order configurations, then an alternative such as “pick to order kits” might be employed.  But this requires inventory to be stocked in final configurations of key assemblies rather than being able to complete a final customer assembly from key sub-assemblies.  A predictable result might be more inventory, more chance of obsolete inventory, more chance of an unshipped order because one “kit” item is missing.

Another frequent outcome is that users build narrowly focused business cases to justify purchasing “point” or “niche” systems when the pain and complexity of their unsolved problem exceeds their ability to address it through workarounds and “Office” software.  Now IT is saddled with integrating and maintaining a system from a “foreign” software supplier, that is, someone other than their primary Enterprise software vendor.  It is very likely that the new package does not use the same integration technology as the original Enterprise system – or that the original system is too old to have a modern, standards-based integration technology.  The result is more work for IT, more cost for IT, and a declining ability of IT to respond to new user requests involving customization of either the niche package or the base Enterprise system.

Another alternative is that consultants are hired to build a custom solution to address the pressing business problem because there isn’t a good packaged system available.

Upgrades become harder and harder to justify because of the new, additional systems that have bolted themselves onto the base Enterprise system.

As a footnote to this case, I’ve seen a customer (more than once) simply fail to take advantage of a feature in the old version of the software that they are using that would solve a business problem for which they have developed workarounds, “Office” solutions, packaged solutions, or custom solutions.  The reason I’ve heard is this rather remarkable quote: “Yes, we know that feature is in the software, but we didn’t implement it originally and so we can’t or won’t implement it now.”

What do you say?

Take a look at the presentation on the “Presentations” page to see what you can do, and for some radical views on how to “get it right.”

Case #2010-0501 – “Forgetting How to Block and Tackle”

In this example of “Your System – Not Guilty as Charged”, we see what happens when there are “quick and dirty” implementations that miss the basics, and do not anticipate the possible future needs of the underlying business.

When an implementation is done quickly, and without proper thoughtfulness and planning, common shortcomings include:

-          Lack of a “knowledge” base among the IT and user community that knows the software well enough to adapt the system’s business processing rules to deal with future changes in the underlying business model.

• There will also not be a workable support mechanism to design and implement those changes.
• There will not be a “support line” of power users and analysts

-          Too often, these same businesses are not willing to hire or build up in-house business analysts.  Sometimes, the line of business (LOB) “owners” – that is, the management team – will wind up  taking on power-user roles at the expense of performing their own functional roles.

This kind of short term thinking is a prescription for a later, or downstream, system disaster.

I had the experience of visiting a company that fit this case precisely.  The original system implementation was focused on the financial applications such as general ledger, accounts payable, and accounts receivable, along with the basics of sales order and purchase order management and inventory.  Little or no attention was paid to manufacturing management and materials planning.  The software was an early release of a new generation of the software vendor’s traditional application offering.

The original implemented was done very quickly.  One key user, familiar with the same software from her work at another company, estimated that even in the heaviest use area – accounting – perhaps only 20% of the software capabilities were being utilized.  No business analysts were ever hired to learn the new system and address the needs of business users; the only contracted I.T. services were for computer operations and report writing.

Line of business users took on more and more of the “power user” and business analyst tasks of managing an on-going implementation, spending their time learning the software details, writing custom reports that seemed unnecessary because existing (but unknown to them) standard reports already existed, and performing other outside-the-system workarounds also because they were unaware of the system’s true capabilities.  As time went on, the business grew and new challenges arose, such as outsourced manufacturing overseas. Various problems and bottlenecks grew with routine matters such as running a trial balance report out of G/L, and more complex challenges such as doing multi-company consolidations.  As they struggled with the software package they didn’t know well, the user community began to wonder if this software package was the right one for their business operations.

By the time I visited (nearly ten years after the original purchase), they had made a “technical” upgrade to a more stable (but by now still quite old) release of the software; however, the upgrade was purely technical and without a single change in the end user implementation (see a later case). My challenge now was to revisit their original and current selection criteria, and help them decide if they were riding the right horse.

I believe the fault is not with the system, but with the implementation of the system.  The next posts will offer further explore “what went wrong” and offer suggestions on “how this could have been avoided.”

What do you say?

Take a look at the presentation on the “Presentations” page to see what you can do, and for some radical views on how to “get it right.”