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.

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.

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

Photo: Data Center, by Bob Mical, CC license

Early in my career I couldn’t stand anyone talking to me about master data. It just wasn’t interesting, and seemed to be just a minor detail in how systems run.
I have since learned that (incorrect or inconsistent) master data can stop in its tracks the coolest, most sophisticated and expensive enterprise software anywhere, which means it can stop all kinds of transactions in your business.

Master data is data that should have a consistent definition and format across your organization.

For example, a ‘finished good’ (product ready to sell) in a manufacturing company should have the same spelling, Universal Product Code (UPC) and internal product number whether it is listed in a sales report or a manufacturing report.

A gallon of Sherwin-Williams paint, for example, might have the following pieces of master data:

For applications to exchange data with one another, regardless of method, they have to use the same definitions of data. If the sales application uses “lbs.” as part of the description, and the finance application uses “pounds,” some type of translation (more software code) will have to be built between the two applications.

If your master data is not standard across your enterprise, the extra code necessary to translate incongruous data will add to the complexity and cost of integration. These custom integration algorithms will be specific to your enterprise and therefore make your whole application structure more difficult for a IT new hire or a contractor to understand.

To further control costs and complexity of integration:

• Use a hub structure if multiple applications need the same data. This could be an “exchange” where pieces of data are posted then retrieved when needed by applications plugged into the exchange. This avoids creating spaghetti (your application maps look like spaghetti).
• Document everything clearly and insist that all documentation be kept current. Otherwise, you will end up with a complicated setup that is mission critical to your business but that only one person is familiar with.
• Let your ERP system define your master data standards, and keep those standards consistent in all systems. If you have an ERP system, most likely it required you to define and set up master data. Since ERP systems usually span multiple functions, the master data setup is shared among functions and therefore common to departments like sales, finance and manufacturing. Keep these standards in place and use them to define the data transfer with any new application.

If you visit OmPrompt in the UK you can stay in the nearby dreamy, historic, and beautiful town of Oxford. Photo by Tejvan Pettinger, CC license.

What if you want to make sure all of the data on a customer’s order is correct before it is processed in your systems?  Or if you want to stop orders that you can’t fill based on time constraints?  Many firms at first apply humans to these tasks (customer service), but what if you process 55,000 orders per year?  There must be some way to automate this screening process, right?

There are at least three ways to handle this problem with software.

The first is to modify your ERP system, to incorporate the rules you will apply to every order that is received.  Not only will the ERP system apply the rules and identify exceptions but alert you to those orders that must be stopped and changed before proceeding through the order cycle.

This is certainly a viable option, but you’ll find yourself pouring lots of money into it, with no end in sight, because as soon as you successfully incorporate a set of order checks, the business will come up with a new set of checks based on a new logistics or pricing strategy.  Most ERP systems are not built with user-configurable parameters; changes require programming by expensive resources.

The second is to build some type of middleware filter.  This is a custom application that every order would pass through before entering your ERP system.  The middleware would catch and hold up non-compliant orders.  A lot of firms adopt this route, because it is so much less expensive and much more flexible that tearing into the guts of an expensive ERP system.  And there is no shortage of eager programmers, within company IT departments, who want to build such a tool, in the language they know best on the computing platform they know best.

This second option is better than the first, but barely.  The second option makes you dependent on the genius that builds and maintains that middleware tool, and that is almost as bad as being dependent on an ABAP (SAP code) programmer.  And there will be instances where no matter how brilliant your middleware architect, certain business requirements will be beyond the capabilities of him/her and/or the software they have created.

The third option is to outsource your order capture, partially or entirely, to a firm that has the systems agile enough to handle the ever changing order filters your business may want to apply.  The advantage of these firms is that they serve as adapters: the incoming order is converted to a standard computer script where all of your rules can be applied; the script is then converted to the digital code (such as EDI) needed by your ERP system.

One firm that does this is UK-based OmPrompt, which specializes in automating business processes for large firms all around the world.  Their services are based on transaction volume and are very inexpensive relative to software modifications or building your own system.

