Method and systems for developing an acquisition integration project plan

[0001] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0002] This invention relates generally to integrating an acquired company with an acquiring company and more particularly, to methods and systems for assimilating a newly acquired asset or company with another asset or company.

[0003] Acquisition integration, as used herein, refers to processes and systems for assimilating a newly acquired asset (e.g., a portfolio) or company with an existing asset or company. For example, acquisition integration occurs when one company acquires another company. Acquiring a company includes multiple phases. Such phases include, for example, a pre-due diligence phase during which objectives to achieve in an acquisition are defined, a due diligence phase during which candidate companies being considered for acquisition are studied, a post-sign/pre-close (i.e., contracts are signed but operating provisions are not yet effective) phase during which contractual contingencies are resolved, a post-closing (i.e., contracts fully effective) phase during which the acquired company comes under the control of the acquiring company, and a transition to operations phase where the former two companies begin to operate as a single entity.

[0004] Integrating the operations and staff functions of the acquired company with the acquiring company traditionally starts with the post-sign/pre-close phase and continues into the post-closing phase. During the post-sign/pre-close phase, the integration activities may be minimal due to complexities and concerns relating to contractual contingencies, e.g., governmental reviews and approvals.

[0005] Although integration traditionally has been performed starting with the post-sign/pre-close phase, there have been attempts to initiate integration earlier in the acquisition time continuum, such as in the pre due-diligence phase. Attempts to initiate integration efforts early in the acquisition process can meet with resistance due, for example, to a desire to focus resources on identifying and screening candidate companies and avoiding perceived unnecessary costs associated with tasks traditionally performed much later in the acquisition time continuum.

[0006] Companies that perform numerous acquisitions throughout any given year may designate a group of individuals to work on acquisitions. Large companies with various operating businesses may designate multiple groups to work within assigned businesses on different acquisitions or on common acquisitions with other groups. The acquisition groups, however, typically focus on identifying candidate companies, performing due diligence on selected candidate companies, and then negotiating and finalizing the agreements necessary to acquire the selected company or companies. Once the acquisition agreements are executed, the acquisition group transitions to another acquisition project. Some members of the group that worked on the just completed acquisition may move on to new jobs, and new members are assigned to the acquisition group. The acquisition group is not necessarily involved in the post-closing integration.

[0007] As a result, the knowledge and experience gained through the acquisition process by each member of the group may not necessarily even be passed along to the post-acquisition integration group. Also, a process utilized in one particular acquisition often is not formally captured in a way that promotes repeating the process for another acquisition. That is, one group working with one business may not necessarily share its experiences and knowledge with another group working in another business, or even with another group in the same business.

[0008] Checklists are commonly utilized in the due diligence phase of an acquisition. A legal due diligence checklist, for example, identifies areas of concern regarding possible legal liabilities that should be analyzed when contemplating acquiring a company. An individual performing the legal due diligence can use the checklist as a tool to help ensure that the usual areas of concern have been addressed.

[0009] Checklists, however, typically are used in the due diligence phase and do not span across multiple phases of the acquisition process. In addition, the checklist is used to indicate whether a particular task has been fully completed (e.g., does not indicate the extent to which a task is partially completed) and does not facilitate capturing process changes implemented in connection with a particular acquisition. Consequently, changes in the acquisition process for particular types of acquisitions often are not broadly communicated and easily replicated throughout a business.

[0010] Further, even with the use of checklists, clearly communicating and assigning tasks to internal and external resources deployed on an acquisition, as well as tracking task completion and results, can be time consuming and difficult due to the number of people involved and the number of tasks to be completed. For an acquisition of a multi-national company having multiple sites throughout the world and thousands of employees located in many countries, communicating and assigning tasks to be completed is time consuming and complex.

[0011] Success in an acquisition, i.e., achieving the acquiring company goals, depends on integration of the acquired company into the acquiring company. Such integration includes not only the operations of the companies, but also the management structures and corporate cultures. Improving the processes and systems utilized in connection with acquisition integration therefore should enhance the likelihood for successful acquisitions.

