Epicor Picks Clarus' Bargain At The Software Flea Market

On October 23, Epicor Software Corporation (NASDAQ: EPIC), one of leading providers of integrated enterprise, e-Business and collaborative commerce software solutions solely for the mid-market, announced its financial results for the third quarter ended September 30, 2002. Total revenues for the quarter were $34.0 million, a 14% drop compared to $39.4 million for Q3 2001, while software license revenue totaled $6.8 million, a sizable 23% drop compared to $8.8 million a year ago (see Figure 1). However, net loss for the quarter, which includes $1.8 million in amortization of capitalized software development costs and acquired intangible assets, was $1.4 million, which is less than a third of a net loss in Q3 2001 of $4.5 million which included $1.5 million for the gain on the sale of a product line and $2.2 million in amortization of capitalized software development costs and acquired intangible assets.

Figure 1.

Epicor ended Q3 2002 with cash and cash equivalents of $28.9 million, as this was the fourth consecutive quarter in which the company generated positive cash from operating activities. Still, as the continued economic slowdown and severely constrained enterprise software spending environment does not appear to be improving any time soon, the company has recently taken decisive actions to further reduce its cost and expense structure going into 2003 with targeted savings of approximately $3.0 to $4.0 million per quarter. These actions include a reduction in workforce of approximately 15% and the consolidation of facilities. Epicor believes these actions will allow it to continue its focus without materially impacting its ability to deliver enhanced product functionality and new technology platforms, as well as maintaining its high standards of product quality and customer satisfaction. With these actions the company expects to achieve profitability in the first quarter of 2003, as it expects to incur charges in the range of $3.0 to $5.0 million in the fourth quarter 2002, while it anticipates revenues for Q4 2002 to be flat to slightly higher than those in Q3 2002.

A week earlier, on October 17, Epicor signed a definitive agreement with Clarus CorporationMicrosoft platforms, in an all-cash transaction for a purchase price of $1 million. The transaction is expected to close in Q4 2002, subject to Clarus shareholder approval. Epicor will provide service and support to the majority of Clarus' installed base of procurement customers, and it has been engaged in reselling Clarus' procurement product for more than two years. Epicor believes the acquisition should enable it to leverage its experience in procurement and sourcing, its integration expertise, as well as its .NET architecture to deliver an expanded suite of supplier relationship management (SRM) capabilities as part of its enterprise suite offering or as stand-alone offering. (NASDAQ: CLRS), a provider of buy-side e-Business applications to the mid-market, to acquire substantially all of its core products, including procurement, sourcing, settlement and analytics written on

During the quarter, in September, the company shipped the market's first CRM.NET product and has been successful with a number of early adopters as well as new customers, including its first customer, The Boeing Company. Unveiled earlier this year (see Epicor Claims The Forefront Of CRM.NET-ification) Clientele Customer Support 8.0 is the first application in the Clientele CRM.NET Suite available to customers. The company is scheduled to release a number of new products on the .NET platform over the next several quarters, including CRM.NET Portal and its enterprise services solution on the .NET platform for project-driven organizations. Clientele Customer Support 8.0 is available immediately in North America, the UK and Australia, as well as select countries in the Asia Pacific region. Existing customers on maintenance will receive the upgrade software at no charge. Standard List Pricing starts at $1500 per user with quantity discounts available.

Despite the challenging environment for attracting new account sales, Epicor reportedly added over 110 new customers in the quarter and has added over 350 new customers year-to-date. It has also launched a number of new business development initiatives to further relationships with vertically focused value-added resellers (VARs) and to expand its international reseller distribution, and its lead generation programs will focus on specific targeted verticals and specific customer size and will continue to leverage co-marketing efforts with partners and industry trade groups. Epicor reportedly continues to invest in its sales, service and support organizations which have undergone significant training on a series of new products as well as value vision methodology training to improve its success in the current economic environment.

Clarus Background:As a preamble, if it weren't for the inevitable �ifs and buts', the acquisition would be logical for various reasons. Clarus would be yet another software vendor that has experienced a dreadful rise-and-fall trajectory. Originally a mid-market enterprise resource planning (ERP) vendor, Clarus' prime was in �remote' 1998, when its revenues reached an all-time high of $41.6 million.

But the arguably hasty sell-off of its financial and human resources software to Geac Computer Systems early in 2000, followed then by a risky all-out dive into e-procurement and Internet exchange realms have apparently not paid off. The strategy had a short-lived immediate success though, with its stock price reaching an all-time high of $144 per share in March 2000 (see With New Clothes and Hairdo, Clarus Asks for Pin Money). Since then, however, the vendor has only seen its revenue and its stock price nose-dive, with 2001 revenue of $17 million and a current stock price of just hovering over $5. For the quarters ending June 30, 2002, and September 30, 2002, Clarus reported revenue of only $1 million and of less than $2 million respectively, with grim prospects on any future revenue levels.

Clarus has been nevertheless regarded as a best-of-breed indirect materials e-procurement application provider that has not only garnered notable expense management and Private Trading Exchange (PTX) applications, but has also espoused a reverse auction, e-settlement, content management, and expense processing capabilities to round out its suite towards a decent supplier relationship management (SRM) suite, a recently emerged new category of enterprise applications (see Clarus - Sprinting or Going the Distance?). From a product perspective, Clarus had also added to its portfolio an Internet marketplace platform, Clarus eMarket, and Clarus Content Services for content management.

In May 2000, the company entered the e-sourcing market through the acquisition of iSold.com, an auction and dynamic pricing vendor, while the acquisition of Ireland-based SAI/Rodeo Technologies has added support for the payment and settlement process. Clarus has also partnered with TPN Register for content management, webMethods for its Clarus Fusion integration toolkit, and with Silver Oak Partners for strategic sourcing expertise for both direct and indirect goods and materials and for expense segmentation and reporting.

In an attempt to increase and make its revenues more predictable, the company had even introduced an ongoing, usage-based revenue model, spreading out revenue from each customer over a protracted period of time. It had also tried to extend its indirect sales channels (albeit at the expense of negligible direct sales force, which has proven to be critically counterproductive revenue-wise), in addition to its partnerships with infrastructure and integration partners Microsoft, Compaq, and Deloitte & Touche, and to partnerships with enterprise applications vendors like Epicor, Ross Systems, Microsoft Great Plains (Microsoft Great Plains Procures eProcure At Last), Manugistics and Commerce One, all throughout 2000/2001.

Unfortunately, few if any of these initiatives have generated the traction needed to reverse the company's sagging revenues bundled with overwhelming costs. Possibly the mortal blow happened when UK-based independent trading exchange BarclaysB2B ,one of Clarus' biggest customers, recently decided to close its operations. Last summer, the company closed its operations in the UK and Canada, concluding an ongoing downsizing of operations in the past year. Clarus has since been operating with approximately a few dozens of staff from its Suwannee, GA headquarters and a skeleton customer support staff at its facility in Ireland, with a vast majority of them only engaged in servicing existing disconcerted customers.

Due to the above adverse events, Clarus ended up in a peculiar situation of its net assets being greater than its market capitalization, prompting an influential group of shareholders to demand that the remaining asset value be delivered back to them. The other faction of the Clarus board has been proposing the sale of the company as a going concern, still without a clear indication from the board which direction the company will take after the above sell-off.

Epicor Background:On the other hand, Epicor had long grappled with shuffling the many brand names/products that have emerged during last few years from now proverbial merger of its ancestors, former Platinum Software and DataWorks. Epicor seems to have nonetheless somewhat successfully refocused on its core areas following the turmoil of the merger and steep revenue decline due to other relevant factors (i.e., enduring sluggish economy and product divestitures) in addition to the above-mentioned internal tumult. The acquisition initially made Epicor one of the largest mid-market ERP vendors (with ~$250 million in 1999) and the company thereby gained some strong products and a large customer base in a number of new markets, especially in the realm of manufacturing, distribution and supply chain management (SCM). Nevertheless, the burden of an unfocused, multi-product and multi-technology (Microsoft, Oracle, Progress Software, etc.) strategy in markets with diverse dynamics also multiplied sales, R&D, and service & support costs, while many of these products could not have sustained long-term success in their respective target markets.