I favor outsourcing the job not so much because someone else can do it better (although that is true) but because you cannot predict what is coming down the road in terms of new business requirements.  You need an open system, an infinitely-adjustable capability, if that is possible.  And firms that make their living on being adaptable to requirements like yours will always have more value to offer.

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.

Two years ago I began exploring “cloud” software for integrating our company with its trading partners. This is how one company explains the benefits of its cloud software solution:

“Cloud supply chain platforms invert the traditional EDI (Electronic Data Interchange) hub equation by moving the data processing and linking logic from the partners at the ends of the spokes to the center hub itself. In this model, the entire value chain community leverages a common core technology utility so that all partners link to a single version of supply chain truth across the entire network.”

Here you have conceptual-speak, what sounds like preamble, and lots of jargon made to sound sensible (who can resist “a single version of supply chain truth across the entire network”?). In the section that is supposed to answer “what is this technology made of?” I come across this explanation:

“First, importantly, it is technology designed for the deep and detailed processes of a specific B2B domain. It is not generic. In this respect it diverges sharply from traditional EDI technologies that were designed for file transport and translation across all processes. Traditional systems take a “one size fits all” to information exchange: EDI file delivery for everyone, but a complete picture for no one.”

There’s more:

“In rich process domains such as supply chain execution, where the processes are long-lived and highly collaborative, what is needed is an information transformation layer that is knitted to the specific business processes at hand. Only by understanding the underlying and highly detailed data models and linkages of the critical business objects themselves can an information exchange platform create tight mappings to process. If an EDI VAN (Value Added Network) transports file packets, but is blind to the contents, the next generation platform interprets at the content level — it applies technology to the inside of the packet, in other words.”

None of this made sense to me, so I met with the firm’s representatives.

What they mean, as it turns out, is that their cloud software acts like a big private Facebook page, where your partners post data and transactions, as compared to traditional EDI, which is like passing a message to your partners in a straw where only you and they can see what’s in the straw.

One of the best ways to start a constructive conversation with a vendor is to say, “Ok I’m stupid. Connect the dots for me. You can link me to my trading partners like we’re all on Facebook. So what? Do I get rid of my EDI? What does that save me? Do I reduce inventories and order lead times? Will my customers and suppliers love me for doing this and will they partner with me on this approach?”

If a software vendor is good, that firm will assess your business situation first – your operation and processes – before trying to sell you anything.

So to handle the FUD experience you have to break the spell.  Be the spoiler in the room who is not going along with the feel-good lingo emanating from the vendor.

In many cases I think traditional ERP is becoming more and more unnecessary.

I don’t mean that the concept of ERP is become unnecessary, just the traditional ERP on the traditional platform as we have known it for the past 15 years. In the future I imagine the following trends will bring about this prediction:

• Enterprises will no longer be willing to spend huge sums for year(s)-long projects where they end up owning, hosting and caring for software that requires upgrades every 18 to 24 months, not to mention the expense and management of IT staff to support the data center, integrations, system backups and nonstop user demand for new features and changes to the software.
• Organizations will trend away from capital investments in software and toward paying for software as an operating expense. This is because: 1) a large capital project is much harder to sell than a relatively small long-term increase in operating expense; 2) associating software expense directly to the function that uses it is a better accounting practice; 3) in an ROI calculation, the added operating expense of a SaaS model only has to be offset by yearly savings brought about by the new application, instead of requiring that three or so years of annual savings pay for the entire cost of the new system.
• The software market will continue to offer new products and services that, while not a complete ERP system, could replace large components of an on-premise ERP.
• Companies will begin to piece together “point” solutions – single-purpose applications – in the cloud as SaaS solutions. By networking their applications in the cloud, they will achieve better functionality, far greater flexibility and lower cost than a traditional ERP system

This trend is not where the big ERP software vendors want to go. To them, the traditional model is quite profitable enough, thank you.

So there is opportunity for you.

• Identify the parts of your enterprise that gain the most from new software solutions
• Identify the information or transaction flows that must be integrated to realize the full value of your project
• Concentrate on software that helps you achieve 1) and 2); if it is a full ERP system then so be it, but I think the value can be isolated and realized in those important areas without making the huge investment a traditional ERP project requires.