[0012] In one aspect, a method in a computer for generating an acquisition integration project plan is provided which comprises displaying a plurality of pre-defined integration events based upon at least one user selected integration area, each pre-defined integration event being associated with a phase in an acquisition process, receiving at least one user selection of a pre-defined integration event for each user selected integration area, displaying the user selected, pre-defined integration events for each user selected integration area, displaying at least one of a name of a person responsible, a due date, a completion percentage, and a commentary for each user selected, pre-defined integration event, and storing the user selected, pre-defined integration events and corresponding integration areas as an acquisition integration project plan.

[0013] In another aspect, a computer is provided which is programmed to display a plurality of pre-defined integration events based upon at least one user selected integration area, each pre-defined integration event being associated with a phase in an acquisition process, display at least one user selected, pre-defined integration event for each user selected integration area, display at least one of a name of a person responsible, a due date, a completion percentage, and a commentary for each user selected, pre-defined integration event, and store the user selected, pre-defined integration events and corresponding integration areas as an acquisition integration project plan.

[0014] In yet another aspect, a database for acquisition integration is provided which comprises data corresponding to at least one integration area and data corresponding to integration events for each integration area.

[0015] In still another aspect, a system for acquisition integration is provided which comprises a database comprising data corresponding to integration events for at least one integration area and a server configured to prompt a user to select an integration area and to provide information regarding a status of integration events within the integration area.

[0016] In a further aspect, a method for acquisition integration planning is provided which comprises selecting, from an electronic interface, at least one of a plurality of integration areas, identifying a responsible person for each integration area using the interface, identifying a responsible person and a due date for each integration event within an integration area through the interface, and requesting, from the electronic interface, a percentage completion for each integration event.

[0017] In still another aspect, an apparatus is provided which comprises means for prompting a user to select at least one integration area, means for displaying a plurality of integration events for the selected integration areas, and means for generating an integration acquisition project plan using selected integration events is provided.

[0018] In another aspect, a computer program embodied on a computer-readable medium is provided which comprises a code segment that manages integration areas for acquisition integration, a code segment that organizes integration events for each integration area, and a code segment that generates an acquisition integration plan including a set of integration events and deliverable checklists based on user selected integration areas, to guide the user through integration process.

[0019] In still another aspect, a method is provided for operating a computer which comprises prompting a user to select an integration area from an acquisition integration main user interface, displaying a set of selectable integration events for the selected integration area, and generating an integration project plan incorporating selected integration events.

[0020] In yet another aspect, a computer is provided which is programmed to prompt a user to select an integration area from a computer generated screen configured as an acquisition integration main user interface, display a set of selectable integration events for the selected integration area, and generate an integration project plan incorporating user selected integration events.

[0021] In a further aspect, a computer-readable medium is provided which is executable by a computer for receiving user selections of pre-defined integration areas, receiving user selections of pre-defined integration events for the selected integration areas, and generating an acquisition integration plan with the user selected, pre-defined integration areas and integration events for a planned acquisition.

[0042] Set forth below is a description of embodiments of methods and systems for acquisition integration. The term acquisition integration, as used herein, refers to processes and systems for assimilating a newly acquired asset (e.g., a portfolio) or company with an existing asset or company. For example, acquisition integration processes and systems are utilized to incorporate a purchasing company's philosophies and operating styles into an acquired company, while realizing that the acquired company may bring “best practices” and operating philosophies that will improve the acquiring company. As used herein, the term “best practices” refers to processes and systems for performing tasks or functions that exceed the results of other known processes and systems.

[0043] While the methods and systems are sometimes described in the context of a specific acquisition, the methods and systems are not limited to practice in connection with only one particular type of acquisition. Rather, the methods and systems can be used in connection with the acquisition integration of many different types of assets and companies.

[0044] Generally, the methods and systems described below are easy to use, and facilitate clear communication and tracking of tasks performed in connection with an integration. Ease of use facilitates initiation of the acquisition integration processes early in the overall acquisition process. In addition, and as described below, the methods and systems are flexible to accommodate unique aspects of each acquisition. The methods and systems also capture the knowledge and experience gained in each acquisition, which facilitates a sharing of such knowledge and experiences with others involved in performing acquisition integration as well as enhances the repeatability of processes that are determined to be best practices.

[0045] Referring now specifically to the drawings, FIG. 1 is a flowchart 2 illustrating process steps for generating an acquisition integration project plan. A person familiar with computer software code can utilize flowchart 2 in combination with various user interfaces (described below), to develop a computer program that is executable by computer systems (shown in FIGS. 2 and 3) which are described herein. In one example, a system based acquisition integration tool provides a framework for generating such a plan. Specifically, after a user logs into the system, the system prompts the user, e.g., via a display, to select 4 an integration area from an acquisition integration main user interface. Examples of pre-defined integration areas include commercial, operational, human resources, legal, and financial. Of course, fewer or more integration areas can be designated within the system. Once the user selects 4 an integration area, the system then displays 6 a set of selectable, pre-defined integration events including deliverables checklists for the selected integration area. Each integration event is listed under a respective heading, and each heading representing a phase in the acquisition process. Examples of headings include pre due diligence, due diligence, post sign/pre close, post close and transition to operations. In addition, deliverables are listed under each heading. The list of deliverables can be used to determine whether all tasks associated with a particular integration event have been completed. The acquisition integration plan is formed 8 based on the user-selected integration areas, and the plan includes, for each integration area and each phase of acquisition, integration events and deliverables.

[0046] Set forth below are details regarding example hardware architectures (FIGS. 2 and 3), and example computer generated screen shots displayed by the system to facilitate acquisition integration (FIGS. 4 through 19). In addition, a list of pre-defined integration areas and a list of pre-defined integration events are set forth in FIGS. 20 through 80. Using the pre-defined integration areas and integration events, a user, as explained below, is able to construct a customized integration plan using those areas and events the user, for example an integration manager for an upcoming acquisition integration, sees as being pertinent to their acquisition integration. Of course, best practices implemented by an acquiring company may cause certain integration areas and integration events to be required in every acquisition integration project plan. Further, a user is able to add user-defined integration areas and events to their integration, based upon specific integration needs, which, in the future, may be added to the pre-defined integration areas and integration events by a system administrator. The user is able to store their “custom” integration plan for access and use by their integration team as a spreadsheet or as a web page. The user and the integration team is thus provided with an acquisition integration plan, which is based upon pre-defined integration areas and events, which provides rigor and consistency to the acquisition integration process, and user-defined integration areas and events, which provides flexibility to the integration process. Again, although specific embodiments of methods and systems for integrating acquisitions are described herein, the methods and systems are not limited to such specific embodiments.

[0047] Hardware Architecture

[0048] FIGS. 2 and 3 illustrate, in block diagram form, hardware architectures that can be utilized in connection with implementing an acquisition integration system. Of course, the system can be implemented on many different platforms and utilizing different architectures. The architectures illustrates in FIGS. 2 and 3, therefore, are examples only.

[0049] More specifically, FIG. 2 is a block diagram of a system 10 that includes a server sub-system 12, sometimes referred to herein as server 12, and a plurality of devices 14 connected to server 12. In one embodiment, devices 14 are computers including a web browser, and server 12 is accessible to devices 14 via a network such as an intranet or a wide area network such as the Internet. In an alternative embodiment, devices 14 are servers for a network of user devices.

[0050] Devices 14 are interconnected to the network, such as a local area network (LAN) or a wide area network (WAN), through many interfaces including dial-in-connections, cable modems and high-speed lines. Alternatively, devices 14 are any device capable of interconnecting to a network including a web-based phone or other web-based connectable equipment. Server 12 includes a database server 16 connected to a centralized database 18. In one embodiment, centralized database 18 is stored on database server 16 and is accessed by potential users at one of user devices 14 by logging onto server sub-system 12 through one of user devices 14. In an alternative embodiment centralized database 18 is stored remotely from server 12.

[0051] FIG. 3 is a block diagram of a network based system 22. System 22 includes server sub-system 12 and user devices 14. Server sub-system 12 includes database server 16, an application server 24, a web server 26, a fax server 28, a directory server 30, and a mail server 32. A disk storage unit 34 incorporating a computer-readable medium is coupled to database server 16 and directory server 30. Servers 16, 24, 26, 28, 30, and 32 are coupled in a local area network (LAN) 36. In addition, a system administrator work station 38, a work station 40, and a supervisor work station 42 are coupled to LAN 36. Alternatively, work stations 38, 40, and 42 are coupled to LAN 36 via an Internet link or are connected through an intranet.

