Maybe software should be packaged like this?  Photo: Tetra Pak Package Portfolio, by Tetra Pak, CC license

A “packaged application” is software already built, coded, tested, used by other enterprises in your industry, and hopefully a solution that will meet most of your needs.  In general I recommend using packaged applications (why re-invent something?)

But a packaged application is not ready-to-use, in any sense of the word. The word “packaged” is kind of a misnomer. You won’t find a warehouse management system in a shrink-wrapped box on the shelf at Best Buy. A packaged application is simply one whose features and functions match in general terms what you want the software to do, but which still needs to be configured for your business. Configuration (also called setup) involves a lot of work and expense.

Much of the time involved in configuration is not in setting up all the data and parameters, but in deciding what data and parameters to set up. What data do you want to/have to set up for each customer? Should employees be “suppliers,” so that you can reimburse them for travel expenses? Do you want to manage your inventory levels according to min/max parameters or days on hand, or some other way? In most enterprises, decisions like these aren’t made by one person – groups of people get involved, and all those meetings and explanations have to be scheduled, and someone has to herd everyone into a decision. Not a quick process.

Packaged software is an annuity business. A software company survives in the long run because it is able to collect annual maintenance and support fees from its customers while providing custom development services and a stream of version upgrades. The support fees can be 20% to 25% of the original cost of the software license, so to the software firm, it’s like selling a new system to the same customer every four or five years. In exchange for the fees, the customer gets access to support desks, can have the software firm make modifications to the system usually on a time-and-materials basis, and automatically gets some upgrades and patches (or fixes) as well as user guides and maybe some technical documentation.

Recurring support revenue is highly profitable for vendors selling packaged applications. It is not unusual for big packaged software vendors like SAP, Oracle, and JDA to have this type of revenue represent 60+% of its sales while incurring only 5% or 10% of its operating expenses.

If you are selecting a packaged application, understand that your vendor will try to sell you the traditional on-premise solution, in which you will own and host the software while paying the vendor for additional licenses, upgrades and custom developments, plus the annual maintenance fees of 20% to 25% of the original license cost, which, on a license costing $500,000, for example, would be $100,000 to $125,000 per year.

And therein lies one of the most debated and disruptive topics in the software market today: the move away from the traditional on-premise (also referred to as perpetual license) model to a service or subscription-based model.  It is not exaggerating to say that the perpetual license model has in a way been the drug, the stream of highly profitable revenue, sustaining the software industry the past two decades.  Stay tuned.

Image by reynermedia, CC license

Finance and accounting functions were among the first to be automated through software. The sheer volume of numbers and calculations, reporting requirements, tax filings and payroll mechanics, plus the fact that nearly every business has to engage in these activities, made the area perfect for software.

When just these basic functions are needed, not much distinguishes one finance application from another. They all post transactions to a cost center and sub ledger account, they all capture sales and costs and calculate required P&L and balance sheet data, and they all provide reports. They might distinguish themselves in terms of ease of use or report writing, or banking account integration, or cash management, or some other aspect.

Many finance applications are simply bookkeeping systems; if you want real analysis you’ll need to extract data to Excel, Business Objects, or another analysis and reporting tool. My own experience with both Oracle and SAP bears this out: even these leading finance packages are mostly concerned with accounting and financial, not management reporting.

Oracle and SAP both have what they call “business intelligence” capabilities, but they are contained in separate modules that must be purchased and integrated with the core software. So companies can easily spend millions implementing SAP or Oracle, and still find themselves extracting data into Excel spreadsheets for basic business analysis.

My experience is that most finance applications lack budgeting and financial modeling capabilities. It is one thing to know that your prior month results were over budget because of rising fuel prices, and quite another to project the future profit impact of different oil price scenarios. At what point would it make sense to switch to alternative fuels, to pass on some of these increased costs, or to buy oil futures as a hedge? A typical finance application won’t help you to answer these questions because they mostly record and categorize costs based on what already happened, not what might happen in the future.

