Is Enterprise Resource Planning Becoming a Commodity?

Transition of "Value into Volume" Business Model

Enterprise resource planning: ERP. The three once-paranoid letters are emerging out of their value shell to reach out to the masses. All was fine, methodical, and elegant, until ERP vendors started aspiring to new customer acquisitions in the hundreds per annum. With the advent of ERP for small to medium businesses (SMBs), the numbers are mind boggling.

Product management researchers case-studying the transition of "value to volume" market behavior are having a field day. To what extent is the ERP selection phase and sales cycle shrinking, along with the implementation timeframes? Will the new ERP avatar be easy to learn, adopt, and maintain? There are innumerous questions that remain open for interesting debate. And the master query is a good riddle to crack: "Is ERP becoming commoditized?"

SMBs have been discussed in different media countless times. Cover stories such as "SMB Is Happening" and "The New Wave Called SMB" are most sought after. What do these SMB customers really want? Does the expanding number of companies in this segment make a difference in buying behavior? Is commoditizing ERP the only option for catering to this market?

The first step in commoditizing any product is to standardize. Common availability and greater awareness are also key characteristics of a commodity. Are ERP vendors ready with such an offering?

What Do SMB Customers Want?

What SMB customers want is driven by what they are. Every research organization defines SMB with respect to two main parameters: revenue, and employee size. The range of sizes varies in each region and market. We'll turn now to some of the defining characteristics of SMBs.

"Owner-driven Cars"
SMBs are like "owner-driven cars." The car starts in the garage and runs along corporate freeways—the ones that lead to global destinations. According to some research, trends in the US amount to an amazing 230,000 SMBs exporting nearly $182 billion (USD) annually, a whopping one-third of all US exports. The same trend is emerging in the rest of the world, most notably in emerging economies like China and India.

Enormous growth potential coupled with a changing environment makes for crazy drivers. Very few moments are available to SMB decision leaders to sit back and think.

As for owner-driven cars, resource constraints and limited risk-taking abilities are general characteristics of SMBs. Unlike large enterprises, SMBs operate in "resource sufficiency" mode.

Juggling "too many balls"
SMBs invariably perform under huge pressures, resource constraints, and tight timelines. Juggling too many balls is a common phenomenon in this business segment. For example, an accountant in a SMB organization may process sales orders to ensure timely deliveries. In certain circumstances, even production managers perform the same process. These factors lead to an absence of well defined user roles (for the reason that "fulfillment of tasks" is considered more important than a non-violated workflow rule); time constraints for adopting a new system; and continual resource constraints for operations.

Lack of IT Infrastructure
It is hard to find SMB organizations with a well-defined IT division. Though top management may be IT-savvy, they are hard pressed to find time for software evaluation and implementation. SMB customers in emerging economies face additional challenges such as only occasionally connected environments, due to bandwidth issues, and poor IT literacy among users.

In turn, these characteristics define the basis of the typical SMB needs regarding ERP systems, and we'll explore these next.

A Fully Functional ERP

The general demand is for a "fully loaded car with no fancy frills." It is a major buying decision, so it had better be good. Is there a "dashboard" control? Can the SMB decision leader determine the driving speed and also have a constant watch on fuel (resource) availability? Yes, one-screen control is vital when momentary decisions need to be made.

Most SMB leaders interviewed agreed that once their organizations choose an ERP system, they will use it for a minimum of three to five years. Growth rates being tremendous, a fully functional and scalable ERP system would be an ideal choice.

"Bought Microsoft Windows, used it as is." "Bought Office Suite, used as is." "Bought accounting software, used as is." ERP should also be usable as is. Configuration yes, but no customization. No fancy frills indeed.

Coexistence of Flexibility and Control
Task fulfillment is key, and hence the ERP system needs to be flexible. At the same time, one of the major drivers for ERP adoption is business control. These contradicting features of "flexibility" and "control" need to coexist. Key users need to have the flexibility for effective fulfillment, and control need to be exercised with respect to the rest of the users. For example, key users should be able to role-play to complete their peer's tasks when the situation warrants, and the system should keep track for business clarity. Role definition in a system thus need to be flexible in order to accommodate these requirements. Flexibility in the sequence of process elements is also needed. A typical need arises when tasks are fulfilled that are followed by procedures to be completed for better business practice and integrity.

Simplicity of Adoption
Can the customer push in a CD and self-install the ERP system? If the customer does not how to go about the setup, does the system incorporate a wizard with business questions to be answered in order to set the entire schema?

As the first IT adoption of any business is simple accounting software, can the ERP system identify and connect to the accounting software in use, and bring in all the data intact to the new screens? Is the ERP solution equipped to connect and talk to the complementary applications that the SMB has invested in?

When the basics are in place, a graphical screen that guides in exploring greater heights of ERP features is an ideal next step. This screen must allow a business user to configure best-in-class features with "drag and drops," relatively few clicks, and basic English. This will transform the customer's business systems into ERP within the constraints of an SMB.

Ease of Maintenance
Adoption is followed by usage and maintenance. While "ease of use" is a default software requirement, "ease of maintenance" is the new jargon being chanted by SMB customers who lack IT resources and infrastructure. Accordingly, there are various critical requirements that need to be satisfied:

• Can customers take backups from the ERP screen through a simple menu? It's better if the backup can be performed while the users are transacting.
• Is there a health monitor that helps in scheduling proactive maintenance calls (so that problems can be averted before they occur and halts the business)?
• Does the ERP solution have self-healing recovery for disaster situations, with the ability to quickly swing back in action for better business continuity?
• Is there a simple click-away backup restore process for emergency situations?
• Can the ERP system perform pull synchronization on demand from various remote locations? It's better if scheduled auto-synchronization happens in a "push mode" without user intervention.
• Is there a dynamic reporting tool that accepts visual drag-and-drop commands and produces desired reports?
• Is the ERP solution agile enough to configure and reconfigure the dynamic changes that haunt the business?

The million-dollar requirement of these SMB customers is that the ERP solution needs to be simple yet powerful, flexible yet with the capacity for control, and easy yet complex.

Affordable and Predictable
When deciding on ERP software, SMB decision makers are daunted by the hourly service rates quoted by vendors and partners. SMB decision leaders need "not only" an affordably priced solution, but also a predictable total cost of ownership (TCO).

• Is there a "product-based" service offering?
• Is there a standard tariff for license fees, implementation fees, and yearly support costs?
• Can the customer pick and choose the features and services as and when required, with the costs agreed well in advance?
• Is there a next-door partner to help in situations of service need?

An affordable yet predictable ERP will open up new horizons for SMBs to embrace ERP systems in growing numbers.

Are Vendors Geared towards Offering "Commoditized ERP"?

