Ad for Infor ERP at O’Hare Airport, image by Steve Brodner, CC license

If you search for “lean ERP,” most of what you’ll read is about whether or not the traditional ERP system supports “Lean Management” concepts. The argument is that Lean Management is based on the pull of demand and Just-in-Time principles whereas traditional ERP is based on set lead times, planning windows, and building inventory based on a forecast. It’s a fair point.

But what about a truly “lean” (skinny!) ERP system – one that is simple, inexpensive, and easy to implement and maintain? Everyone knows that the typical ERP project, and the maintenance of the system thereafter, has more in common with the word “fat” – as in fat timelines, fat cost, and fat (extensive) complexity.

Stripped to its essentials, an ERP system is supposed to

• Tell you what resources (materials, labor) you need to make and sell your products;
• Serve as a system of record for standard business transactions;
• Record and store the financial results of all transactions

But many companies want their ERP system to do everything from managing specialized customer service rules to providing supply chain analytics – that is a mistake. There are better alternatives.

And ERP vendors want the footprint of their product in your business to be as big as possible (more modules, more users = more revenue).

Both of these factors make the typical ERP solution complex, bulky, and expensive.

A Skinny ERP is one that is limited in scope, relatively un-modified out of the box, and no more complex than what is needed for your business. It largely delivers the essentials mentioned above, and no more.

Here’s how to get there:

• Make peace with your ERP solution. Let it do what it was designed to do, and give it accurate and consistent data across the enterprise. I’ve seen companies try, and largely fail, to modify the guts of their ERP system to automate workflows for order processing, customer claims, weight-based pricing, inventory reservation, and other processes with complex business rules and logic the ERP package wasn’t built to do. The modifications usually delivered a fraction of the intended functionality.
• Use other, nimbler tools and 3^rd party services to manage what doesn’t naturally fit in your ERP system. It’s now possible, for example, to send your all of your transaction data, automatically every day, via file extract, to a vendor’s cloud-based server, and use the vendor’s very rich analytics software to create the facts and insights you need, with no upfront costs, on a pay-by-month basis, with no annual contract. Stop trying to make your ERP a reporting system.
• Start managing the “enhancement request” desk that most IT departments have to entertain the user population’s list of desired improvements to your current systems. Some needs may be a natural fit with an ERP and you should do them. But many will be enhancements — suggested by smart and creative people — that improve only the part of the canvas they are looking at, and really don’t belong in the core ERP system. Go ahead and build them anyway, and you’ll have a very fat ERP.
• Question why you want to manage the business process at all, rather than letting a 3^rd party handle it for you. Is the process so important to the business that you need to control it in-house? You can outsource almost anything, and one advantage of this is that usually the 3^rd party specializes in the processes you want to jettison. An example is transportation: instead of trying to make your ERP manage shipping, or buying expensive transport software, let a logistics firm handle the whole thing – dodging the whole question of how to enable the process with your own software.

Start thinking of your ERP as the basic plumbing – the core – and begin to explore not how you change that core, but how you supplement or compliment it with the many alternatives now available.

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.

Image: Singapore Finance District, by Joan Campderros-i-Canas, CC license

“Financials” is a term used by software vendors and others that normally includes accounts payable, accounts receivable, balance sheet and P&L. There can be extensions of this definition to include such areas as payroll, treasury (bank account inflows and outflows), and tax management.

In an ERP system, all of the required financial postings are made as other transactions take place. A shipment to a customer generates an invoice and posts the accounts receivable for that customer. Production of finished goods creates inventory with its corresponding value on the balance sheet. Benefit: reduction in administrative labor needed to manually post transactions from one system to another.

Because the Finance module in an ERP system records all the operating transactions, that data resides in the main ERP database, which means it can be extracted for reporting and analysis purposes.

If the Finance module is “robust” enough, it will already have built-in queries or user-defined reports to analyze the basic transactions such as sales by customer, manufacturing costs by product, and other “intelligence” needed to manage the enterprise.

But my experience is that a standard ERP system never satisfies the analytics needs of a good finance department. In this case, you have two choices: spend a good part of your budget building custom reports in the ERP system (not recommended), or invest in an application-neutral reporting database.

This means more information is available that is critical to evaluating the performance of the business. Calculating actual dollar benefits of a new ERP system here can be difficult, but consider what you could save if you knew things like how much overtime pay you incur and in what areas of the business, how much profit or loss you are trending year to date, and which products generate the least profit margin.

