A Simple PlanB2B implementation takes much more foresight and preparation than the B2C variety, so plan accordingly
By Dagmar Anne Bogan Planning is the most important success factor in implementing business-to-business (B2B) applications such as e-catalog, e-procurement, or Web-enabled ERP packages. It is also the most overlooked factor, even by many professional B2B service companies. I recently met a manager for a new B2B services company who has extensive B2C experience. When I asked him what services his firm provides to clients, he replied: "Product selection and implementation." When I asked about planning, he responded that his company would provide "project" planning; he saw no need to have strategic or IT plans in place prior to e-business development. Unfortunately, this attitude is common among folks without much B2B experience. For many companies, the B2B plan is simply, "Let's build a Web site." This attitude is beginning to change, at least at the executive level. According to a recent survey of global CEOs by management consultant firm A. T. Kearney, although only 41 percent of CEOs believe that e-business will have an impact on their organization, more than 70 percent have decided to implement an e-business strategy. Those who have been down this path before realize that having an e-business strategy in place first is the critical success factor in B2B implementation. Unfortunately, even when such planning occurs, B2B strategists often do so in an incorrect manner by focusing solely on either the business side or the IT side of the organization. Consider this example: I know of one company implementing a B2B e-catalog site that developed an IT project plan but never shared it with its business managers. However, sales personnel who had heard rumors about it soon told their customers that the application would be available by a specific date - but not the production one estimated by IT. Consequently, customers began requesting the service far in advance of its availability, resulting in an increased number of customer complaints as well as customer loss of faith. It's easy to implement B2C applications, which usually are some type of e-catalog or e-brochure. In these applications, most customer transactions occur completely inside the Web front end and then stream into the existing production system; the Web site and the legacy systems and other company systems are very loosely coupled. Consequently, with such a low impact on the production systems, planning is not as great a need in B2C implementations. FIGURE 1 Implementation difficulty. 
In contrast, B2B solutions require tight coupling within the organization as well as outside it. B2B processes such as ordering, purchasing, and shipping are highly dependent on existing production systems, so more planning in required. For example, your company cannot streamline its supply chain to connect the customer and supplier if your internal ordering system can't communicate with the warehouse system. Unfortunately, the greater the opportunity for ROI, the more difficult the task will be. (See Figure 1) The High Cost of B2BMany companies have been only slowly undergoing e-business transformation partially because of the costs involved. ROI is a significant issue, but ensuring ROI from a B2B project requires fixing existing production system problems that no one wants to tackle. Usually those legacy fixes are time consuming and have little or no payback until they become impediments to the B2B project. Dirty data is one common example of such a fix. In this era of "business cases," it is nearly impossible to justify the cost of cleaning data. However, if this data is going to be visible to either your customer or supplier, the data needs to be "clean," with a very high level of data quality. It may just be inconvenient for employees to deal with "dirty" data in a corporate system, but a number of customer satisfaction and legal issues can occur when the customer is viewing this same data. For example, say a company's inventory management system is known to be inaccurate, and the current process has the order-taker calling the warehouse to ensure a critically needed item is available. If this same inaccurate data is presented to the customer via the Web, the customer is led to believe the item is available for immediate shipment, when in fact it is not even in inventory. To gain a perspective on the amount of time and money involved in upgrading your back-end systems, consider the evidence that suggests integrating legacy and e-business systems can consume as much as 60 to 80 percent of your entire e-business development effort. According to research from Jupiter Communications ("Commerce Site Implementation: The Speed to Market Trap," Feb. 9, 2000), in more than half the companies studied, this process pushed the implementation timeline to between six months to a year or more. In an environment where six months is considered an entire life cycle, many executives regard taking a year or more for an implementation an unacceptable burden. In addition to taking so much time, B2B is very expensive. In 1999, the Gartner Group estimated development costs for a B2B site to average at least $1 million; Forrester Research estimated the cost from $1.5 to $15 million. Unfortunately, the expense doesn't stop at implementation. Similar industry studies show annual maintenance costs ranges from $750,000 to $4 million. Another cost of B2B is the expense of securing the site and its data. There are two major areas of concern: denial of service and security. B2B sites must be very security conscious because Internet access often provides a path straight to the company's mission-critical systems. A company may be able to survive if the Web site is down and can't take an order, but how many companies can survive if the financial systems are completely shut down? Not only is the organization subjected to direct financial damages - lost sales, for example - but it also must endure the notoriety of negative publicity, resulting in indirect losses. Other obstacles to a successful implementation exist as well, such as a misalignment between IT and business strategy, channel conflicts between the Web site and brick and mortar stores, an e-brochure or pared-down product offering site that gives customers the wrong view of the company, or the fact that most existing production applications are not designed for Web support. E-business planning won't eliminate all these problems, but it will force your company to think about these issues and consider alternatives. Your business must define a level of risk it is willing to accept and have IT provide the technology and architecture that will minimize the jeopardy involved. Hurdling the ObstaclesIn holistic e-business planning, business strategy, the IT systems project portfolio, and identified opportunities for e-business are synthesized into a single methodology. To achieve this goal, your organization needs to produce four things: a business-strategic plan, an information system plan, an e-business plan, and e-business architecture. The business strategic planning process has several components, but its primary mission is to identify business goals and critical success factors. The information system plan is a catalog of your existing systems and the functions they support. Comparing these two plans results in the e-business plan, which identifies areas of opportunity and prioritizes business projects. Finally, the e-business architecture is the IT roadmap for implementing the e-business plan; it provides the implementation details. The plans are not "data sinks." Rather, they are continually feeding information to each other in order to adjust to changing business requirements. Competitive and environmental pressures, as well as legal mandates, may require alterations to the plans. For example, last year, a large corporation planned to implement an electronic catalog for its customers with an expected ROI within one year. However, one high-value customer indicated it needed an e-catalog implementation immediately and asked if the corporation would be interested in serving as an application service provider (ASP) to develop and manage the e-catalog as well as performing all supply chain management. Being an ASP was not a service the company had considered. Thus, the business, IT, and e-strategy plans were reanalyzed and resources redeployed in order to build the customer e-catalog first, leveraging ASP code. This project generated a new revenue stream with minimal impact on the original strategy and schedules.
The Business Strategic PlanAs I explained previously, many companies that do perform e-business strategic planning do so incorrectly. In these cases, the corporate officers usually appoint a team of intimidated employees and then hire a consulting company. After several agonizing weeks spent questioning other employees, the consultants return armed with a "strategic" plan. But as one executive described this process to me, "I spent a lot of time and money, and all I had to show for it was paper." The problem is summarized in the immortal words of one director, who after receiving a hefty presentation about his business strategy from a consulting company, asked incredulously: "Now what do I do?" That's the main problem with traditional strategic planning methodologies: No tactical or operational plan is involved. In contrast, when developing a true business strategic plan, executives try to identify fundamental business processes as well as a few critical strategic goals. The ultimate objective is to understand current and future customers, as well as how to best serve those customers in order to increase revenues. In a nutshell, the objectives of the strategic plan are to:
These objectives and their consequences are illustrated by a recent strategy effort in which I was involved. During a meeting, an executive suggested that the company expand a prototype used by one customer. When someone asked if the other customers wanted this functionality, nobody knew the answer. Thus, there was insufficient customer feedback to make a sound decision. When the strategy was completed, it was known only at an executive level and not shared with the rest of the organization. As a result, the employees became very frustrated. Each time a project was proposed or initiated, they were told by the executives, "it doesn't fit." This company is not alone in this approach. If you were to ask the person sitting in the next cubicle or office to explain your organization's goals and the customers' greatest needs, they probably wouldn't have an answer. How can employees support the strategic goals if they don't know what they are? Similarly, you can't expect employees to provide quality customer service if they don't know what the customers are saying about them. Therefore, you should give a copy of the strategic plan to each and every employee so they can clearly understand what the company is "about" as well as its intentions. Processes should be documented and continually modified so the company can adapt quickly to changes in its environment. The organization should also understand the various business models the strategy is to support. For example, will new channels be created, and if so, how will they affect existing channels? Specifically, will Web site sales "cannibalize" the brick and mortar business? Who will get credit for leads or sales obtained via the Web? And what will the impact be on other channel partners? Last, you should extensively research competitors and industry trends to correctly identify current and future business drivers. This research should complement a comprehensive strategy that moves your company forward. The Information System PlanThere's a good reason that most organizations do not perform any type of information systems planning: because most methodologies take a year or longer to perform. However, in order to support e-business processes, the organization must understand all the subtleties of its IT infrastructure. Integrating the supply chain - from your vendors all the way to your customer - will be impossible if you can't integrate the order system with the warehouse system. The information system plan will provide a snapshot of your organization's processes and which functions are supported by applications. The information system plan should also include all in-flight, proposed, and backlogged projects. The information system plan goes beyond just applications, however. It should also include information about your network, desktop computers, servers, laptops, and other hardware or infrastructure. Volumetric information, such as average server and network capacity, should be documented as well. When complete, the plan will catalog all the major applications within your organization by function, hardware, and software. By mapping the applications to process activities, the opportunity arises to identify candidate redundant systems as well as functions lacking system support. In the case of the latter, the function in question is probably a manual one, and multiple manual processes may even exist for the same function. The E-Business PlanThe e-business plan reflects the alignment of the business strategy and priorities documented in the business strategic plan with the current IT environment documented in the information system plan. (See Figure 2.) For example, it can reveal whether your existing IT environment can support the goals of the business. If the network is at capacity, it will be a challenge to sustain a large increase in transactions because of a new Web site unless you upgrade the network. FIGURE 2 Artifacts of e-business strategic planning. 
This plan gives you the ability to review alternatives and then weigh them for risk, cost, and speed to market. For example, if your company's systems are mainframe-based, would it be wiser to replicate data in a client/server environment, or go to the expense of using the mainframe as a Web server? IT and business need to discuss these alternatives carefully: The business needs to understand the systems risk, and IT needs to understand the impact on your business. This discussion should also touch on projects for upgrading or enhancing legacy systems, such as data cleansing, as well as purchasing or developing new applications. In most projects, the bulk of the work will be in repairing or upgrading the existing production systems to support a very narrow set of e-business functions. Unfortunately, this is a natural state of affairs for companies saddled with huge investments in existing applications that may not be designed for Web support. Negotiation and compromise are keys to success at this point. The result will be a list of prioritized IT projects required to support the business strategy. E-Business ArchitectureThe e-business plan not only contains a list of prioritized projects required to support the strategy, but also a methodology for how these projects are achieved. This e-business architecture is the operational roadmap for project implementation. At this stage, you should first review commercial off-the-shelf (COTS) products suitable for the identified opportunity areas. This review should include application software, as well as middleware, hardware, enterprise application integration packages, and so on. Create a short list of no more than three application suites. Some criteria for selection are:
You'll also need to review and identify your current employee headcount and skill sets. The goal here is to answer several important questions: Will you need to hire new employees? Will you need to train current employees in new technologies? Will you need to hire consultants for experience and expertise in specific areas, such as e-procurement or supply chain management? Will you need to augment the existing headcount with contractors for a limited initial period, and then ramp them down? When you've finalized your product list and have answers to these employee questions, you can work on the architecture itself. (This topic is a separate article in itself; I'll stick to planning processes here.) Your strategic and tactical objectives are now laid out as operational tasks. You know which projects can be performed in parallel and which must be performed serially, and each one has an estimated timeline and budget. The final architecture will integrate all these projects over time. If done correctly, this plan will predict and document projected changes in your IS/IT environment, preferably in six month intervals, for the next several years. Does It Work?Are there metrics to prove that e-business planning will save your company time and money? Unfortunately, no hard numbers are available to support the contention that proper planning will streamline e-business implementations. However, anecdotal evidence from organizations that perform e-business planning suggests that these organizations experience less pain and expense. Their names are not on the nightly news, nor are they written up as horror stories in trade magazines. Rather, they are moving forward, making progress, and steadily bypassing their nonplanning competitors.
Dagmar Anne Bogan (d_bogan@mindspring.com), based in Irving, Tex., has more than 17 years of experience in application architecture and performance engineering. She also has extensive experience developing information systems plans and performing application strategic planning. |
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| |||||||||||||||||||||||||||||||
