Network Computingwww.networkcomputing.com

>>   Be prepared. The beginning phases of preparing for ERP are like any other implementation's opening steps. Select a vendor and assess what impact its applications will have on your existing network. Business and growth requirements are key to product and vendor selection. A specialized business may choose a second-tier ERP vendor that has applications tailored for a specific industry. PeopleSoft, for example, has focused on financial-service applications. As you start the vendor- or application-selection process and conduct a specific technical audit of your network, keep these issues in mind.

Different databases have different pluses and minuses. Oracle, for example, will work only on an Oracle RDBMS (relational database management system). If you're running Microsoft SQL, installing Oracle 11i could be a problem. Many firms have begun to standardize their applications on IBM DB2 Universal Database as the preferred RDBMS. DB2 is regarded as highly scalable and a good performer on a variety of hardware platforms. Make sure you have enough space for data when you conduct a technical audit on the database.

ERP data stores are growing at twice the rate they were five years ago. Vendors have put so much functionality into their new applications that the data volumes can kill you.

Sizing the database can be tricky. Performance falls when database size grows, so it's best to keep the number of transaction-heavy databases to a minimum. The challenge is to figure out how to make your business data readily available without burdening the OLTP (online transaction processing) database. One smart move during the preparation stage of the implementation is to figure out a way to archive closed transactions from OLT to an online archive on a periodic basis.

Database sizing is a project in its own right. Generally, the vendor and/or the implementation partner will have a formulated approach and, after determining the current estimated data load, will determine through a series of formulas what size database you need.

You need to ascertain which legacy systems stay and which go. An assessment of potential network data movers needs to be performed, and you'll need an interface strategy. That strategy will determine what additional network or system requirements are necessary.

>>  Consider the data-conversion process. Convert data early and often. Data elements are often "cleaned up" and improved because every legacy database has tons of irregularities. Experiment with conversion utilities early on -- you need to root out any data-conversion problems. Moving a huge number of records to a new environment is a big task.

>>  Consider scalability, connectivity and downtime requirements. You can never have enough bandwidth or storage space, so scalability needs to be a key consideration, particularly if your company is doing e-business. The amount of storage space per user depends on the situation. A casual user requires less storage space than a frequent user who is constantly processing orders or transactions. Baan estimates 10 MB per year per employee in database records. This does not take into account the actual product or process definition data supported by the RDBMS metadata.

OuterBay Technologies estimates a range of 15 MB to 45 MB per employee for enterprises with significant operations, such as manufacturers. The storage per employee will depend much on your data-retention plan and at what intervals you purge and archive data. Aggressive use of purging and archiving can drive the number down and save the company significant amounts of money.

For bandwidth, the rule of thumb is to plan for 10 concurrent users per 56-Kbps WAN line. This number may be adjusted based on the specifics of each organization's implementation, as the average bandwidth per end user will vary by application and functional area.

Bandwidth specification depends on the application. For this reason, simulation can help determine your exact needs. Several years ago, when 3M was installing a PeopleSoft application, 3M brought employees into a simulation lab to get a sense of how much bandwidth would be required. By simulating the transaction process, the company found that each user would require 20 Kbps of bandwidth to access the application in an acceptable time frame. 3M found that its existing circuit could hardly support two simultaneous users. Rather than upgrade numerous circuits, the company moved to a different version of the software.

>>  Consider hardware requirements. Every ERP vendor has a list of hardware it supports. But just because an application can run on a hardware platform, that doesn't mean it should. For example, a $1 billion dollar company with 400 users probably should use something heftier than Microsoft Windows NT for its ERP platform.

Baseline hardware requirements include not only the back-office machines, but the desktop requirements in the field. Too often, end-user systems are given short shrift. IT staffers have heavy iron on their desks, and it's easy to forget about the guy on the loading dock who's working with a 486.

>>  Scrutinize your hardware support contracts. Do they provide a level of support consistent with your goals and requirements? More vendors are providing specific support tailored to ERP applications. Knowing this can aid in hardware selection during the implementation period and beyond. Be careful when you assess your hardware needs. When vendors first sell their software they tend to downplay the need for additional or different hardware because it increases the costs of implementing their systems.

>>  Consider downtime. Backing up, tuning, and upgrading hardware and software will require downtime, but the key question is, How much? In conducting backups, clustering solutions may let you perform nondisruptive upgrades. A cluster member, such as a server, can be disassociated from the cluster, so when you're upgrading and doing tuning procedures on it, the resulting downtime is kept to a minimum.

>>  Factor in the deployment strategy -- big bang or piece by piece? One of the earliest strategy decisions you'll be faced with is the approach to your rollout. A big-bang approach is attractive in that it minimizes the duration of the project. Doing it all in one shot also minimizes disruption of operations and curtails consulting expenses.

But it's risky. As we've seen, Hershey rolled out an ERP system big-bang style in 1999, only to find that its candy products weren't reaching the market during the critical Halloween season. In this case, big bang was a big bust. A piece-by-piece rollout requires less up-front planning and coordination. You can plan and learn as you go without tangling up the whole enterprise. Distributing the rollout requires a determination of the number and type of users to include in each stage.

What is the optimal number of end users to provision at a time? That depends on how many can be outfitted and trained within the desired incremental time frame and with the available resources. Rollouts generally follow some logic, such as the functional line of business, geographical line, or business product line, unit, location or function. Often the rollout strategy is dependent on the quickest return on investment of time, effort and money.

For example, purchasing and accounting users might be rolled out first, followed by finance, manufacturing and sales. This strategy is often combined with a geographical approach -- Boston, New York and Philadelphia operations will be rolled out first, for instance, then Midwest locations will be provisioned.