[0052] Each work station 38, 40, and 42 is a personal computer including a web browser. Although the functions performed at the work stations typically are illustrated as being performed at respective work stations 38, 40, and 42, such functions can be performed at one of many personal computers coupled to LAN 36. Work stations 38, 40, and 42 are illustrated as being associated with separate functions only to facilitate an understanding of the different types of functions that can be performed by individuals having access to LAN 36.

[0053] Server sub-system 12 is configured to be communicatively coupled to various individuals or employees 44 and to third parties, e.g., user, 46 via an ISP Internet connection 48. The communication in the embodiment described is illustrated as being performed via the Internet, however, any other wide area network (WAN) type communication can be utilized in other embodiments, i.e., the systems and processes are not limited to being practiced via the Internet. In addition, and rather than a WAN 50, local area network 36 could be used in place of WAN 50.

[0054] In the embodiment described, any employee 44 or user 46 having a work station 52 can access server sub-system 12. One of user devices 14 includes a work station 54 located at a remote location. Work stations 52 and 54 are personal computers including a web browser. Also, work stations 52 and 54 are configured to communicate with server sub-system 12. Furthermore, fax server 28 communicates with employees 44 and users 46 located outside the business entity and any of the remotely located customer systems, including a user system 56 via a telephone link. Fax server 28 is configured to communicate with other work stations 38, 40, and 42 as well.

[0055] User Interfaces (Screen Shots)

[0056] FIG. 4 is an example of a login user interface 100 for an acquisition integration framework tool. Authorized users are able to access the acquisition framework tool by entering a valid user name and password. If a password is forgotten, a link exists where a user can notify a system administrator of the forgotten password. A link where a non-user can request an account is also supplied in the embodiment of user interface 100 shown in FIG. 4. In one embodiment, login user interface 100 includes an advisory. For example, in one embodiment, login user interface 100 includes the following advisory: “In order to become compliant with Web Security Procedures, we need to cancel generic passwords. Please take a moment and register your proper account. Meanwhile you will be added to our users distribution list, so we can keep you more effectively updated about coming AIF updates and enhancements.”

[0057] FIG. 5 is an example of an acquisition integration main user interface 110 for athe acquisition integration framework tool. Main user interface 110 includes headings for Commercial, Operational, Human Resources, Legal, and Financial. Under each of the headings are groupings of pre-defined integration areas, which are selectable by a user. Selection of a heading or the integration areas under a heading, causes to be displayed pre-defined integration events for the selected integration area. The display further includes a name for a person responsible for the selected integration area. In one embodiment, data corresponding to integration areas and integration events are stored within database 18 (shown in FIG. 2).

[0058] As shown on user interface 110, an example pre-defined set of integration areas that a user can select from, includes, under the Commercial heading, sales and marketing, E-commerce financial services, including customer service and collections, and sourcing. Under an Operational heading, pre-defined integration areas include product, services, risk, six sigma and systems/information technology. The term six sigma, as used herein, refers to a quality initiative for reducing the number of defects to a quantified goal (i.e., six sigma). The product integration areas includes integration areas for manufacturing, engineering, logistics, and environmental health and safety (EHS).

[0059] A human resources integration area heading includes, in the embodiment shown, pre-defined integration areas for communication, culture, and strategy, including organization development, labor relations, employee benefits, compensation, employment practices, and employee services implementation (payroll benefits, expatriate administration and travel and living expenses).

[0060] A legal integration area heading includes, in the embodiment shown, pre-defined integration areas for legal, intellectual property and compliance. A financial integration area includes treasury, Euro programs, financial planning, closing reporting, tax integration, controllership, and insurance.

[0061] Further included on user interface 110 are selectable links, selection of which provide the user with pre-defined integration events for a business leader, a due diligence leader, and an integration leader, in a graphical depiction of the relationship between those leaders. A user is further able to select an acquisition integration framework (AIF) overview or a feedback link (both described below), to provide comments to the administrator regarding system functionality.

