Introduction The rationale for buying software is compelling. The industry is forever comparing itself to more familiar trades, so how about this bit of hype: Could you conceive of a machine parts company building its own lathe or a restaurant building its own grill? (Okay, cutting-edge organizations might, but that is why there will always be custom software.)

While I am at facile analogies, executives think they can buy software like they buy a suit ­ add cuffs, take in the seat a little ­ ta-dah! Buying SAP is not too dissimilar from buying your first jumbo jet: a thousand little switches all set just so. Why are there so many switches? Because you may not want your switches set like they set them at the pharmaceutical company or the cardboard box manufacturer or wherever.

Fundamentally, data analysis is meant to answer the question, "What do you want?" Knowing what you want is a pretty good place to start when deciding what package, if any, will do what you want. Even after the crate of CDs arrives, you still have to configure the application. Something tells me the story Stuart Pim tells in his article is true. The project team chooses to ignore discord over the meaning of a key entity ­ a mistake I have also made.

Bob Schmidt consults for Stone Carlie and authors course work on data modeling. His CBT is distributed by IBM, Sybase and agpw. His book, Data Modeling for Information Professionals, was published in August, 1988, by Prentice Hall (ISBN 0-13-080450-9).

With tight budgets, expensive software, more expensive implementation services and 24-month-long project estimates, project managers are looking for ways to shorten the time frame for a software project. Is it still necessary to develop an integrated data and process model if you plan to select and implement a software package?

An effective analysis project prior to software purchase provides the users with an important understanding of the data relationships in their business. After analysis ­ but before they have spent all their money ­ the users will either know what they want or realize that they are hopelessly lost. When software is not measured against clearly defined needs, you may find yourself either woefully short of features (running Exxon on Excel) or woefully over built (Billings Boy's Choir Summer Fund Drive on SAP). With the data relationships in hand, you can choose software that supports the needs of your users. Software that has 99 percent of the data but only 50 percent of the functionality might be a good fit, but the reverse may not be true. When a software package is implemented, the understanding achieved through analysis shows users how to map their data into the database provided by the package, which configuration alternatives will meet needs and how to take advantage of user-defined tables and fields. In other words, development of a business data model is still the best way to achieve this understanding.

Right-Size Projects

Ten years ago, the biggest risk in software packages was the "absence" of software functionality in the marketplace. Because of the increase in usage of software packages, this is seldom the problem in a current selection. Most companies can find a software application that meets their needs. The primary benefit of a software selection is the prioritization of the available functionality. ERP packages today are offered in three "tiers," and price typically follows software flexibility and complexity. The biggest risk today is the purchase of "too much" functionality.

There is a distinct difference between the "Tier 1" and "Tier 2" ERP packages, but your company must be a very advanced organization to take advantage of many of the "Tier 1" differences. Some companies make the mistake of buying excess functionality with the intent of growing into the software they are not currently using. As a result of this logic, they find that the excess costs do not stop at the application purchase; they continue through implementation services, as well as through ongoing support. Complex software takes longer to implement, and the support costs (especially labor) for the "Tier 1" software packages are higher. Because of these differences, the "top-of-the-line" software package decision has a significant impact on overall costs.

If you think your business requires the "top-of-the-line" complexity, an analysis project with data and process models will confirm it. It should be proven that this cost is required before the investment is made.

So, let's say you bought the expensive one. You are part of the project team for a "Tier 1" manufacturing system implementation for a major packaging corporation and are ready for your final design meeting with the top sales manager in the division. You have completed the four-month conceptual systems design phase, established the system configuration parameters across the enterprise and are nearly complete with a gap analysis.

You think you've done everything right so far. You established an enterprise-wide scope and performed your design phase from planning through execution. You started with annual and quarterly budgeting and planning, worked through master scheduling, order management, MRP and procurement, production management, inventory control, shipping and receiving, and all of the financials.

Your project plan shows that you are on schedule and are nearly complete with the design of the system. The only thing that remains is ad hoc customer reporting. You have a meeting with the sales manager responsible for the company's biggest customer, who requires a special inventory report each month. You plan to show him all of the reporting flexibility of the proposed system and its Web capabilities. You have prepared a presentation to demonstrate one of his reports and have added some additional flexibility. You have been looking forward to this meeting because the sales manager has a great relationship with the president and will be a great spokesperson for the progress you have made.

What's Data Got to Do With It?

One of the biggest changes in the new system implementation is the concept of a revision to an item. In the old system, all inventory, production and cost were managed against an entity called "product." However, there is no entity in the software package named "product." Instead, the package uses the terminology "item" and a "revision" to an item to manage product information.

The package allows a business to manage production at the "revision" level, if necessary, and work with the customer at an item level. Customers order "items," and designers revise "items," thereby creating the "revisions" to "items." Each revision is associated to one (and only one) item. When a customer orders an item, the available inventory consolidates across all active revisions, and shipments are created from all available inventory. Product obsolescence is managed at the revision level with an "active/inactive" status field. If there are engineering changes to a product throughout its life cycle and the customer is indifferent to these changes, this flexibility can be used very efficiently. Production can be managed at the revision level, and order processing can be managed at the item level. This feature establishes a hierarchy to manage product information ­ and increases flexibility, but also increases complexity.

You saw tremendous power with the item/revision concept. The old system did not manage business rules established with product, each revision was a new product, and the system had no way to associate revisions. When a customer placed an order, the good customer service representatives kept a cheat sheet of related product numbers so they could find the interchangeable inventory. Many of the customer service representatives didn't keep up with this, so obsolete inventory continued to grow. The key project benefit is a significant inventory reduction, which justified the cost expenditure for the expensive software package. The item/revision feature should allow you to manage inventory so that you can keep up with obsolete inventory, but you have to decide how to implement the feature.

You have done your research, and you have three options:

  1. Have item usage only, and ignore revision tracking,
  2. Have item usage with revision tracking and all inventory transactions at the revision level, and
  3. Have item usage with revision tracking and all inventory/shipment transactions at the item level.

How do you decide which one to use? Do you: a) pick the design that matches closest to the old system, b) pick the design that meets the users' requirements, or c) pick the design that provides a more stimulating work environment for the IS staff.
You think "b" is probably the right answer. But you also think that you shouldn't have to toil over these tough choices with this expensive software package because you aren't writing any code, and these software packages are supposed to be designed so that you can change your mind. "Hey," you think, "if we're wrong, we'll just need to reset some switches."