ERP systems usually define authorization levels for different types of users, allowing control of sensitive transactions. The Sarbanes-Oxley law and other regulations require separation of duties to ensure financial controls are followed. Benefit: centralized control of transactions users have access to and a system infrastructure that satisfies auditor requirements.

An ERP system can enable you to match invoices with receipts and purchase orders so that what you pay for is what you ordered and what you received. The purchase orders, receipts, and invoices are all in the same system, so the system can compare them and immediately determine if the invoice is valid and should be paid or if it’s not. Benefit: elimination of overpayments or duplicate payments to vendors, reduction of paperwork and manual comparisons reducing administrative overhead.

An ERP system can also manage your contracts with vendors, including pricing and terms of payment. This means that data from invoices can be instantly compared to contractual terms to make sure the invoice is correct. The benefit is the same as above – elimination of overpayment. If your enterprise is large and is processing a large volume of vendor invoices you are bound to have at least a small percentage savings – say 5% of the amount you spend — and 5% of a big number may be enough to pay back at least part of the ERP investment.

A price-shopping or auctioning application or an online buying service can be an extension of the ERP system so that you can search for the best price for your materials, goods, or services, select the vendor, and place the order. Usually these apps and web-available services are specialized according to what you are buying, such as transportation and delivery services, office supplies, basic materials such as standard corrugated packaging, shrink wrap, paper stock, chemicals and industrial supplies, and more recently energy sources such as electricity and natural gas. Benefit: getting the best price and terms and automatically creating a purchase order which is integrated to your financial system for proper payment. Again, the dollar benefit can be a percentage of your total spend, especially if you think you haven’t opened up your purchasing to alternative vendors for awhile.

When purchasing is part of your ERP the proper postings to financial accounts are automatically done. When you issue a purchase order an entry is made in the ERP system that authorizes receipt of whatever you are buying. When you receive what you are buying a payable is created which goes on the balance sheet as a liability. All the accounting is taken care of.

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.

Image: Balzac Fresh Food Distribution Center, by Walmart

Few areas of the software market in the past ten years have been as hot as supply chain.

Supply chains in many industries have been trying to cut costs out of distribution networks while reducing order lead time and inventories. They want solutions for modernizing what has traditionally been a backwater: truck booking; warehouse management; pallet management; order picking; truck loading; yard management; and delivery discrepancy management.

This category also includes software for demand forecasting and optimal product deployment throughout a company’s distribution network. Demand planning software can be fraught with peril for companies lacking the discipline and attention to detail needed to master these applications. These applications can be difficult to evaluate, from a buyer’s standpoint. Proceed with caution.

Companies in the supply chain space, known as SCM, (supply chain management), include industry leaders Oracle and SAP, and firms like JDA Software, Manhattan Associates and Red Prairie (recently merged with JDA). JDA is a firm that has grown by acquiring industry-leading supply chain management applications such as i2 and Manugistics. The company claims that 6,000 firms worldwide use its SCM software.

Supply chain applications can be single-purpose or inter-connected, like an ERP system. The supply chain is like a business-within-a-business: it has at least five processes that must be interconnected in some way: 1) demand planning (what will customers order?); 2) distribution network planning (where should we store it before it is shipped to the customer?); 3) manufacturing scheduling (how much should we make, when?); 4) material requirements planning (MRP – what raw materials & supplies do we need?); and 5) warehousing, transportation, and shipping (store the product and ship it to the customer when needed).

A single-purpose application (Demand Planning, Warehouse Management, Transportation) will claim to solve your problems in one or maybe two of these areas. An inter-connected supply chain application will manage all five of these areas. Vendors that offer an inter-connected solution will present themselves as offering total SCM, or supply chain management, solutions.

It’s hard to carve up the supply chain and say one application is better in one area than another, because probably the most important thing is the integration between the five main segments of demand planning, distribution planning, manufacturing scheduling, MRP, and warehousing and shipping.

If you had to choose, the demand planning software might be most important, unless your customers place orders way in advance of shipment; on the other hand, you might have multiple manufacturing locations or warehouses and you need a solution for where to make and ship your product most efficiently.

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.

Talk about disruption!  An anti-Uber taxi protest in London, June 11, 2014.  Photo by David Holt, CC license.

Does anyone think Uber would exist without mobile computing?

You might think of mobile as providing convenience, which it does, but there are deeper and more significant advantages of having mobile as an asset in parts of your business.

The most lucrative uses of mobile are in the selling channels.

Mobile versions of online ordering sites.  This capability increases the surface area of your selling space; the consumer is exposed a higher percentage of time to your products and services and the opportunity to buy them.

