Models for Business Process Outsourcing
Onsite Model of Business Process Outsourcing
The success of any business process outsourcing contract lies in the appropriate and precise gathering of information about the project. According to the onsite business process outsourcing model, the whole set of processes starting from information gathering to implementation is done at the client's premises. This model ensures that the result is correct at the first instance. Based on the needs and requirements of the client, the design, development and test teams are deployed for a short time frame at the client's location. The business process outsourcing service provider utilizes its workforce for service of its clients at their premises. This business process outsourcing model becomes essential and suitable if the project needs a specific resource type of post-deployment, maintenance, support and follow-up activities. This model is helpful for those projects that are mission-critical, require proper and constant attention and also need everything to be done in the client's location. Thus, the onsite business process outsourcing approach is ideal for:
1.Requirements not being defined at length
2.Dynamic changes in deliverables or requirements
3.Tough and Rigid deadlines
4.Constant need of support
5.Direct interaction with client
6.Scalable staff augmentation
7.Moving across time lines
8.Mission Critical Projects
9.Product engineering-related services
10.Open-ended and iterative nature of project scope
11.Projects that are highly secured and confidential
In this approach, all the activities mentioned below are executed onsite:
1.Initial Study/Understanding the client's requirements
2.Planning
3.Technology Assessment
4.Development
5.Design
6.Testing
7.Installation
8.Maintenance and Support
9.Offsite Model of Business Process Outsourcing
According to this model of business process outsourcing, the service provider will have its office near the client location. Not only does the business process outsourcing offsite center have the benefit of being close to the client, but it also gives support to the onsite team and the offshore development activities at the offshore center. Thus the experts at the business process outsourcing offsite center in tandem with the corresponding offshore center team ensure on time, quality service through collaborative skills across different time zones. This business process outsourcing model is appropriate:
1.For short-term business process outsourcing projects
2.When requirements are defined beforehand
3.When there are no frequent changes in the business process outsourcing project
4.When the client's location may not have extra capacity
Offshore Model of Business Process Outsourcing
This model of business process outsourcing entails that the project-related activity; right from initial study to testing is done at the service provider's premises. The business process outsourcing service provider will not have any presence at the client's location but the client will interact directly with the offshore team. This model is best suited when the project plan is well defined and the development team has a clear understanding of client requirements. The team members at the business process outsourcing offshore location interact with the client through various communications means such as telephone, fax, email etc.
This business process outsourcing model has been proved to be effective in terms of:
1.High quality service with low labor cost
2.Effective utilization of time zone (24x7 service)
3.Availability of multi-technology skills
4.30 to 50% reduction in project cost
But the high level of risks associated with this business process outsourcing delivery model becomes a critical success factor for some clients. Some analysts are of the opinion that a 100% business process outsourcing offshore model is not workable. The risks, which are associated with this model:
1.Risk of communication gap between the vendor and client
2.Client requirements may not be captured in real terms
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Source:http://businessmajors.about.com
Thursday, June 03, 2004
The banking industry is ripe for business process outsourcing
For more than 30 years, the banking industry has used outsourcing as a means to reduce costs. Until recently, IT processes accounted for the majority of large-scale bank outsourcing.
In the past two or three years, however, more and more banks are dipping their toes into the fresher waters of business process outsourcing (BPO). A recent example is Bank of America’s deal with Exult to run its human resources department.
BPO entails outsourcing an entire business function—not just certain aspects of the function, such as IT systems. Good BPO candidates are key back-office processes, such as items processing, call centers, and even entire HR departments.
The impetus behind this more extensive kind of outsourcing is certainly cost savings. In addition, the flexibility with which banks must respond to industry challenges presented by straight-through processing (STP), electronic bill presentment and payment (EBPP), and truncation is increasingly important.
Outsourcing bank back-office processes also helps mitigate risk. And many banks choose BPO to gain access to intellectual capital and skill sets.
Issues to consider before making the move to BPO
Banking is ripe for BPO. For example, of the top 20 banks in North America, more than half have outsourced their items processing, are actively searching for providers, or are reviewing the business case for such a move. So, what should banks consider before making the BPO decision?
Pricing needs to be at the top of the list. However, it's also one of the hardest things to get right. BPO is immature, and drawing up the right cost structures and identifying good deals is often something of a guessing game. So the financial side of any contract, let alone any other clauses, requires appropriate expertise to judge correctly.
Two additional factors compound the problem. First, BPO typically incorporates a desire to improve best practices or deliver operational transformation. It can be difficult to discern where the danger points lie in the relationships governing these crucial but intangible qualities.
Second, the very nature of BPO requires companies to negotiate functions that they have little knowledge about, which is one of the reasons they want to outsource in the first place. But this can pose a serious risk. Unscrupulous outsourcing partners may use this lack of expertise to pull the wool over a company’s eyes. Therefore, banks should begin by outsourcing what they thoroughly understand before moving to more innovative projects.
How soon will BPO benefits be quantifiable?
How soon a bank will realize the benefits of BPO depends on the situation, according to "BPO in Banking: Outsourcing the Back Office," a Giga Information Group report by analyst Julie Giera. If the scale of outsourcing is one small area of back-office operations, then banks will potentially realize benefits sooner because conversion to the outsourcer’s area of responsibility will occur sooner.
However, if a multibillion-dollar bank decides to outsource its entire items processing facility and consolidates, say, 15 different capture facilities into five, while converting to image and truncation at the same time, it could be at least a year before the bank will realize any substantial benefits.
In addition, banks are often ill-equipped to assess the benefits that BPO can bring, let alone when it might bring them. The focus of most traditional outsourcing relationships is solely on reducing the cost of current services, which has resulted in an important missed opportunity for increasing the business impact of outsourced IT as well as BPO.
Successful outsourcing contracts involve relationships between parties, not transactions. As such, the value an outsourcing partner can and should deliver goes well beyond cost savings. But most CIOs and IT managers have little experience in measuring that type of value, and they're often unprepared to apply such concepts to BPO.
BPO should be an offer that many banks simply cannot refuse. Whether it's an offer they can understand is another question entirely.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Source:http://techrepublic.com.com
For more than 30 years, the banking industry has used outsourcing as a means to reduce costs. Until recently, IT processes accounted for the majority of large-scale bank outsourcing.
In the past two or three years, however, more and more banks are dipping their toes into the fresher waters of business process outsourcing (BPO). A recent example is Bank of America’s deal with Exult to run its human resources department.
BPO entails outsourcing an entire business function—not just certain aspects of the function, such as IT systems. Good BPO candidates are key back-office processes, such as items processing, call centers, and even entire HR departments.
The impetus behind this more extensive kind of outsourcing is certainly cost savings. In addition, the flexibility with which banks must respond to industry challenges presented by straight-through processing (STP), electronic bill presentment and payment (EBPP), and truncation is increasingly important.
Outsourcing bank back-office processes also helps mitigate risk. And many banks choose BPO to gain access to intellectual capital and skill sets.
Issues to consider before making the move to BPO
Banking is ripe for BPO. For example, of the top 20 banks in North America, more than half have outsourced their items processing, are actively searching for providers, or are reviewing the business case for such a move. So, what should banks consider before making the BPO decision?
Pricing needs to be at the top of the list. However, it's also one of the hardest things to get right. BPO is immature, and drawing up the right cost structures and identifying good deals is often something of a guessing game. So the financial side of any contract, let alone any other clauses, requires appropriate expertise to judge correctly.
Two additional factors compound the problem. First, BPO typically incorporates a desire to improve best practices or deliver operational transformation. It can be difficult to discern where the danger points lie in the relationships governing these crucial but intangible qualities.
Second, the very nature of BPO requires companies to negotiate functions that they have little knowledge about, which is one of the reasons they want to outsource in the first place. But this can pose a serious risk. Unscrupulous outsourcing partners may use this lack of expertise to pull the wool over a company’s eyes. Therefore, banks should begin by outsourcing what they thoroughly understand before moving to more innovative projects.
How soon will BPO benefits be quantifiable?
How soon a bank will realize the benefits of BPO depends on the situation, according to "BPO in Banking: Outsourcing the Back Office," a Giga Information Group report by analyst Julie Giera. If the scale of outsourcing is one small area of back-office operations, then banks will potentially realize benefits sooner because conversion to the outsourcer’s area of responsibility will occur sooner.
However, if a multibillion-dollar bank decides to outsource its entire items processing facility and consolidates, say, 15 different capture facilities into five, while converting to image and truncation at the same time, it could be at least a year before the bank will realize any substantial benefits.
In addition, banks are often ill-equipped to assess the benefits that BPO can bring, let alone when it might bring them. The focus of most traditional outsourcing relationships is solely on reducing the cost of current services, which has resulted in an important missed opportunity for increasing the business impact of outsourced IT as well as BPO.
Successful outsourcing contracts involve relationships between parties, not transactions. As such, the value an outsourcing partner can and should deliver goes well beyond cost savings. But most CIOs and IT managers have little experience in measuring that type of value, and they're often unprepared to apply such concepts to BPO.
BPO should be an offer that many banks simply cannot refuse. Whether it's an offer they can understand is another question entirely.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Source:http://techrepublic.com.com
Wednesday, June 02, 2004
Revisiting Key Provisions in Software and Outsourcing Agreements
Key provisions in software license and outsourcing agreements should be revisited and updated in light of the events of 9/11 and changes in privacy laws, intellectual property practices, and the business purposes of information technology projects. Central to this is the use of technology to implement business transformation, that is, the use of software and outsourcing to improve, or transform, a company's business operations.
An example of business transformation could be taken from the use of a manual system to order custom products in the retail industry. Let us assume that the use of manual orders causes in salesmen to miscode forms and that the volume of handwritten paperwork causes manufacturing mistakes at the factory. If the manual system were replaced by software and the software prevented miscoding and its automated order placement prevented factory mistakes, then the number of products that would have to be discarded or returned would be greatly reduced. In this case, the improvement in business operations, at both the retail store and the factory, is included in the software. The business transformation is embodied in the adoption of the new technology.
The topics covered by this article are also important even if business transformation is not the primary purpose of the IT transaction. For such cases, this article provides updated licensing techniques. Among other topics, this article covers: (1) the changes required in confidentiality agreements to accommodate the privacy of personal information; (2) rethinking the purpose of force majeure provisions in light of 9/11; (3) the potential problems of using joint ownership as a solution for intellectual property rights; (4) the impact of statements of work on litigated disputes; (5) having master agreements control over subsequent transactions documents; (6) the advantages of placing confidentiality obligations in a separate agreement; (7) framing a motion for an injunction to require the vendor to provide maintenance during a dispute as a motion to maintain the status quo rather than as a request for an extraordinary affirmative remedy; (8) converting source code escrow to technology escrow (including placing the names of the programmers in escrow); and (9) requiring employee background checks as protection against software sabotage. The article concludes with a discussion of the core factors necessary for successful outsourcing or software licensing agreement.
MODIFYING CONFIDENTIALITY AGREEMENTS TO PROTECT PERSONAL INFORMATION
New privacy law regimes and the business need for a software or outsourcing customer to protect the personally identifiable information (PII) in its possession require changes in standard confidentiality agreements. The PII can belong to the customer's customers, its employees, business partners, and others. In the United States, the new privacy laws include Graham-Leach-Bliley for financial information, the Children's Online Privacy Protection Act for online sales to children, and the Health Insurance Portability Protection Act for personal health information. Elsewhere, new privacy legislation includes the European Directive on the Protection of Individuals with regard to the Processing of Personal Data and on the Free Movement of such Data in EU member states, the Canadian Personal Information Protection and Electronic Documents Act, and Australian Federal Privacy Act.
Standard confidentiality agreements were generally written to protect trade secrets and other proprietary business information and to exclude publicly available information from nondisclosure obligations. These confidentiality agreements need to be revisited because they were not written to cover PII entrusted to a party. A company that is a customer in a software license or outsourcing transaction will want the vendor to keep PII confidential. It will argue that, because it has an obligation to do so, so does the vendor that acts as its agent. The vendor, however, may argue that it has no confidentiality obligation because the PII fits within the exception for public information. This is because personal information such as home addresses is technically available to the public in the county clerk's office and other similar sources. To protect its business interests and to avoid possible liability under privacy regulations, the customer will insist on an exception to the exception to prevent the disclosure of PII.
In some cases, a vendor may have already received the same PII in its possession, and it may have received the consent of the owner, as is available under privacy laws, to disclose that information. This can occur, for example, when the vendor is a large institution that licenses software to this particular customer but provides data processing or outsourcing services to other customers and has the right to disclose the PII for those purposes. As a result, the vendor will require the right to disclose PII that it has independently received, even if the same PII is the incidental possession of the customer, in order to preserve the rights it previously obtained for that information.
COMBINING FORCE MAJEURE AND BUSINESS CONTINUITY PLANS
An issue highlighted by 9/11 is the need to rethink the purpose of force majeure provisions. I suggest that force majeure provisions be combined and coordinated with disaster recovery and business continuation provisions. Disaster recovery and business continuation plans are meant to operate when certain force majeure events occur. The force majeure provision should not operate to relieve the vendor of the obligation to perform. While force majeure events might reduce the obligations of the vendor, they should not eliminate them. Instead, the contract should identify certain foreseeable events and delineate what the vendor's obligations should be (even if reduced) when those events occur. Put another way, the contact should require the vendor do be part of the disaster recovery and business continuation process. In essence, the contract should specify the acts the vendor is to take in the event of particular force majeure events instead of simply excusing vendor performance.
POTENTIAL PROBLEM WITH JOINT OWNERSHIP OF PATENT RIGHTS
One difficult intellectual property issue that arises in software development and outsourcing agreements concerns the ownership of improvements and new inventions, especially those created as a result of joint or collaborative effort of the vendor and customer. A common contractual provision provides that the parties will jointly own the patents that result from jointly developed inventions. The practicalities of patent prosecution can confound the parties' expectations, however. By way of background, recall that a patent has several sections, including the claims. When a patent is enforced or infringed, it is the claims that are enforced or infringed. Utility patent applications are filed with an initial set of claims (as distinguished from provisional applications, which need not include claims), but the claims can be completely changed during the course of the prosecution (provided that the new claims are supported by the specification section of the patent application). In fact, during prosecution, the Patent and Trademark Office (PTO) generally will reject or require changes to the claims as originally filed in order to allow the application to mature to an issued patent. In addition, the party prosecuting the application may introduce new subsets of claims during the two or three years that it typically takes a software or business process patent to issue.
If one party (either the vendor or the customer) controls the prosecution, it is possible for that party, intentionally or not, to over time change the claims in a way that favors it and disfavors the other party. In addition, it is conceivable that the party controlling prosecution could draft the claims more narrowly in a jointly owned application than it would if it were to be the sole owner of the patent precisely because the patent will be jointly owned with another party.
Accordingly, a party interested in preserving benefits of joint patent ownership must take the long view and stay involved during the full period of patent prosecution. This is often a challenge as the two-year, or three-year, or even longer prosecution process may outlast the software development project. This party and its own patent counsel will need to have the right to approve claim changes and other filings with the PTO. Obtaining mutual agreement on all prosecution filings can prove difficult, especially as each party pursues its own agenda. An agreement to joint decision making during the course of prosecution does not mean that the resulting patent will be equally beneficial to each party. Therefore, once a decision to jointly own the patent is made, the parties need to carefully manage the patent process. It needs to be made an important part of long-term contract administration handled by qualified lawyers who must monitor prosecution developments.
LIMITING LICENSE RIGHTS FOR JOINTLY OWNED INTELLECTUAL PROPERTY
A related issue concerns the parties' respective rights to license a jointly owned patent. A party that is the sole owner of a patent probably would not license it to its competitor. However, if the same patent is jointly owned, the other owner might license it to the first party's competitor. This is because the scope of license rights was not addressed when the parties agreed to joint ownership in the contract and because the licensing could not occur until the patent issued several years after the contract was signed, and this is probably several years after the software development project ended. Thus, in addition to ownership, each party needs to focus on, and perhaps limit, the scope of license rights that the other party will have. These license restrictions need to be determined at the beginning of the development agreement even though such license rights will not be exercised until years later.
Joint owners of a copyright also have the right to independently grant non-exclusive licenses. Jointly owned copyright in important software presents the same licensing issues and also should be addressed when the contract is being drafted. It is important to note that copyright authorship is different from patent inventorship; it is possible that an invention relating to the software can be jointly owned, while the copyright in the software will not, or vice versa. As a result, the agreement must treat patents and copyrights separately.
LAWYERS SHOULD DRAFT TECHNICAL SCHEDULES
In complex software licensing and software development projects, as well as outsourcing arrangements, the transaction documents initially will consist of a master agreement and a series of schedules, project plans, and other documents. Later, the parties will enter into various statements of works and amendments to govern new work. Litigations arising from these agreements are often factintensive and involve the definition of the parties' obligations, software functionality, the exact scope of outsource services, and whether performance justified payment and at what price. These issues are governed in many cases by service level schedules, statements of works, and other technical documents. Because of the litigation impact of these documents, there is a danger in having them drafted solely by technical personnel. For this reason, it is important that lawyers draft these documents even though they cover technical subject matter and that the lawyers understand this subject matter or work closely with experts who do.
PROPER RELATIONSHIP BETWEEN MASTER AGREEMENT AND STATEMENTS OF WORK
The transaction documents for complex software and outsourcing agreements typically consist of a master agreement; a set of specialized schedules or sub-agreements, such as service level agreements; price documents; maintenance and support agreements; security schedules; and so forth. Later on, the parties will enter into various statements of work and project plans to implement the next phases of the project. The lawyers for the vendor and customer will have carefully negotiated the master agreement. The real-world danger is that the subsequent documents will undue the balance of rights that were so carefully negotiated there.
This often happens because the vendor tenders its standard form statement of work forms to the customer's technical (as opposed to legal) staff, the technical staff signs the form because it focuses on technical matters, and ignores the legal provisions. The result is that the new form undoes the concessions that the customer's lawyer was able to skillfully negotiate in the master agreement. (Note that it is not always the vendor's form that causes this. Large users also have their own standard forms, and use of these can cause the same result in reverse.)
The way to protect against this is somewhat counterintuitive: The first document, not the last document, should govern. Thus, the master agreement should provide that, in the event of a conflict with subsequent transaction document, the master agreement should control. This is especially important with respect to "master" provisions, such as representations and warranties, indemnities, intellectual property ownership, limitation of liability, and the like. Exceptions may be appropriate for changes in price or adjustments in service levels, but the basic principle is to protect the careful balance of negotiated rights from being undone when lawyers are not involved.
SEPARATE CONFIDENTIALITY AGREEMENTS
Entering into a separate confidentiality agreement instead of including confidentiality and non-disclosure provisions in a master agreement can provide several advantages. First, it can make it easier for the aggrieved party to obtain a judicial remedy for a breach of a confidentiality obligation. A separate agreement can put a simple, focused dispute before the court and reduce the opportunity for the defendant to cloud the wrongful-disclosure issues by introducing potentially irrelevant counterclaims going to an alleged breach of the main agreement that would be more readily introduced if the confidentiality provisions were part of a single contract.
Second, it can take a long time for parties to negotiate the master agreements. In the mean time, they will be exchanging confidential information (as part of the RFP process, for example). The vendor will disclose proprietary technology and the customer will disclose its business plans, including possible deficiencies in its current operations. In many cases, the customer will be negotiating with several potential vendors, in which case it will be necessary to protect the confidentiality of the information disclosed to the semifinalists who are not ultimately selected. Thus, a comprehensive confidentiality agreement entered into before the master agreement is executed can protect the pre-contract disclosures, the disclosures made during the initial phase of the contract beginning after execution, and disclosures made under agreements other than the master agreement, such as project plans and statements of work entered into in future phases of the project. As with the master agreement, the confidentiality agreement should be drafted to prevail over any inconsistent provisions in future statements of work and so forth to preserve the careful balance of rights negotiated by the attorneys at the beginning of the relationship. (This should include the proper treatment of personally identifiable information).
Third, in the RFP process when multiple vendors are bidding for the contract, each vendor runs the risk that the proprietary information disclosed to the customer will be disclosed to its competitors during the selection process. Having this information covered by the confidentiality agreement can protect the vendor. Confidentiality agreements with potential or actual subcontractors also may be needed.
Finally, the customer should have the confidentiality agreement cover evaluations and reports made by the vendor of the customer's operations. As noted, the customer may be entering into the agreement to transform its business operations. It will not want its customers and competitors to know of any weaknesses in its technology or business practices. A customer also may want to keep improvements confidential because the new technology offers a competitive advantage. Improvements in intellectual property should be protected for the same reason. Similarly, a vendor may wish to have reports kept confidential that indicate deficiencies in its technology or outsourcing operations.
PUBLISHED IP AND CONFIDENTIALITY
A related issue regarding confidentiality concerns published intellectual property. Commonly used confidentiality agreements generally cover intellectual property. However, the recipient of another party's intellectual property may take the position that issued patents and other publicly available IP of the disclosing party are either subject to the standard confidentiality exceptions or should be excluded by contract from confidentiality obligations. Foreign patent applications (including foreign counterparts of US applications), and under a relatively recent change to US patent laws, US patent applications (subject to certain exceptions) will be published 18 months after the first filing date. Even though the applications are published in official government patent publications, it can be argued that they are not readily available to the public. Because of this, the party owning the application may wish to require by contract that the recipient not disclose the application or the subject matter thereof. Moreover, in a multiyear contract, both parties may wish to maintain the confidentiality of applications published during the term, especially if the patent rights are jointly owned.
MAINTENANCE DISPUTES
A risk that a customer runs is that the vendor will cut off maintenance and support during the pendency of a payment or other dispute. This can place undue leverage in the hands of the vendor when the payment was withheld because of its failure to meet required performance levels. Courts are often reluctant to grant injunctions when affirmative relief is sought. A solution to this is to have the customer frame the relief sought not as a request for an extraordinary affirmative remedy but as a request that the status quo be maintained while the dispute is being resolved. The customer should anticipate this eventuality and draft the contract, including the maintenance and support obligations, to support this position. The customer can further support this by showing that members of the public at large, who happen to be its customers, will be the ones injured if maintenance is allowed to be suspended. For example, a bank could argue that the public interest would be harmed if ATMs were temporarily withdrawn from service when service withdrawal avoidable. Courts are also reluctant to order parties to work together when human anguish will result. A sizable vendor will be providing support and maintenance services to a number of customers on a one-to-many basis. The customer can argue that no human anguish will result if the vendor is required to provide it with support because little additional work is required to provide remote services to the customer as well as to the vendor's other licensees.
TECHNOLOGY ESCROW
Traditional source code escrow arrangements should be converted to full-bodied technology escrow arrangements. The party seeking the protection of the escrow should take the long view and carefully consider what materials it will need to support the technology that it is acquiring. In addition to placing source code (in fully commented form, or course) in escrow, the escrow should include design documents, protocols, test programs, certain software tools, diagnostics, maintenance and support tools, and similar materials. The customer also may want to use any knowledge base developed to maintain the software placed in escrow. This knowledge base (as well as other deliverables) should be in a technology-neutral format so that it can be used without the vendor's proprietary software.
A problem with source code released from escrow is that it often consists of hundreds of feet of magnetic tape or hundreds of pages of program listings. This can make the protection afforded by escrow somewhat illusory (even assuming that the escrow has been updated with new versions of the code as they are released). As a practical matter, it will be difficult for a party who obtains the source code from escrow to locate the actual lines of code that contain the programming problem that the escrow is meant to address.
A solution to this problem is to go one step beyond the source code and place the names and addresses of the programmers themselves in escrow. The programmers who are best able to fix the code are the ones who wrote it, and they can be made available. Any restriction in the agreement against hiring the programmers must be modified to permit such hiring by the customer in a bankruptcy or similar situation that triggers the release of the source code from escrow. The party obtaining the release from escrow also will need an intellectual property license to make derivative works of the code.
EMPLOYEE BACKGROUND CHECKS
The events of 9/11 also highlight the risk that programmers can sabotage code and introduce errors into the customer's system that cause potentially significant malfunctions. This risk may be increased in outsource agreements when software is written in foreign countries. Similarly, code can be written that allows unauthorized access to a customer's confidential information, and this can include the credit card numbers and other sensitive data belonging to the customer's customers. One way to address this risk is to conduct background checks on the programmers before they are hired or assigned to the customer's project. In addition, the software can be verified by a third party or checked by the customer before it is implemented in a live environment.
TEN KEY FACTORS FOR SUCCESSFUL SOFTWARE AND OUTSOURCING AGREEMENTS
In addition to the updating the contractual provisions discussed above, the following core factors are necessary for successful information technology agreements in today's business environments.
Clear Description of Software's Functionality. A customer needs the scope and description of the functionality of the software and services to be clear, complete, and unambiguous.
Meaningful Acceptance Criteria. Acceptance criteria should be objective, rigorous, and tailored to the needs of the customer. It should be possible to fail the test, quantify the failure, and determine what changes are required to pass the retest.
Meaningful Service Levels. A service level is the level of service that the software will provide. Service levels are often expressed in percentage terms. For example, a contract may require a service level of 100 transactions per second 95 percent of the time. A common mistake is to ignore the other 5 percent of the time. The contract should impose a service level on that remaining percentage; otherwise, the exception could provide a large whole for in performance obligations.
Accurate Metrics. Metrics are the standards and other criteria used to measure the performance of the software and related services. Continuing with the example in number three, the metric would be the criteria used to determine whether the software processes 100 transactions 95 percent of the time.
Meaningful Service-Level Credits. These credits are payments, offsets, or other forms of compensation that a vendor is obligated to pay the customer when it the software fails to meet service levels. These payments are what put teeth in service-level obligations.
Maintenance and Support Levels and Response Times. The safest assumption for the customer to make is that software or outsource services will not work completely. To compensate, the customer must receive complete and timely maintenance and support services with proper escalation provisions to be sure that the appropriately skilled vendor employees resolve the problems.
Avoid Too Much Shared Responsibility. To the extent possible, functions should be the responsibility of either one party or the other. If functions must be shared (for example, first-level support provided by the customer and higher levels of support provided by the vendor), then the demarcation lines should be drawn cleanly. When no one party is responsible, the task often will not get done properly.
Avoid Uncoordinated Amendments. A danger in complex information technology licensing transactions is that, over time, the collection of statements of work, work orders, amendments, and the like introduce inconsistent provisions with the result in extreme cases that it is not clear what the contract requires.
Avoid Paying Too Much Money Upfront. Paying most of the fees at the beginning of the contract reduces the customer's leverage, and in some cases, the key vendor employees will be assigned to other customers.
Termination Rights and Transition Services. A customer will want the right to terminate the agreement both for cause and for convenience. Termination for convenience is an important remedy when the customer downsizes or reduces the scope of the project. A customer will want the right to transition the software or services in house or to another vendor. The vendor will want to be paid for these services. The customer may consider paying a premium for transition services in order to obtain the benefit of an orderly transition.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Source:http://articles.corporate.findlaw.com
Key provisions in software license and outsourcing agreements should be revisited and updated in light of the events of 9/11 and changes in privacy laws, intellectual property practices, and the business purposes of information technology projects. Central to this is the use of technology to implement business transformation, that is, the use of software and outsourcing to improve, or transform, a company's business operations.
An example of business transformation could be taken from the use of a manual system to order custom products in the retail industry. Let us assume that the use of manual orders causes in salesmen to miscode forms and that the volume of handwritten paperwork causes manufacturing mistakes at the factory. If the manual system were replaced by software and the software prevented miscoding and its automated order placement prevented factory mistakes, then the number of products that would have to be discarded or returned would be greatly reduced. In this case, the improvement in business operations, at both the retail store and the factory, is included in the software. The business transformation is embodied in the adoption of the new technology.
The topics covered by this article are also important even if business transformation is not the primary purpose of the IT transaction. For such cases, this article provides updated licensing techniques. Among other topics, this article covers: (1) the changes required in confidentiality agreements to accommodate the privacy of personal information; (2) rethinking the purpose of force majeure provisions in light of 9/11; (3) the potential problems of using joint ownership as a solution for intellectual property rights; (4) the impact of statements of work on litigated disputes; (5) having master agreements control over subsequent transactions documents; (6) the advantages of placing confidentiality obligations in a separate agreement; (7) framing a motion for an injunction to require the vendor to provide maintenance during a dispute as a motion to maintain the status quo rather than as a request for an extraordinary affirmative remedy; (8) converting source code escrow to technology escrow (including placing the names of the programmers in escrow); and (9) requiring employee background checks as protection against software sabotage. The article concludes with a discussion of the core factors necessary for successful outsourcing or software licensing agreement.
MODIFYING CONFIDENTIALITY AGREEMENTS TO PROTECT PERSONAL INFORMATION
New privacy law regimes and the business need for a software or outsourcing customer to protect the personally identifiable information (PII) in its possession require changes in standard confidentiality agreements. The PII can belong to the customer's customers, its employees, business partners, and others. In the United States, the new privacy laws include Graham-Leach-Bliley for financial information, the Children's Online Privacy Protection Act for online sales to children, and the Health Insurance Portability Protection Act for personal health information. Elsewhere, new privacy legislation includes the European Directive on the Protection of Individuals with regard to the Processing of Personal Data and on the Free Movement of such Data in EU member states, the Canadian Personal Information Protection and Electronic Documents Act, and Australian Federal Privacy Act.
Standard confidentiality agreements were generally written to protect trade secrets and other proprietary business information and to exclude publicly available information from nondisclosure obligations. These confidentiality agreements need to be revisited because they were not written to cover PII entrusted to a party. A company that is a customer in a software license or outsourcing transaction will want the vendor to keep PII confidential. It will argue that, because it has an obligation to do so, so does the vendor that acts as its agent. The vendor, however, may argue that it has no confidentiality obligation because the PII fits within the exception for public information. This is because personal information such as home addresses is technically available to the public in the county clerk's office and other similar sources. To protect its business interests and to avoid possible liability under privacy regulations, the customer will insist on an exception to the exception to prevent the disclosure of PII.
In some cases, a vendor may have already received the same PII in its possession, and it may have received the consent of the owner, as is available under privacy laws, to disclose that information. This can occur, for example, when the vendor is a large institution that licenses software to this particular customer but provides data processing or outsourcing services to other customers and has the right to disclose the PII for those purposes. As a result, the vendor will require the right to disclose PII that it has independently received, even if the same PII is the incidental possession of the customer, in order to preserve the rights it previously obtained for that information.
COMBINING FORCE MAJEURE AND BUSINESS CONTINUITY PLANS
An issue highlighted by 9/11 is the need to rethink the purpose of force majeure provisions. I suggest that force majeure provisions be combined and coordinated with disaster recovery and business continuation provisions. Disaster recovery and business continuation plans are meant to operate when certain force majeure events occur. The force majeure provision should not operate to relieve the vendor of the obligation to perform. While force majeure events might reduce the obligations of the vendor, they should not eliminate them. Instead, the contract should identify certain foreseeable events and delineate what the vendor's obligations should be (even if reduced) when those events occur. Put another way, the contact should require the vendor do be part of the disaster recovery and business continuation process. In essence, the contract should specify the acts the vendor is to take in the event of particular force majeure events instead of simply excusing vendor performance.
POTENTIAL PROBLEM WITH JOINT OWNERSHIP OF PATENT RIGHTS
One difficult intellectual property issue that arises in software development and outsourcing agreements concerns the ownership of improvements and new inventions, especially those created as a result of joint or collaborative effort of the vendor and customer. A common contractual provision provides that the parties will jointly own the patents that result from jointly developed inventions. The practicalities of patent prosecution can confound the parties' expectations, however. By way of background, recall that a patent has several sections, including the claims. When a patent is enforced or infringed, it is the claims that are enforced or infringed. Utility patent applications are filed with an initial set of claims (as distinguished from provisional applications, which need not include claims), but the claims can be completely changed during the course of the prosecution (provided that the new claims are supported by the specification section of the patent application). In fact, during prosecution, the Patent and Trademark Office (PTO) generally will reject or require changes to the claims as originally filed in order to allow the application to mature to an issued patent. In addition, the party prosecuting the application may introduce new subsets of claims during the two or three years that it typically takes a software or business process patent to issue.
If one party (either the vendor or the customer) controls the prosecution, it is possible for that party, intentionally or not, to over time change the claims in a way that favors it and disfavors the other party. In addition, it is conceivable that the party controlling prosecution could draft the claims more narrowly in a jointly owned application than it would if it were to be the sole owner of the patent precisely because the patent will be jointly owned with another party.
Accordingly, a party interested in preserving benefits of joint patent ownership must take the long view and stay involved during the full period of patent prosecution. This is often a challenge as the two-year, or three-year, or even longer prosecution process may outlast the software development project. This party and its own patent counsel will need to have the right to approve claim changes and other filings with the PTO. Obtaining mutual agreement on all prosecution filings can prove difficult, especially as each party pursues its own agenda. An agreement to joint decision making during the course of prosecution does not mean that the resulting patent will be equally beneficial to each party. Therefore, once a decision to jointly own the patent is made, the parties need to carefully manage the patent process. It needs to be made an important part of long-term contract administration handled by qualified lawyers who must monitor prosecution developments.
LIMITING LICENSE RIGHTS FOR JOINTLY OWNED INTELLECTUAL PROPERTY
A related issue concerns the parties' respective rights to license a jointly owned patent. A party that is the sole owner of a patent probably would not license it to its competitor. However, if the same patent is jointly owned, the other owner might license it to the first party's competitor. This is because the scope of license rights was not addressed when the parties agreed to joint ownership in the contract and because the licensing could not occur until the patent issued several years after the contract was signed, and this is probably several years after the software development project ended. Thus, in addition to ownership, each party needs to focus on, and perhaps limit, the scope of license rights that the other party will have. These license restrictions need to be determined at the beginning of the development agreement even though such license rights will not be exercised until years later.
Joint owners of a copyright also have the right to independently grant non-exclusive licenses. Jointly owned copyright in important software presents the same licensing issues and also should be addressed when the contract is being drafted. It is important to note that copyright authorship is different from patent inventorship; it is possible that an invention relating to the software can be jointly owned, while the copyright in the software will not, or vice versa. As a result, the agreement must treat patents and copyrights separately.
LAWYERS SHOULD DRAFT TECHNICAL SCHEDULES
In complex software licensing and software development projects, as well as outsourcing arrangements, the transaction documents initially will consist of a master agreement and a series of schedules, project plans, and other documents. Later, the parties will enter into various statements of works and amendments to govern new work. Litigations arising from these agreements are often factintensive and involve the definition of the parties' obligations, software functionality, the exact scope of outsource services, and whether performance justified payment and at what price. These issues are governed in many cases by service level schedules, statements of works, and other technical documents. Because of the litigation impact of these documents, there is a danger in having them drafted solely by technical personnel. For this reason, it is important that lawyers draft these documents even though they cover technical subject matter and that the lawyers understand this subject matter or work closely with experts who do.
PROPER RELATIONSHIP BETWEEN MASTER AGREEMENT AND STATEMENTS OF WORK
The transaction documents for complex software and outsourcing agreements typically consist of a master agreement; a set of specialized schedules or sub-agreements, such as service level agreements; price documents; maintenance and support agreements; security schedules; and so forth. Later on, the parties will enter into various statements of work and project plans to implement the next phases of the project. The lawyers for the vendor and customer will have carefully negotiated the master agreement. The real-world danger is that the subsequent documents will undue the balance of rights that were so carefully negotiated there.
This often happens because the vendor tenders its standard form statement of work forms to the customer's technical (as opposed to legal) staff, the technical staff signs the form because it focuses on technical matters, and ignores the legal provisions. The result is that the new form undoes the concessions that the customer's lawyer was able to skillfully negotiate in the master agreement. (Note that it is not always the vendor's form that causes this. Large users also have their own standard forms, and use of these can cause the same result in reverse.)
The way to protect against this is somewhat counterintuitive: The first document, not the last document, should govern. Thus, the master agreement should provide that, in the event of a conflict with subsequent transaction document, the master agreement should control. This is especially important with respect to "master" provisions, such as representations and warranties, indemnities, intellectual property ownership, limitation of liability, and the like. Exceptions may be appropriate for changes in price or adjustments in service levels, but the basic principle is to protect the careful balance of negotiated rights from being undone when lawyers are not involved.
SEPARATE CONFIDENTIALITY AGREEMENTS
Entering into a separate confidentiality agreement instead of including confidentiality and non-disclosure provisions in a master agreement can provide several advantages. First, it can make it easier for the aggrieved party to obtain a judicial remedy for a breach of a confidentiality obligation. A separate agreement can put a simple, focused dispute before the court and reduce the opportunity for the defendant to cloud the wrongful-disclosure issues by introducing potentially irrelevant counterclaims going to an alleged breach of the main agreement that would be more readily introduced if the confidentiality provisions were part of a single contract.
Second, it can take a long time for parties to negotiate the master agreements. In the mean time, they will be exchanging confidential information (as part of the RFP process, for example). The vendor will disclose proprietary technology and the customer will disclose its business plans, including possible deficiencies in its current operations. In many cases, the customer will be negotiating with several potential vendors, in which case it will be necessary to protect the confidentiality of the information disclosed to the semifinalists who are not ultimately selected. Thus, a comprehensive confidentiality agreement entered into before the master agreement is executed can protect the pre-contract disclosures, the disclosures made during the initial phase of the contract beginning after execution, and disclosures made under agreements other than the master agreement, such as project plans and statements of work entered into in future phases of the project. As with the master agreement, the confidentiality agreement should be drafted to prevail over any inconsistent provisions in future statements of work and so forth to preserve the careful balance of rights negotiated by the attorneys at the beginning of the relationship. (This should include the proper treatment of personally identifiable information).
Third, in the RFP process when multiple vendors are bidding for the contract, each vendor runs the risk that the proprietary information disclosed to the customer will be disclosed to its competitors during the selection process. Having this information covered by the confidentiality agreement can protect the vendor. Confidentiality agreements with potential or actual subcontractors also may be needed.
Finally, the customer should have the confidentiality agreement cover evaluations and reports made by the vendor of the customer's operations. As noted, the customer may be entering into the agreement to transform its business operations. It will not want its customers and competitors to know of any weaknesses in its technology or business practices. A customer also may want to keep improvements confidential because the new technology offers a competitive advantage. Improvements in intellectual property should be protected for the same reason. Similarly, a vendor may wish to have reports kept confidential that indicate deficiencies in its technology or outsourcing operations.
PUBLISHED IP AND CONFIDENTIALITY
A related issue regarding confidentiality concerns published intellectual property. Commonly used confidentiality agreements generally cover intellectual property. However, the recipient of another party's intellectual property may take the position that issued patents and other publicly available IP of the disclosing party are either subject to the standard confidentiality exceptions or should be excluded by contract from confidentiality obligations. Foreign patent applications (including foreign counterparts of US applications), and under a relatively recent change to US patent laws, US patent applications (subject to certain exceptions) will be published 18 months after the first filing date. Even though the applications are published in official government patent publications, it can be argued that they are not readily available to the public. Because of this, the party owning the application may wish to require by contract that the recipient not disclose the application or the subject matter thereof. Moreover, in a multiyear contract, both parties may wish to maintain the confidentiality of applications published during the term, especially if the patent rights are jointly owned.
MAINTENANCE DISPUTES
A risk that a customer runs is that the vendor will cut off maintenance and support during the pendency of a payment or other dispute. This can place undue leverage in the hands of the vendor when the payment was withheld because of its failure to meet required performance levels. Courts are often reluctant to grant injunctions when affirmative relief is sought. A solution to this is to have the customer frame the relief sought not as a request for an extraordinary affirmative remedy but as a request that the status quo be maintained while the dispute is being resolved. The customer should anticipate this eventuality and draft the contract, including the maintenance and support obligations, to support this position. The customer can further support this by showing that members of the public at large, who happen to be its customers, will be the ones injured if maintenance is allowed to be suspended. For example, a bank could argue that the public interest would be harmed if ATMs were temporarily withdrawn from service when service withdrawal avoidable. Courts are also reluctant to order parties to work together when human anguish will result. A sizable vendor will be providing support and maintenance services to a number of customers on a one-to-many basis. The customer can argue that no human anguish will result if the vendor is required to provide it with support because little additional work is required to provide remote services to the customer as well as to the vendor's other licensees.
TECHNOLOGY ESCROW
Traditional source code escrow arrangements should be converted to full-bodied technology escrow arrangements. The party seeking the protection of the escrow should take the long view and carefully consider what materials it will need to support the technology that it is acquiring. In addition to placing source code (in fully commented form, or course) in escrow, the escrow should include design documents, protocols, test programs, certain software tools, diagnostics, maintenance and support tools, and similar materials. The customer also may want to use any knowledge base developed to maintain the software placed in escrow. This knowledge base (as well as other deliverables) should be in a technology-neutral format so that it can be used without the vendor's proprietary software.
A problem with source code released from escrow is that it often consists of hundreds of feet of magnetic tape or hundreds of pages of program listings. This can make the protection afforded by escrow somewhat illusory (even assuming that the escrow has been updated with new versions of the code as they are released). As a practical matter, it will be difficult for a party who obtains the source code from escrow to locate the actual lines of code that contain the programming problem that the escrow is meant to address.
A solution to this problem is to go one step beyond the source code and place the names and addresses of the programmers themselves in escrow. The programmers who are best able to fix the code are the ones who wrote it, and they can be made available. Any restriction in the agreement against hiring the programmers must be modified to permit such hiring by the customer in a bankruptcy or similar situation that triggers the release of the source code from escrow. The party obtaining the release from escrow also will need an intellectual property license to make derivative works of the code.
EMPLOYEE BACKGROUND CHECKS
The events of 9/11 also highlight the risk that programmers can sabotage code and introduce errors into the customer's system that cause potentially significant malfunctions. This risk may be increased in outsource agreements when software is written in foreign countries. Similarly, code can be written that allows unauthorized access to a customer's confidential information, and this can include the credit card numbers and other sensitive data belonging to the customer's customers. One way to address this risk is to conduct background checks on the programmers before they are hired or assigned to the customer's project. In addition, the software can be verified by a third party or checked by the customer before it is implemented in a live environment.
TEN KEY FACTORS FOR SUCCESSFUL SOFTWARE AND OUTSOURCING AGREEMENTS
In addition to the updating the contractual provisions discussed above, the following core factors are necessary for successful information technology agreements in today's business environments.
Clear Description of Software's Functionality. A customer needs the scope and description of the functionality of the software and services to be clear, complete, and unambiguous.
Meaningful Acceptance Criteria. Acceptance criteria should be objective, rigorous, and tailored to the needs of the customer. It should be possible to fail the test, quantify the failure, and determine what changes are required to pass the retest.
Meaningful Service Levels. A service level is the level of service that the software will provide. Service levels are often expressed in percentage terms. For example, a contract may require a service level of 100 transactions per second 95 percent of the time. A common mistake is to ignore the other 5 percent of the time. The contract should impose a service level on that remaining percentage; otherwise, the exception could provide a large whole for in performance obligations.
Accurate Metrics. Metrics are the standards and other criteria used to measure the performance of the software and related services. Continuing with the example in number three, the metric would be the criteria used to determine whether the software processes 100 transactions 95 percent of the time.
Meaningful Service-Level Credits. These credits are payments, offsets, or other forms of compensation that a vendor is obligated to pay the customer when it the software fails to meet service levels. These payments are what put teeth in service-level obligations.
Maintenance and Support Levels and Response Times. The safest assumption for the customer to make is that software or outsource services will not work completely. To compensate, the customer must receive complete and timely maintenance and support services with proper escalation provisions to be sure that the appropriately skilled vendor employees resolve the problems.
Avoid Too Much Shared Responsibility. To the extent possible, functions should be the responsibility of either one party or the other. If functions must be shared (for example, first-level support provided by the customer and higher levels of support provided by the vendor), then the demarcation lines should be drawn cleanly. When no one party is responsible, the task often will not get done properly.
Avoid Uncoordinated Amendments. A danger in complex information technology licensing transactions is that, over time, the collection of statements of work, work orders, amendments, and the like introduce inconsistent provisions with the result in extreme cases that it is not clear what the contract requires.
Avoid Paying Too Much Money Upfront. Paying most of the fees at the beginning of the contract reduces the customer's leverage, and in some cases, the key vendor employees will be assigned to other customers.
Termination Rights and Transition Services. A customer will want the right to terminate the agreement both for cause and for convenience. Termination for convenience is an important remedy when the customer downsizes or reduces the scope of the project. A customer will want the right to transition the software or services in house or to another vendor. The vendor will want to be paid for these services. The customer may consider paying a premium for transition services in order to obtain the benefit of an orderly transition.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Source:http://articles.corporate.findlaw.com
Tuesday, June 01, 2004
Security is a major issue in outsourcing
When it comes to outsourcing, security is a must, not an option.
Outsourcing involve to significant extent transmitting corporate data sometimes to and from halfway across the globe. Technology and the Internet makes it possible, for example, for a US company processing credit card transactions to send information across to India.
It only makes sense for a client to demand from a service provider that the they make sure no sensitive information is in danger of being "leaked" to outside parties.
META Group includes data security and protection as among the top 10 risks to offshore outsourcing.
A Gartner analyst, meanwhile, stressed the importance of security, and understanding the risks involved, during the early stages of negotiations for an outsourcing deal especially those which involved offshore work.
On the part of the client, this means a more pro-active role from its technical staff.
Gartner recommends that a company's security staff should be included in the operations management functions, working with the service provider's delivery management staff.
Not only should they be concerned with security alone, they should also be involved in strategic planning when standards, architecture and integration decisions are made.
Gartner recommends that large enterprises audit prospective enterprise service providers to ensure the policy and control of outsourced functions or systems meet the enterprise's security standards.
Companies unable to do so are advised to hire a third-party company to do an independent audit.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
When it comes to outsourcing, security is a must, not an option.
Outsourcing involve to significant extent transmitting corporate data sometimes to and from halfway across the globe. Technology and the Internet makes it possible, for example, for a US company processing credit card transactions to send information across to India.
It only makes sense for a client to demand from a service provider that the they make sure no sensitive information is in danger of being "leaked" to outside parties.
META Group includes data security and protection as among the top 10 risks to offshore outsourcing.
A Gartner analyst, meanwhile, stressed the importance of security, and understanding the risks involved, during the early stages of negotiations for an outsourcing deal especially those which involved offshore work.
On the part of the client, this means a more pro-active role from its technical staff.
Gartner recommends that a company's security staff should be included in the operations management functions, working with the service provider's delivery management staff.
Not only should they be concerned with security alone, they should also be involved in strategic planning when standards, architecture and integration decisions are made.
Gartner recommends that large enterprises audit prospective enterprise service providers to ensure the policy and control of outsourced functions or systems meet the enterprise's security standards.
Companies unable to do so are advised to hire a third-party company to do an independent audit.
Sitemap
Ecommerce
Financial
B2B
Free Evaluation
Subscribe to:
Posts (Atom)