Yes, there are “what if” modeling applications available on the market, but as a stand-alone application they aren’t very useful, since you have to enter all of your data, as if you’re using an Excel spreadsheet. The modeling application needs integration with your ERP to be most effective. Your ERP is the source of all kinds of data needed for financial modeling: production costs, formulas, material costs, transportation costs, revenue by product, as well as cost standards and budget information. This data changes frequently based on business conditions, competition, labor costs, and many other factors.

Microstrategy, Oracle Hyperion and Cognos are leading names in the financial modeling and analytics areas, but other, smaller firms are emerging. Netsuite, the ERP-in-the-cloud vendor, offers an add-on financial modeling application. Netsuite’s web site states that the modeling application features these capabilities:
• Dynamic formulas and assumptions
• “Actuals” data incorporated into new forecasts
• Workflow management
• Planning of full financial statements
• Unlimited versions for “what-if” analysis
• Multi-dimensional models for complex sales and product planning
• Multiple currency budgeting
• Graphic drag-and-drop report builder
• Multi-version variance reporting (vs. budget, vs. plan, vs. forecast)

A3 Solutions is another, smaller firm offering financial modeling applications, either on-premise or as Software-as-a-Service. A3 uses the Excel spreadsheet as the user interface, claiming it is the friendliest environment for creating what-if scenarios, and provides tools to link multiple sources of corporate data and manage modeling versions dynamically and virtually through its Spreadsheet Automation Server. A3 claims McDonalds, Honda, Toyota, T. Rowe Price, and American Airlines as clients. Simplicity, speed of implementation, and low cost are A3’s main selling points.

Once you have the “system of record” stabilized in a strong finance application, as well as good controls over product, customer, and sales data, you can start to think about these higher-level analytical tools. Define a standard model for delivering analytics, put someone in charge of the data, and tightly control the “official” analyses that are produced.

You’ve heard the complaints: your systems are too clunky, slow, have too many steps, and they take too long to execute everyday transactions.

The dialogue plays out probably hundreds of times a day in offices throughout the world: users complain about to-hard-to-use systems and their IT departments tell them they just don’t know the right way to use them.

This can be a big problem, but costs and other impacts are not easy to measure. A rough estimate can be had by extrapolating the lost time per user across the enterprise.  A 15% hit to people’s productivity because the systems they use slow down their work actually means you need 1.176 people to do the work of one person.

Extrapolating this, if you have a 500-person organization, an equivalent of 88 of those people are needed only because you have sub-optimal systems.  As convincing as this seems, it’s hard to get the money to improve systems based on this argument. With perfectly-efficient systems, you wouldn’t actually need 88 fewer people because the sum of wasted time is across all 500 people.

What do you do? Two relatively low-cost options are user interface (UI – what you see when you look at the screen) tools and mobile applications.

UI Tools: There is an active market for these, which are intended to be used with widely-deployed ERP systems like SAP and Oracle. These solutions modify or enhance the system’s UI for simplified navigation and a more intuitive feel, and may combine several steps in a transaction or query into one, like an Excel macro.

One company marketing UI solutions (Winshuttle) claims to “turn everyday SAP users into heroes who transform the way their companies work.”

Solutions like this are only relevant for those companies that have full control over their systems environments – companies that own their own “instance” of the ERP system, versus those who use a SaaS ERP or one that is shared across many different business units. This is because you’ll need access “under the hood” to configure these tools.

Mobile: A shortcut (sometimes) to simplified ERP transactions is via mobile applications. A mobile application, out of necessity, must have minimal steps involving minimal data entry. No one wants a Windows version of the ERP system on their 5-inch smartphone screen.

This forces the software to consolidate steps in the transaction and pre-populate fields with user data and settings. If a given ERP transaction involves 5 or 6 steps on a desktop it will likely require only 2 or 3 steps on a mobile device.

