June 13, 2002

TOWARD THE GLOBAL INTELLIGENT ENTERPRISE

Beyond the Department

Intelligent project management is your best course when deploying global, multitiered strategic business apps

By Sudhi Sinha

Globalization is a major buzzword in business today. Every day, new IT projects launch in different corners of the world, and advances in IT have made the globalization of those projects easier. Such projects are usually undertaken to implement a common solution across many business units or locations (or tiers) of a large corporation, with the possibility of the units or locations being geographically dispersed and involved in dissimilar business activities.

These projects, which could be ERP, CRM, business intelligence (BI), or legacy integration systems, could originate from a package or be homegrown. Regardless, implementing multitiered, global strategic business systems is quite different from executing stand-alone ones, and most such existing implementations are relatively new.

In this article, I'll explore some areas of potential concern specific to such multitiered implementations and offer some advice about how to overcome those issues.

Project Control

The biggest question in any multitiered implementation project is who has the ultimate decision-making power. For example, one site in a human resources system implementation might decide to do monthly performance evaluations of people and roll it up once a year for calculating bonuses, while another site may make the complete procedure a semi-annual event. If both sites are allowed to make such decisions with far-reaching effects on the business process, different solutions will be created instead of a common one.

Rather, most such projects will be part of a corporate initiative toward common enterprise solutions or process improvements. To prepare a business case for the project, a corporate sponsor generally funds the pilot implementation.

To evade future control conflicts, corporate should retain executive control of the project and institute a program office with wide-ranging powers to steer the project. The program office should be headed by a senior executive leader and staffed with personnel who have proficiency in technical, functional, and project management domains. This program office should collaborate with the different sites involved to fulfill the project charter. There should be one primary development team for the project, and it should be affiliated with the program office.

Although it should be empowered with final decision-making authority, the office should act more as a facilitator than as an enforcer. Ownership of the system will eventually rest with the implementing sites to which the program office should give due.

At the onset, the program office should decide on a uniform project life cycle and management methodology that all the teams will follow. The process should include stipulations on reviews and documentation. Sometimes, adhering to these stipulations appears to slow the project; sites are often tempted to "just go ahead and implement" by circumventing the process. The program office has to supervise and eliminate all such temptations because they might cause deviations from the common solution.

Intelligent Design

IT should be a reflection of a corporation's business goals. That being the case, most system solutions can be designed in two ways: based on business transactions or common driving business rules.

For multitiered implementations, a common design is essential. Most business transactions are a by-product of business rules; diverse divisions or locations share a common set of business rules if they're engaged in similar business activities and share a common history. However, the dynamics change drastically for acquisitions and expansions, creating diverse ways of doing business. The presence of a large number of discreet legacy systems stems from this fact.

If broad-level business rules are defined at a corporate level, they can allow a common design while supporting some operational flexibility at local levels. Thus, before commencing design for a multitiered project, you'll need to survey the business processes of the implementation locations.

These processes can be categorized into two groups: those that form a part of the common system being implemented, and those that are typical of the location for its specific business needs. If there's any difference in the common business processes, one single set of business rules must be enforced for the site by the corporate program office; the site-specific processes shouldn't be made a part of the common system. The design phase should establish a common philosophy for the solution that should be adhered to at any cost.

For example, imagine that a hypothetical company has two principal distribution centers, DC1 and DC2, in two countries. DC1 qualifies its product pricing by the distribution channel while DC2 determines prices based on customer groups. For DC1, recognizing the channels is extremely important; for DC2, identifying individual customer affiliations is critical because they form the basis of the company/customer relationships. This dichotomy results in a complex web of product pricing classes and codes.

The common link between the two methods, however, is that different buyers will pay different prices for the same thing. Therefore, the common business rule could define that there will be different partner classes (not channels and customers) with distinct prices. Thus, DC1 and DC2 both get the freedom of defining their partner classes.

Technical Architecture

There's some general agreement in the technical community about standards for tools, coding, and testing, but every developer and DBA has a distinct flair for development and implementation. The subtle differences in the technical environment and standards have been observed to cause a lot of developmental rework. Such rework leads to delays and unnecessary customization that aren't only expensive but also defeat the purpose of common systems.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC