Implementing Enterprise Resource Planning (ERP) on the desktop was properly feared as a gut- wrenching, multimillion dollar jump off the end of the pier. Huge, complex software programs touching all aspects of a business were assimilated in an upheaval characterized by the mantra, "It will be worth it once we're done."

In the middle of such battles, managers remember the joke about the guy who is asked why he keeps hitting his finger with a hammer. He answers, "Because it feels so good when I stop."

The internet is where that chaos should stop. Migrating ERP software to the internet is not the same as rewriting from Cobol to C++, and then deploying the new monster. One of the advantages of the internet is that it is a standards-based environment. No one can claim to have new-and-improved internet. The interface is the browser, anyone's browser, and the standard communication protocol for most online applications is as shown in Figure 1 below.

In the new ERP environment, the standard communication protocol has a user filling out an online form using any browser, on any computer, anywhere in the world. The form, for example requesting parts availability, is parsed and processed by middleware, software where the online application's business logic resides. The middleware outputs a query to a database, for example, inventory. As long as that database is online, ODBC compatible, and gives access to the middleware, it can be any vendor's database, on any computer, anywhere in the world. The database functions mainly as an intelligent information bucket. It supplies the requested records back to the middleware, which translates it into a form the browser can display, like a results table of available parts.

Instead of having lots of stored procedures within the database (making it proprietary to that database), the middleware uses the database much like a device, like a printer. Because the database contains no business logic (where all the programming work took place), it can be replaced the minute it is not fast enough, becomes too expensive, or suffers quality problems. At the same time that this flexibility was welcome by the user community, it has caused concern among the big database vendors. And for large ERP software vendors, worse is yet to come.

Starting with the object-oriented roots of the middleware languages, the online applications tend to be small, compartmentalized software programs. Because of the standards-based nature of the internet, it is comparatively easy to write Java middleware using an Oracle database, for example, that in turn uses business logic in another PHP application with a MySQL database.

That is the opportunity that has changed everything. Now a company can determine what are the most important business processes to move to the internet, and migrate them online piecemeal, so to speak. Because middleware architecture will allow other online applications to join the first one, online ERP is no longer the all-or-nothing behemoth of the desktop.

The extensive sys tems inte gration work that ERP vend ors used to provide to tie together an enter prise can now be done using the built-in commun ication pro tocols of the internet.

These protocols are further defined by standards such as XML, web services (SOAP, WSDL, etc), and lots more acronyms. Supply chain managers can now search for the high-value applications that need to migrate to the internet first, get that job done, minimize disruption, and get on to subsequent migrations while business carries on.

ERP managers can also shop best-of-breed web services, that emerging class of online applications where interconnectivity to other applications is particularly straightforward and well documented. These can be large collections of ERP modules in the classic sense or the SCM waves on top of that, but online. On the other hand, they can be niche applications focused around a particular point issue.

A web service from a currency trader, for example, can provide current exchange rates to plug into a firm's various ERP web services with import/export functions. In another example, a firm's growing collection of online ERP applications use web service standards to connect to the online ERP applications of their vendor. With the vendor's permission, the firm's estimated receiving date on an order is updated by the vendor's estimated shipping date. This last example leverages the theory that drives SCM and online portals called trading exchanges.

In a maintenance mode, the pattern repeats. A superior web service from one vendor replaces an inferior one, often transparently to the enterprise. Since all business logic is contained within the four main languages of middleware, programmers are much easier to find (and more reasonably priced) then for desktop ERP tools with proprietary development environments.

In the real world, however, there is perhaps a Cobol ERP dinosaur that is still operational. The web services components have to interface to that for a while, and perhaps it's been a decade since anyone has seen a User's Manual for it.

If the legacy database is ODBC compatible, the job of connecting to it is relatively easy, even if the business logic is obsolete. The middleware can often be set up to work with the data only, supplying the web service and posting back to the legacy database. This is then transparent to the employees using desktop terminals or workstations on the legacy system.

One advantage for ERP managers saddled with obsolete ERP systems is that they already have support for an upgrade, and now web services presents an effective migration path. This is not the case for managers with the latest desktop SCM software which still lacks a complete online solution. The CIO will need convincing to open the checkbook again.

This ability of the internet to support a migration to web services doesn't mean it should be haphazard. Just because enhancements are quick and easy doesn't mean every department should field an idea online as they get one. Requirements analysis and planning are as important as ever, in fact, it becomes an ongoing process throughout the migration.

In terms of requirements, the web brings another leverage point to improve the situation. Instead of specifications making the in-basket rounds gathering signatures, typically growing obsolete in the process, the web presents a better approach. Requirements can be gathered into an online Functional Description where it becomes a collaborative requirements tool.

The Functional Description breaks the requirements into sections, much like a Table of Contents in Figure 4 above. The body of the document contains examples of the forms and reports users will see, just like they will appear in the final deliverable. The main application commands won't work of course, but picklists, entry validations, and overall layout can help give a clear picture of where this road map will take all concerned.

Around the forms wraps plain English text that describes the flow of information between forms and onto reports. It describes the if-then business logic in clear sentences. At the top-right is a persistent comment/question button that any reader can click at any time. The Requirements Manager, often the upcoming Project Manager, receives the comments, upgrades the Functional Description, and iterates with all concerned. What used to take months, if not years, of committee meetings can be cut to weeks, if not days. The centralized document streamlines the comment/update process. And per our earlier explanation, a web service is much smaller than a full-blown ERP package, hence the requirements can be understood and concluded much faster.

As a centralized road map, the online Functional Description synchronizes the expectations of at least four important groups:

1. Management - Of course they will decide if the migration project goes anywhere
   
   
2. Operations Employees - They will use the web services and can make or break it if they feel as though their requirements were addressed.
   
   
3. Trading Partners - The companies on the other end of a company's ERP can provide their input. Not only does this promote successful adoption, but they will bring their own valuable perspectives.
   
   
4. Programmers - We know these folks come from a different planet and speak a different language. A centralized Functional Description allows programmers to make sure the requirement can be converted to the precise logic they need, that they will not be called on to ad lib business logic to connect the information flow. And they often point out where the emerging areas of the internet may have surprising relevance.

Once underway, a web services development project can use the internet yet again to insure the momentum of the migration to web services. At the point that a desktop ERP upgrade would hand the project to the IT group, to disappear for a few months while programmers do their magic, a web service's development doesn't disappear at all. The Project Manager breaks out the development tasks from the Functional Description and puts them online into a centralized, online task management system as in Figure 5 below.

Unlike all the Gantt Charts, critical path, etc. of MS Project, this is really just a centralized to-do list. The Program Manager uses it to stay on track, but because it is online, all the players can see it. Not just the programmers so they can update their task's status, but managers and operations people who are the customers. They can check to see if things are on schedule (or in the case of a manager, within budget), and occasionally get assigned a task themselves like providing data or reviewing a prototype.

The internet makes this process truly a team sport, and with each game much smaller than the Super Bowls typical of an ERP undertaking. The winds of change can be disquieting, but this one is destined to be a refreshing breeze for those accustomed to the storms of ERP.

Peter Shikli is CEO and founder of Bizware Online Applications Inc., a dozen-employee, 18-year-old online applications development firm in San Clemente. Mr. Shikli is a UCLA engineer with a Loyola MBA, a PE and a Certified Manufacturing Engineer. He has built over 200 online applications since ‘94. You can see his bio at www.bizware.com/shikli.htm and contact him at or 949- 369-1638, ext 77.