In simple terms, SMBs want a "commoditized" ERP system, meaning that it is simple to choose and fully functional, with dashboard controls; affordable and predictable; easy to adopt, adapt (to business changes), and maintain; connects to third-party applications; flexible but with strict control capabilities; and with next-door partner service.

What should be the ERP vendor's response to this "value into volume" game? The current efforts of these vendors to make a SMB-fit offering are yielding some results and perhaps some chaos. Let us take a closer look at ERP vendor responses by category.

Traditional ERP Vendors
Vendors such as SAP and Oracle fall into the traditional ERP vendor category. Traditionally catering to large enterprise customers, these vendor's solutions are percolating down to SMBs. Vendors in this category bring the experience of managing the most demanding customer requirements, the expertise of best practices, and deeper domain knowledge. The transition to the value-into-volume business model is more evident with these vendors. However it is important to understand some of their characteristic initiatives (or lack of initiatives) and market responses.

Traditional vendors do have a comprehensive full-functional ERP solution in the rack. They offer a SMB-fit solution and provide a value chain to scale to the comprehensive solution. They also offer third-party partner products integrated "out-of-the-box" to fulfill comprehensive solution requirements on a lower TCO. As far as affordability is concerned, ERP vendors seem to be geared towards satisfying SMB customers. Predictable TCO is offered by products such as Oracle's e-Business Suite, with a comprehensive tariff and a point price which includes license fees and implementation fees.

For instance, SAP has acquired 10,000 SMB clients for its Business One offering. As these SMB customers grow, options are open to move up the value chain by adopting SAP Enterprise solutions. SAP Business One provides dynamic reporting functionalities.

Oracle 10g Database SE1 addresses the "self-healing" and "easy-to-install" requirements of SMBs in the absence of a database administrator (DBA). Applications built on this platform tend to fulfill the SMB requirement of single-click system installation, according to a 2005 IDC white paper sponsored by Oracle Corporation titled "Oracle Database 10g Standard Edition One: Meeting the Needs of Small and Medium Sized Businesses."

Wizard-driven setups, and graphical tools to explore and configure are not commonly seen in this category offering, but traditional vendors are gearing up their partner ecosystems to address the next-door partner service requirements.

Incorporating business changes on the fly for a set of customers or transactions is unheard of in the traditional ERP world. Traditional ERP gurus suggest a detailed business process re-engineering (BPR) report before touching on such changes. However, SMBs aspiring to best practices often find it difficult to devote time for sitting back, analyzing, and adopting these aspects and practices.

Mid-tier Vendors

Sage Software, Microsoft, and 3i Infotech are the kind of vendors in this category. They have been providing extended solutions to SMBs for some years now. Current volume levels achieved by some of these vendors have come about mainly through inorganic growth.

A visual modeling tool for explore-and-configure adaptive processes aspires to be "tomorrow's model-driven design," according to Bill Gates in his presentation at Convergence 2005.

Mid-tier vendors also offer third-party partner products integrated out of the box. However, unlike the traditional vendors, these applications are not an option to reduce TCO. They act rather as complementary products to bring about a comprehensive solution framework.

Like the SAP Business One offering, the mid-tier product Sage ACCPAC provides dynamic reporting functionalities. In terms of affordability, mid-tier products such as ORION Advantage from 3i Infotech offer one-point pricing that includes license fees, implementation fees, a micro-vertical schema, a database license, and server hardware. By and large, the affordability aspect of SMB requirements is well met by these ERP vendors.

Small Business Solution Vendors

Product offerings such as QuickBooks from Intuit, Peachtree from Sage, Tally, and MYOB fall under this category. These product vendors have emerged to respond to SMB customer ERP requirements.

Volume is synonymous with the small business solution (SBS) vendor's business model. Affordable price is well attuned to volume. Customers find easy to make their choice, based on the following reasoning: "there is this vendor who provided us with the accounting software we've been using for years; this vendor has come up with an enterprise-wide application; the simplest choice is therefore to adopt such a business application from the existing vendor." However, it is not as easy as it may seem. There are other unanswered questions such as product comprehensiveness, domain expertise, and product-oriented services.

SBS vendors are scaling up their product functionalities version-on-version to reach the comprehensive enterprise-functional levels. Some of them do have complementary third-party applications. Most SBS vendor products have a single-screen business manager that gives visibility and control to SMB decision leaders. These vendors have provided dashboard, single-click install, and explore-and-configure features in their smaller accounting applications upwards.

Many SBS Vendors do have a large partner network in place. While mid-tier vendor partners have a solution provider business model, SBS vendor partners are still in the distribution mindset.

Some Commonalities

There are, however, some common issues across the ERP vendor categories. Though the first step to commoditizing any product is to standardize, there seems to be a big lack in this respect. Common availability and greater product awareness are key characteristics of a commodity. This saves the customer's time and money. Simply choosing an ERP system requires conscious know-how of one's own business objectives; a product track record in a similar industry; a, test run in the shortest possible timeframe; knowledgeable human resources; and many other elements. Is there a way to choose an ERP system as we choose potatoes, in other words, as we purchase commodities? No ERP vendor seems to have cracked this requirement.

Most ERP applications support import and export of data in various formats ranging from Excel, CSF, and Access, to extensible markup language (XML). Although this gives the possibility of connecting to other applications, the process of data movement and of avoiding data duplication is still a challenge. There is no single drag-and-drop, click-and-connect solution built into an ERP that allows trouble-free connectivity without sacrificing data integrity levels.

And finally, allowing flexibility yet providing control is as perplexing for ERP vendors as a cold fire. We are yet to come across an ERP product that demonstrates both qualities to the fullest satisfaction of SMB decision leaders.

Conclusion

SMB are in need of ERP solutions. Growth, change, and "economies of speed" drive this business segment to have a system that provides greater business visibility and control. The requirements of SMB are perhaps unique, and emanate from their business nature, along with their inherent characteristics and constraints. Though idealistic, there is a crying need for a commodity called ERP for SMB.

ERP vendors have started becoming aware of this need, and are moving towards meeting it. While some of the needs are met in fragments through different ERP products, a single product meeting all these needs is not in the vicinity. Commoditizing a product means it must be simple for customers to make a choice. Such a product for SMBs needs still to emerge—at this point, vendors are moving in the right direction but yet to arrive.

Architecture-Centered Information Systems In The Manufacturing Domain - Part IV - Moving From Planning to Implementation

About This Note:

This note is presented in five parts as follows:

1. Introduction to Software Architecture
   
   
2. The Architecture Process
   
   
3. Steps in the Architecture Process
   
   
4. Moving from Planning to Implementation
   
   
5. Applying the Methodology

Part IV - Moving from Planning to Implementation

This section covers the steps involved to move from Planning to Implementation.

Prototyping the System