[0062] FIG. 6 is an example of a Send Feedback user interface 120 for an acquisition integration framework tool, showing a comment area where a user can enter comments for storage in database 18 (shown in FIG. 2) and submission of user-defined integration areas and integration events to a system administrator.

[0063] FIG. 7 is an example of an AIF Overview user interface 130. In addition to the AIF overview shown, one embodiment of user interface 130 includes a description of the DMAIC (Define, Measure, Analyze, Implement, and Control) Integration Process, Non-Negotiables (elements that are essential for conducting business), and the Features of the AIF. Data corresponding to the AIF overview is stored within database 18, for display by system 10. AIF Overview user interface 130 describes the philosophy underlying the acquisition integration framework, and is used to inform the user about critical aspects of Acquisition Integration. In one embodiment, AIF overview user interface 130 includes a background section. For example, in one embodiment, AIF overview user interface 130 includes the background: “Acquisition Integration is defined as the ‘Process of Preparing for and Assimilating a Newly Acquired Company or Portfolio into the Family’. Integration is the vehicle by which we realize the expected goals and benefits of our acquisitions. Because we do numerous acquisitions each year, integration needs to be a repeatable process. A structured approach to integration serves as a source of competitive advantage by providing a strategy for managing integration efforts from day one. In addition, the Acquisition Integration Framework tool facilitates the sharing of integration best practices and lessons learned. All of the business can benefit from the collective knowledge of our acquisition integration experiences. The AIF tool was designed to greatly increase the speed and success rate of our acquisitions by eliminating the need to ‘re-create the wheel’ each time. One important principle to the Acquisition Integration Framework is to understand that every integration is different. While you can surely benefit and learn from past integration experience, the success factors for one effort may not be relevant to another integration initiative. Similarly, you can't expect all tolls and processes to be equally applicable to every case. So, you must carefully evaluate the objectives set out by the leadership team and the characteristics of the new company to shape and customize the optimal integration approach.”

[0064] FIGS. 8 and 9 are an example of a Business Leader integration area and deliverables checklists user interface. In a first portion 140 of the user interface, are links to AIF main user interface 110 (shown in FIG. 5), an Overview user interface, a “Do's/Don'ts” user interface, a Contacts user interface, and Examples user interface, a Links user interface and a Project Plan user interface. It should be noted that the links to the overview, “Do's and Don'ts”, contacts, examples user interface, links user interface and project plan are configured for the integration area displayed. For example, selection of the “Do's and Don'ts” link in first portion 140 causes a display describing what a business leader should and should not do in an acquisition integration. More detailed descriptions of the links within an integration area are included below.

[0065] First portion 140 also includes under the Business Leader heading a graphical representation of the stages of the acquisition integration, referred to herein as headings for groupings of integration events. The headings include pre-due diligence, due diligence, post signing/pre-closing, post closing, and transition to operations topics. Listed under each of the heading topics are listed pre-defined integration events for the integration area. As will be described below, each integration event is selectable by the user, and selection of an integration event causes a screen to be displayed. describing the integration event.

[0066] FIG. 9 is a second portion 150 of Business Leader integration area and deliverables checklists user interface. Second portion 150 includes under the headings described above, deliverables which are to be completed before the integration team moves to the next heading. Deliverables checklists are stored within database 18 (shown in FIG. 2). For example, before proceeding to a due diligence, the deliverables “integration leader appointed/steering committee appointed” and “participate in define tollgate” are completed in the pre due diligence stage, and checked. An example of a tollgate is a meeting or conference call to review completeness of deliverables on the checklist and determine whether the integration can proceed to the next stage, for example, pre-closing to post-closing.

[0067] FIG. 10 is an example of an integration event explanation user interface 160 which is displayed upon selection of an integration event, for example, the integration events shown in FIG. 8. In particular, user interface 160 shows a Step 2100: Present an Overview to Target Management user interface, showing advice to a manager associated with the acquisition integration and including a link to previous management presentations (described in FIG. 11). In one embodiment, user interface 160 includes the following text below the section entitled Step 2100: Present an Overview to Target Management: “At the beginning of the due diligence, the Business Leader should take the time to introduce his leadership team to the Target Company. Presenting an overview pitch on the due diligence process is helpful for the Target Company to understand what may be required of them and how the process will work. This is also terrific time to get the key members of the Target Company excited about joining the family. Giving an overview presentation on the history and its major accomplishments is recommended. Example: Management presentations.” Description of the integration event is important to a person responsible for the integration event, since he or she determines completeness and updates a completion percentage for one or more integration events.

