Data processing, 1959. Image by James Vaughan, CC license

If you search “technologies for supply chain evolution” you will get 17.8 million results, many of which will mention IoT, robots, driverless vehicles, mobile technology, predictive analytics, network optimization software, and 3-D printing.

The presumption is that industry will want these solutions because of the coming added complexity and demands of the modern supply chain in the digital age.

But most supply chains still confront very basic problems and inefficiencies; they haven’t in many cases even fully deployed yesterday’s technology, so delivering product with drones doesn’t make the priority list.

So which technologies are key to the supply chain of the future? The same ones that were introduced 15 years ago that companies still haven’t adopted! This is unfortunate, because many of these technologies were designed to automate the supply chain office, and without automating the supply chain office, all of that promising talent you are committed to developing is typing away at tedium.

Just visit your customer service department, where very smart and capable humans – some with $120,000 college degrees — are reading data from pieces of paper and entering them into systems, an act which, according to supply chain technology gurus, should have disappeared years ago with the introduction of EDI, integrated systems, and OCR.

Supply chain managers are managing minutiae, not the supply chain.

Where does the minutiae come from? From the 18,000 to 30,000 phone calls or emails and the 120,000 to 350,000 manual interventions a typical ($2 billion +) company must make just to ensure proper system processing of its order-to-cash flow. And this is with all the normal ERP and associated technologies, such as EDI, that a company of that size normally uses.

Companies still have teams of people shuttling information and data all over the supply chain office, and because they are busy shuttling information they don’t have time to look at it to make sense of it and use it to improve your business.

Automating the supply chain office is one of the cheaper technology moves you could make. The EDI and OCR of the 1980s has gotten better and easier to deploy, and when strung together with complimenting technologies, can automate nearly all of your order processing, exceptions management, invoice discrepancies and customer claims work.

Automation also has the enormous benefit of – by definition – digitizing every piece of data from every transaction. If all of your shipping and invoice claims are scanned, stored, and sent to transactional systems for disposition, all that data is available to study for patterns, relationships, and other insights that can mean immediate savings. Like getting a view of the forest.

Want to evolve? Make the supply chain office run itself. For a $2 billion company selling to major retail outlets in the US, this means zero human intervention for every one of 60,000 deliveries a company of that size is likely to make. Most business rules are simple to automate: if X order received, send to Y location and reply Z back to customer.

A truly evolved supply chain office is one where all human assets are users of data, not movers of data, creators of opportunity based on a view of the forest, and customer relationship builders.

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.

Photo by Meredith Cook at Breckenridge, CO on a “blue bird” day, a clear day following a fresh snowfall.  It’s unrelated to SaaS or Cloud (or is it?); just nice to look at.

SaaS and cloud are starting to be used interchangeably (“we’re looking for a cloud solution”) but they really are not the same thing.

Software-as-a-Service (SaaS) is: software that is made available for use based on access to features, time, number of transactions, number of users, or a combination of variables.  A ‘cloud’ is simply a server – a computer you don’t own or maintain – that sits somewhere other than in your building, that you access to run applications or store data.

SaaS describes a type of software, cloud describes a type of platform.

So you can see it’s possible to take applications that you own, and put them in ‘the cloud,’ and also possible to use software you don’t own, but pay for based on usage, that is sitting in your data center with all your other applications.

But there are more important distinctions.

Type of Software-as-a-Service: Is it software that only you access (single tenant), or is it an application that many other people or companies use (multi-tenant)?  Multi-tenant is generally lower cost, but with less specialized functions for your particular enterprise.  Is it truly SaaS, or just a full cost, configured-for-you application hosted by someone else whose costs have been spread out monthly over 5 years to look like a SaaS solution?  True SaaS works like a subscription: sign up, pay by month and use it; when you no longer need it, you cancel.

Type of Cloud: Is it a private or public cloud, or a hybrid?  A private cloud is a single tenant environment (your enterprise) where you control access and have firewalls for security and where you can define the hardware.  A public cloud is where you are paying for a part of an existing cloud server environment; here, you “rent” space and the advantage is flexibility, low cost, and the ability to scale capacity up or down based on your needs.  Hybrid clouds offer both private and public spaces for you to use.

Let’s look at examples; in both cases we will use the scenario of a manufacturing company selling to major retailers in the U.S. and Canada.

True SaaS:  You contract with a company that offers tools for analytics (software) together with point-of-sale (POS) data for your products for your largest retail customers.  You pay by month to access and analyze POS data. The costs vary depending on how many report levels you want to see.  You access the application via internet, anyone in your company can use the service, and you can cancel at any time.

True Cloud: For purposes of experimenting with business intelligence applications, you purchase database space from a vendor, at a cost that varies depending on how much space you use.  You can scale up or down in terms of the storage you need.  You can connect to this space with a variety of tools for transporting  data and you can install and remove applications easily.  For running your business day to day, you can host your most critical applications in this cloud, and have in reserve an identical cloud with servers ready to take over in cases of disaster or over-capacity of your main servers.

