[From iSource Business, May 2001] To understand the complexities of fabric manufacturer Dan River's supply chain and manufacturing operations, you have to understand this: Dan River is a manufacturer of yarn-dyed apparel fabrics, says Bob Beecy, senior director of planning and customer requirements.
The distinction is an important one. The color is woven in, not dyed on. This makes our manufacturing processes more complicated because most of our jobs are made to order, he explains. In the past, once a client placed an order, loom space was reserved to ensure it was filled on time. Coordinating loom time and other production activities was an all-encompassing task, and one Dan River handled well. Or at least it seemed that way until the manufacturer acquired a competitor with a better system in place.
The newly acquired company had created a sophisticated system using FoxPro, an old database application development tool, which optimized production in a limited floor space area. The facility didn't have room for bobbins of material lying around waiting to go on the loom, so the company had to be able to manage production on a just-in-time basis.
Unfortunately, the acquired company lost most of the very people who were best-suited to handle the system, the Information Technology staff, once word of the acquisition leaked. So, Dan River was faced with a choice: limp along with a system that worked well when adequately and expensively staffed or buy something new.
The company opted for the latter and decided to integrate Camstar Systems' InSite e-manufacturing system and i2 Technologies' Factory Planner into its Enterprise Resource Planning (ERP) backbone, a European package designed for the textile industry called Datatex.
All in all, their application integration project has been successful. Lead times have been reduced by 33 percent, and on-time delivery accuracy has increased from around 70 percent to more than 90 percent. Costs have been reduced, inventories have been lowered even further and clients have been made happier, as can be seen from a description of how the new system handles a simplified transaction:
1. The demand-planning group, which is based in New York, takes orders from clients and then checks the availability of loom space at the facilities, which is kept updated by InSite.
2. The demand-planning group lets the customer know of the availability. It then puts a temporary reserve on the loom. All the while, i2 and InSite juggle and shift order schedules in order to maximize the scarce space on the facility floor.
3. Upon receipt of the purchase order (PO) from the customer, the demand-planning group places a firm order into the ERP system. The ERP in turn drops the order information into InSite and i2. The resource reservations are changed from temporary to firm.
It may sound complicated, but, in reality, it's quite simple, Beecy says. In fact, all Dan River's supply chain operations are relatively straightforward, at least compared with other industries.
But, it wasn't a hassle-free integration by any means, he says. Oh yes, we had some problems.
The Nightmare Emerges
For instance, Beecy says, We realized in the middle of the project that some of the functionality we needed hadn't been developed yet. We had to add time into the schedule for the expansion of this tool set.
They also realized it was a system that needed a degree of babying, not something that could be completely left to function on its own. Through trial and error we learned we had to be painfully watchful of the care and feeding of our files as we dropped them into the system, Beecy explains. Some of the suppliers would give you the impression that these things can think for themselves. It's not that easy.
It was a long and sometimes arduous process, Beecy concludes. And that is probably one of the nicest summations you will ever get from a survivor, excuse me, supply chain professional, of an application integration project.
Nasty, Risky and Just Plain Hard
Hardly any supply chain professional over the age of 21 is unacquainted with the joys and sorrows of system integration. Such projects were common enough in the corporate landscape over the last 10 years, peaking at the end of the 1990s when companies scrambled to install new ERPs that would head off the threats of Y2K. Lessons were learned, often the hard way, about the necessity of properly managing IT projects. (Some would say there is no way to properly manage such large-scale endeavors.)
Now, a new generation of supply chain applications exists. They are smaller than the ERPs of yesteryear, but, in some cases, far more sophisticated and targeted. Beyond that, it appears little else has changed.
There is no easy answer to full integration, despite supplier promises, says Allen Shaheen, CEO of ArsDigita, a software firm in Cambridge, Mass. that provides enterprise application services. Achieving integration seamlessly and easily has been oversold and is not possible without some deep thinking about the systems in place and the purpose of linkage to each individual site and source.
Or, to be more precise, Integration is expensive, time-consuming, nasty, risky and just plain hard, no matter how many silver bullets the software industry throws at it, and there have been many, Shaheen says.
Certainly, there are many companies reluctant to embark on a new IT integration project, if not for the hassles, then because their preference is to invest in other capital projects. A lot of manufacturing companies find it more cost-effective to put these dollars into equipment rather than an expensive system, says Linda Swerling, an operations consultant with Level II Solutions, a Brookline, Mass.-based company.
However, supply chain efficiencies are no longer a luxury for the largest multinational. They are no longer even optional, quite frankly. Companies of all sizes are finding that they have to maximize their production, distribution, sales, customer relationship management (CRM) and procurement operations in order to stay competitive. To accomplish this, they more than likely will have to implement and integrate new applications into an existing structure.
TINA, is how Peter Bendor-Samuel, CEO of the Dallas-based Outsourcing Center, sums up the situation. There Is No Alternative. That is basically what drives beleaguered companies to embark on such a project.
It's a dismal state of affairs, to be sure. And so, to help said-beleaguered companies pick their way through the issues that make up what is known as enterprise application integration, iSource Business magazine has decided to develop its own list of frequently asked questions.
Your FAQ for Integration
Beleaguered company: Let's start from the beginning. What is enterprise application integration (EAI)?
iSource: One definition is that it's a relatively new discipline that addresses the problem of how two applications work together across an enterprise and among different enterprises. Another definition is that it's controlled sharing of data and business processes among participating inter-and intra-enterprise applications in support of a common business event. EAI companies are basically product companies. They build tools that are used to connect disparate systems.
Beleaguered company: What's the difference between EAI companies and systems integrators (SIs)?
iSource: I'm going to let Thomas Ryan, practice leader of Chicago-based eSYNC International's enterprise application integration group handle that one.
System integration companies still tend to do low-level integration (code-based or module-level alterations) of different applications together. This is still appropriate when you have a warehouse management system, say, needing to talk with or control a conveyor or sortation system. [A sortation system is a conveyor-like structure that sorts packages into appropriate lanes that convey packages to the next step in processing. The sortation system has a scanner that reads each package and directs where the package is to be dropped/diverted. For example, a tilt tray or slot sorter.] When you have different applications, as opposed to modules with an application, you will be better-served using an EAI company and its tools to tie your applications together. It may be necessary for an SI to write custom code to enable the application to send and receive a set of data and use the EAI to manage the flow and transformation of that data for other applications.
Beleaguered company: Why am I hearing so much about EAI these days? Two years ago, I hardly ever heard the term.
iSource: Another question I am going to hand off, this time to James Whitmore, associate director for SeraNova's Global eMarkets Practice.
It's true that the EAI landscape has changed radically in the last year. It used to be that EAI was seen as middleware' that sat in between the various ERP, SCM [supply chain management] and CRM systems. The players back then included IBM's MQSeries, TIBCO and CrossWorlds. Then the drum began beating in the B2B integration space. New entries, such as webMethods, Extricity and Vitria, talked about the opportunities for integration between enterprises, with a much more sophisticated process approach than the static exchange of data from the EDI era.
Beleaguered company: Isn't this sudden need for EAI just more IT hype?
iSource: Well, Steve Jones, executive director of Trifolium, a Raleigh, N.C.-based enterprise application integration and e-commerce provider, tells of one large company he has for a client that maintains different bits of customer data in 33 different systems, none of which talk to each other. I'll leave the explanation at that.
What is hype, however, is the myth of easy integration. The success statistics for such projects have traditionally been very disappointing and continue to remain so. One study, commissioned three years ago by Las Vegas-based Expert Buying Systems, found that almost half of all implementations fail, forcing some very expensive and time-consuming restarts. Of those systems that did get implemented, 75 percent fell far short of expectations, with 90 percent significantly over budget in time or money or both. A more recent study by Grant Thornton showed that 75 percent of companies that implemented new technology cited higher than expected implementation costs as major drawbacks to their purchases.
Beleaguered company: Haven't things gotten better the smarter we have become?
iSource: Not really. Many of these applications were never developed with integration in mind, believe it or not, according to Forrester Research. And, if you think that's bad, Forrester goes on to point out that most of the integration solutions expect a fairly standard package on both sides. In other words, a lot of these integration tools don't work that well if there has been any sort of software customization within the individual applications, even though most software packages are tweaked at some point or another.
Another problem or some would say, the major problem is the fact that no single supplier can effectively cater to a company's end-to-end supply chain needs. These days the battle cry is, Multiple solutions from multiple suppliers. And suppliers on the market are proliferating: IBM, webMethods, NEON, Netscape, BEA Systems, TIBCO Software, Vitria, GE Enterprise, Extricity, HAHT, CrossWorlds Software, Mercator, IPNet, Top Tier, GEXS and Oracle are some of the more popular suppliers for internal and B2B integration, according to Forrester Research. And these aren't the only ones by a long shot. By the way, are you aware that, in current IT lexicon, there is more than one type of application integration?
Beleaguered company: No, I was not.
iSource: According to Dave Wasson, senior vice president for Technology Solutions Co., an e-business consulting and systems integration firm based in Chicago, there is:
1. process integration, which identifies the common processes that need to be integrated; 2. business rule integration, which identifies the business rules between partners that need to be automated (an example in this category would be a supplier that receives a PO but can't meet the requested date. An automated business rule might be to instruct the system to send the PO to the next favored supplier); and 3. information integration, which is all about standardizing the pure exchange of data.
Beleaguered company: Just tell me what the bottom line of all this is in plain English, please.
iSource: In plain English, to remain competitive, you have to break outside the four walls of your company to manage transactions with your suppliers, customers, transport providers, and any other partners you might have in your particular supply chain. And transactions, in this case, can mean anything from simple procurement to research and development to industry-wide demand planning.
And it's in that context that you have to worry about common business rules, connectivity of Web sites, seamless exchange of data and work processes, and visibility into and synchronization of certain external and internal activities.
Beleaguered company: Okay. It's clear I'm going to need help. Where can I get it?
iSource: IT consulting is a booming business.
Beleaguered company: How much will all this cost?
iSource: On average, most companies spend anywhere between $100,000 to close to $1 million for internal integration, and $1 million to $10 million for B2B connections, according to Forrester Research. For you, individually, the answer is: it depends.
Beleaguered company: Depends on what?
iSource: On how well you can negotiate.
Beleaguered company: I thought these sorts of systems and services were set in stone, according to project size, number of intended users and transactions.
iSource: Nothing in this industry is set in stone. Remember that, and you'll be okay.
Now, It's Time to Proceed
Even if your company ultimately decides to wait it out a bit longer, putting on hold new supply chain investments, it's important to do so from a position of strength. This means at least knowing what your company should do when the time to act does come. The following are a few pointers that will help you arrive at a sense of what your firm will need to do.
Many are just plain common sense: Evaluate your needs. Have a plan. Get good help. Appoint a strong project leader. But as applications become more sophisticated, the market becomes more competitive and your shareholders become more demanding, the basics sometimes get lost.
1. Evaluate the problem Even before a tech audit, it might be worthwhile to be reminded of your overall business goals.
You would be surprised at how many businesses don't know where they are going or why, says Kathleen Allen, co-author of eBusiness Technology Kit for Dummies, and director of the University of Southern California's Alliance for Technology Commercialization, who tells of interviewing two business partners, each with vastly different visions for their company.
First of all, look at your business goals for the company or division. Then try to find the technology that will best help you get there.
2. Develop detailed system requirements This might seem to be a no-brainer, but enough companies skip this step to make it worthwhile to include.
The key thing is to identify only strategic requirements, says Robert Novick, principal with North Highland Inc., a national business and technology-consulting firm headquartered in Atlanta.
Companies routinely send out RFPs [Requests for Proposals] that are 200 pages long, he says. Our approach is to send out smaller RFPs and skip the requirements about features that have become standard issue. All of the suppliers in the market today will have accounts payable features, general ledger features and accounts receivable features. To get into 400 requirements about the general ledger doesn't make any sense. Trust me, it will be there.
Instead, concentrate on what is really important to your particular company. Suppliers will try to show you the latest, hottest feature they have, but it may not be what you need to run your company, he says.
For example, one supplier's multicurrency feature may allow you to enter only the current exchange rate, while others may allow you to enter past and future exchange rates and use them in accounting and tax planning functions. A global company will have definite opinions on which method is best-suited for its operations.
3. Have a plan before you start Be careful what you ask for because you might get it. Thus, Jay Grieves, lead developer for e.magination network, a Baltimore, Md.-based integrator, pronounces the big lesson recently learned by one of his clients: We had a client that wanted to build an electronic time-management system that would coordinate contracts and projects with employee schedules, he recounts. After they decided to hire us, they gave us a complete description of what they needed. We said, That's a great overview but we need a few more details before we get started.' The entire discovery process would have taken about a month of planning, and the client balked at the lost time, not to mention extra expense.
We needed just a few more details, Grieves says. Such as, if a certain event happens, how would the company react, that sort of analysis. The client thought if we could start building the system and they could get to the point where they were able to capture enough time to manage projects better, then they could start making any changes.
Unfortunately, what happened was every few months we would do a little more discovery about what they needed and would have to do certain elements over. If we had started at the beginning, going through their detailed requirements and forced them to make decisions then, they would have been far better off.
4. Standardize and cleanse the data Integration requires a deliberate, planned approach to succeed, says eSYNC's Ryan. If you don't deal with the minute details of the content, semantics and context of the information, the application will fail.
He gives the example of a transportation solution that views shipments as weight, cube, pickup point, destination point and freight class. A fulfillment solution, meanwhile, sees the same problem as a shipment or customer order that is a stock keeping unit (SKU), quantity, ship from, ship to and value-based. Both models address the same order, but look at them from a different view. Interfaces [must be able to] bridge these contents.
To do that, however, data must be reclassified in some uniform manner before the start of an integration project. A lot of times, companies will think they can go back and do this, after the project is implemented, says Craig Verran, assistant vice president of Dun & Bradstreet's Supply Chain Solutions Group. Usually this happens when the integration project is led by an IT person who needs to get the project done on schedule. The IT person might know the data that is being loaded into the system has problems, but with a deadline looming ...
Verran also points out that, outside of integration, unorganized data is bound to be costly and unproductive for a company. For example, some of Dun & Bradstreet's clients have gone through the integration process only to realize that some of their suppliers were part of a larger corporate family. Once clients became aware of this, they were able to negotiate better prices because they were doing business with other entities in that corporate family.
5. Don't underestimate costs Software suppliers and systems consultants can count on more profit from developing the links than from the original systems themselves, says Bruce Miller, vice president of Technology for Epic Partners, an Orange County, Calif.-based information technology services provider. Yet companies always seem to underestimate the costs associated with these pricey transactions.
Systems interfaces, he goes on to say, are also a source of continuing revenue, since any update or upgrade of one of the end systems causes the interface to be vulnerable to the same change. In other words, he says, every time you customize or make a change to a particular component of a system you will have to modify the interface between those systems.
Miller says this is the biggest mistake companies make when calculating the Return on Investment (ROI) of a particular system. They don't take into account the price of the interface. They might price it as part of the initial cost but not as part of the ongoing cost.
6. Select a good project manager The project manager (or lack of one) can make or break an integration project. This person has to be able to devote most of his or her time to the project for the next nine to 15 months. Other qualifications: the ear and respect of top management in the company, a good view of the business, a sophisticated knowledge of tech applications and hardware, and the ability to make hard decisions. Infinite patience is highly recommended.
7. Select a good tech consultant (besides your supplier) The single most important variable in a successful adoption of technology is the tech consultant, Allen says.
Unfortunately, more often than not, companies wind up sorely disappointed with their consultant. Allen cites a study she recently conducted on behalf of Microsoft and other software providers. In this survey, eight out of 10 respondents gave their tech consultant a poor rating.
Oftentimes the problems would stem from a consultant's poor understanding of the company's business needs, she says. We found in our research that a tech consultant would come in, look at the situation and immediately spot a tech gap without understanding how the business works.
Sometimes the dissatisfaction was the result of bad manners. Some consultants wouldn't keep appointments, and then wouldn't call ahead to let the company know, she says. I had one client who told of a previous consultant that would come into the office and take down a live database server without telling anybody why. Another company told me of a consultant who went to Europe suddenly without leaving a backup for customers.
Such bad apples, she says, are unfortunately almost endemic in the industry. Because there is such a demand for their services, they don't necessarily have to be concerned with customer relationships. But, as the industry shakes out, the good consultants will survive because they have built long-term relationships with customers.
A good consultant, she defines, is not just someone with expertise in the latest technology, but also someone who has the attitude that he or she is part of your team, and will help you grow.
Or at least make the process as painless as possible.
So, is Bob Beechy from Dan River Fabric Co. up to another application integration? Well, while he may not be looking for another one to do, he's ready. He understands the challenges and realizes you can always turn such projects into opportunities. Opportunities to make your organization that much more competitive. In e-business terms, that clearly leads to success.