[0068] FIG. 11 is an example of a sample presentations user interface 170, in particular a management presentation, which is displayed upon selection of a management presentations link within an integration event description. While content of a management presentation will vary from integration event to integration event, user interface 170 illustrates that sample presentations are typically attached files, for example, slide presentations, presented previously and attached to the acquisition integration tool using system 10. In one embodiment, user interface 170 includes the following text: “One-on-Ones, Interviews and Work-Out to Capture Best Practices 2/00–4/00 . . . Design and Validation 4/00–7/00 . . . Pilot and Revisions 10/00–1/01 . . . Launch 1/01 . . . ”. Data corresponding to presentations and explanations of integration events are stored within database 18 (shown in FIG. 2).

[0069] FIG. 12 is an example of an Intellectual Property integration area user interface 200. As shown on user interface 200, for the intellectual property acquisition integration task, there are multiple, pre-defined integration events listed under previously described pre-due diligence, due diligence, post signing/pre-closing, post closing, and transition to operations headings. Further included on user interface 200 are links to an AIF Main user interface, an intellectual property overview user interface, an intellectual property “Do's and Don'ts” user interface, an intellectual property contacts user interface, an intellectual property examples user interface, an intellectual property links user interface and an intellectual property project plan user interface. FIG. 13 includes an intellectual property deliverables checklist 210, which is typically displayed with intellectual property integration area user interface 200. Checklist 210 includes intellectual property “deliverables” which are to be completed for each heading (e.g. pre due diligence) before proceeding to the next heading (e.g. due diligence).

[0070] FIG. 14 is an example of an Intellectual Property Overview user interface 220, describing an intellectual property acquisition integration task list which is assigned to the intellectual property integration leader. User interface 220 is accessed by selecting the overview link described in intellectual property integration area user interface 200 (shown in FIG. 12.) In one embodiment, user interface 220 includes the following text under the section entitled Intellectual Property Overview: “Effective and timely intellectual property integration includes a multitude of tasks to be performed over a period of time. IP integration is best achieved where these tasks are planned and initiated early in the acquisition time continuum. The earlier the planning, the better. For this reason, the IP integration framework described hereafter moves the planning tasks and the tasks associated with developing an effective plan and integration team, toward the front of the acquisition time continuum. For example, appointing an IP Integration Leader, performing Gap Analysis, defining an IP integration structure and preparing an initial IP integration budget have all been placed in the measure or pre-signing step. Beginning early on all these tasks facilitates IP integration. However, for any given acquisition, it may be appropriate for several reasons, to slip these tasks downstream in the acquisition time continuum. For example, some of these tasks, such as the Gap Analysis or budget, may be performed in the post-signing/pre-closing or analyze phase. The key is that they are performed. That said, however, the ‘define’ phase should take place prior to due diligence. From an IP integration perspective, two main objectives need to be achieved prior to commencing the due diligence: 1. An IP Integration Leader needs to be selected. 2. This IP Integration Leader needs to understand the IP aspects of the business case: What role is IP expected to play during and after the transaction? How are we going to implement the IP Objectives?” In addition, in one embodiment, user interface 220 includes the following text under the section entitled 1000 DEFINE: “He or she will be part of or lead the due diligence team and be responsible for transitioning the knowledge to the IP Integration Team. Deliverables for the define phase tollgate include: 1. IP Integration Leader appointed. 2. Scope of IP Integration—assessment of importance of IP in transaction. Define key assumptions and ‘must have’ underlying IP aspects of business case or synergies. 3. List of goals/CTQ's.”