Before you accept at face value the terms ‘cloud’ or ‘SaaS,’ make sure you understand what the vendor is telling you. Ask for details and explanations.  What the vendor thinks is cloud or SaaS can certainly be different from what you expect.

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: Island Peak, Nepal, by McKay Savage, CC license

“Scope,” or “footprint” in software terms refers to the number of business processes that an application will “cover,” or enable.  The scope of an accounting system is usually: general ledger, accounts payable, accounts receivable, fixed assets, P&L and balance sheet.

The scope has to fit the application, and vice versa, and it has to be feasible for the project team and deliver the benefits expected to pay back the investment in the new system.

Too big a scope can overwhelm the team and the application you select.  It will also cost more.  Too small a scope might not be worth the time and expense, and may not yield the financial benefits expected.  A creeping scope starts out small and feasible, then as the project progresses scope is added in the form of requests for features and functions not originally planned.

Money pits are usually found at the end of projects with too big of a scope or a creeping scope.

How do you find the right scope?

Determine which areas of the business would benefit the most from a new or better application. Can you define the specific problems that are leading your enterprise to consider new software? Where are those problems located – in what functional areas and related to which current (legacy) system? Is the problem that a) a particular application is too limiting; b) a group of applications are islands and that integration of them would yield benefits; c) none of your applications are integrated; or d) something else?

Consider a range of scope options to find the optimal one. In some cases, expanding the scope of a new application beyond “problem areas” can be the optimal choice. The process is iterative, and you should consider several alternatives. For example, implementing a new accounting system may satisfy most of a company’s needs and produce a good ROI on its own. But expanding the application footprint to, say, payroll and purchasing, may result in an even better return because it simplifies integration costs, eliminates more manual work, and may strategically be a better decision.

Set up a framework to evaluate each scope alternative. In a framework (Excel comparison) you can evaluate each scope option according to such factors as cost, complexity, length of time to implement, risk to the business, ROI, required internal resources and strategic value. Then you have a logical basis for your decision.

The scope of an ERP project does not have to be huge. You can be selective in what processes to migrate to an ERP system, and you don’t have to convert everything at once – both of these steps will reduce the overall risk of the project. For example, you can implement demand planning systems first to shake out the bugs in what is traditionally a complex and parameter-sensitive application. The core financial systems of an ERP can also be phased in first before everything else.

Please choose the door through which your next software vendor will take you.  Image: Doors of Dublin, by Tim Sackton, edited to fit 569 X 368px, CC license.

Selecting a software vendor is difficult at best in the 21st century; here are some must-have criteria, in addition to, but perhaps more important than, cost and time:

Does it solve my problem? Does the software company’s system solve your business problem? Does its existing functionality match the business requirements you drafted?
Does it pay back? Do the financial benefits from the solution pay back the total cost of implementing it in three years or less?
Do I understand all of the solution’s costs? Have you accounted for initial license, recurring support fees, custom development costs for changes you want to make to the software, hardware costs, upgrades to your network bandwidth or operating systems on your current servers or PCs, the cost of the next version upgrade, the cost of consultants, of hiring backup staff for project team members, and travel?
Is the solution in line with my strategy? Does the system match your criteria for what types of information solutions you will invest in, now and in the near future?
Do I understand all of my alternatives, besides this particular vendor? Have you done your homework regarding software options available? Have you constructed an evaluation matrix and compared all the alternatives to one another?
Does my team have the time and skills to implement this solution? Can you secure near full-time people to manage this project? Is the system easy to learn? Is it intuitive? Has your team evaluated it and are they comfortable they can master it?
Do my users have the aptitude to learn it and become proficient? Can you envision your end users quickly learning to use all aspects of the software? Are there enough users who could become proficient enough to serve as key users and help other users with training and troubleshooting?
Does my team fully understand how this solution will integrate with the company’s other systems? Has the vendor demonstrated to your satisfaction the ease with which the system will integrate with your other systems? Are other enterprises already running the software with systems like yours? Try to get at least a conference call with those references to gauge the level of integration complexity.
How risky is this particular software alternative compared to others? Can the software be phased in without interrupting the business? If the solution fails or the team encounters startup problems, how easy will it be to keep mission-critical activities running?
Vendor reputation. How many enterprises are using the vendor’s software, and for how long? Get references and check them.
Can I find programming help in the open market? If you need customizations, can you readily find people to do the work? Or are you locked in to using the vendor to make all your changes?

All of this is of course after you have submitted and reviewed detailed RFPs from the most appropriate vendors.  You can build a grid or a table, with vendors/solutions across the top and your most important criteria down the left hand side, and weight the relative importance of each. The result is an overall score that points you to a solution that best fits your needs.

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

If you don’t know where you are going, you will wind up somewhere else.
– Yogi Berra