But this decision is a critical one, because it affects how everyone works with inventory, especially the warehouse people. This is important because these are the people who are going to save all of the money to pay for this expensive software package. So, you decide on option "3" because it provides the most flexibility to customer service, and it will make the warehouse people's life much easier.

There. You've found a way to achieve the inventory reduction using the flexible software package, and you didn't have to write any custom modifications. In order to implement this design, you must set up strict rules regarding revisions, and everyone in the system must strictly follow those rules. These rules must be set up in "configuration tables," and you assign resources to accomplish this task. Then you set out to explain the "item/revision" concept to the users.

Initially, all of the users struggled with this item/revision concept. The product was the heart of the old system, but the package application doesn't have a product. You expected this issue; so before you started the conceptual design phase, you spent three days discussing the concepts of "item" and "revision." After all, your project approach was a "user-driven" one. You presented the benefits of the item/revision feature to the users and focused on the revisions rule ­ all revisions for an item must be interchangeable for our customers.

In fact, the only thing the users remembered after your discussions was the revision rule. It was important to validate this assumption before you could move forward. The customer service representatives confirmed the revision rule for you.

The result of your conversation with customer service made the rule simple. The thing you called "product" in the old system was an "item" in the new system. All of the customer service representatives joked about "the computer guys making such a big deal about the item thing. No wonder these projects always take so long ­ they always analyze everything to death."

The core project team knew that the concept "item=product" was incorrect. It really didn't matter, you thought; the users didn't have to understand the difference now. They would see what you meant after the system was in operation. You thought you had done the analysis to eliminate your risk in this misunderstanding. You configured the applications so that customer service and the warehouse would execute transactions at the item level, and production would report at the revision level. The application package would have the production history at the revision level, which would enable the quality control organization to gather statistical information for each revision. All revisions to an item would consolidate for inventory control purposes. After a few weeks of careful system configuration, the package would take care of everything "behind the scenes," and you wouldn't have to spend additional time clearing up this misunderstanding. After the users worked with the software for a few months, they would see the true meaning on their own.

