Leveraging Technology to Maintain a Competitive Edge During Tough Economic Times -- A Panel Discussion Analyzed Part Six: Custom Development and Single-Vendor versus Multi-Vendor


At the IFS Executive Forum, which took place on March 29 and 30 in Orlando, Florida (US), leading research analysts and industry experts discussed how companies can still leverage technology to maintain their competitive edge, even during tough economic times. The event was held in conjunction with IFS World Conference 2004, and it included six panel discussions, with each panel including top executives, analysts, and journalists. Some of the renowned panelists were Geoff Dodge, vice president, Business Week; Dave Caruso, senior vice president, AMR Research; Barry Wilderman, vice president, Meta Group; Leo Quinn, vice president of operations, Global Manufacturing Solutions, Rockwell Automation; Dave Brousell, editor-in-chief, Managing Automation; David Berger, Western Management Consultants; and Josh Greenbaum, principal, Enterprise Applications Consulting. Breakout sessions explored such topics as turning global competitive threats into opportunities, increasing the bottom line through operational efficiency, complying with the Sarbanes-Oxley Act of 2002, and using enterprise software to prepare for future challenges.

Technology Evaluation Centers (TEC) was represented at the executive panel titled "The Future of Enterprise Software and How It Impacts Your Profitability", which was aimed at helping companies find out where enterprise software is going in the next five years, and how it can make or break their profitability and market share. The panel, which was moderated by Josh Greenbaum, included the following participants: Barry Wilderman; Peggy Smedley, president and editorial director; Start Magazine; Dave Turbide, an independent consultant and renowned columnist for magazines such as The Manufacturing Systems; and Predrag Jakovljevic, research director, TEC. In preparation for the event, we polled the thoughts and opinions of our experts and contributors: Olin Thompson, Jim Brown, Joseph Strub, Kevin Ramesan, and Lou Talarico, given they were unable to attend the event in person.

Below are the questions and consolidated thoughts and answers that transpired from the panel discussion. We also took the liberty to expand with a few pertinent questions and thoughts that were not discussed at the panel per se (due to the time limit), but transpired from many other interactions and presentations at the conference. Also, some pertinent articles published previously on our site, which may shed more light at the respective topic are mentioned as further recommended readings.

The questions are

Q1. What is the one piece of new software or technology that will be a must-have in the next five years? (see Part One)

Q2. Some pundits say the future of enterprise software lies in service-oriented architectures and component applications. True? False? (see Part One)

Q3. How does the development of new business processes and business process modeling fit in? (see Part Two)

Q4. What are applications hosting and other service models? (see Part Three)

Q5. Radio frequency identification (RFID) is on everyone's mind these days. Let's discuss the software issues around RFID and what kind of software solutions will be taking advantage of RFID. (see Part Four)

Q6. Technology aside for a moment, what can we say about its impact on profitability? (see Part Five)

Q7. With all this new technology, the question is what happens to existing applications and technology. Nobody wants to start over, but how much will existing IT systems have to change? (see Part Five)

Q8. Will the newest and greatest only come from packaged software? What about custom development? What is the build versus buy equation look like in the near future? (see Part Six)

Q9. How will the latest improvements in software flexibility and agility play in the single-vendor versus multi-vendor solution equation at multi-division corporations? (see Part Six)

This is Part Six of a multipart trend note.

Each of the parts covers questions and answers addressed by the panel.

Questions and Answers (continued)

Q8. Will the newest and greatest only come from packaged software? What about custom development? What does the build versus buy equation look like in the near future?

A8. When packaged software exists that solves problems effectively, it is a simple matter of the economy of scale to use it. Namely, it does not make business sense for thousands of companies to develop software to pay an invoice, for example because there are a number of common, best practices that are effective and standardized horizontally across industries. However, when enterprises are trying to do something unique, and there is no good packaged software, they will have to develop custom applications. One example to justify custom development is a TV shopping channel provider. With only a few other companies playing in that sandbox, no vendor could justify developing software for this limited marketplace. Thus, we believe that at least 85 percent of all enterprise systems will be obtained via the purchased package approach. The reason being simple: "Don't re-invent the wheel unless you looking to build an empire."