Being able to find your web site on a smartphone is not the same thing; at the very least your site has to be “responsive,” so that the online version scales down in proportion to a mobile device.  Otherwise your site looks terrible on a smartphone and is nearly impossible to use.  For more effective results, have a mobile app built and connected to your back office systems.  Vendors in this area range from thousands of independent programmers to companies who build mobile apps and network them to your systems, such as Mashery, Sourcebits, and DMI, and full-service B2C providers such as CapGemini, Infor, Accenture, and Deloitte.

Close-the-sale documents in mobile form.  When buyers decide to buy can be uncertain; a sales call can be a propitious moment.  Waiting for the necessary forms and signatures risks losing the sale in the interim.  Document-signing has moved to electronic form (DocuSign, eSignLive, and ElectronicSignature.com), opening opportunities to conclude in mobile form all kinds of commercial transactions.

Sales rep access to company sales order and other systems, for order placement, product demonstration, or sharing of data and insights.  In-store stock replenishment has been done for many years by companies that distribute directly to retail stores via route drivers. But these systems were/are usually expensive and custom-built, with very narrow single-purpose capabilities.  The smartphone and its digital network changed all of that.  Don’t under-estimate the value of sales people with tablets who can share upcoming marketing plans and data confirming promotional lifts in sales from prior events.  For more on this, peruse this link, which discusses a wide range of mobile applications for use in sales.

Point-of-delivery generation of invoice, credit, and debit transactions.  In many businesses, point-of-delivery processes are extremely inefficient.  Delivery discrepancies are hand-written on paper copies of receiving documents, which are then sent to offices where the data is entered into a system.  The delivery data flows back to the shipper, and is investigated by back office people.  Inventory and customer accounts are adjusted for the discrepancies.  The customer’s payment — which differs from the invoice — is received, and short-pay amounts are assigned to special accounts.  Good automated point-of-delivery solutions can usually be found from transportation or logistics management software providers, such as JDA, LeanLogistics, Logility, Infor, or TecSys.

For more on mobile app usage, check these out:

The Mobile App Development Playbook for 2015, Forrester Research

7 Ways Mobile Apps Are Driving Revenue for Businesses

How Businesses Are Using Mobile Apps – 2015 Canvas Survey Results

Inside a Red Wing shoe factory.  Photo by Nina Hale, cc license.

The supply chain – a term used to describe all the activities needed to bring goods to market, is a natural beneficiary of a good ERP system because the supply chain extends from one end of an enterprise to another. Often the individual parts of a supply chain run on their own systems – a system for raw materials, another for planning finished goods production and deployment, and so on. It’s possible to have three or four separate systems running different parts of the supply chain. With an ERP system, all parts of the supply chain are connected to one another.

All of the costs and activities associated with each part of the supply chain are in one place, and they are mutually dependent on one another as either inputs or outputs. It is at least theoretically the logical software equivalent of the connected enterprise. And if the enterprise is truly connected and coordinated, then theoretically there is never any wasted inventory, lost sales, out of stocks, overproduction, late deliveries, etc.

A good ERP system will coordinate the supply chain like this:

• It will have a sales forecasting module that allows users to source historical sales data and model it to derive projected sales;
• The projected demand, by day, week, and month, will automatically determine quantities of raw materials needed, where, and when;
• The required materials will automatically be converted to purchase orders for those raw materials;
• The projected demand will determine a production schedule by plant and a schedule of where the finished goods are to be shipped;
• Sales orders are received, checked, confirmed, and sent to the warehouse or distribution center for shipment;
• Sales orders will “consume” a sales forecast so that managers can track shipments against projected sales;
• Sales orders will be routed for delivery via the most efficient method of transportation and transportation providers will be confirmed and scheduled;
• Inventory will be shipped to distribution centers according to the geographic demand of product;
• Distribution centers will receive sales orders for shipment, and shipments to customers will recorded, posted to financials, and used to generate an invoice;
• Warehousing and transportation costs will be posted back to the financial system and the corresponding accounts payable will be created.

For more on this topic, Gartner has some interesting research here.

Photo by Blake Patterson, CC license.

See those app icons on your iPhone? Don’t you think it makes sense to put corporate apps on an iPhone too? Yes, as long as the interface is easy and you don’t have to type a lot on your tiny glass screen. Enterprise apps are going there, and that means the desktop/laptop is moving into the palm of your hand.

This is a good thing, and it’s not just about convenience. There are sales to be made. Employees in customer- and partner-facing roles want the superior capabilities of Apple or Android products to enhance their selling stories or engage on a different and more dynamic level with customers, partners, banks, and the general public. Seeing is believing, and only mobile computing brings that to the field in an effective way.

