The application is launched concurrently with the product after a year of hard work. The launch proceeds flawlessly in the companys U.S. home base.
At this point the team proceeds to expand the application to also cover the Chinese market. Because of a lack of familiarity with the Chinese market, it takes them another year to finishat great expense and significant rework. Meanwhile the China launch is held up.
Also because company rules treat China as an information controlled country, the Chinese team has difficulty in getting information for the new product line on a timely basis.
The CRM launch in China is badly botched. This creates significant customer dissatisfaction, the product flops, and it takes two years for the company to overcome the negative market perception.
Lets try a third scenario with loosely coordinated local teams.
The U.S. team experiences unavoidable glitches supporting the product line under development, but this experience and the fixes are quickly passed to the Chinese team in such a way that mistakes, when they happen, happen only once.
The U.S. launch is still done within the year. The Chinese team continues doing some final touches afterwards, and the launch for the Chinese market takes place three months later, without a hitch.
FTD (not the flowers)
The scenarios that we have just described are part of an analysis applicable to development teams in global organizations. For lack of a better term, we call this process federated technology development or FTD.
The application integration scenarios just described are just one context in which FTD can be applied. It is applicable not just to IT and business process, but equally to processes involving software, hardware and manufacturing development.
FTD represents a business outcome optimization exercise along a single dimension. At one end of the spectrum, a local organization enjoys total freedom to make decisions. This is the equivalent of no coordination at all, and hence, synergies due to the coordinated action of multiple organizations are never realized.
At the other end of the spectrum is a centralized organization where every subsidiary operates under uniform mandates and processes.
This situation is less than optimal as well because it may lead to over-specification or red tape, i.e., processes that have no tangible business results carried out only because they have meaning in some other locality.
In the introductory scenarios, the reader may recognize scenario No.1 as a highly centralized; scenario No.2 as a highly decentralized and scenario No.3 as the optimized, "somewhere-in-between" scenario.
Companies go through mergers or divestitures in attempts to optimize these outcomes. FTD is useful in providing insight into the underlying dynamics
Because most companies started small and because of complexities in managing large organizations, there is a tendency to view regional variances as departures from the norm and hence most organizations exhibit a bias toward centralized approaches.
For instance, corporate budgets might be managed from headquarters, in an environment where regional offices must secure approval from headquarters for any major program spending and headcount authorization.
Data centers in an outsourcing arrangement constitute an example where forcing identical processes would lead to sub-optimal results.
Because of higher cost of labor in the U.S., data centers are designed to minimize this component with greater consideration to lights-out operation. Whereas the cost of equipment in India is relatively higher, and hence asset management is probably a first consideration.
It makes little sense to apply the same rules across the two geographies as long as the parties in an outsourcing arrangement abide by the contractual rules. In fact, an outsourcer implementing FTD would likely have a competitive advantage through lower capital and operational expenditures.
In this article, the first of a three-part series, we presented the dynamics behind FTD. In the next article we describe how it works and how it could be deployed. In the third and last article we present a few examples of how its been applied.
Enrique Castro-Leon is currently an enterprise architect and technology strategist for Intel Solution Services with 22 years at Intel. He has taught at the Oregon Graduate Institute, Portland State University, and has authored over 30 papers. Castro-Leon holds Ph.D. and M.S. degrees in Electrical Engineering and Computer Science from Purdue University.