Several of the large ERP vendors already have mobile versions of the most frequently used transactions, such as purchase orders and purchase order approvals.

You can always design your own mobile applications (there’s no shortage of people creating new smartphone apps), and doing so can lead to some very creative results that have a huge impact on user morale.

Image by lofrev.net

It’s getting harder to determine which software vendors have what capabilities. This is because:

• The number of technology startups has increased;
• Big software companies have been acquiring other firms to increase the breadth of their capabilities;
• Established firms are rapidly making changes to their suite of applications – adding capabilities so quickly that it’s difficult to land on a static evaluation and comparison vs. other vendors.

The branding of specific functionality continues to proliferate. Firms don’t define their software’s features all the same way – they give them a brand name, which only adds terminology that is unnecessary and gets in the way of a clear comparison of features.

Firms are offering products and services that overlap what other firms offer, making it more difficult to weed out who truly offers what you want.

It used to be that, if your company needed software in some form – packaged or custom – it was “installed” on a server. Then a “client” for the software – a relatively small piece of software – was installed on desktops so that the software on the server could communicate with the user on the desktop.

In between the two was a local-area network (LAN), which is jargon for a wired connection. In this configuration, a user could launch the client software on a PC, and the client would, via communication over the LAN to the server, enable the user to fully use all the features of the software.

Players in this market looked like this:

• The firm that wrote the software;
• The firms or independent consultants that support the software;
• The firm(s) that helped you to install, configure, test and launch the software you bought;
• The company from which you bought your servers;
• The company that supplied your LAN and wide-area network (WA)

All of this has changed. Now there are vendors that can do all of the above, without stepping inside your building, through a web portal.

How do you get what you need in this environment?

1. Find the software vendors that know your industry and understand what they offer. Software companies are usually organized according to what they call industry verticals, such as health care, pharmaceuticals, consumer goods, banking. A company with lots of clients in your industry is a good start
2. Find the software vendors that are the best for your targeted functional area such as sales, manufacturing, finance, etc.
3. Focus on the firms that are well represented in #1 and #2 above

The short answer to why corporate software costs so much is that implementing it takes so long, even if everything goes perfectly, which happens exactly as often as Haley’s Comet passing through our skies. It’s expensive for one reason: specialized, and therefore expensive, skills. It takes expensive skills to:

• write the software in the first place;
• modify it to your precise business needs; and
• install and test it and fix problems before you can use it.

The three biggest cost buckets of a software investment are implementation, software modifications, and the cost of delays or disruption to the business.

What is “implementation”? It is the process of making your business function using the new software, or “integrating” the software into your business, however you choose to look at it. Companies have different philosophies about this; some insist the software must be modified to accommodate the way the business functions; others believe in keeping the software as “vanilla” as possible by changing processes to fit the way the software was designed to work.

There is probably a happy medium.  I think the more you modify a program the more trouble you can expect.  It is not unusual to spend a (low) percentage of the project cost on modifications.

“Implementation” is also the process of matching each step in your business process to corresponding steps in the software. A business “process” is usually something like “ship a customer order” or “receive a shipment from a supplier.”

There might be 100 or so distinct business processes in a company, each with five to eight steps or transactions involved, so a software implementation could involve matching all of those 500 to 800 steps or transactions to the new software, and that takes time, knowledge of your business, and knowledge of the new software.

That’s why implementations are expensive: high cost per hour multiplied by many hours.

But if a perfect project is expensive, imagine how expensive a delayed or failed project can be. Failure is the norm, according to some studies, defined as over budget, not meeting implementation dates, or not delivering functionality as expected.

I would add to that list, from personal experience, failure also includes unexpected business disruption, like temporarily shutting down a manufacturing plant or shipping to your customers a day late. So the fact that software implementations are perceived to be wildly expensive is not just because software implementations are wildly expensive anyway – they also have a high failure rate, which only adds to the cost.

Image by Digital Strategy, CC license

Although EDI has been around for 20 years, lots of companies still process orders and invoices manually; that is, they receive a written, faxed, or e-mailed purchase order or invoice, then  type it into whatever software they have for tracking and fulfilling orders and paying suppliers.

If you  can’t or don’t want to get into EDI with your trading partners, there are at least two other options: buying software to image the paper documents and convert them to digital format for integration to your systems, or outsourcing the imaging and integration to a third party.

Let’s review the first option.  ReadSoft is one leading vendor offering document imaging.  The company states that it’s solutions “automate the processes of scanning, interpreting, and filing of invoice data,” and provide “seamless workflow integration with SAP, Oracle and over 50 ERP systems.”  The software enables three-way matching of invoice, purchase order, and contract.

My experience with ReadSoft is that it is a solid solution; although the expertise began with invoices the company also manages the purchase order side as well.  The companies that I know use ReadSoft have purchased it as an “on-premise” solution; that is, they have purchased the license for the software and installed it on a server within their organization.  It has a good rules-based engine for checking documents for certain attributes prior to integration with your main systems.

The second option is to outsource the receipt, capture, filtering, and integration to a 3rd party.  One vendor that does this is OmPrompt, a UK-based firm that is relatively small but boasts numerous marquee brand-name global companies as clients.  I also have experience with this company and indeed their solutions are solid and deliver as promised.

OmPrompt, in simple terms, works like this: your paper traffic is diverted to the company, you apply whatever business rules and filters to those documents, and OmPrompt then sends to your ERP system the proper digital files to complete the transactions.  OmPrompt handles business from around the globe, from the Middle East to China.  OmPrompt also processes EDI exchanges, and customer claims — a huge headache for many companies.

Which type of solution — on-premise or service — is better for you?  I am biased toward services rather than buying software, but you do need to consider the pros and cons in a balanced way:

The on-premise solution might be better if you want tight integration with the SAP or Oracle workflow, although the OmPrompt service can also filter invoices, claims, and POs based on your contracts and business rules.  The service-based solution removes the obligation to maintain server, operating system, licenses, users, and the core software;

Cost-wise you may pay much more upfront for the on-premise solution (license, installation, configuration, server, etc.) as well as 20-25% of the license cost each year for software maintenance.

The service option is very low-cost, after some setup fees, because you are using computing power that is shared across many clients.

Whichever option you choose, automating the manual work will bring clear returns:  reduced administrative work and solid internal controls to ensure you’re paying what you should on invoices and claims, plus the ability to standardize your inbound purchase orders or create a web portal for order capture.

Image: opensource.com

The term ‘adaptive software’ has at least two meanings: 1) software that is created with built-in capabilities to change its logic in the future; 2)  software that enhances an existing software application without significantly changing the underlying code of that application.

I have not seen real-world examples of 1) above, so I will focus on adaptive software as defined in 2) above.

The value of this type of adaptive software is in providing new functionality without the high cost of re-programming existing software applications.  Those existing applications are often referred to as “legacy” applications.  They could be five, 10, or 15 years old or older.  In some cases the company that wrote the program is no longer in business.  What do you do if you want to make changes to those applications?  In some cases adaptive software can be used.

Bob Kennedy, VP for business development at DMLogic LLC, describes in a recent article for supplychainbrain.com how adaptive software can be used to add features and functions to a warehouse management system (WMS).  He explained how companies used adaptive software with an existing WMS to create weight-check functionality and messaging and develop new screens to collect international shipping information.

I like the concept of adaptive software but a few hurdles have to be overcome, and you need to understand the limitations.

The main hurdle is access to the existing application’s database.  If you own the application and it resides on a server inside your enterprise this is probably not an issue.  But if you are part of a multi-company or multi-division enterprise all of whom depend on the application you want to adapt, you’ll need internal agreement on any changes (easier said than done!).