Screen definitions from the System Requirements Analysis can be used to create an on-line mockup of the system to show to end users and managers. Dummy data and simple file I/O can provide a realistic simulation for the essential parts of the user interface. End users and architects then jointly review the mockups and run through the Use Cases to validate requirements. Often, new or modified requirements will emerge during this interchange. Print outs of these modified screens can be created and marked up for subsequent development activities. Any modifications to requirements are then incorporated into the other architectural activities.

Through the mockup, management can see visible progress, a politically useful achievement for most projects, that reduces both political and requirements-oriented risk. With rapid prototyping technologies such as screen generation wizards, mockups of most systems can be rapidly constructed.

Building Block Based Development

There are two distinct approaches to acquiring and deploying software systems:

Product based - which solves specific problems using components of individual systems. These components can be integrated to form a complete system, but the resulting integration may or may not possess the attributes of good architecture.

Asset based - which solves problems in different contexts using components that are architected to provide services greater than the sum of their parts.

Figure 1. The process of reusing asset base software systems.

In Figure 1, the architects' role is to of avoid the inclusion of the product based must have requirements that corrupt the architecture.

Building Blocks of the Prototype

Building blocks are an architectural paradigm that provides the means to construct system along three dimensions [TOGAF00]:

Structure - determine the system decomposition parts and the relationship between the parts.

Aspects - model the functional decomposition of the system.

Behavior - deals with processing that takes place within the system.

Structure should be considered the most important of the three, since it is through structure that the system complexity can be reduced.

This is the primary motivation for the architecture-centric view management of structure. Without control of structure, the resulting system is simply a collection of parts. Gaining any synergy from the collection is now longer possible without a structural framework in which to place the components and their interacting interfaces.

The building blocks of a manufacturing system are usually centered on the ERP system, since the Bill of Material is owned by this application. In order to avoid a detailed discussion of ERP and its relationship with other business applications, a set of generic building blocks can be developed which can be used for all manufacturing applications.[10]

Figure 2 - Generic Building Blocks of the system architecture

Footnotes

[10] Many ERP vendors provide toolkits for customizing the applications. In the past this approach was seen as a competitive advantage for both the vendor and the user. It is now understood that this approach is very expensive in terms of maintenance, upgrades, and continued operations and support. The tailoring aspects should be viewed from the user interface and federation interface paradigm, rather than tailoring the core functionality of the system. [Aust98], [Upto97]

Managing the Project

As the final step in the pre-development process, the project management team plans and validates the deployment schedule to resolve resource issues including staffing, facilities, equipment, and commercial technology procurement [PMI96].

At this stage the schedule is defined for the parallel incremental, external and internal activities performed during Incremental Development. External increments support risk reduction with respect to requirements and management support. Internal increments support the efficient use of development resources - for example, back-end services used by multiple subsystems. Current best practices suggest performing several smaller internal increments that support larger scale external increments, the so - called V-W staging approach [Redm97], [Cock95], [Cock99], [Boeh88].

The architecture-centric process provides for the use of parallel increments. Since the system is partitioned into well-defined computational boundaries, integration teams can work independently and in parallel with other teams, each within their assigned boundaries. Integration planning includes increments spanning architectural boundaries.

The plan should be detailed for early increments and include re-planning activities for later in the project, recognizing the reality that project planners do not know everything up front. At this stage, the team should prepare a risk mitigation plan that identifies technical backups. The integration team involved in mockup and architecture prototyping should continue to build experimental prototypes using the relatively higher-risk technologies well in advance of most developers. This run-ahead team is an essential element of risk mitigation [Sist94], [Redm97], [McCo96], [Karo98], [Hump89], [Doro96], [Boeh91].

The final activity in project management planning is the architectural review and startup decision. Up to this point, the enterprise sponsors have made relatively few commitments compared to the full-scale deployment costs (about 25% of system cost). Executive sponsors of the project must make a business decision about whether to proceed with the system. This executive commitment will quickly lead to many other commitments that are nearly impossible to reverse (such as technology lock-in, expenses, and vendor-generated publicity). At this point, the system architects are offering the best possible approach given the current business and technology context.

Prototyping the Architecture

The architecture prototype is a simulation of the system architecture. System API definitions are compiled and stub programs are written to simulate the executing system. This architecture prototype will be used to validate the computational and engineering architectures, including the flow of control and timing across distribution boundaries.

Using technologies such as CORBA, a computational architecture specification can be automatically compiled into a set of programming header files with distributed stubs (on the calling side) and skeletons (on the service side). Processing can be simulated in the skeletons with dummy code. Simple client programs can be written to send invocations across computational boundaries using dummy data. A small number of essential, high-risk Use Cases can be simulated with alternative client programs. At this point, the prototype execution is used to validate conformance with engineering constraints. This is also the time to propose and evaluate changes to the Computational View, Engineering View, or Technology View architectures.

Incremental Deployment of the System

Deployment starts with several essential activities. The integrators must learn and internalize the architecture and requirements. An effective way to achieve this is with a multi-day kickoff meeting, which includes detailed tutorials from domain experts and architects. The results of all previous steps can be leveraged to bring the integrators up to speed. Lectures should be videotaped so that replacement staff can be similarly trained.

Each increment involves a complete development process, including design, coding, and testing. Initially, the majority of the increments will be focused on individual subsystems. As the project progresses, an increasing number of increments will involve integrating multiple subsystems [Cock95], [Cock99].

For most of the software integration activity, the architecture is frozen, except at planned points where architectural upgrades can be inserted without disruption. Architectural stability enables parallel development. For example, at the conclusion of a major external increment, an upgrade might be inserted into the computational architecture before the next increment initiates. The next increment starts with a software upgrade that conforms to the changes. In practice the need for and frequency of such upgrades decreases as the project progresses. The architect's goal is to increase the stability and quality of the solution based on feedback from development experience. A typical project requires two architectural refactorings (upgrades) to get to a stable configuration that is suitable for deployment.

Transitioning the System to Production

Deploying the system to a pilot group of end users is an integral part of the development process. Lessons learned during this initial deployment will be translated to new development iterations. Schedule slips are inevitable, but serious quality defects are intolerable.

Improving quality by refactoring the integration (improving software structure) is an important investment in the system that should not be neglected. At this stage, architectural certification - where the architect confirms that the system implementation conforms to the specifications and properly implements the end users' requirement - becomes extremely important. In effect, the architect should be an impartial arbitrator between the interests of the end users and the developers of the system. If the end users identify new requirements that affect architectural assumptions, the architect can assess the request and work with both sides to plan feasible solutions.

Operating and Maintaining the System

Operations and Maintenance (O&M) is the proving ground to verify if the integration was done right. The majority of system cost will be expended here, and as much as, 70% of the O&M cost will be due to system extensions. The associated requirements and technology changes are the main drivers of continuing development. Typically, half of each integrator's time will be spent trying to figure out how the system works. Architecture-centered development resolves much of this confusion with a clear, concise set of documentation, i.e., the system architecture itself.