IT strategy is not a topic reserved for lofty white papers. It is something you see in action (or not in action) every day and every time you have a decision to make about your company’s enterprise software.

Why would a non-IT executive care about IT strategy? Because whatever your function as an executive, your success will depend on having the right technology tools for your company’s strategy, customers, profit goals, and future aspirations. And you or your department might be responsible for launching a big new system that could really hurt your business if it isn’t done right.

The most important thing about your IT strategy in the 21st century is not how impressive or savvy it is, but whether it fits who you are and what you want to be as a company.

Here are some choices:

The complete outsourcing strategy

Your company outsources all IT and software needs. It does not own any applications; it just uses them as a service. It pays these service providers to upgrade or further customize the applications it uses on an as-needed basis.

The strategy fits you because you want to devote your internal resources to the core business. Your firm is too small to afford a large in-house group of people watching over servers and networks and applications.

The pure ROI-based strategy

You evaluate and select software and IT investments according to strict financial hurdles. Every investment has to pay back within 24 months, and you include all external and internal costs in that ROI model. All projects are reviewed post-implementation to confirm the expected ROI was actually achieved. In-house vs. external solutions are selected according to the best ROI.

This strategy fits your firm because its culture is bottom-line oriented, and has many other attractive investment choices available. Investments in IT have to compete with other promising ventures.

The anticipated growth strategy

Your organization heavily weighs anticipated future needs in decisions about new systems. It looks ahead three to five years to anticipate what customers, suppliers and competitors might be doing. It might end up making a new application investment for purely strategic reasons.

This strategy fits your firm because its success hinges on having the most up to date information systems possible. A large portion of your revenue and profits are dependent on technology that enables you to create new revenues and control costs.

The complete in-house strategy

Your company’s business model is so unique, and its processes and competitive advantage so specialized, that it never finds what it needs in commercially available software packages, other than software for basic support functions like HR, payroll and accounting. It uses software programming languages that are well-known and well-established in the industry so that it has a large pool of talent available for its growing needs.

This strategy fits you because for your company the right software is a strategic necessity and an area in which it invests heavily. You need software solutions that are tightly aligned with your specialized business processes.

A stable, 30-employee company with no significant growth plans can do just fine with many off-the-shelf applications or one of the many SaaS providers now coming onto the market.

A vertically integrated auto parts maker with 3,500 SKUs and contracts with large auto companies probably needs top-of-the-line supply chain and distribution applications capable of strong integration with supplier and customer systems.

A credit card company with 4 million customers needs very secure applications with redundant backup capabilities and rich data mining software to analyze customer transactions.

Invest in applications that help you do excellently those things that are critical to your business. Go light on or buy generic applications for functions that you consider support, and not central to your business strengths, unless you see a clear, hard ROI for one of those areas. But get or develop the best possible applications for those functions that make or break the success of your business.

There is no general rule of thumb for these decisions, just common sense. A company with $10 million in revenue simply won’t be able to afford an application that will cost $2 million to launch and another $500,000 a year to support. The logic of aligning your software tools with who you are as an enterprise is just one more ingredient in staying out of the software money pit.

Software-as-a-Service is challenging the paradigm that software is a thing you buy, take back to your office and install. Looking back some day, we might shake our heads and wonder why any enterprise ever thought it had to purchase and physically install a copy of millions of lines of code that ran on a computer within its premises, just to transact day to day business.

On-premise going the way of cassette tapes……?

The market is receptive to more and more SaaS solutions, and software firms are positioning themselves to offer those products. Most of the big, traditionally on-premise software providers now offer at least some of their applications in SaaS form. For you, this will mean more choices.

But remember this: SaaS applications do not guarantee perfect performance and 100% uptime. They are still computer programs running on a server somewhere, and if those programs are buggy, unstable, corrupted, or lack proper expert support you will land in the money pit just as sure as if you bought that same buggy and unstable application and installed it in your own data center.

Are there any good reasons why you would want a traditional on-premise application?

Yes: security is one reason, in certain circumstances. No matter how demonstrably secure a third party may seem, you simply may not want to entrust your data security to a third party, period.

Your customers, particularly, may want the relative or perceived assurance of your own firewall surrounding your applications and their data. Their business relationship is with you, not the company hosting your applications.

You may already have economies of scale suited to on-premise hosting – plenty of server capacity, a built-in support staff, and developers on your team who are capable of building out the application the way you want it.

If you are positioning the application to be used by several divisions within your company, you may also want central on-premise hosting. You may want to tightly control modifications to the “core” system and also manage access permission levels among users, as well as the total number of users. These actions can significantly reduce per-user costs.

With SaaS applications, you still need to do the same due diligence you would do with a traditional on-premise application. The fit analysis, testing, and project management are largely the same, as are the same precautions to avoid the money pit. You can still spend a fortune modifying a SaaS application, as well as integrating it to your other systems and pulling data out of it for analysis purposes.