Strategic alliances are initiated in a number of ways, but those impleme nting the alliance (that is, IT) seldom play a part in the initial deal- making process. Too often, the business areas negotiate and sign the deal, with little or no IT involvement. Alternatively, the business areas might seek IT involvement in a fragmented manner based on specific questions.
Admittedly, a decentralized IT organization makes it difficult to pinpoint the correct person to contact on a particular issue. Also, while organizations might discuss the relevant requirements of the strategic alliance with those specifically involved, such as application development support, they often leave important linkages out of the discussion, such as telecommunications, data sharing, or call-routing topics.
Even if the organization has centralized IT support, the business area might still only feed parts of the strategy to IT, instead of taking the time to fully engage IT in the potential alliance discussions. Additionally, because IT is critical to existing business operations, the individual business units might be reluctant to use IT resources for such exploratory activities. For their part, IT organizations are often reluctant to make time available for such discussions, unless they are confident that concrete activities will result.
Of course, if an organization is creating a new business unit from an alliance, the business processes should be set up first, and the supporting IT infrastructure developed secondarily. However, these realities lead to a fragmented approach in setting up an alliance, and produce inefficiencies and weak links in the union between the companies.
the issues
There are many problems when IT is not involved from the outset of negotiations through finalization. When IT does not understand the entire strategy, it cannot provide the most effective, right -sized solutions. For example, if the alliance is already proven, and needs to be set for a long-term relationship, IT should invest considerable time so things are done correctly from the beginning. However, if the alliance is merely to be tested before the requirements are known, IT should invest less time, and the technology processes should be set up more quickly.
On the one hand, the two IT departments involved in the alliance will have technological differences. Even if both organizatio ns use the same basic technology, and have similar business applications, both must make changes in order to build a working environment. Because smoothing out the technological differences between the IT installations will take time and patience, IT representatives should be brought into the process as early as is practical.
In addition, it will require time to resolve the cultural differences between the two organizations, so they can reach a common ground. Therefore, the sooner IT from both sides can start planning and working together, the better it will be for everyone involved. Dealing with production problems at the same time as blending the cultural and technical aspects will only make an already tension-filled process worse. Involvement and input will be rushed to meet immediate requirements; and compromises will be made, requiring later IT rework.
Because IT staff members are generally analytical and critical thinkers, they tend to point out problems, instead of seeing new-found “challenges” and providing solutions. If IT is brought in early, it can raise issues and bring solutions at the same time. As a result, the business area will more likely realize the value of IT involvement, and start to include IT more naturally. If, however, the proper business/IT relationships are not established from the start, the two areas will have difficulties working together.
Unforeseen costs will also arise when IT costs for the alliance are not researched and accounted for in the financial transaction. The cost of software has increased in the last 10 to 15 years as vendors realized the value that software adds to business productivity. In addition, vendors continue to enhance and create product functions and features leading to upgrades. There are also more productivity tools available,
which have become necessary in day-to-day business. And the many platforms that software is designed to run on also contribute to the continued rise in costs.
Third-party processing provides one real example of how software licensing can delay or add significantly to the cost of an alliance. Thus, after the deal is executed, the original company might continue to run the application on its mainframe to benefit the new company, thereby creating a third-party processing arrangement. Because software contracts often do not address third-party processing, there will be additional fees.
In addition, each software contract must be systematically inventoried and negotiated to ensure that application software packages are properly run and maintained. This also requires the IT departments to begin working together as soon as possible, and developing plans for the transition. Once developed, the plans must be communicated to everyone who will be involved in the changed environment.
The organizations can thus save money by fully understanding what will be required on both sides. In addition, appropriate planning and communication can mitigate the high frustration levels resulting from the changes.
Since IT staffing is critical to the success of an alliance, the organizations must pay special attention to retaining the necessary IT staff, particularly in light of the current IT market. The organizations should focus on those staff members who support the current systems, who work on the business transition, and who build the new linkages. The organizations might negotiate “stay” bonuses for existing staff, hire contracting firms to continue to run the applications, or combine the two strategies.
If organizations can retain their staff, training will generally not be required to keep the systems operational. However, additional skills may be required at appropriate intervals for transitioning the business and building new linkages, including specific languages, tools, or platforms.
the business/it relationship
The lack of a good relationship between the business and IT areas often figures prominently in the problems that arise when IT is left out of alliance negotiations. In the past, the data processing (DP) staff members were the only employees who knew anything about computers. The DP operation often featured a mainframe hidden in a basement corner. The computer performed batch operations, with viewing capabilities only during the day.
By contrast, today’s PC/Internet environment allows significant, individual processing capabilities. Over time, the business community has also become far more knowledgeable about technology. In addition, some successful IT staff have moved to the business side of the organization, bringing their IT knowledge. As business users’ computer knowledge increases, they feel less need to involve IT early on in the alliance process.
At the same time, however, the IT environment is becoming far more complex. The environment of mainframes and dumb terminals has changed to one of fully networked PCs, servers, and mainframes across LANs and WANs. Systems are no longer developed in flat file formats; developers now use relational and object databases with new languages. So the business areas cannot keep pace with IT
changes. For their part, IT staff members easily get caught up in the newest toys and latest technology, implementing solutions for the sake of using new technology, rather than meeting business needs.
The “expense factor” also contributes to the ineffective business/IT relationship. Here, because the business areas view IT as an expense that is constantly increasing, they try to avoid dealing with it until absolutely necessary. Because IT is often critical to company -set priorities, resources are too tight to designate time up front. However, up-front time is necessary in alliances, just as investing time up front in system development helps save time on back-end rework and retesting.
If IT spends time developing and fostering a positive value-added relationship with the business area, the business will naturally include IT sooner. In addition, it helps if a good business/IT relationship is developed before the two must interact in the stressful, time -sensitive manner that an alliance requires.
understanding the alliance
Because there are so many possible alliance options, IT should review and evaluate the specific alliance in question. When the organization first determines its business direction, IT should assess and understand top management’s corporate prioritization for the alliance, as well as the financial aspects. While ideas are easy to develop, a successful alliance requires full corporate backing. For example, success is more likely if the CEOs have met and signed the deal, rather than vice-presidents’ authorization in one line of business. In addition, public relations must communicate to the marketplace about the alliance.
IT should also consider the other company, determining if it has experience with alliances or is subject to any special or sensitive issues. Different alliances have contracts with different requirements and success factors. Although work on the contract might be time -consuming and take attention from current work, knowing the terms of the agreement will be invaluable later on.
Due diligence work is typically required before a deal is signed. Companies look favorably on IT managers who offer to complete the IT due diligence section. In addition, IT managers might thereby meet counterparts with whom they will work during the alliance project. Examples of due diligence areas include the company background, terminology, competitors, types and volumes of data to share, timeliness of communications, and data definitions. Some industries have common file sharing formats and data definitions that can quickly bridge the data definition knowledge gap.
The due diligence process also involves clearly identifying the methods of data transfer, communication, and security between the alliance partners. It is important for the data to move smoothly, and that it be protected at all times. IT should not make assumptions about the communications hardware and software in the other organization. Furthermore, the organizations want to prepare beforehand, rather than straightening out incompatibilities while trying to process the data. The latter will not only cause frustration on both sides of the transactions, but can become critical if the difficulties involve the alliance’s customers.
The organization’s financial investment in the alliance project can reveal the critic ality of the alliance. The importance can be gauged by comparing the project budget to the corporate budget, or the revenue projections to the corporate total.
In general, larger alliances can support more investment in infrastructure up front to set up the alliance. Smaller alliances must move quickly to prove themselves, in order to justify additional investment in infrastructure. Even in developing a shorterterm solution, however, it will still benefit IT to build a solution that can be built upon, rather than thrown away or replaced.
No comments:
Post a Comment