Continuous Migration of the System Components

System migration to a follow-on target architecture occurs near the end of the system life cycle. Two major processes for system migration are called Big Bang (or Cold Turkey) and Chicken Little [Ston92], [Brod95]. [11] A Big Bang is a complete, overnight replacement of the legacy system. In practice, Big Bang seldom succeeds; it is a common antipattern for system migration [Brow98]. The Chicken Little approach is more effective and ultimately more successful. It involves simultaneous, deployed operation of both target and legacy systems.

The Cold Turkey approach in which the legacy systems are replaced in-kind with the new systems has many impediments:

• A better system must be promised - the current user base expects that the replacement system will perform significantly better, since the effort necessary to deploy the new system needs to be paid back many times over.
  
  
• Business conditions never stand still - the new system must be capable of evolving with the changing business conditions. As time moves on, the requirements themselves change. Changes in the deployed system must be capable of keeping up.
  
  
• Specifications rarely exist for the current system - by definition, the legacy system is poorly documented.
  
  
• Undocumented dependencies frequently exist in the current system - over time, the legacy system has become customized to meet the previous tactical requirements.
  
  
• Legacy systems are usually too big to be simply cut over from old to new - millions of database entities and hundreds of mainframe applications are tightly coupled to form the legacy system. This complexity becomes a serious burden simply to understand.
  
  
• Management of large projects is difficult and risky - all the problems associated with managing large projects are present.
  
  
• Lateness is rarely tolerated - since the legacy system is mission critical, any delays become exaggerated.
  
  
• Large projects tend to become bloated with new and unjustified features - once the system is opened to migration, all sorts of new features will be required.
  
  
• Homeostasis is prevalent. [12]
  
  
• Analysis paralysis sets in - with all the issues stated above, the analysis activities become bogged down in details

The Chicken Little approach is one in which the system components are incrementally migrated in place until the desired long-term objectives have been reached.

• Controllable - since the scope of each incremental effort can be managed within the overall architecture of the system vision. The failure of one step in the process does not affect the proceeding deployments. In principle, the failure of one step would also not affect future steps. Once the failed step has been corrected, the project would proceed as planned.
  
  
• Only one step fails - there is no Big Bang approach, with an all or nothing result
  
  
• Incremental, over time - effort, budgets, human resources can be incrementally deployed.
  
  
• Conservatively optimistic - success is always in hand with incremental benefits paving the way.

In the Chicken Little approach gateways are integrated between the legacy and target systems. Forward gateways give legacy users access to data that is migrated to the target system. Reverse gateways let target-system users have transparent access to legacy data. Data and functionality migrate incrementally from the legacy to the target system.

In effect, system migration is a continuous evolution. As time moves on, new users are added to the target system and taken off the legacy environment. In the end, it will become feasible to switch off the legacy system. By that time, it is likely that the target system will become the legacy in a new system migration. The target system transition overlaps the legacy system migration. In the Chicken Little approach, Transition, Operations and Maintenance, and Continuous Migration are part of a continuous process of redeploying the system to meet the ever changing needs of the business.

Footnotes

[11] The concept of Chicken Little and Big Bang or Cold Turkey originates from the two references. Stonebraker's paper describes how GTE migrated 10,000 workstations using the business applications from a mainframe environment to a client/server environment [Ston92]. This work was done before the advent of CORBA ORB's and the current trend of wrapping the applications into a federated system through the OO interface. The lessons learned in this work as well as the work at Boeing Aircraft Company in [Ganti95] supports the notion that a good architectural foundation is a mandatory requirement if there is going to be any hope that the outcome will be successful.

[12] hoomeostaosis n.1. the tendency of a system to maintain internal stability owing to the coordinated response of its parts to any situation or stimulus tending to disturb its normal condition or function. 2. A state of psychological equilibrium obtained when tension or a drive has been reduced or eliminated.

Conclusion of Part IV

This is part IV of a five part note. The next part covers applying the methodology.

The Author

Glen B. Alleman, has provided consulting services to a variety of industries and business domains in the industrial and commercial market places. These include, e-commerce systems, publishing systems, information technology strategies, manufacturing systems, engineering design systems, and software process improvement.

He has direct experience in a variety of large scale integration environments and business domains. He also has extensive program and project management experience with multiple concurrent projects involving hardware, software, multiple sites and legacy business systems integration.

Mr. Alleman has deep technical and architectural knowledge of a variety of system paradigms including: client/server, CORBA, and web-based systems.

He is the Principal Consultant for Niwot Ridge Consulting, Niwot, Colorado, www.niwotridge.com.

References

[Aust98]	"How to Manage ERP Initiatives," R. D. Austin and R. L. Nolan, Harvard Business School Working Paper.
[Boeh91]	"Software Risk Management: Principals and Practice," B. W. Boehm, IEEE Software, January 1991, pp. 32-41.
[Boeh88]	"A spiral Model of Software Development and Enhancement," B. Boehm, IEEE Computer, May 1988, pp. 61-72.
[Brod95]	Migrating Legacy Systems: Gateways, Interfaces & The Incremental Approach, M. L. Brodie and M. Stonebraker, Morgan Kaufmann Publishers, 1995.
[Brow98]	Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis, W. J. Brown, R. C. Malveau, H. W. McCormick III, and T. J. Mowbray, John Wiley and Sons, 1998.
[Cock99]	"Using 'V-W' Staging to Clarify Spiral Development," A. Cockburn, Human and Technology, Inc. members.aol.com/acockburn/papers.
[Cock95]	"Unraveling Incremental Development," A. Cockburn, Object Magazine, January 1995, pp. 49-51.
[Doro96]	Continuous Risk Management Guidebook, A. J. Dorofee, et al, Software Engineering Institute, Carnegie Mellon University, 1996.
[Ganti95]	The Transition of Legacy Systems to a Distributed Architecture, N. Ganti and W. Brayman, John Wiley and Sons, 1995.
[Hump89]	A Discipline of Software Engineering, W. A. Humphrey, Addison-Wesley, 1989.
[Karo98]	Software Engineering Risk Management: Finding Your Path Through the Jungle, Version 1.0, D. W. Karolak, IEEE Computer Society, 1998.
[McCo96]	Rapid Development: Taming Wild Software Schedules, S. McConnel, Microsoft Press, 1996.
[PMI96]	A Guide to the Project Management Body of Knowledge, W. Duncan, Project Management Institute, 130 South State Road, Upper Darby, PA 19082, 1996.
[Redm97]	Software Projects: Evolutionary versus Big Bang Delivery, F. Redmill, John Wiley & Sons, 1997.
[Sist94]	Software Risk Evaluation Method: Version 0.2, F. J. Sisti and S. Joseph, CMU/SEI-94-SRE, V0.2, Software Engineering Institute, January, 1994.
[Ston92]	"DARWIN: On the Incremental Migration of Legacy Information Systems," M. Stonebraker and M. L. Brodie, TR-0222-10-92-165, University of California, Berkley.
[TOGAF00]	http://www.opengroup.org/public/togaf/
[Upto97]	"A Path-based Approach to Information Technology in Manufacturing," D. M. Upton and A. P. McAfee, Harvard Business School Working Paper.