[0071] FIG. 15 is an example of an Intellectual Property “Do's and Don'ts” user interface 230, which provides advice to managers of the acquisition integration of a target company's intellectual property. User interface 230 provides advice regarding which actions should be taken and which actions should be avoided. In one embodiment, user interface 230 includes the following Do's: “Begin integration planning before due diligence; Understand the relevance and importance of IP to the transaction; Understand the IP health of the acquired company . . . perform a Gap Analysis; Develop strong cross functional IP integration expertise . . . legal, engineering, human resources, security and so on; Establish clear CTQ's and goals to direct the IP integration; and Involve employees from the acquired company in the integration.” In addition, in one embodiment, user interface 230 includes the following Don'ts: Underestimate the cost of the IP integration; Assume existing company has the best practices, look at the best practices of the acquired company; and Don't shy away from tough decisions.

[0072] FIG. 16 is an example of an Intellectual Property contacts user interface 240, showing contact information for an individual who has been designated as a source of knowledge when confronting intellectual property acquisition integration issues. In one embodiment, user interface 240 includes the name, title and phone number for an individual who has been designated as a source of knowledge. For example, in one embodiment, user interface 240 includes: “Joe Counsel—Associate General Patent Counsel and IP Transactions Counsel; (555) 123-4567.”

[0073] FIG. 17 is an example of a portion of an intellectual property integration project plan 250, showing pre-defined intellectual property acquisition integration events, or tasks, to be carried out before due diligence, during due diligence, and during the post-signing/pre-closing phase. A continuation (not shown) of user interface 250 identifies the integration events which take place after closing, and during a transition to normal operations phase. In integration project plan 250 for each integration event, there is listed, a name of a person responsible for the integration event, (e.g. a responsible person), a percentage complete, a date due, and any comments relating to the integration event. User interface 250 further includes integration sub-events, not listed on user interface 200 (shown in FIG. 12), which further define the integration events to be accomplished.

[0074] FIG. 18 is an example of a Search AIF user interface 260, where the user can search the acquisition integration tool for the occurrence of a specified term, which is entered by the user.

[0075] FIG. 19 is an example of an Integration Progress Report user interface 270, showing a percentage completion against plan with respect to each of the integration areas and headings used to group integration events. Specifically there is shown the processes relevant to integration of the acquisition, broken out by phase in the acquisition integration, including pre-due diligence, due diligence, post signing/pre-closing, post closing, and transition to operations phases.

[0076] FIGS. 20 through 80 contain an example acquisition integration plan, including pre-defined integration events, for the following pre-defined integration areas: business leader, integration manager, due diligence leader, sales/marketing, E-commerce, customer services, collections, manufacturing, engineering, logistics, EHS, services, risk management, six sigma, information technology, communication, culture, human resources (HR) strategy, HR labor relations, HR employee benefits, HR compensation, HR employment practices, payroll benefits, expatriate administration, travel and living expenses, legal, intellectual property, compliance, treasury, Euro program, financial planning, closing reporting, tax integration, controllership and insurance.

[0077] Each of the above listed acquisition integration areas are accessible from main user interface 110 (shown in FIG. 5), and selection of any of the areas causes to be displayed integration events and deliverables checklists user interfaces for the integration area (similar to those shown in FIGS. 8 and 9). Further as system 10 displays integration area and deliverables checklists user interfaces for the above listed integration areas, integration events are selectable for a displayed description of the integration event. Also, from the integration area and deliverables checklists user interfaces, overviews, “Do's and Don'ts”, contacts, examples, links and project plans are selectable for viewing as above described.

[0078] Use of system 10 provides an integration team with the resources needed to perform the acquisition integration tasks involved when combining one business entity into another. System 10 provides integration resources by providing a user with a knowledge depository, (e.g. an acquisition integration database based on input from subject area knowledge experts), collected from previous integration experiences, and presented in a format to enable the user to use the gathered knowledge to provide for smoother transitions and repeatable processes when conducting an integration of an acquisition. The user is further provided a integration project management tool where they can prepare their own acquisition integration plan by selecting integration areas and events from the pre-defined integration areas and events, which the integration manager user determines is relevant to their integration of an acquisition. An integration manager uses the selected integration areas and events to provide rigor, repeatability and the benefit of stored experience to their integration process. The integration manager is also free to add user-defined areas and events, based upon individual acquisition integration needs.

[0079] While the invention has been described in terms of various specific embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the claims.