Build, Buy, Port or Stay?

Last month I summarized my HP World presentation and laid out a basic formula for determining a strategy for addressing HP 3000 transition issues. This month, I will examine each alternative in detail.

Even HP now admits that most HP 3000 users have yet to commit to a transition strategy. Despite what some consultants, vendors, and even HP are saying, there is no obvious choice. In fact, a portfolio solution that combines several of the alternatives may be the best bet for many. I’ll detail that in next month’s installment, since it borrows from the other four options.

Remember, you really do have multiple choices. You can build every module, or just parts, of a new system essentially from scratch, but utilize the knowledge gained from your existing systems of what works well and what does not. You also have in-depth knowledge of the business processes for your organization that make a “build” less risky. You can buy (replace) some or all of your systems with best-in-industry software. You can port or migrate your code from the HP 3000 to some other platform. (This is where most of the activity from consultants, vendors and HP is focused.) You can choose to “stay” where you are indefinitely.

There is no one size fits all solution. Every organization is different. Your challenge is to determine what is the best combination for your organization.

In examining your choices, keep in mind a couple of things. The line between “build” and “port” is blurred somewhat, especially if you plan to port completely to native mode. A marginal application ported natively to another system is still going to be a marginal application. Do not overlook the challenges involved in moving your data to another platform.

Your data is critical. Unless you plan to homestead indefinitely or use Eloquence on your target platform, you will have to convert your data. You need to intimately understand both the physical and logical structure of your data. In a typical HP 3000 application, the “logical” structure is usually buried in the code. Take advantage of any “free” help offered by HP, its partners or other software and hardware vendors. Just remember that “free” does come with a price: those offering free advice usually have an agenda, which is to steer you in a direction where they can make money off your transition project.

Your transition is going to cost a lot of money whichever path you choose, so consider hiring a firm or consultancy to do an independent transition study for you. You could even try to stipulate they would have no participation in any future transition project you enter into as a result of their recommendations — as a way to ensure their independent evaluation.

When you “build” you have total control over the transition and the final product. Building leverages your company’s resources and existing business logic while allowing you to take advantage of new technology. Studies indicate that at most 33 percent and as little as 10 percent of your code is business logic. The rest is presentation, database, reporting, glue, etc. Your costs are most easily managed in a build scenario and are potentially smallest among all the options. You have the opportunity to “do it right” this time.

“Build” might be part of a portfolio solution. For example, you might decide to buy software for the back office functions and then build value added organization and industry specific surround code. If you have marginal code, it may be preferable to rebuild than to port. This was a situation I faced some years ago. I was brought in to save a floundering consolidation project. It was apparent to me early on that the code they had designed and programmed was marginal at best. Immediately upon getting everything up and functioning, I started in on a rebuild effort. It took almost four years (and did not involve a platform change) but it was done with existing personnel and without any increase in budget because we had complete control of the effort.

“Build” will almost certainly take the longest time to complete. A lot of people discount this option for that very reason. However, if your current systems are serving you reasonably well, then you have the time. In the situation HP 3000 users currently face, a build or rebuild project means a new platform and the learning curve which that implies. If your resources are limited, you may have to impose a lengthy code freeze on your existing systems so you can make progress on your build project. Your project will have to include significant end-user documentation and training, something programmers are notoriously bad at doing.

If an ISV currently provides your primary application and your ISV is porting to another platform then you are essentially in a buy situation. Your ISV is asking you to buy its “new” package, a package that certainly has no history and may not be as stable as what you are used to. You need also to consider whether your vendor has the resources and stability to pull off its migration. At this point, you owe it to your organization to evaluate the offerings of other vendors.

“Buy” is your opportunity to get best-in-industry software to run your organization or a part of your organization. “Buy” can be part of a portfolio solution where you buy the back office applications since there is no point in reinventing the wheel and then leverage you staff’s talent and business knowledge to build or port value-added surround code. If you are buying, choose the application first, not the platform. Since you will be changing platforms anyway, you should concentrate on getting the best possible software fit for your organization’s needs. Many applications run on multiple platforms so you may still be able to choose the platform you are most comfortable with. In buying software, you may either gain or lose functionality. It depends.

“Buy” will be your most expensive option short-term, particularly if you purchase a complete ERP system. Maintaining control over costs, schedules and people is a significant challenge. Studies suggest that as few as 10 percent of ERP implementations actually finish on time and on budget and, as many as 35 percent are cancelled outright. Extensive end-user training will be required and there is a high risk of business disruption.

You will undoubtedly have to make the decision whether to make the business fit the software by changing your business practices, or make the software fit your business through extensive customizing. If you customize too much, you run the risk of not being able to upgrade when the vendor rolls out a major new version. Understand that you may lose functionality and that packaged applications do not necessarily take fewer resources to maintain, in fact, you may need to add headcount plus bring in consultants during the implementation. The “buy” decision, particularly of a complete ERP system, puts you and your staff at the most career risk.

But perhaps not, in spite of the evidence. I was involved, though not as the primary decision maker, in an SAP implementation moving from homegrown HP 3000 systems that took almost six years (the original schedule was 30 months), and cost over $30 million in direct costs (compared with an original budget of under $10 million). We saw a doubling in total IS/IT personnel (as opposed to a budgeted constant), saw an increase in central clerical personnel (the budget called for a decrease), and ended up with a near 100 percent turnover in IS/IT. Believe it or not, this project is being trumpeted by the company as a major success story.