Production Planning and Scheduling Software for the Textile Industry: Unknown Frontiers

Introduction

As far as enterprise resource planning systems (ERP) are concerned, the textile industry may still be a manageable affair. But the moment you talk about developing a production planning and scheduling software for this industry, you are asking for a difficult task to be performed. Many a veteran has failed in attempting to achieve this feat.

Challenges

Some of the unique challenges posed by the textile industry to any production planning and scheduling software vendor are discussed here. These challenges can be grouped as raw material concerns, manufacturing lead time, manufacturing constraints, orders, and inventory.

Raw material concerns involve high raw material costs and seasonal raw material procurement cycles. Cotton, for example, is a seasonal commodity; therefore, the availability and price will change throughout the year. High raw material cost is another issue. Raw material costs may constitute as high as 60 to 70 percent of the total costs.

Manufacturing lead time can also pose challenges. Manufacturing lead times can be excessive, sometimes more than two months. This is because the raw cotton production process, for example, has to go through many processes and most of them have huge lead time requirements. Looms in particular take the most lead time. A loom machine can make only 500 meters of fabric in a day whereas typical order lengths are in the range of 25,000 to 50,000 meters range.

Most of the manufacturing processes also have high setup times. Quality analysis time also runs high as the finished cloth needs to be manually inspected for defects. Extra lead times also result due to unavoidable generation of inventory in the form of extra meters than the ordered lengths.

Another challenge involving manufacturing is that different processing speeds occur at different work centers, which must also be included in the equation. Dyeing machines, warping machines, spinning machines run at speeds of 30,000 to 50,000 meters of yarn per day but looms run at 500 meters of fabric per day. Because of this, there may be only 2 to 5 dyeing machines, but there may be as many as 500 looming machines in the same plant.

Likewise there are different processing requirements on the same production line. For example, up until the dyeing process, the manufacturing process fits orders that are big and similar. But at looming, the manufacturing process fits many smaller and varied orders. This poses a real challenge as fitting these two diametrically opposite requirements is next to impossible to do.

Another issue is the unpredictable generation of second quality textile and the fact that variations in color and shade is only known after the fabric has been woven and finished (though they are caused back at the dyeing stage). This can result in a lot of rejected material being processed unnecessarily, thus adding to manufacturing costs and processing time.

These manufacturing constraints ultimately impact customer orders. Because the production rates are very low on looms, customer orders are broken into smaller sub-orders, and the sub-orders are distributed to many looms to reduce the lead time for individual orders. However, variations in the color or shade from the order can also emerge, which, as explained earlier, are detected at the end of the entire process.

Not surprisingly, inventory is another challenge faced by the textile industry because there is a high generation of extra finished products. In addition to extra material resulting from second quality and color shade variations, extra yarn moves through the entire production cycle. Up to dyeing stage, the work-in-process (WIP) is in yarn form and the length of this yarn is fixed at the yarn making stage. It cannot be cut as per order lengths. These extra meters travel through the production cycle and end up as excess inventory, which is later adjusted in the next planning cycle. Consequently, plant capacity is inefficiently utilized due to unavoidable generation of extra meters—more than the lengths ordered.

After going through these constraints, it is obvious that it is difficult to develop production planning and scheduling software for the textile industry. Only a veteran who has in-depth industry knowledge as well as knowledge of how to tackle these constraints in the implementation can develop a software for planning and scheduling for the textile industry.

Dyeing versus Looming

It is very important to understand the different requirements at the dyeing and looming processes so a suitable planning and scheduling software can be suggested. The dyeing and looming processes are the true bottlenecks in the entire production cycle of all textile plants. Both dyeing and looming have high setup time, high production time, and high change overtime, but looms are far slower than dyeing machines. Looming is more like a warehouse with a lot of WIP inventory called grey stock and this grey stock is on many looming machines, in small quantities. Dyeing machines, however produce long sets of warp (dyed yarn). One set of warp can be produced by one dyeing machine in one day but the warp can only be consumed by at least 50 looming machines in one day. To keep the ability to produce many kinds of fabric, the manufacturers generally install many kinds of looming machines. All of these looms are fed by only 2 to 5 dyeing machines. Due to these factors the dyeing area is always hard-pressed to feed the looms with small lengths and different types of dyed yarn for the next work orders in line.

So dyeing machines are better suited to produce big quantities of dyed yarn of the same type, (e.g. same color and same number of ends). For example, if the ordered length of fabric is 25,000 meters and the order has been broken into 10 work orders at 10 looms, then it will take 5 days to finish the WIP at looming. This is if all the work orders are done simultaneously and speed of looms are 500 meters of fabric woven per day. A single dyeing machine will produce 25,000 meters of warp in half a day.

Solutions

These challenges in the textile industry can be met by conducting a profitable to promise analysis; grouping, breaking, and sequencing orders; and by routing WIPs. In the textile industry, orders are considered more like combinatorial meters rather than individual order meters, so the same type of orders can be grouped and sequenced to achieve production efficiency as well as reduce inventory creation. All WIPs can also considered the same way for the same purpose.

Profitable to Promise Analysis

Businesses in the textile industry mostly gets varied orders in terms of rate per meter, quantity, fabric type etc. Because of this, each order has to be evaluated on profitability, customer service levels and long and short term goals of the company. Profitable to promise analysis allows the business to find out if the particular order will be profitable to make by considering the costs of raw material, process, inventory, and other factors against the price the customer is willing to pay. Thus it can be seen that some orders will be a lot more profitable than other orders. This analysis is perfectly possible if you have the right software tool, which can provide you with this kind of information.

If raw material availability, machine capacity, and production lead time are known at the time of order taking, then it is possible to give a definite delivery date to the customer. This is known as capable to promise. If we can also provide information about customer, production, inventory, stock out, material, and other overhead costs down to the item level, and then compare all incurred costs to the selling price, it will be possible to decide whether the incoming order should be taken and what priority it can be assigned, at the time the order is being taken. This functionality is very important for the textile industry.

In conjunction with above mentioned factors, a planning system that is also capable of grouping, breaking, and sequencing orders while it is doing total lead time calculations to determine a delivery date will solve many production planning problems. It will eliminate waste, reduce the generation of extra inventory, increase machine capacity utilization, increase customer service levels, eliminate stock out costs, and reduce production costs.

Grouping, Breaking, and Sequencing Orders