To capitalize on mobile, you need software on the device and a way for the device to reach your enterprise systems. The apps that check you in for your flight are programs made to run on an iOS or Android device, which then connect over the digital network to an interface mechanism that is the connection to the airline’s main reservation system.  It is not difficult for your enterprise to do the same; there are many firms that can build apps and also provide the integration to your ERP systems.

But most of the mobile-platform software needed will be custom.  Enterprise software vendors are starting to offer mobile versions for small parts of their entire system solution. SAP says its Retail Execution mobile app works with its enterprise customer relationship management software to provide “anywhere, anytime access to data from mobile devices….”

Oracle offers Business Approval for Managers, a Smartphone app to approve expenses, purchase orders and other pending transactions.

Mobile also offers the promise of a totally new interaction with your ERP system. Out of the box, basic transactions – like determining quantities of raw materials required and placing a purchase order for those quantities – is a multiple-screen, multiple data entry affair for the leading ERP systems.

As your business grows or becomes more complex, you need good ERP system jockeys, and more of them. But a mobile app is the perfect consolidator of unnecessary steps. A PO creation in your ERP system that is three screens and eight fields of data entry could be simplified to four taps on two screens.

I believe that many enterprises have or will eventually realize that a large part of their work force is devoted to feeding systems like Oracle and ERP the data those systems need to create transactions, reports, and messages needed to keep the business running.  And many times that data has to be created in Excel or other systems, in order to give the classic ERP system the pristine data it needs. This is a gross misuse of talent, and can only go on so long.

I have seen smart young SAP users figure out how to automate the in-feeds needed for everyday transactions.  They are resourcing what they know to make their life simpler, and much of what they do is exactly what mobile apps do — consolidate steps in a transaction.

The mobile app is the model — simplicity and intuition — that big ERP vendors need to invest in.

Photo: “Trails in the Sand,” Dubai, by Kamal Kestell, CC license

If “Humanscale” computing is managing bags of sand, “Hyperscale” computing is managing each individual grain of sand in every bag.

“Hyperscale” computing (HC) is the processing of data, messages or transactions on a scale orders of magnitude larger than traditional computing.  HC is becoming a need for many businesses.  Why?

Consider a company that sells bottled water.  Its main business used to be selling truckloads full of cases of water to big grocery chains.  It has 25 different products, or Stock Keeping Units (SKUs).  The big grocery chains then distributed cases of water to its stores, which numbered 20,000.  The data requirements for the water company’s computers was manageable, even as the company grew rapidly.

Now, the company wants to analyze the performance of its products on store shelves by measuring things like velocity (how fast the product turns), price compared to competing products, and out-of-stocks.  It’s customers — the big grocery chains — are offering to supply data from their systems on every scan of every product in every store, because they too want to improve the performance of products on the shelf.

In one month during the summer, about 3.5 billion bottles of water are sold.  A data file from just one big grocery chain runs to 3 million lines.  How and where will you process this data?  Traditional databases will be too slow.  You will need superfast databases that distribute computing to many servers — this is called in-memory, or massively parallel computing.  This is an example of hyperscale computing.

Other examples where you would need HC: selling direct to consumers through their smartphones, where you might have to process millions of transactions say, during the Christmas holiday season; gathering machine data every second to monitor a machine’s performance (a General Electric turbofan jet engine generates 5,000 data points per second, which amounts to 30 terabytes every 30 minutes); and managing millions of product-attribute combinations.

The computing tools for hyperscale will not be found in your ERP system.  Trying to engineer your existing systems to handle hyperscale data and transactions will be a costly failure.  But there are tools available on the market today, and many of them are found in cloud applications, and in application hosting providers.

Cloud application and hosting vendors usually have much larger data processing capabilities, including automatic failover and redundant servers.  You can take advantage of this capacity.  For example, you can obtain, from a leading application hosting provider, at a cost less than the monthly rent of an apartment in New York City, 30 terabytes of storage and a massively parallel computing environment.

My advice:

• Identify areas of your business that are significantly under-scaled, or where you have large gaps in business needs compared to processing capability;
• Pick one and design a pilot project (many vendors are willing to do this with you at very low cost);
• Measure results and benefits, and if beneficial, expand the solution to other parts of your business.

It’s probably not OK to ignore this trend.  Even of you don’t need HC today, think about the future and where commerce is going.  If you don’t gain the capability for hyperscale computing, one or more of your competitors probably will.