Still, as componentization and Web services mature, packaged software will be less rigid and easier to adjust to unique practices thereby gaining some of the benefits of the custom approach. Conversely, with pre-built components, custom software will become easier to build and maintain and will, in turn gain some of the benefits of the packaged approach. Consequently, there is a fuzzy space in-between packaged and custom developing—the above-mentioned composite, assembled or cross-applications—that hold promise. Most packaged vendors are moving in that direction, and so are the custom system integrating houses.

Still, for anyone considering building software in-house, the key question must be "Why?" If the answer is to not build or maintain a competitive advantage, then the economics and realities of today's software market should encourage buying packaged software over building in-house. If the answer is to build or maintain a unique competitive advantage, then it must be determined if it will be more cost effective to start with a package in-house and then modify it to meet the peculiar needs of a company. If it is both cost effective and addresses a competitive advantage, by all means, one should custom build.

For more information, see the following recommended readings: Build versus Buy—A Long Term Decision, and What's Wrong with Enterprise Applications, and What Are Vendors Doing About It? Part Three: A New Approach and User Recommendations

Q9. How will the latest improvements in software flexibility

Q9. How will the latest improvements in software flexibility and agility play in the single-vendor versus multi-vendor solution equation at multi-division corporations?

A9: There has long been a siren's song urging enterprises with multiple operating divisions to standardize with a single set of software. The "one vendor-one ERP system" idea, although highly attractive, has, until recently, remained a utopian ideal, partly owing to the functional inadequacy of any enterprise resource planning (ERP) suite to satisfy enterprise-wide requirements. The recent broadening of the scope of major ERP products to include e-procurement, supply chain management (SCM) and customer relationship management (CRM), and the advent of Web-based product architecture may, however, tempt corporations to reconsider deploying this concept. Although enterprises can generate many benefits from standardization, they can also create other issues that often result in disruptions. If the standardization driver comes from anywhere but operational needs (such as a justified business process unification) the project will likely result in shortcomings. Nonetheless, the following type of enterprise might benefit from considering ERP standardization: a centrally managed organization with a strong corporate headquarters and rigid, globally enforced corporate policies, either with a single core service business or with similar manufacturing environments in all plants.

The level of operational integration will give us a sense of how integrated the systems of any two units within the corporation must be. Yet, having some joint operational issues, such as serving the same market, using the same suppliers, manufacturing for each other, selling each other's products or other similar types of relationships, is insufficient to advocate that all the units need the same system. These intimate cross-unit business processes can be achieved via a kind of business process integration (e.g., EDI, a message broker, a portal, BPM tools) between disparate ERP systems. The same approaches that work for collaboration between two different companies can be applied to internal collaboration between operating units. Moreover, how the relationship is structured between units is also an issue. Namely, if the current interaction is between a customer and supplier, then that connection can be handled by the same methods with their other customers and suppliers. This again obviates the need for the same ERP system.

Globally widespread corporations may furthermore be hard pressed to find a single ERP system that meets local regulatory compliance in every country that the enterprise has presence in. They may often have to resort to using an alternative, more locally apt vendor for certain organizations. Many ERP systems have also been based on a top-down, centralized organization, which does not enable effective planning and management of autonomous satellite plant operations. What will thus differentiate the leaders from the rest of the ERP pack will be the breath, depth, and diversity of the plant-level and distribution centers requirements. The planning functionality will have to extend to the shop floor and distribution center level, whereby manufacturing and distribution functions will become intermingled.

Last but not least, if the business has a culture of frequently buying and selling businesses, tightly integrated systems can even be negative. Tightly integrating systems across multiple units may mean that the units cannot stand-alone without a major systems' investment, which can create an obstacle in selling a unit. If the philosophy purports tightly integrated systems, the acquisition of a new unit may dictate large investments to replace the existing systems. Thus, in an economy with ever increasing competitiveness, corporations have to become more agile. For that reason, the flexibility that these new technologies, such as Web services and BPM, promise should bode well for the amenability of corporations to a multi-vendor platform.

The recent success of vendors like QAD, Epicor/Scala, MAPICS, IFS, SSA Global, etc., illustrate their readiness to coexist at the divisional level with tier 1 ERP products at the corporate level. The SAP BusinessOne product, which SAP has delivered by acquiring a more suitable genuine product for the lower-end of the market, might be its new tacit conceding that "pushing" the unwieldy mySAP Business Suite into smaller divisions of corporations has not particularly worked so far.

For more information, see the following recommended readings: Standardizing on One ERP System in a Multi-division Enterprise

comments powered by Disqus