Grouping, breaking, and sequencing orders will also help to overcome textile production challenges. Group smaller orders at dyeing process. The same dyeing WIPs can be grouped so the generation of extra meters can be minimized. Break bigger orders into many smaller orders at dyeing, and sequence them with other orders. Loom areas typically have many kinds of loom machines which can produce different kinds of fabric but at very slow rates. If big orders of same material are continuously coming from dyeing, they will only go to a particular loom machine which can process it; other loom machines which cannot use these warps will go idle for want of material. Another way to minimize set up time is to sequence WIP orders with the same color at the dyeing process. This will minimize the set up time to change of color. Also, breaking individual orders into many parts will create many work orders for the same order at looming process. This will minimize lead times significantly at looming.

Also, look for already existing inventory in the form of extra meters at looms and finished stock in the inventory to allocate these meters against the matched fresh orders and plan for the remaining meters.

Production Planning and Scheduling Software for the Textile Industry: Unknown Frontiers

Introduction

As far as enterprise resource planning systems (ERP) are concerned, the textile industry may still be a manageable affair. But the moment you talk about developing a production planning and scheduling software for this industry, you are asking for a difficult task to be performed. Many a veteran has failed in attempting to achieve this feat.

Challenges

Some of the unique challenges posed by the textile industry to any production planning and scheduling software vendor are discussed here. These challenges can be grouped as raw material concerns, manufacturing lead time, manufacturing constraints, orders, and inventory.

Raw material concerns involve high raw material costs and seasonal raw material procurement cycles. Cotton, for example, is a seasonal commodity; therefore, the availability and price will change throughout the year. High raw material cost is another issue. Raw material costs may constitute as high as 60 to 70 percent of the total costs.

Manufacturing lead time can also pose challenges. Manufacturing lead times can be excessive, sometimes more than two months. This is because the raw cotton production process, for example, has to go through many processes and most of them have huge lead time requirements. Looms in particular take the most lead time. A loom machine can make only 500 meters of fabric in a day whereas typical order lengths are in the range of 25,000 to 50,000 meters range.

Most of the manufacturing processes also have high setup times. Quality analysis time also runs high as the finished cloth needs to be manually inspected for defects. Extra lead times also result due to unavoidable generation of inventory in the form of extra meters than the ordered lengths.

Another challenge involving manufacturing is that different processing speeds occur at different work centers, which must also be included in the equation. Dyeing machines, warping machines, spinning machines run at speeds of 30,000 to 50,000 meters of yarn per day but looms run at 500 meters of fabric per day. Because of this, there may be only 2 to 5 dyeing machines, but there may be as many as 500 looming machines in the same plant.

Likewise there are different processing requirements on the same production line. For example, up until the dyeing process, the manufacturing process fits orders that are big and similar. But at looming, the manufacturing process fits many smaller and varied orders. This poses a real challenge as fitting these two diametrically opposite requirements is next to impossible to do.

Another issue is the unpredictable generation of second quality textile and the fact that variations in color and shade is only known after the fabric has been woven and finished (though they are caused back at the dyeing stage). This can result in a lot of rejected material being processed unnecessarily, thus adding to manufacturing costs and processing time.

These manufacturing constraints ultimately impact customer orders. Because the production rates are very low on looms, customer orders are broken into smaller sub-orders, and the sub-orders are distributed to many looms to reduce the lead time for individual orders. However, variations in the color or shade from the order can also emerge, which, as explained earlier, are detected at the end of the entire process.

Not surprisingly, inventory is another challenge faced by the textile industry because there is a high generation of extra finished products. In addition to extra material resulting from second quality and color shade variations, extra yarn moves through the entire production cycle. Up to dyeing stage, the work-in-process (WIP) is in yarn form and the length of this yarn is fixed at the yarn making stage. It cannot be cut as per order lengths. These extra meters travel through the production cycle and end up as excess inventory, which is later adjusted in the next planning cycle. Consequently, plant capacity is inefficiently utilized due to unavoidable generation of extra meters—more than the lengths ordered.

After going through these constraints, it is obvious that it is difficult to develop production planning and scheduling software for the textile industry. Only a veteran who has in-depth industry knowledge as well as knowledge of how to tackle these constraints in the implementation can develop a software for planning and scheduling for the textile industry.

Dyeing versus Looming

It is very important to understand the different requirements at the dyeing and looming processes so a suitable planning and scheduling software can be suggested. The dyeing and looming processes are the true bottlenecks in the entire production cycle of all textile plants. Both dyeing and looming have high setup time, high production time, and high change overtime, but looms are far slower than dyeing machines. Looming is more like a warehouse with a lot of WIP inventory called grey stock and this grey stock is on many looming machines, in small quantities. Dyeing machines, however produce long sets of warp (dyed yarn). One set of warp can be produced by one dyeing machine in one day but the warp can only be consumed by at least 50 looming machines in one day. To keep the ability to produce many kinds of fabric, the manufacturers generally install many kinds of looming machines. All of these looms are fed by only 2 to 5 dyeing machines. Due to these factors the dyeing area is always hard-pressed to feed the looms with small lengths and different types of dyed yarn for the next work orders in line.

So dyeing machines are better suited to produce big quantities of dyed yarn of the same type, (e.g. same color and same number of ends). For example, if the ordered length of fabric is 25,000 meters and the order has been broken into 10 work orders at 10 looms, then it will take 5 days to finish the WIP at looming. This is if all the work orders are done simultaneously and speed of looms are 500 meters of fabric woven per day. A single dyeing machine will produce 25,000 meters of warp in half a day.

Solutions

These challenges in the textile industry can be met by conducting a profitable to promise analysis; grouping, breaking, and sequencing orders; and by routing WIPs. In the textile industry, orders are considered more like combinatorial meters rather than individual order meters, so the same type of orders can be grouped and sequenced to achieve production efficiency as well as reduce inventory creation. All WIPs can also considered the same way for the same purpose.

Profitable to Promise Analysis

Businesses in the textile industry mostly gets varied orders in terms of rate per meter, quantity, fabric type etc. Because of this, each order has to be evaluated on profitability, customer service levels and long and short term goals of the company. Profitable to promise analysis allows the business to find out if the particular order will be profitable to make by considering the costs of raw material, process, inventory, and other factors against the price the customer is willing to pay. Thus it can be seen that some orders will be a lot more profitable than other orders. This analysis is perfectly possible if you have the right software tool, which can provide you with this kind of information.

If raw material availability, machine capacity, and production lead time are known at the time of order taking, then it is possible to give a definite delivery date to the customer. This is known as capable to promise. If we can also provide information about customer, production, inventory, stock out, material, and other overhead costs down to the item level, and then compare all incurred costs to the selling price, it will be possible to decide whether the incoming order should be taken and what priority it can be assigned, at the time the order is being taken. This functionality is very important for the textile industry.