Meeting with the Sales Manager

He comes prepared. He starts off the meeting saying, "I heard this system was pretty expensive, and that you guys have been going at this for about six months now. But I hear it's going to help us reduce our inventory, and we need to do that. I'm easy to please. If you guys can do this report for me, I'll be happy."

Luckily, it's the report you have prepared to show him. It's an inventory report he must currently develop in a spreadsheet, sorted by package style and product. He does a download out of the current system for all products, sorts out the products his customer wants to see and works with customer service to arrange all of the "like products," or revisions, together. He must build this from scratch every month, and it takes about a day each month to develop.

You immediately ask about the reason for the report. You find out that the user of this report is the customer's corporate buyer. He is responsible for managing inventory levels for your products, guiding your company by establishing periodic inventory levels and reorder quantities, and minimizing his company's exposure on obsolete products. You quickly determine that the report requires you to manage inventory at the "revision" level so that he can understand his exposure on older "versions" of the product.

Your mistake becomes clear. Your customers place orders on "revisions" ­ not "items." They want you to report inventory on "revisions" ­ not "items." Your data model is wrong, and it's going to cost you time, money and, most likely, some political capital.

Your face turns pale. In order to avoid any embarrassment, you focus your demonstration on everything but the content of the report. You show the Web capabilities of the system and how the customer can access reports on the Internet. After ten minutes of this dog and pony show, the sales manager interrupts you and asks, "But what about my report? Show me the numbers."

You explain that you will need some additional time to prepare the details. He replies, "Listen, I'll be happy to come back when you are ready. It's Friday, I'm out of town next week, and I have to do my quarterly forecast the week after. Call me to schedule a time after that." You see him walk into the president's office and close the door.

After the meeting, you have a team meeting to understand the issues that have resulted from this meeting. It is Friday, and your weekly status report is due to the president by the end of the day. The following are now the top issues, and they came from a simple meeting with sales:

  • Your inventory model is flawed and must be revised. You do not know the correct approach, so you must develop a model that best represents business requirements.
  • Once you understand the appropriate structures supported by the system, you must find the best method for communicating this model to the users, validate the model with them and build consensus on any changes that will occur.
  • Luckily, you uncovered this problem in the design phase, but you must redevelop business procedures according to the changes and reconfigure system parameters accordingly. In one week, you fell four weeks behind.
  • The warehouse will now need to track inventory at the revision level, which adds significant complexity in the warehouse and was not planned for. Will you be able to achieve the inventory reduction targets with this expensive new system? Now, you're not sure.

Publications for information professionals are filled with horror stories about software package implementations that were in trouble. These projects are consistently over-budget, months late and short on the promised functionality. Many of the problems these implementation projects face probably could have been avoided with a user-involved analysis effort prior to the purchase of the software package.
The users of a business system must understand the data relationships to most effectively use any application. The system is not fully implemented until this understanding is established. This requirement does not "go away" in a software package implementation; it is merely postponed until later in the project. The cost of errors in data definition is as costly in a software package implementation as it is in a custom-developed system.

It Shouldn't Take Long

The 80/20 rule applies to most software package selection projects. An eight-week analysis project should eliminate 80 percent of the software selection risk. A structured analysis methodology, performed by experienced data and process analysts, is critical to success in this type of analysis project. Scope definition for this project is very important and will enhance the value of this effort.

It is probably not necessary to perform analysis on the entire scope of the project. Analysis should focus first on your customer interface processes and then on your supplier processes. If there is time, you can focus on your key internal processes ­ those processes that provide a competitive advantage to your company.

This short, focused effort will drive out definitions of the key entities and will uncover the need for complexity in critical areas. You will build extensive definitions of customer, product, supplier, employee, customer order, production plant, warehouse, purchase order, inventory and cost. These definitions will guide you to the required complexity and assist in prioritization of system requirements.

Software package implementations still have risk. You always read about those companies who have spent millions of dollars on software package implementations and are unsatisfied with the results. You should remember the lessons we learned from custom development: effective analysis can reduce your risk in system implementation.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access