However, the divestiture of certain secondary and focus-diverting product lines (see Latest Development on Epicor's Trying The Divestiture Tack) has therefore allowed Epicor to lately concentrate on developing applications and functions based on Microsoft's .NET technology framework and SQL Server database. Consequently, it is more likely Epicor will succeed in integrating its internally developed applications by concurrently expanding its Web services and collaborative commerce capabilities.

With its solid cash position and current development work in progress for contemporary Internet-based, 'software as a service' enterprise and collaborative commerce applications, and given its intentions to continue to sell both directly and indirectly with accredited VARs within certain vertical segments, a return to better days does not seem as a far-fetched possibility for Epicor. Attempting differentiation, Epicor will continue to invest in its products in order to assemble the right mix of back-office, front-office, and collaborative e-Business functions, delivered under a single-point accountability (one-stop shop) approach that is desired by its target market.

Epicor's Strategy:To that end, Clarus' acquisition for a little dent in Epicor's purse makes sense, given Epicor has resold in an OEM fashion the Clarus eProcurement product as part of its application suite from February 2001. Epicor will have thereby proven itself successful at selling and implementing the Clarus solution, and the experience with the eProcurement product will have given Epicor a deep understanding of the Clarus products from a selling, service and support perspective. Epicor was consequently among the first vendors to offer Web-based e-procurement at an affordable price for the mid-market and, with this acquisition, Epicor should soon offer an expanded set of SRM solutions, including e-procurement, e-settlement and e-sourcing, as viable add-ons to an overall applications suite for the mid-market segment.

Epicor's and Clarus' products seem to be very complementary in terms of their technology, their mid-market fit, and the business value that they deliver. Both Epicor and Clarus have recently focused their development efforts on Microsoft technology and, specifically, on the Microsoft .NET platform lately. Like Epicor's products, Clarus' products provide advanced functionality, but have been designed keeping the challenges of a mid-size company in mind (i.e. limited IT budgets and limited IT staffing resources).

As an example, Clarus' applications do aim at enabling companies to streamline their operations and significantly lower costs associated with e-procurement. Clarus eProcurement is a slick e-procurement product for small to medium enterprises (SME) rather than an overkill application with unneeded, complex functionality demanded by trading exchanges. Clarus' Microsoft-centric product architecture, the support for many languages and alliances with trading exchanges that do not charge transaction fees should be additional attraction for the intended customers.

Further, the product could reduce significantly the costs of goods and services by enabling supplier performance analysis and tracking and cost analysis and directing purchasing to more profitable sources. It also enables search capabilities internally and externally to both online marketplaces and directly to suppliers for more strategic product selection and pricing. Integration with an online marketplace enables organizations to conduct auctions, reverse auctions and comparison shop, ensuring a competitive price.

Clarus features an architecture that can be configured to mirror almost any organization's operating structure, by using strong mapping capabilities for unlimited levels of approval. Purchase orders can be routed according to price, category, job classification or a number of other attributes. Moreover, with mid-market companies focusing on increasing efficiency and lowering costs more than ever, Clarus eSourcing, which provides a complete auctioning, bidding and weighed RFQ solution, becomes a pivotal component of a solid SRM solution.

Additionally, Epicor has a large customer base that can provide valuable input into future direction of these products, in addition to cross- and up-sell opportunities for the vendor. The company should also benefit from an additional revenue stream from several dozens Clarus' customers and from some ancillary Clarus applications, like a business intelligence (BI) module and an e-learning application to boot. There are significant opportunities for Clarus' international expansion owing to Epicor's strong international presence in the EMEA, Latin America and the Asia Pacific regions.

Software Evaluation, Selection, and Procurement

A 1995 Standish Group research study based on over 8000 software implementation projects found that nearly one third of the projects were canceled before completion. And over 50% of the projects cost nearly twice their original estimates. The study further concluded that only 16% of all software projects are completed on time and on budget (only 9% for large companies)¹.

With these grim statistics firmly in hand, a plethora of books, white papers, and articles have been written on implementation success factors and software implementation methodologies.

While these publications offer sound and sage advice, the problems remain and the project failure statistics have not improved.

One area receiving little scrutiny, however, is the software evaluation, selection, and procurement processes employed by most organizations. This article reviews common problems associated with software evaluations, and introduces several ideas for improvement.

The Capital Investment Paradigm:

Financially, GAAP requires companies to account for most software license and implementation costs as capital investments. This makes perfect fiscal sense, as the software lifecycle is long and depreciating the investment over multiple years is sound financial practice.

Unfortunately, the software procurement process does not follow a similar, long-term capital investment approach. Instead most companies handle software purchases like departmental operating expenditures. This flawed paradigm is the root of many implementation failures and the cost overruns cited above.

To illustrate the capital investment approach, let's use the example of production machinery for a manufacturing firm. When considering an investment in new machinery, multiple departmental teams with varying requirements participate in the decision making process. Typical activities might include:

Team	Activity
Manufacturing Management	Build business case for investment in new machinery Investigate alternatives to new machinery purchase (i.e. outsourcing, continued use of existing machinery, etc.) Investigate the service and warranty support provided by the candidate vendor(s) Investigate the financial viability of the candidate machinery supplier(s)
Engineering	Test the machine to confirm it will produce the necessary product within tolerance
Factory Operations	Test the machine to make sure it fits within the allocated floor space, is easy to operate, and will improve productivity as expected
Quality Assurance	Test actual runs of product through the new machine to confirm the error rate is within requirements
Customers	Manufacturing process changes may need to be reviewed by external customers to ensure they conform with agreed to specifications
Suppliers	Raw materials will need to be confirmed on the new equipment and possibly alternative suppliers must be evaluated
Procurement	Negotiate final contract terms
Finance	Arrange for acquisition of needed capital

Other forms of capital investment (such as facilities or real estate) generate similar analysis and due diligence activities from a variety of internal and external teams. This model recognizes the fact that a capital investment must serve the organization well for multiple years. Spending time and effort up front to ensure a smooth transition to the new machinery (facility, etc.) is simply good business practice.

Software Evaluation Challenges:

Most companies do not treat software procurement in a similar manner. A series of common flaws can be found in most selection processes. The following table outlines the most common software evaluation and selection flaws, and the associated risk.

Flaw	Leads to...	Project Risk
Insufficient time devoted to evaluation and selection	Ill informed decisions �	Poor software "fit" against business requirements Improper expectations on implementation cost, time, resources, etc. Erosion of project support Increased user resistance
No business case or Poorly defined business case	Inaccurate projection of: Costs Benefits Alternatives Risks Assumptions etc.	Cost overruns due to poor planning Lack of business benefits Lack of "Ownership" of each individual benefit Erosion of project support
Affected departments not part of selection team	One-sided evaluation of software fit Unidentified software gaps Poor software "fit"	Cost overruns due to unplanned work to resolve new software gaps Erosion of project support Increased user resistance
Incomplete or inaccurate set of business / technical requirements	Unidentified software gaps Inability to sufficiently "test" the system	Cost overruns due to: Unplanned work to identify new requirements at a later date Unplanned work to incorporate additional functionality Unplanned work to perform additional testing Erosion of project support Increased user resistance
Insufficient testing of candidate solutions	Unidentified software gaps Unidentified integration issues Poor software fit	Cost overruns due to: Unplanned work to resolve new software gaps Unplanned work to build interfaces Erosion of project support Increased user resistance
Insufficient verification with external customers/suppliers	Customer/supplier discontent with new system	Lost sales Lowered customer service Supplier cost increases
Insufficient due diligence of software vendor (i.e. references, viability, future development, support, etc.)	�	Poor support Lack of future functionality for upgrade, enhancement Increased total cost of ownership

The software evaluation and selection process builds the foundation for the entire implementation project. A foundation that includes one or more of these flaws will inevitably crack under the pressure associated with a mission-critical software implementation. A structured and disciplined software evaluation and selection approach will mitigate this risk and establish a solid foundation from which to move forward. The following section outlines our recommended guidelines for such an approach.

This concludes Part One of a two-part article. Part Two makes Recommendations for Improvement.

Software Evaluation, Selection, and Procurement Part Two: Recommendations for Improvement

Recommendations for Improvement:

Take a Guide

Software evaluation and selection is a learning process. The selection team will learn a great deal about itself, the company requirements, external software vendors, application software tools, and outside consultants. During this "journey of discovery" it is often helpful to take a guide � someone who has been there before and can lead you through the process.

When looking for a consultant to guide you through the process, look for a firm that is unbiased and has no hidden agenda. Many consulting firms resell software or have close financial alliances with software vendors. While these consultants may be very useful during the implementation phase, their judgment may be impaired during the selection phase. Also closely examine the specific individuals who will work on the project.These are the people you will work closely with on a daily basis, so choose them wisely. Evaluate their skills, past experience, market knowledge, industry expertise, honesty, integrity and references. Be wary of any consulting firm that will not clearly identify the resources for your project.

Don't rush the process!

This seems like heresy in today's corporate climate where everything must be done yesterday. The key here is to maintain the paradigm of software as a capital investment. Look at similar corporate decisions regarding machinery, real estate, facilities, etc. and use that as a guideline for your decision-making timeline.

Obviously there is a balance between "analysis paralysis" and constructive action toward a known objective. Effective management is crucial at this early stage to ensure the team continues to make progress and does not bog down in over analyzing the selection.

Build a strong business case

Probably the most important deliverable in the entire evaluation and selection process is the business case, which serves as the "guidebook" for the remainder of the project. A strong business case establishes the project expectations and guidelines including:

• Project scope
  
  
• Expected costs
  
  
• Expected benefits
  
  
• Project performance metrics
  
  
• Risks
  
  
• Overall implementation approach and timeline
  
  
• High level project workplan
  
  
• Resource requirements
  
  
• Assumptions

But it is not enough to simply produce these documents and call the business case complete. Sufficient analysis must be performed such that the project expectations are realistic and supported by factual evidence. For example, saying that a project will result in $1M in cost savings due to "more efficient supplyy chain processes" is not sufficient analysis. One must identify the specific performance metric that will improve due to the new system, discuss how the software will actually improve that metric, assign an "owner" responsible for delivering that benefit, and then calculate the expected financial results.

For example, if your project is expected to reduce raw material inventory, a thorough business case will record this as follows:

Expected Benefit #1 - Reduce raw material inventory in category A by 25%

• Justification:
  • Software and business process enhancements will reduce the purchasing cycle from 4 weeks to 3 weeks. This 25% reduction will allow a corresponding reduction in raw material inventory on hand. This benefit assumes that the three week purchasing cycle will not result in additional transportation costs due to increased shipment frequency or less than truckload shipments (this assumption is supported by the evidence presented on page XXX of the business case).
    
    
• Owner:
  • Bob Jones, Director of Purchasing
    
    
• Savings Summary:
  • Expected annual savings = $125,000
    
    
  • Expected one-time reduction in working capital investments = $1,250,000
    
    
• Savings Detail:
  • Current average raw material inventory value in category A = $5,000,000
    
    
  • Expected inventory reduction = 25%
    
    
  • Expected annual return on invested capital = 10%
    
    
  • Annualized Dollar Savings = $5,000,000 x 25% x 10% = $125,000
    
    
  • Reduction in working capital = $1,250,000

As you can see, a more detailed set of benefits will remove ambiguity, assign ownership and give the project team a clear set of goals and metrics to target. Developing a business case at this level of detail is a key component in gathering executive support for the project.

In addition, a strong business case serves as the project reference manual. As the implementation begins questions will arise surrounding scope, objectives, budget, resources, deadlines, milestones, etc. The business case must be used to guide the decision making of the project management team. Without an effective business case, and managers who use it properly, an implementation can quickly lose focus and wander off course.

Involve all affected departments on the selection team:

What seems to be a simple concept is often bypassed for political, personal, and resource/schedule constraints. But there should be no compromise here. A software evaluation and selection team that does not include affected parties will invariably face high-levels of resistance and increased risk of failure. When implementation troubles set in or questions arise over the software capabilities, organizational buy-in and support will help you manage through these issues. Without it, the project can and will lose momentum.

Be thorough in your requirements definition

Again this is a simple concept, but one that is often bypassed due to expediency or difficulty. A comprehensive set of business functional and technical requirements serves multiple purposes:

• Acts as a basis for software evaluation
  
  
• Acts as a basis for defining software gaps
  
  
• Acts as a basis for final software testing (system, performance, user acceptance, etc.)
  
  
• Acts as a basis for training
  
  
• Establishes project scope

Concentrate on data

Many legacy systems are weak and ineffective because they don't provide the information desired by the Executives to effectively run the business. Often, the needed data does not exist in the legacy system. Hence the company embarks on the implementation of a new, modern system.

When analyzing the new system, concentrate on the required data elements. These data elements may not be readily available in your company, and without them the new software will not work properly. As part of the evaluation process, assess your company's ability to provide the requisite data to the new application. If additional data gathering is necessary, consider how this will be done (manually, or through automated means such as bar code scanning, or through interfaces to other systems, etc.). Also consider the cost associated with this data gathering effort, as it can often be substantial.

To illustrate, a large, multi-national semiconductor company recently initiated a project to implement a state-of-the-art supply chain planning system. The new software was purchased and initial analysis begun before a major data issue was brought to light. The new system required consistent item information. Unfortunately, item master information for the company was located on several different systems, with little consistency between applications. The data problems were so large that the new system was simply unable to perform properly. To rectify the problem, the company embarked on a 12-month item standardization process that delayed all efforts pertaining to the supply chain planning system. When finally completed, executive support for the supply chain planning system had eroded and the project was shelved. Over $2M in software, hardware and consulting services was wasted.

Prototype the software BEFORE buying!:

During the heyday of application software sales in the mid-to-late 1990's, large application software contracts were being signed regularly and without rigorous buyer evaluations. Except in certain circumstances (i.e., large buyer in strategic market), software vendors were reluctant to expend abnormal amounts of effort convincing a customer to buy their software. Pre-configured demos, high-level brochures and limited technical documentation were the basic info given to the buyer. Demands for additional evaluation hurdles were often met with delays, excuses, and even flat refusal.

But the times have changed and the power is now most certainly in the hands of the buyer � where it should be. Returning to our capital investment paradigm and machinery analogy, an organization would never consider buying a key piece of production machinery without ensuring that it had been thoroughly tested for quality, ease of use, and engineering/supplier/customer acceptance. Software should be no different.

In short, before signing the final contract and buying a piece of software, put the selected candidate package through a rigorous set of tests. Require the vendor (or an implementation partner) to build a prototype using real data and execute a test using real processes. Produce extract files and reports that are close approximations of technical interfaces and user requirements. Allow users from various business departments to see, touch and manipulate the system. Basically build a prototype.

You should expect to compensate the vendor for his time and effort to build such a model since the work product serves as a solid basis for full project implementation. But a small amount of time and money invested up front to discover gaps, product issues, and vendor capabilities is invaluable. This prototyping effort will limit the project risk and provide an option to stop the project before wasting significant time, energy and money.

Don't focus on price!

Price is obviously a key component of any business purchase, and software is no different. But price is not the right factor to weigh. The cost of the software itself is minor compared to the long term costs associated with its "care and feeding". Instead look at Total Cost of Ownership (TCO), which includes support costs (both internal and external), service fees for implementation, enhancement and ongoing growth of functionality, maintenance fees, vendor viability risks, software upgradability, and hardware requirements.

Often the cheapest software solution ends up being the most expensive over its lifetime. For example, one factor that significantly impacts the total cost of the solution is software customization. Modifying packaged software is strongly discouraged due to the high-cost and complexity in supporting and upgrading the software over time. Often the lowest priced software lacks functional depth, driving companies to adopt a software customization approach. When a software customization path is chosen, expenditures for software development, long-term support costs, and upgrade costs must be included in the total cost of ownership and ROI models. Invariably, when TCO is considered, the lowest priced solution becomes more expensive and the benefits of the cheap price are lost.

Conclusion:The implementation of any mission-critical software application is fraught with risk. As the Standish Group statistics at the beginning of the article note, over 30% of implementations fail, and over 50% cost more than twice the original estimates. Those are very bad odds that most organizations should not accept. Pursuing an alternative strategy for software evaluation and selection based on the capital investment paradigm and the principles outlined above is an effective method to mitigate this inherent risk.

ERP Systems and the ETO Manufacturing Market Part Two: ETO versus Repetitive Differences

ETO versus Repetitive Differences:

Having outlined the above, it might be useful for us to recap the major differences between engineer-to-order (ETO) and repetitive/volume-base manufacturing environments throughout different phases of a product life cycle as well within various functional departments within a manufacturing organization. First of all, prior to any manufacturing, there is extensive work in the product definition phase (i.e. estimation, design, and engineering) before anything can be made, bought or delivered. However, the major difference is that within ETO companies the product design is an integral part of production (if not even afterwards, during the site installation and commissioning), whereas for repetitive, standard items the design is typically completed and handed "over the wall" to the manufacturing well before the production starts.

In volume manufacturing, product definition work is amortized (recovered) over the items' life cycles, which are often measured in thousands of items and over several years of commercial use. Whilst a possible time overrun here will effect the time-to-market of the product, (which is often the competitive advantage (strategy) in addition to lower costs for repetitive manufacturers), it has no effect on the overall lead-time of any particular sales, job, or project order, and is therefore not handled in the same way. Moreover, the extensive costs of product definition are absorbed into the company overhead or standard product costing, so that an overrun of costs can be managed in the context of a long term pricing strategy.

Project-based/ETO manufacturing is very different, as a majority of the total project lead-time and expenditure can come from engineering, which makes it crucial for the company to engineer correctly and maintain costs. Complex manufacturers produce products that are of high variation, have complex features and options, and vary in end user configuration. Each job is unique and the variables are based on client specifications rather than on the options from the stock. They consequently invest significant dollars in product design and have lengthy sales and manufacturing business processes, often requiring collaboration between the customer, sales representatives, and critical back-office experts.

ETO manufacturers focus on special jobs that have never been done before, or custom jobs that are similar to others but require extensive modification to accommodate customers' special requirements. Further, customer approval may stipulate many engineering changes and adequate information about these changes must be timely when released to manufacturing and purchasing, and sometimes even to the field service force. As a matter of fact, product design almost never stops, given customers' prerogative of changing their minds in the midstream, to a degree that they feel free to change specifications or add new requirements to the original orders, sometimes by directly instructing the supplier's manufacturing personnel and circumventing the proper channel of the sales and engineering department. Occasionally, the customer might attempt to play dumb and even refuse to pay for any changes to the original orders if the enterprise is unable to track all these change requests back to the initial order and prove him or her wrong.

Furthermore, since most projects have unique requirements, lead time of the product definition processes will directly impact on the delivery of the project, and will affect the contract. The company will go through it all over again on the next project, even if the product is similar to the previously delivered one. Thus, there is effectively little or nothing to amortize or recover the costs. For these reasons, far from being ignored, these "upfront" product definition processes need to be carefully planned and accounted for.

Moreover, sophisticated customer interactions (such as order/contract definition and management applications) are required, while customer service needs are also oriented toward hands-on contract management and cost reporting. Frequent changes force contract supplier engineers and subcontracted original equipment manufacturer (OEM) engineers to be in a constant collaborative communication throughout the design and production cycle of the unit. One of the most manual functions in a supplier organization have traditionally been the sell-side request for quote (RFQ) management (as opposed to standard price and discount lists in repetitive environments), which usually revolves around a few key expert individuals that have direct knowledge of the product or who can manually pull together the diverse information sources into a unified document, as contract proposals include quotations, pricing, detailed product information, data sheets, and computer-aided design (CAD) drawings. In complex ETO manufacturing, where the quality is a given, and while available capacities are on par, what makes the winner is the ability to set a competitive price. There is a huge difference between winning business and winning business that is profitable to accept and that is a win-win situation for both the customer and the provider.

On the other hand, in almost all industrial manufacturing segments, the pressure to reduce lead times has become a constant and ever-expanding concern. Depending on product complexity, some parts or sub-assemblies might be quoted immediately, while others have to be highly specified. Developing a contract proposal requires many levels of checking and re-checking customer process requirements and facilities capabilities, as well as preliminary design work and sourcing of specific components or materials. The process typically goes through much iteration every time the customer uncovers a new requirement or constraint. The labor-intensive nature of this process has often resulted in lengthy estimating cycles, which have in turn often translated to lost business opportunities.

Product Configurators May Play the Role:

By harnessing an enabling technology to make everybody work smarter rather than harder, complex manufacturers could, in some instances, reduce the time it takes to create contract estimates. To that end, modern product configurators have become the pivotal enabling technology for simplifying complex ETO operations in the direction of mass customization, providing the ability to more easily configure individualized products and services at the point of sale (POS) with integration to back-office systems. Providing customers with exactly what they want is not exactly a new concept, but the idea of giving the customer ever-expanding range of choices as early as possible has become the center of many various industries' customer-oriented activities, given that getting an accurate, customized product to the customer more quickly fosters competitiveness.

In general, product configurators are software tools that streamline order entry process by asking the customer to select from a set of predefined options associated with a generic product line, and then apply predefined rules with constraints to correctly configure the particular end product. The configurator then populates the attributes of the newly configured end item (called the variant product), tests for any conflicts, and generates the variant product with appropriate BOM, routing, and pricing based on preconceived rules and calculations. As product configurators have evolved to include even more sales, marketing, and financial functions tangential to the product per se (e.g., pricing, cost analysis, sales commissions, available-to-promise [ATP], order status, etc.), the term "sales configurator" has been used to increasingly to reflect their expanded role. It may more accurately describe their extended role as tools that assist salespeople with not only building viable products, but performing related tasks, such as proposal and quote generation. Still, configurators may have only limited usefulness for the most complex, unique "one off" project-based environments.

In any case, the ETO-oriented systems must facilitate the near real time transfer of information and complex product knowledge for collaboration across the extended enterprise, and should especially be suited to organizations that seek to maintain complex selling relationships, such as businesses whose procurement and sales functions rely on subcontractors, channel partnerships or a distributed sales force. To that end, a manual process that took anywhere from a day to several days should now be accomplished in about one minute with the appropriate use of technology.

In volume manufacturing, concurrent engineering means getting teams together. According to APICS Dictionary, it is "a concept that refers to the participation of all the functional areas of the firm in the product design activity. Suppliers and customers are often also included. The intent is to enhance the design with the inputs of all the key stakeholders. Such a process should ensure that the final design meets all the needs of the stakeholders and should ensure a product that can be quickly brought to the marketplace while maximizing quality and minimizing costs". Also called co-design, concurrent design, early manufacturing involvement, parallel engineering, simultaneous design/engineering, team design/engineering, integrated product development, participative design/engineering, quality circles or design for manufacture (DFM), concurrency is mostly about teamwork and the sharing of knowledge. In project manufacturing, however, concurrency goes a mile further by running design, manufacturing, and commissioning simultaneously, since it is often the only way to satisfy the customer's deadline.

ETO and project-oriented ERP buyers should therefore ask prodding questions about how the systems they are evaluating handle concurrency. For example, can the design department release a partial BOM for manufacturing to work on, and then add to it or modify it later when they are sure of all the facts? This capability is sometimes referred to as "progressive engineering", which is the ability to handle items that are part of the project but still undefined—they can nevertheless be included in the project work breakdown structure (WBS) and the application will plan around those items without losing the integrity of the structure.

More Differences from Repetitive Manufacturing:

In rigid systems for repetitive manufacturing, implementing a change to a BOM or routing would require canceling all the affected open, closed, and in-progress orders and re-creating them with the new information. This in itself can create countless hours in administering the ERP system. As mentioned earlier, project manufacturers have frequent changes imposed upon them in the midstream, and, if the ERP system can cope at all, it should be able to provide the rationale to the following "what if" questions—"what is the cost difference between the designs?", "what is lost and unusable?", and "what is still good or could be reworked?".

Consequently, the BOM and the way it is handled are different for project manufacturing to that of volume manufacturing, and not only in terms of deep, multilevel ETO BOMs versus flat BOMs for repetitive items. For one thing, a BOM in a project environment is not limited to standard factory items (such as widgets), or even items used to make the product. It is often even preferable to be able to create a BOM without using part numbers for some components, since these are only purchased to a particular project (and not received into the stock at all), whereas the finished unit is often shipped straight from WIP, again without being reported to the inventory. Further, in order to commission a project, consumables and sundry items, tools, jigs, and fixtures may well be required. Often, on surface, this may appear to be supported by a volume-based ERP system that recognizes that a certain tool must be available to run an operation step in the routing on a certain machine in the factory. Thus, to remove any confusion, here is an example of making machine tools. When the time comes to commission the machine, users may well require a cement mixer and cement in order to bed the machine down—but only after the machine is already "made" and delivered from the plant floor—and of course these items are required at the customer's site, not the factory floor. Another example could be boiler manufacturers that require welding, painting or corrosion-protective work, at the installation site.

Also related to the above, at the core of ETO/Projects functionality is often a "service item" feature that allows the system to define and manage service products (which are often activities rather than physical stock items) such as engineering, education, installation, and consulting. Similar to the way BOMs aid production planning for physical products, the service item aids scheduling and capacity planning for services. This brings us to commissioning and installation, and service and support activities that come post manufacturing. Project manufacturers may indeed have to put extensive planning and effort into what happens after work in the factory is finished.

Staying with our earlier example, a manufacturer of boilers, may have to involve contractors, testing agencies, haulers, and extensive labor, all to commission the project. Yet volume-based manufacturers may see things in a different light. They presume that product is commoditized, since it can be distributed from finished goods inventories to users, resellers, and other manufacturers who know what to do with it. Their traditional lead-time calculation only counts up to final assembly, while, as previously mentioned, the design typically ends before the production starts (unless we are talking about some design changes due to such as recalls or design refinement). On the other hand, the ability to track warranty and provide aftermarket services, and manage spare parts with remote inventory tracking (for example parts stored on service trucks) would be additional gauges of any ERP system's strong fit for project-based and service industries.

Service Chain Information will Transform the Total Chain

Spending time with very diverse sets of businesses—from Combatant Commanders in the military to a dishwasher repair business, the obvious facts continue to haunt me—and probably a huge amount of business people—is the lack of real information about what happens to products once they leave the manufacturer. From a hot bumpy ride (RFID sensors, anyone) to a lost shipment bound for Iraq, everything that happens has some kind of relevancy to a host of business people, product designers, quality engineers, logistics firms, aftermarket managers... oh, and did you mention the customer? Everyone seems to want the data, yet so little is known.

There is a whole series of structural reasons for this.

First, many user organizations have a stovepipe procurement process where the purchaser (or the original equipment) is not the same person maintaining it. So information about performance on the plant floor or in the field may not be known in headquarters. Also, many products don't stay with their original owners, making their way to new buyers—from huge used car networks to ebay. The recent commercial where the father is quizzing the automobile to determine if it will take good care of his daughter highlights this issue.

The converse of this is also true. The OEM's service business is disconnected in process, systems philosophy, accounting, etc. In fact, today much of the last mile service businesses may be outsourced. Though best practice says we get connected for the total life cycle of the product, only the very best and very rare of entities can boast this.

Lack of integration between logistics and repair. Getting the stuff to the point of breakdown is a nontrivial exercise. Vision of FedEx packages with laptops might be great for consumer electronics, but large components of aircraft, power generators, even autos—well they don't get there in a mailer—may require a hard day's night, or weeks of travel to get to where it is needed.

Performance-Based Management Philosophy Will Transform Business

In recent years we have gone through a life cycle of improvements in the service infrastructures. And with more and more manufacturing moving offshore, the need for still more local service providers is evident. Long life products are particularly expensive not only to repair, but many businesses maintain significant backup parallel equipments just to offset the vagaries of downtime. But that stuff's expensive! And the tolerance for this is wanning, with economic pressures increasing. We just don't have an unlimited amount of capital—and it is possible to get much better performance. Imagine the average household buying a backup auto, dishwasher, TV, and all their appliances, because the uptime on these products was less than 50 percent and they had to have a backup while their furnace was in for repair.

Performance-Based Management:

Moving to a performance-based business model will have huge implications for the whole value chain. Firstly, it's giving customers what they really want. As someone once said, "our customers don't want drills, they want holes!" Having said that, it means architecting your processes and technology, from the point of performance back. Rather than pushing our parts through distribution networks, it's predicting performance, building products better and sensing or predicting when they will fail—before they fail—and then averting downtime.

The implications are profound and don't make everyone feel happy about this.

More uptime means less sales of original equipment.
The DoD, for example, is beginning to write contracts for these "Performance-based Logistics" weapons systems, like the Joint Strike Fighter, etc. Performance-based Logistics is a leading-edge approach to managing complex supply chains. Its principle is to manage for outcomes—procure performance rather than parts and people. It requires total business process reorientation from servicea and maintenance through procurement techniques, as well as the IT platform for integration. Technologies that allow predictive management dramatically improve the DoD's ability to predict and prevent weapon system failures. This includes the addition of sensing and monitoring technologies for both new and legacy weapon systems, and incorporates consideration of operational and environmental factors in preventative maintenance. It also includes data gathering and transmission in a distributed environment, and represents an integrated approach to driving weapon systems availability.

Many IT-focused businesses already have this approach as a core tenant. If you outsource your data center to SUN, Unisys, etc., you are not particularly interested in details, you expect uptime. SUN has done a good job of marketing this approach—access anywhere—total performance to their customers. Real-time sensing tools, performance analyses, and remote diagnostics have all been part of this model for some time.

Owning or managing more of the logistics process.
So, an OEM will sell less parts—less original equipment, but increase service. Less parts can mean JIT Logistics, if you will. So planning systems like multi-echelon planning play a prominent role here as well. What is the best network and how do I position inventory best? Many OEMs are starting logistics businesses, either with partners or moving into them on their own. Good product companies who may not have overly thought about supply chain excellence, now have to be just that—excellent.

The IT business.
Performance-based management is an information-intensive play. The information at the point of performance is key to so many partners, processes, etc., but the challenge will be how to get that data. On-boarding diagnostics technologies embedded within the product, and then integrating that intelligence through a network provides not only the pinpoint data, but also allows the various entities who need the information access to synchronize the whole execution process as well as feed demand, product quality, etc.

Change in Revenue Model:

Many firms will also need more knowledge—not just on what to do—but how to make money at it. From selling equipment and systems to leasing and transaction fees, in businesses where they may not adequately understand the business model—what to say, what it takes to provide stellar performance—will challenge firms who will attempt this. Understanding the path and practices of firms who already deliver in the model—at least at a foundation—will provide some guideposts. But managing an industrial facility, versus a data center versus an automobile repair center versus a thirty year weapons system, all have their unique attributes, as well as winning the supply chain components to ensure the complete seamless efficient model.

There is gold in this model, though, not just in added services to charge for, but in customer retention and an exclusive feedback loop to your product developers for the next generation of 'satisfiers' in the killer product.

The Value Shift:

Managing performance—sustained, responsive, and customer centric—changes the way we think about, procure, and manage supply chains. This value shift to the real desired outcomes, performance-based management (PBM), has a dramatic impact on the design and cost of supply chains, as well as how core suppliers and OEMs design, build, and service their products. It changes the business models of the enterprise. Policies, processes, and IT systems that are designed around building, buying, and moving assets with material as their core will change to performance as the core. Integrated, visible processes allow the sensing and seeing of what is needed, rather than over procuring equipment or overstocking inventory. Technology innovation is creating capabilities supporting the next shift toward this performance-based approach.

Partnerships in the value chain—sharing of knowledge, process innovations, and technology concepts, as well as the building of agreements, will be bedrock to the success of performance-based business models. The data is housed in too many locations, in too many enterprises, in all level of aggregation, formats, etc., for partnerships not to be essential to performance-driven business models.

JDA Portfolio: For The Retail Industry Part Two: JDA Portfolio 2004.1 Components

JDA Portfolio 2004.1 Components:

JDA Software Group Inc. (NASDAQ: JDAS), a prominent global provider of integrated software and professional services for the retail demand chain and over 4,600 customers, plans to build upon the collective JDA Portfolio to enable its customers to achieve a new level of operational excellence. The vendor plans to establish this capability as a defining and differentiating characteristic of its next generation PortfolioEnabled solutions over the coming months and years. JDA Portfolio 2004.1 software and service offerings will include the following:

1. Portfolio Merchandise Management
2. Portfolio Allocation and Replenishment
3. Portfolio Planning and Forecasting
4. Portfolio Store Systems
5. Portfolio Customer Management
6. Portfolio Revenue Management
7. Portfolio Advanced Optimization
8. Portfolio Business Intelligence (BI)
9. Portfolio Infrastructure
10. Portfolio Collaborative Solution

This is Part Two of a six-part note.

Part One presented the event summary.

Parts Two through Four detailed the components of JDA Portfolio 2004.1.

Part Five will analyze the market impact.

Part Six will look at ERP vendors and the retail market and make user recommendations.

1. Portfolio Merchandise Management:

Portfolio Merchandise Management corporate HQ/host transaction systems are typically utilized by retailers and provide solutions for enterprise management of inventory throughout the retail demand chain. To that end, the latest JDA Portfolio offering exhibits improved scalability and configurability to meet the challenges of more retail formats, now including grocery and convenience stores, whereas the JDA Portfolio Merchandise Management (PMM) product has been successfully meeting the needs of "softlines" and "hardlines" retailers for years.

Namely, PMM 2004.1 will deliver specialized recipe management, meat-cut test and transformation management, random weight, direct-store-deliveries (DSD), and other capabilities. PMM is an open/client server merchandise management system that is designed to operate with Oracle relational database management systems (RDBMS) running on the most popular UNIX platforms and with Microsoft Windows NT/2000/XP. The product, which consists of functional modules that can be selected and configured to fit multiple processing requirements, has long provided retailers with applications for core inventory control, cost and price management, purchase order management, promotional planning, automated replenishment, expert pricing, vendor submissions, rebate management, and a business process level on-line help system. It also supports the information requirements of international and multi-format retail organizations including multiple, concurrent languages and currencies, user-specific terminology, and user-defined data structures. PMM has also long included functionality specific to the inventory management requirements of the grocery industry for perishable products and prepared foods.

Additionally, JDA has a strategic alliance with Manhattan Associates under which it has and will work with mutual and prospective customers to develop, maintain, and support a standard toolset to ensure ease of integration between PMM and Manhattan Associates' PkMS warehouse management application, which might enable JDA to more effectively pursue larger customers that require an advanced warehouse management system (WMS) and extended supply chain execution (SCE) solution.

Another product in the merchandise management group is the mature Portfolio Merchandise Management System-i (MMS), which is a merchandising management system designed for the IBM iSeries environment and is one of the most installed merchandise management systems in the world. MMS consists of functional modules, similar to those offered for PMM, which too can be selected by a retailer and configured to fit their unique requirements. MMS also features enhanced functionality for apparel clients and international retailers, and a Java-based graphical user interface (GUI) that incorporates technology licensed from third parties. To ensure growth for retail stores that carry premium merchandise, retailers often opt for the product in order to obtain greater margins by gaining better control of their out-of-stocks, and through the more intelligent management of their promotional and regular pricing, as well as customer preferences.

2. Portfolio Allocation and Replenishment:

Portfolio Allocation and Replenishment, sometimes also referred to as Demand Chain Solutions, provide management and optimization of inventory from finished goods at the CPG manufacturer through the demand chain to the end consumer, including computer assisted ordering, forecasting, replenishment, inventory optimization, and allocation. By significantly investing in the expansion and enhancement of its well-known line-up of E3 products to address user driven requirements, JDA was ready to demonstrate new and improved forecasting, replenishment, and allocation functionality, while the vendor also previewed the next generation of its SCM solutions to be released later in 2004.

Portfolio Advanced Replenishment Solutions by E3 is an inventory optimization suite that utilizes sophisticated algorithms to enable warehouses, distribution centers (DCs), and retailers to more effectively forecast and replenish inventory, and manage the movement of goods from supplier to store. It includes Advanced Warehouse Replenishment by E3AWR), a warehouse and distribution center forecasting and replenishment solution; Advanced Store Replenishment by E3 (ASR), a store-level forecasting and replenishment solution; Network Optimization by E3, an application that automatically synchronizes and analyzes inventory data between stores; and DCs, and Vendor Managed Inventory by E3VMI), a collaborative solution that facilitates joint management of forecasting and ordering by providing trading partners with access and visibility to a retailer's orders and forecasts. A product that is sometimes associated with the allocation and replenishment portfolio is Advanced Allocation by Arthur, an application for product and store allocation decision-making that runs both on UNIX/Oracle and Windows 98/2000/NT platforms.
( (

3. Portfolio Planning and Forecasting:

Portfolio Planning and Forecasting solutions provide retailers and their suppliers the ability to plan and project demand and ensure that customer service levels are optimized through strategic, financial, assortment, space and floor planning and category management solutions. To that end, the conference attendees were able to view the latest innovations within the Arthur and Intactix suites, in terms of delivering advanced business process level integration, improved scalability and broad strategic merchandise management capabilities. In addition, JDA presented its new Web Publisher that offers a robust, flexible solution enabling users to save time and costs by distributing so-called planogram and floor plan data via the Internet.

Advanced Planning Solutions by Arthur is a set of integrated decision support three-tier applications that are currently available for user client applications on Microsoft Windows 95/98 or NT/2000; for application servers on NT/2000; and for database servers on NT/2000, AIX, HP UX, and Sun Solaris. The suite is comprised of five core components:

1. Merchandise Planning by Arthur, an application for strategic and channel merchandise planning;
   
   
2. Advanced Allocation by Arthur, the above-mentioned application for product and store allocation decision making;
   
   
3. Assortment Planning by Arthur, a product assortment planning application for seasonal merchandise (typically own brand);
   
   
4. Arthur Knowledge Base (AKB), a database that allows for central organization of data and applications; and
   
   
5. Performance Analysis by Arthur, a web based analytical tool designed to support the analysis of planning and actual performance information using the AKB operating on Unix/Oracle.

According to many JDA's customers, these solutions offer neat features that provide more flexibility when handling multiple allocations at the same time, better support for new store openings, and more accurate allocation of their new season fashion products, with often cited benefits being improved gross margins and overall profitability through better assortments, faster turns, and reduced markdowns.

The planning and forecasting portfolio of solutions also includes RAPID Packages by Arthur, a deployment template that provides retailers with the industry's best practice implementation methodology.

Finally, Advanced Space Management Solutions by Intactix is a set of space management applications, which enables retailers to collaborate with their suppliers to ensure optimal product mix and shelf positioning. It is comprised of four core components:

1. Space Planning by Intactix, a "planogramming" solution used by both retailers and their suppliers, that allows users to build, analyze, and distribute graphical diagrams for space management, store layout planning and shelf assortment analysis;
   
   
2. Floor Planning by Intactix, a floor planning tool that enables retailers and their suppliers to merge store design efforts with category and space planning;
   
   
3. Efficient Item Assortment by Intactix (EIA), a tool providing product assortment planning for branded merchandise; and
   
   
4. Intactix Knowledge Base, an enterprise level relational database supporting the space planning and floor planning applications, as well as all product and fixture information for an entire store system.

The portfolio for space management also includes applications for streamlining day-to-day space management business processes including the above-mentioned Web Publisher by IntactixSpace Automation by Intactix that utilizes a business-level scripting tool to automate day-to-day activities performed within the space planning, floor planning and Intactix knowledge base applications; and Planogram Converter by Intactix that facilitates the conversion and migration of planogram data available on competing systems. that enables retailers and manufacturers to distribute planograms and floor plan data via the Internet;

A Well-designed Solution for Sourcing: Its Technological Foundation and How It Works

The Technological Foundation Explained:TradeStone Software, Inc. (www.TradeStoneSoftware.com) has displayed consummate perseverance in becoming a provider of collaborative e-sourcing solutions for Global 2000 companies. The vendor offers what is possibly the first composite application to the retail global sourcing market that leverages an organization's information technology (IT) infrastructure. This application operates either on a stand-alone basis, or as a layer into an application mix to cover any global sourcing functional gaps. Built on modern technology and conveniently accessed through simply a web browser, TradeStone's offering, initially named SteppingStones (and recently renamed TradeStone Suite), supports most of the key functional areas of international buying and selling, such as the request for quote (RFQ) pre-buy process, ongoing order management, sourcing logistics, track-and-trace visibility, government-related compliance processes, and payment processing. It also provides underlying event management and alerting. It works across currencies, languages, and countries, without necessarily invoking the need to train users, even if they have lower levels of computer literacy.

Part Two of the series Collaborative Sourcing Solution Vendor Leaves No Stone Unturned.

For information on TradeStone's history, see Collaborative Sourcing Solution Vendor Leaves No Stone Unturned.

For an extensive discussion of global retail sourcing, see The Gain and Pain of Global Retail Sourcing, The Intricacies of Global Retail Sourcing, and The Fashion and Apparel Retailers' Conundrum.

In order to foster rapid widespread adoption with an intuitive "zero training" environment, and also to leverage and enhance current IT investments, all with rapid phased deployments that would ideally deliver return on investment (ROI) in 90 to 120 days, the TradeStone Suite architecture had to espouse several design principles. For one, it features global access by leveraging web browsers and the Internet using hypertext markup language (HTML). The application can be easily accessed not only by users within the client enterprise, but also by users (such as trading partners) via extranet. Furthermore, the application is accessible to other programs through the power and flexibility of integration via Web services (see Understanding SOA, Web Services, BPM, BPEL, and More). This brings us to the ability to leverage existing applications (with data views and extraction from several disparate source systems) such as order management systems, warehouse management systems (WMS), item master, vendor master, and so on; and the ability to aggregate them on a single screen, thus minimizing traditional "hard-coded" integration costs.

The product was also designed for collaboration from the ground up, to leverage e-mail alerting and workflows, so as to reducce dependency on pesky and tardy phone and fax communications. With a built-in security infrastructure, the application manages and tracks the users' workflows, whereby the screens are not meant simply for data entry, but rather have a built-in logic. The product suite is configurable via available system tools and rules-driven logic, and is also expandable, with the ability to add new functionality—not just by customizing, but by downloading from the hosted site, thus minimizing upgrade and implementation costs.

The TradeStone Suite is also a scalable, multi-tiered, server-based enterprise application built on the standards-based Java 2 Enterprise Edition (J2EE) development model, with support for Web services and extensible markup language (XML) leveraged for integrations (see Understand J2EE and .NET Environments Before You Choose).

On the database tier, the product supports IBM DB2 and Oracle, and IBM WebSphere as the application server. The Web server (which can be Microsoft Internet Information Server [IIS] or Apache Tomcat) has bidirectional communication with the Microsoft Internet Explorer (IE) browser via the hypertext transfer protocol (HTTP)/secure socket layer (SSL) combination. The application security consists of user authentication, network security (via firewalls and SSL), and the application security per se, which is role-based and also data-based (to provide transaction- and field-level security).

The Apache Tomcat open source web servlet container complements TradeStone's own model-based "data anywhere" architecture spanning multiple systems, thus leveraging an organization's current IT investment. It also aims at driving down IT costs by eliminating the need for redundant databases, replication and continual reimplementation, and retraining of employees and trading partners. With this architecture, the TradeStone Suite accesses data from multiple applications without copying or replicating the data, and ultimately eliminates the need for modifying existing applications. The "data anywhere" architecture can accept data from a variety of data sources and formats, and allows an application to provide a unified view of a transaction even if its constituent data is located in several different databases.

Rather than a traditional costly database-to-database integration approach, TradeStone's integration approach consists of a user interface (UI) engine, a model-based application logic independent of the database, and a dynamic data mapping integration engine. XML is used for data mapping and process definitions to Web services, legacy systems, and databases, or to any other third-party system. Data channels to data sources like databases, enterprise resource planning (ERP) systems, legacy applications, and so on, can go via Java database connectivity (JDBC), Web services, and messaging.

In other words, by leveraging the integration capabilities of standards-based Web services technologies, TradeStone has been able to put together an application that can be relatively quickly configured to shift data in and out of traditional enterprise planning systems. This should allow buying organizations to more easily intertwine the basic procurement information these systems typically store, with crucial sourcing data such as specifications, schedules, and statuses.

More on the Design Principles:

Also, to tackle the aforementioned global sourcing issues, the product can be sliced into several logical layers that cater to data and content management, embedded intelligence, dynamic processing, and industry engines (such as costing, planning, order batch sizing, and event management). For now, it suffices to say that the functional layer caters to the overall product design-to-delivery process (with underlying critical path and event management capabilities), logically grouped into five major modules: Design & Planning, Sourcing, Order, Logistics, and Finance, which will all be detailed later in this series. The collaborative layer is to help establish the nature of a collaborative process, as well as the roles and responsibilities to leverage trading partners' assets for mutual benefit. This is provided via shared data, alerts, automated emails, shared business processes, authorizations, and approvals, and is independent of the underlying data source, which should result in fewer delays in the critical steps in the supply chain.

Given that functionality alone is not sufficient if it is not guided by the business process context, the process layer is where the data is interpreted, both in terms of the functionality it calls upon, and the process it fits within (for example, the role of shipment details). The layer provides the tools that allow the application to be configured to support well-oiled business processes, rather than to be shoehorned (see Business Process Management: A Crash Course on What It Entails and Why to Use It). Closely related to this is the intelligence layer, where the system inherently understands how to process tasks, and where the complexities of international and domestic trade are masked from the user to let them focus on their particular job. The intelligence layer provides content as well as functionality, such as harmonized tariff schedule (HTS) data.

To bolster these two layers, in mid-2004 TradeStone Software and ILOG announced that ILOG JRules, a key offering in ILOG's Business Rule Management System (BRMS) product line, would enhance TradeStone's flagship product. The combination of TradeStone's global sourcing software and ILOG JRules has been enabling manufacturers, retailers, and other businesses involved in global trade to configure, maintain, and change their business processes with increased agility in response to business growth and other dynamic business demands.

Electronic sourcing refers to the ability to bring together different trading partners over the Web into a supply chain network that responds to changing market demands. ILOG JRules, which allows the business logic embedded in business applications to be represented as rules that can be managed by business analysts, supply chain planners, and other business users, enables businesses to automate business policies, procedures, and best practices, improving resource management and accelerating investment in business process management (BPM). As a key component of the TradeStone Suite, ILOG JRules has enhanced supply chain usability for IT and business users, helping to ensure that the suite is scalable to the needs of TradeStone's customers. Compliance solutions powered by ILOG JRules monitor high volumes of data in real time, enabling the immediate detection and reporting of faulty or fraudulent information. By embedding this industry-recognized business rules engine, TradeStone believes that the suite is deployed more rapidly, while the best practices are available too.

Last but not least, the underlying tools layer supports all of the layers of the application to reasonably rapidly bring together, configure, implement, and maintain a solution. It consists of features like the Query Builder, Model Builder, Composite Screen Builder, Step Builder, Business Rules Builder, Collaboration Tools, Integration Mapper, Application Configuration, and so on.

Recap:

To recap, graphical UI and workflows that require hardly any user training per se promote more rapid adoption rates (user buy-in) throughout buyers, merchants, finance, logistics, and suppliers. The model-based "data anywhere" architecture means that the solution layers across legacy systems, dynamically tapping only key data, while concurrently filling in any functional gaps and providing one view of the data and one working environment for all users. As for exception-based workflows, they keep each trading partner focused on critical issues, and promote collaboration to resolve issues. Finally, a single view of the truth, which means one view of transactional data, regardless of legacy systems in place (or central repository for all commitment and contractual data), should eliminate redundancy by making it unnecessary to update multiple spreadsheets, hunt desperately for e-mail strings, or constantly re-key information in multiple systems.

In addition to a broad and focused sourcing functionality, backed up with a well-devised technology blueprint, TradeStone espouses the implementation approach, with the flexibility of either a tailored implementation or a straightforward out-of-the box deployment. In either case, the first step would be information gathering with key stakeholders within the business and IT organizations, so as to determine key business drivers, identify pain points and impediments, and identify opportunities for improvement. The next phase would be to develop a "scope document" that articulates, at a high level, the key business opportunities (in order to quantify a potential ROI), and for which one has to determine high level "as is" processes. Then the team would configure a prototype of the TradeStone solution based on the scope document, review the prototype with key stakeholders, and secure agreement on next steps for the functionality demonstrated in the prototype.

In case of the user opting for the "out of the box, from day one" implementation scenario, they would have to use standard business processes and workflows, standard screen interfaces, standard reports, and standard business form layouts. Since the touted "no training" environment provides intuitive workflows for all users, the vendor would merely provide the admin or user guide.

In the case of a more involved tailored implementation, though, the team would have to design, among other things, detailed business processes with associated business rules; custom interfaces (including the look and feel of transactional screens); custom reports; and custom requirements for business forms (such as requests for proposal [RFPs], bids, purchase orders, invoices, and so on). It would also have to develop custom training programs (for administrators, super users, end users, and the like), and customized documentation and "quick reference" materials. This type of customer still reports the TCO as being well under seven figures, and a hosted service was recently launched to accommodate IT budget-constrained customers. TradeStone is also developing a program that will allow even the "littlest guys" to pay per transaction.

A Simple Illustration of How It Works

To illustrate how the solution works, one scenario would be that a user company wants to extend an RFQ to several small manufacturers in the Far East to make a batch of polo shirts. The buyer would input the specifications in a preset form designed to support retail purchases, with fields for necessary data like size, fabric, or color. The buyer would also have to provide the e-mail contact addresses of the suppliers he or she desires to engage, and then would initiate the quote process. Currently, TradeStone does not help with finding prospective vendors in these faraway regions—this is in the long-term development plan—but for the time being, the retailers have to know their roster of suppliers and contractors beforehand.

The suppliers would then receive the e-mail invitations containing the RFQ, along with instructions to follow a hyperlink to a web page (hosted by TradeStone) to provide their bids. Once all the bids are in, the buyer would use TradeStone to compare them based on projected landed costs, using the HTS codes to determine the duties (with the system normalizing and synching all the data in the background, so as to avoid any awkward "apples to oranges" comparisons. When the buyer eventually decides to award an order, the data already in the system can be leveraged to generate a purchase order, transmit it to the supplier, and even apply for a letter of credit (LoC).

Through a Web services-based architecture that fosters loosely decoupled connections between the buyer's enterprise resource planning (ERP) system and TradeStone, the purchase order data would be written into the back-office system automatically, thereby obviating the need to re-enter the information to create an official order. Since TradeStone is tailored to the needs of the global sourcing process, it presents fields for the supplier to detail important milestones such as the expected production start date and expected ship date. When those dates come close, the solution can automatically remind the supplier to provide an update on status and any changes, and should the supplier forget or ignore the reminder, the system will repeatedly send reminders via e-mail (or escalate with higher frequency) until the required crucial information is received. There is also the ability to collaboratively discuss, online, back and forth, details of the order before the purchase is finalized. The system also has an online change order request, so that buyer can select a still outstanding purchase order and send it to the supplier with a proposed change.

When production is complete, the supplier can once again leverage the data (without ever re-keying the information) to create appropriate, accurate shipping documents such as the bill of lading (BOL) and the commercial invoice. If equipped with electronic data interchange (EDI), the supplier can even upload EDI-formatted documents such as advanced shipping notices (ASNs) into the buyer's TradeStone system. When a purchase order is complete (landed and duty paid [LDP]), the system offers the ability to compare actual to estimated landed costs, so that the buying company can adjust its formulas as needed for the future. For well-established, recurring relationships, the buying company can even upload inventory and point of sale (POS) information into TradeStone, so that the trusted suppliers can actively plan production and ship replenishment orders.

Different Stokes For Different Folks:The year 2004 was a time of controlled expansion, with three more development partners/customers signed (The Children's Place Retail Stores [US], American Eagle [AE] Outfitters [US], and Deutsche Woolworth [Germany]), and more staff of similar experience and heritage added. More former RockPort staffers joined the fold in their familiar Gloucester, Massachusetts (US) facilities, and former QRS moved out (literally and symbolically), while TradeStone moved in. The four first high-profile customers may also demonstrate the versatility and applicability of the solution to cater to differing customers' sourcing needs (� la "different strokes for different folks"). Still, the common theme for all of them would be that TradeStone has streamlined their entire purchase order management processes, allowed merchants to understand and analyze their businesses better, eliminated errors caused by piles of spreadsheets, and ultimately reduced data entry and training hours.

For example, the very first customer, Ocean State Job Lot, sells off-price electronics, housewares, lawn and garden items, stationery supplies, gourmet foods, sporting goods, toys, pet supplies, home decor, computer supplies, and seasonal items. With a chain of about 70 stores in New England (US), a typical Ocean State store stocks more than 4,000 items, many of them imported from a wide array of small offshore suppliers. Because the retailer provides "opportunistic" merchandise—which changes frequently based on availability—it was vital that the retailer have a global sourcing system that would enable it to move more quickly while dealing with a large variety of small suppliers. Opportunistic buying assumes little or no training at all for neither internal employees nor casual suppliers, although deep and rapid collaboration and global visibility certainly had to be deployed with vendors.

On the other hand, The Children's Place is a specialty retailer of high quality, value-priced apparel and accessories for children (newborn to age ten), and designs, contracts to manufacture, and sells its products under the "The Children's Place" brand name. It operates about 700 stores, with the vast majority of stores in the US, and about 40 stores in Canada. It also sells merchandise through its virtual store located at www.childrensplace.com. The Children's Place selected TradeStone's suite hoping to more effectively collaborate with global suppliers, and improve its production tracking and global visibility into the pre- and post-shipment supply chain. TradeStone also replaced some legacy sourcing systems (such as product costing, vendor self invoicing, and so on) in a "fill-in-the-gaps" manner, to create a single global order management infrastructure for sourcing of domestic, international, direct, and indirect materials. Using TradeStone Suite has allowed the company to notably reduce the cost of merchandise and transportation, improve its back-office productivity, and reduce markdowns.

At AE Outfitters, TradeStone provided a global order management composite layer over the mix of existing legacy systems, as a great example of composite applications in action. For example, the existing systems have thus been integrated via TradeStone's overlay. These systems include product development (via Gerber WebPDM, which provides data such as item characteristics, attributes, and images), merchandizing (via JDA Software's Arthur Allocation, which provides data such as seasons, master data, merchandise hierarchies, and the like), sourcing (via Inovis Sourcing, which provides data such as item collaboration, RFQ, costing, event management, item characteristics, sell channels, size and color flows, and packing), and planning (via Island Pacific's order management system). AE Outfitters is a lifestyle retailer which designs, markets, and sells its own brand of relaxed, casual clothing for 15- to 25-year-olds, providing high-quality merchandise at affordable prices. Its collection includes modern basics like jeans, cargo pants, and graphic t-shirts, as well as a stylish assortment of cool accessories, outerwear, and footwear. Its Canadian subsidiary, Bluenotes/Thriftys, offers a more urban-suburban, denim-driven collection for 12- to 22-year-olds.

AE Outfitters currently operates about 750 stores in 49 US states, the District of Columbia, and Puerto Rico; 64 AE stores in Canada; and over 100 Bluenotes/Thriftys stores in Canada. The retailer also operates via its Web storefront business, www.ae.com, which offers additional sizes and styles of AE merchandise. TradeStone's solution has allowed AE to leverage its current investment in software, while strategically expanding functionality such as vendor collaboration, ASNs, packing lists, self-invoicing, and so on. The idea is also to expand the suite's capabilities for all parties to better define products, collaborate, and manage purchases across the global supply chain.

Finally, in 2004, German retail group Deutsche Woolworth (operating more than 330 outlets in Germany and Austria, with 14,700 employees and revenues of approximately $1.4 billion [USD]) tapped the global sourcing solution from TradeStone Software to purchase global merchandise for its own stores and to offer a service bureau environment to smaller retailers who buy through Woolworth. This agreement marked TradeStone's entry into the European market, and the vendor has worked with Deutsche Woolworth and implementation partner IBM to tailor its global order management functionality (which replaced the legacy one) to meet the unique requirements of the European market, such as the need to be integrated with the planning system at the product category level to drive global sourcing. The resulting solution supports Woolworth's global order management requirements with sourcing and order management collaboration across its supplier base. Having been embraced by the merchandisers, this capability has gradually been expanded to the company's customer base, which should then be able to use the software to source goods from Woolworth, its suppliers, and its service providers. Deutsche Woolworth recently garnered two prestigious awards for its TradeStone implementation: Computerwoche's IT User of the Year, and Retail System's Global Retail Achievement Award.