In conjunction with above mentioned factors, a planning system that is also capable of grouping, breaking, and sequencing orders while it is doing total lead time calculations to determine a delivery date will solve many production planning problems. It will eliminate waste, reduce the generation of extra inventory, increase machine capacity utilization, increase customer service levels, eliminate stock out costs, and reduce production costs.

Grouping, Breaking, and Sequencing Orders

Grouping, breaking, and sequencing orders will also help to overcome textile production challenges. Group smaller orders at dyeing process. The same dyeing WIPs can be grouped so the generation of extra meters can be minimized. Break bigger orders into many smaller orders at dyeing, and sequence them with other orders. Loom areas typically have many kinds of loom machines which can produce different kinds of fabric but at very slow rates. If big orders of same material are continuously coming from dyeing, they will only go to a particular loom machine which can process it; other loom machines which cannot use these warps will go idle for want of material. Another way to minimize set up time is to sequence WIP orders with the same color at the dyeing process. This will minimize the set up time to change of color. Also, breaking individual orders into many parts will create many work orders for the same order at looming process. This will minimize lead times significantly at looming.

Also, look for already existing inventory in the form of extra meters at looms and finished stock in the inventory to allocate these meters against the matched fresh orders and plan for the remaining meters.

Getting Strategic Planning and Financial Planning in the Same Bailiwick

By partnering with operations on balanced scorecard initiatives, financial managers are helping their companies focus on critical business processes and gain consensus on the critical set of measures to help drive desired business results. In addition, with the explosion of Enterprise Resource Planning (ERP) and e-Commerce systems, financial executives are leading the charge in going from theory to practice by developing a cascading measurement architecture and providing the key linkages to other relevant information (e.g., products, projects, performance plans, and organizational data).

Certainly, the financial community has responded to the 'relevance' challenge that was laid down over a decade ago¹. In fact, relevance has been contagious. Already companies are tying balanced scorecard initiatives to leadership and strategy; making sure operating managers are focusing on the right issues and priorities, and coordinating the actions of the company as a whole in implementing those strategies².

While the role for today's financial managers is quickly moving upstream in the strategic planning domain, the challenge becomes even greater in light of the accelerating pace of change. This reality is quickly rendering obsolete the traditional approaches to corporate governance, such as 3-5 year strategic plans, annual planning and static budgets. In this new environment, financial managers can play a key role in driving the corporate agenda through their sponsorship and support of projects and investments that deliver critical business capabilities. To provide useful financial insight, sooner rather than later, financial managers need to think about business strategy as a process of continuous course corrections, evaluated more like a series of 'real options' than a single projected cash flow³. While the concepts behind real options are certainly familiar to most executives, the trick to identifying, valuing and making strategic choices lies in the complex and often overwhelming task of understanding the linkage between initiatives and changing corporate goals and managing the interaction among projects.

This article provides a breakthrough planning approach for rapidly realizing the business capabilities dictated by strategy and then through the financial lens of 'real options' shows how to time strategic choices⁴.

Identifying the vision is only half the job

At its core, strategic planning is a process that documents a set of choices made by management of a business describing 'the vision', objectives, goals, and supporting action plans along with the rationale and implications associated with these choices. However, as senior executives seek to realize the new vision, the momentum for change often stalls. As energized and well intentioned as the management teams and project teams may be, they often lack a disciplined approach to orchestrate change within their organizations. To realize the vision, management must be concerned with three key priorities:

• Developing a set of Business Capabilities to capitalize on the vision

• Translating Business Capability Requirements into necessary business processes, information technologies, and organizational systems

• Deploying a process for the rapid, ongoing realignment of key process, technology and organizational elements.

As straightforward as this sounds, most company projects aimed at the vision are often off the mark.

Interviews with over 100 executives in Information Technology (IT) and Operations areas reveal several common root causes leading to strategy execution failure:

• Rapid changes in technology and business process require a consistent disciplined approach, yet most companies don't have any enterprise-wide strategy

• Incorrect decisions are made because current reality failed to take into account predictable future events

• Companies are constrained in the execution of their business plan by past business application choices

• Key initiatives are often launched from functional silos, lacking alignment and fit with the greater organization with respect to process, technology and/or organization.

• Financial planning and budgeting fail to take into account the timing and interaction between projects.

The consequences can be disastrous as see in the following table.

Table 1: Lessons Learned from other Companies

	Situation	Assessment
	Abandoned its SAP implementation after investing over $20m in the project.	Management relized late in the game that the system being implemented would not fit its new, decentralized management model that was believed to be a key source of competitive advantage.
	Spent 7 years and a half-billion dollars implementing a mainframe-based enterprise system. Abandoned the project and started over with a client-server version.	The project duration exceeded the rate of technological change by such a degree that the system was obsolete before deployment. By anticipating that technology changes would in some way impact the project, management may well have adopted a different approach to bringing the desired business capabilities to the organization.
	Abandoned its ERP project in mid-implementation	The company found itself overwhelmed by the organizational changes caused by the project.
Source: Tom Davenport, Putting the Enterprise into the Enterprise System, (Harvard Business Review, July-August 1998)

The Case for Convergent Business Architecture^SM

To address these issues, companies need a breakthrough approach for rapidly realizing the new business capabilities dictated by the vision, strategy and/or forces acting upon the business, whether it be entering new markets, deploying a new operations model, product expansion, etc.

Convergent Business Architecture^SM (CBA) is a low overhead, highly iterative planning process that:

• Establishes a rapid-response mechanism for monitoring and responding to external and internal change forces

• Defines the essential business capabilities required to achieve enterprise goals

• Aligns business process, technology, and organizational strategies to improve operational capability

• Defines and prioritizes critical initiatives

• Rapidly deploys an ongoing three-month program/project integration cycle

The science of 'change'

The following figure depicts the process of translating external changes such as market shifts, regulation or new customer requirements and internal forces (e.g. new strategy or vision) into a sequence of appropriate actions that will move the organization in a coordinated way towards the realization of necessary business capabilities.

Figure 1: The Science of Change

Defining the terms

Looking at some key definitions, one can see the model more clearly:

Table 2: CBA Terminology

Change Forces	Those external and internal forces that are impacting the enterprise and may require it to move
Reveal critical
Change Drivers	Those change force groupings that will act as a lever upon the company and force it to alter the way it does business
Which must be responded to with
Essential Capabilities	These are the quantified target capabilities that the company must possess in order to respond to the change drivers
Which place unique demands and dynamics on the company's...
Organizational, Process & Technological infrastructure	Those people, process and technology "systems" that interact with one another to get work done.
Which must function within parameters set by
Architectural Requirements	A framework within which the company can act on the delivery of capabilities, thereby greatly increasing the level of assurance that conflicts with other elements of the organization are not being created. They establish guidelines that potential solutions may not violate (without explicit management approval) and offer steerage towards the selection of an optimal solution.
That are realized through
Projects	Actions that affect change on the organizational, process & technological infrastructure to propel the organization towards its goals through the realization of needed capabilities and the removal of obstacles.