The limitations of adaptive software are …. not yet known, but I can guess they would start to be apparent when you try to change something very fundamental to the logic of the application.  Example?  Trying to use adaptive software to add a new unit of measure called “truck” to an existing WMS wherein you have only defined valid units of measure as “case” or “pallet.”

Having tried to find holes in the concept, I will say again I like the idea, because I think software vendors have intentionally or not created products that are too difficult and expensive to change.

Big ERP systems are a good example.  These systems are built with the back office in mind, they are workhorses and can scale as big as you want, but they are inflexible systems and they require disciplined data entry into the right screens at the right time with pristine data.

Can adaptive software solutions meet this challenge?  Can they provide a user interface for complex and heavy ERP systems that simplifies keystrokes and everyday transactions?  I think so, because we have already seen that mobile and tablet applications can simplify what are basically multi-step transactions.

Read Bob Kennedy’s article here.

The Landmark Shopping Mall in Hong Kong.  Photo by See-ming Lee, CC license.

It’s now possible to string together data points collected from the shelf (POS) and upstream from there (your supply chain) to optimize your sourcing, production and distribution decisions.  Application vendors are calling this Demand Signal Management (DSM).  It’s not new; the same concept a few years ago was called shelf-driven demand management.

Is this something you should invest in?

My experience is that these tools used even on a small scale are insightful and provide real returns, but that it’s easy to over-invest and get lost in what you’re trying to do with the mountains of data now available.

The vendor landscape is predictably unclear.  Before you consider vendors, though, it’s helpful to understand the different segments within DSM:

• Shelf or Point-of-Sale data is just one component and by itself in its raw form it’s not very useful without formatting and organizing it and normalizing it to your definitions. This is where POS data providers add value.  Many retailers will only supply data for your products, not selected competing products or your product category as a whole. This to me is a big gap in understanding true demand.  From POS data one can calculate product performance indicators such as days of supply, out of stocks, and item velocity.
• Customer warehouse data is one step upstream and is usually available from most retailers and included in the data package offered by POS vendors.  This data shows the quantities into and out of the warehouse, quantities on order, and current inventory. Again, usually only data for your products.
• Upstream from the warehouse is your enterprise and any data you might want to incorporate into the analysis: forecast, orders, inventory, past or planned promotions, production plans, supplier orders, marketing events, advertising, etc.
• Then there’s everything else: environmental data such as market size and segment trend data, geographic/demographic data, social media, the weather, the time of year, and cultural trends.

Putting all these pieces together for a coherent and insightful view of your demand is the promise of DSM.

Application vendors in this area fall into two main categories: 1) “point” applications that offer one solution for one part of the supply chain, such as POS data vendors; and 2) fuller end-to-solutions that offer the ability to incorporate many different data points from many parts of the enterprise and to relate them in a logical way to one another.  My advice:

1. Try a point solution approach on a particularly difficult or troublesome part of your supply chain; it’s not expensive and many application vendors can enable a solution quickly on a cloud platform;
2. Keep the financial commitment small and the option to exit from the solution easy.  This should not be difficult, as vendors often will agree to month-to-month contracts;
3. Do steps 1) and 2) before launching any large end-to-end DSM initiative.  An end-to-end project can involve lots of data management (conversion, translation, normalization) and if its not done right the result could be a confusing and unreliable addition to your demand planning efforts.

Photo by Jimmy Brown, CC license

FUD stands for fear, uncertainty, and doubt, and was a phrase used in the early 1980s to describe the unsettling and confusing atmosphere companies faced as they began investing heavily in software applications.

In 1979 Gideon Gartner, formerly a top technology analyst at Oppenheimer & Co., capitalized on that confusion and formed an advisory firm to help companies with technology decisions. Gartner Inc. now has a market value exceeding $4 billion and customers in 85 countries.

Although we have software tools far superior to what was available in the the 1980s, FUD still exists.