In our experience, the CBA process helps to identify and define critical projects - including projects not even on the table - that are needed to build the capabilities to achieve the strategy. It also forces a hard look at the existing portfolio of projects; killing existing projects that are not in synch with the strategy. Eliminating some projects frees up scare resources to work on the projects that have higher value contribution to strategy.

A case study

Dell Computer abandoned their ERP program only after several months of detail planning and implementation when they realized that is was inappropriate in their environment. Analysis had focussed on inefficiencies caused by multiple home-built, unconnected, information systems that inhibited information flow across the company. This analysis led them in to choose an integrated suite of applications. Even as the decision was being made, two Dell executives were providing sufficient information to invalidate the ERP decision.

At one of their Platinum Council meetings where Dell executives meet with key customer account CIO's, Kevin Rollins, Dell's Vice Chairman, talked about the critical need for every aspect of the company to be capable of changing its process rapidly. He referred to this as an essential part of what he called velocity or the continuous speeding up of every business process. At that same meeting, Michael Dell described his business as being a virtually integrated system of processes and products extending from suppliers through Dell's manufacturing and distribution processes, on to end customers and the support of the product on their desktops. He also talked about the company's distributed management style and how continuous process improvement was a way of life throughout the company.

The ERP solution certainly provided zero-latency data availability, and it promised more seamless virtual integration and less complexity. However, other traits of the solution would have limited the ability of the company to manage processes in a distributed manner; violating the company's management and process improvement style. As shown in Table 3, had the Essential Business Capabilities of Dell been mapped against the Operational Capabilities of the ERP system, two strong cautions would have raised. This would have taken place even before potential suppliers were engaged and well before any large expenditure had been made.

Table 3: Sample Reference Architecture Comparison

		Architectural Impacts
		Business Processes	IT	Org. Dynamics
Character- istics of ERP Systems Source: CBA Architecture Reference	Pre-defined business functions prescribe organization structure	Work architecture must map directly to transaction definitions.	Reporting systems that infer org. structure from business function will need adjustment.	Some companies find it inefficient to adopt prescribed business function models
	Integrated Transactions and functional modules demand users who are task and context skilled	Impact of Zero-latency and Zero Propagation Time must be designed into processes.	Data consistency highly determined by workflow configurations.	Workers required to learn upstream and downstream implications of transaction
	Shared and enforced business rules facilitate a high degree of coordination / collaboration	Rule variations for unique requirements are costly and slow to implement.	Business rule changes will propagate simultan- eously & immediately to all processes.	Demands of a Cross-Functional process Management Orientation.
Legend			Good fit or no issue
			Some negative impact
			Apparent conflict

CBA is a methodology that helps to assess the appropriateness or fit of a solution to its target problem in the context of the complete set of essential business capabilities. The result is a much more thorough examination of project feasibility. There are similar interactions in e-Commerce projects causing delays, overruns and project failures. CBA is designed to assure a complete and appropriate set of actions that will deliver on an enterprise strategy. The completeness of the set of projects poses another set of issues including project coordination, resource allocations and timing.

A New Role for Financial Managers

As enterprise leaders, one of the most important roles that a financial manager fulfills is their sponsorship of critical business projects, in balance with the responsible management of corporate assets. Thinking about projects a set of 'real options' - interacting with each other over time - helps management teams understand which projects to invest in and when to make the investment. In other words making go, no-go decisions on current projects or understanding the value gained from being able to defer an investment (e.g., greater agility, less exit costs, etc.), increases the likelihood of strategy execution.

As seen in Figure 1 above, a crucial phase of a CBA cycle is 'project alignment' to strategy. In other words, are the right sets of projects identified to execute the strategy. By adding the concept of real options into the planning process, financial executives can help operations evaluate when the projects should be funded. First, let's consider the different type of options and how they relate to strategic choices⁵:

Table 4: Real Options in a Strategic Sense

Real Options	Similar 'Strategic' Option
Growth options - investment creates future growth options above and beyond the returns generated by the initial investment	Infrastructure projects such as investments in a new platform
Timing options - delay investments until more data is available, thereby reducing risk	Delaying new technology until more stable or standards accepted
Staging options - invest in stages rather than all at once, allowing decisions (new options) at critical stages	ERP or software releases can be implemented in stages
Flexibility options - investments generate interaction and provides options not previously possible	Building shared (or multiple) call centers allows agent load balancing
Exit Options - reduce investment risk by defining exit points	Kill projects in markets where share targets not met

Once projects are framed in terms of the options they create, the next step is considering the value to the strategy based on current knowledge of the marketplace. This requires two critical pieces of information about projects: their value to cost (similar to a ROI calculation but for a first pass analysis, a qualitative assessment will suffice) and their volatility (i.e., the stability of the technology, marketplace, etc.).

By thinking about projects in terms of value to cost and volatility (see Figure 2), management can quickly identify not only which projects are needed and when as well as key risk factors.

Figure 2: The 'Real Options' Grid

The following is a partial table of projects at one company, who first identified over 50 candidate projects using CBA and then used the concept of real options to further filter investment decisions prior to detailed financial calculations.

Table 5: Qualifying Real Options

	Project	Option Type	V1*	V2*	Real Options Assessment	Impact
1	Enterprise Technical Architecture	Staging	H	L	Invest Now	Technical Architecture viewed as critical input to determining the sequencing of IT investments and make/buy/lease decisions.
2	"90-day Product Demo"	Growth	H	L	Invest Now	This pilot, designed to demonstrate synergies between proprietary technologies, will be used to sell clients on the potential of the product platform.
3	Define Product Solution Modules	Flexibility	H	M	Maybe Now	This move to modular product design, away from custom development, will support solution re-use and rapid deployment. Evaluate resources after 'Invest Nows' are launched.
4	Client Account Mgmt.	Growth	H	H	Probably Later	Prerequisite projects and change management efforts must be accomplished before this project can be successfully implemented. Take a wait & see approach, but be ready to act.
5	Implement Oracle HR	Staging	M	M	Maybe Later	Despite the momentum behind the Oracle implementation in other areas, this did not immediately support required critical capabilities. Revisit in 6 months
Etc...

*V1-Value
*V2-Volatility

Summary

Convergent Business Architecture provides the science behind change and highlights the interaction among projects. Real Options adds a financial perspective and a common language for both operating managers and financial managers to discuss strategy. In doing so, companies benefit from:

• Executive teams having a comprehensive & cohesive story about where they are going and how to get to there (even if the destination changes)

• A clear agenda for setting and measuring operational performance on an ongoing basis

• Organizational learning about process and technology capabilities

• Early identification mechanisms to identify tradeoffs, disconnects, and secondary impacts

• Project discipline; including when to start and stop projects