It exists wherever software marketers and commercial enterprises interact.  The dialogue is predictable: “Can your system do this, that, and the other thing.”  “Our system can do that, and much more; it can do X, Y, and Z.”

But the two parties (software, business) are talking past each other.  They aren’t even using the same language.

Software marketing is filled with evocative corporate-speak; it is opaque, conceptual, and general.  Meanwhile, the business person looking for a solution is mired in her own problematic world and knows in general what she needs but doesn’t realize that the software company she is speaking to has no idea of the details of her situation and even more cannot imagine it.

They speak to one another and try to find some common things they both agree on and understand.  The business person is left bewildered.  FUD.

Money pits thrive where FUD exists.  In this situation, bad and costly decisions are highly probable.

• Take a step back and evaluate your business and technology strategy.  Do you really need this technology or could you outsource the whole business process?  Will the investment in this technology make my customers happier?
• Before considering any solutions offered by software vendors, take the time to evaluate processes the software will support, document how those processes should flow in the future, and prepare a detailed list of requirements for the future application.  You will use this to evaluate the “fit” of each software solution to your situation.
• Like anything else, educate yourself before you buy.  Understand the type of technology you need, and the options available in the current market.  An advisory firm is recommended here; it will cost you a fraction of what you intend to spend and save you multiples of that.
• Change the conversation with the vendor.  Stop talking about the software.  Instead talk about your business context and the goals you have.  Most vendors really do want to understand your needs but they don’t have the advantage of being in your shoes.
• Take the vendor’s software solution for an imaginary “test drive.”  Spend time with the vendor walking through your future process and the associated technology requirements.  The result will be much more clarity and understanding of the vendor’s potential to meet your needs.

There’s the human factor to consider.  Photo: Workers at the Jamaica Plain Post Office, 71 Green Street, Boston, 1920.  Boston Public Library, CC license

Have you ever spent, say, half a million dollars and nine months of effort with new software or changes to existing systems for purposes of automating processes, only to discover that afterwards the processes are just as inefficient as they were when you started?

I’ve worked on several of these projects.  People claim they can save hundreds of people-hours per week if only …. Usually these projects require custom development of existing software or additional software to eliminate process steps.  Why do these efforts fail to deliver promised benefits?

A ‘soft’ or hard-to-prove ROI .  Frequently labor savings from automation do not result in actual reductions in labor cost; instead the argument is made that the work force can engage in more “value-added” work.  Consequently, if you had 30 people processing customer orders before the automation project and 30 people after, it’s still possible to call the project a success, because you can say that now the customer service team is pursuing more “value-added” work.  But is it?How do you know?

A tendency to stick to comfortable work routines .  When people have been using the same systems to do their work for 10 years, it’s very hard to change their routines and not to do certain steps inside those systems because the steps are no longer necessary.  People are going to do what is comfortable for them, especially when they see only a marginal benefit to changing.  You need a big change management campaign to ensure new more efficient practices are followed.

Higher than expected  costs to modify software .  It is also a human tendency to underestimate costs of making changes to existing software.  In the case of ERP systems this cost can be astronomical – not so much because a lot of hours are needed to modify the software – but because the original code was never intended to be changed in the way we want it to change.  You can only do so much change before the entire program has to be overhauled.  Everything inside a complex software program is interconnected.

So what do you do? 

Avoid big and expensive modifications to software as a way to automate business processes.  The people who created the software had a specific purpose in mind; that purpose may or may not be compatible with what you imagine to be a more efficient business process.

If you want true automation, outsource the process altogether .  Taking pieces of a process and eliminating them through software modifications might be minimally helpful, but it’s not a big enough change to modify behavior.  Yes, to make a process more efficient you may have to remove it from those people currently performing it.  The adage about teaching an old dog new tricks is true.

Outsourcing the process does not mean you can – or want to — eliminate whole departments.  But it does ensure that certain activities – non value-added processes – no longer exist within your organization, for anyone to waste any more time on.