Build Buy Partner
•Télécharger en tant que PPT, PDF•
6 j'aime•8,456 vues
Build Buy Partner by Deborah and Noma
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Build Buy Partner
Similaire à Build Buy Partner (20)
Dernier
Dernier (20)
Build Buy Partner
- 1. Build, Buy, or Partner How To Speed Your Time to Market or So Many Choices, so Little Time Deborah Henken, Highland Team Norma Watenpaugh, Phoenix Consulting
- 2. NorCal PDMA 2 Agenda The Challenge of Product Management Build/Buy/Partner: Benefits and Tradeoffs Case Studies: Success and Failures Situation Analysis: What to do, When Partner Assessment and Readiness: Choose and Enable Successful Partners Recap: Build/Buy/Partner
- 3. NorCal PDMA 3 The Challenge of Product Management “Weneed awhole product solution; not point products” “The productneeds ananalytical tool” “Weneed Security featuresto be competitive” “We Need it NOW! My customerwon’t buy unlesswe havemanagementtools “We need a CRM Product”
- 4. NorCal PDMA 4 What is going on ? Create competitive differentiation Fill gap in product technology Offer a complete solution The Question: Build Buy Partner
- 5. NorCal PDMA 5 Sustaining Competitive Differentiation at BEA Application Server
- 6. NorCal PDMA 6 Build, Buy, Partner: Benefits and Tradeoffs BuildBuild BuyBuy PartnerPartner Time to Market & Control & Profit Cost&Risk Most product control Own the IP Most profit opportunity Longest time to market Risk in market shifts High development costs Highest switching costs Pros Cons Shorten time to market Own the IP Acquisition costs Integration costs Least Control Integration Costs Shared gross margins - Least Profit Opportunity Shortest Time to Market Conserves Resources Try before you Buy Lowest Switching Costs Credibility and access
- 7. NorCal PDMA 7 Why Build: Technology Leadership Pioneer in the field Patentable technology Need to own the intellectual property Core business Have time or can build in increments Have in-house expertise
- 8. NorCal PDMA 8 Why Buy: Core to business Core to business Need intellectual property Time critical Shortage of in- house expertise Acquire market leadership
- 9. NorCal PDMA 9 Why Partner: Speed Fastest Time to Market Reduce Risk Leap Frog Competition Customize for Specific Markets Customers buy best of breed
- 10. NorCal PDMA 10 Which horse to pick? Build Buy Partner Leadership Core Business Time to Market Reduce Risk
- 12. NorCal PDMA 12 MarketFirstOEMs BusinessObjects to addAnalytics toMarketingCampaigns Create Competitive Differentiation HP Buys Compaq To Broaden Product Line “Network Assoc. partners with Internet Security Systems to combat hybrid security threats” Vocent builds Voiceprint Authentication solutions Channel Wave and E.piphany integrate PRM and CRM
- 13. NorCal PDMA 13 Fill Gap In Technology HP OEMs Canon printers BEA partners withWebGain forapplicationdevelopment tools Sun OEMs Veritas for storage management Intuit andVerisignCollaborate toOffer Websitesolutions toSmallBusinesses PC Mfgs buy and assemble OS, chips, storage, etc
- 14. NorCal PDMA 14 Offer a Complete Solution: Whole Product Acquisition at PeopleSoft Red Pepper Mftg Supply Chain SkillsVillage Services Vantive CRM Advance Business Planning Intrepid Retailing TriMark Insurance Salem noM ftg Q uality Cam pus Soln Education Distinction Consumer Supply Chain TeamOne Integration Services PeoplPeopl eSofteSoft
- 15. Situation Analysis: Build, Buy or Partner Always Start with the Customer Whole Product Offering Product Adoption Lifecycle
- 16. NorCal PDMA 16© Frank Lynn & Associates, IDC What are They Buying? Source: IDC, High Performance Partnering Workshops Whole Product Offering Post- Sales Support Transactional Support Pre-Sales Support Integration Services Softw are Consulting Hardware The Product
- 17. NorCal PDMA 17 Elements of the whole product Consulting services System hardware System software Development tools Server applications Application development/ modification services PC/client hardware Desktop applications LAN products WAN connectivity products Systems integration services Training services Maintenance/support services Server hardware Client hardware Software Network © IDC Source: IDC, High Performance Partnering Workshops
- 18. NorCal PDMA 18 Whole Product Case Study (Build, Buy or Partner) –The Database Wars Informix/Oracle Wars: Whole Product Solution: Informix partners:1200 applications and tools partnerships Informix buys Illustra Oracle partners and builds applications IBM buys Informix Database Developmen t Tools Application Partners H a r d w a r e O E M sSystem Integrators C o n s u l t a n t s
- 19. NorCal PDMA 19 Product adoption life-cycle Time First time buyers Revenue Laggards 44 Late Majority 33 Early Majority 22 Innovators Early Adopters 11 “early market” 1 S.D.1 S.D. © IDC Source: IDC, High Performance Partnering Workshops
- 20. NorCal PDMA 20 Buyer motivation affects product decisions 11 “I will work with vendors of bleeding edge technologies, to fundamentally reshape my business or my competitive environment” “I will deploy proven technology to deliver services expected by my customers” 33 © IDC Source: IDC, High Performance Partnering Workshops “I will use stable but not yet common technology to develop a competitive advantage 2222 “I will buy commodity technology to cut costs” 44
- 21. NorCal PDMA 22 Partnering Requirements Time Innovators Early Majority Late Majority Laggards Early Adopters technical value-add End of life logistics value-add Goal: Bring product to market Reason to Partner: Building own product, fill in gaps in technology with partners Type of Partner: OEM, Technology co-development Goal: Penetrate market/win marketshare Reason to partner: Customize built product to specific market segments, whole-product, provide services Type of Partner: SIs, VARs Goal: Moving Volume Reason to Partner: Widespread market penetration Type of Partner: Distributors
- 22. NorCal PDMA 23 Partnering Examples Time Innovators Early Majority Late Majority Laggards Early Adopters technical value-add End of life logistics value-add Goal: Bring product to market RSA and Symbian develop a small footprint version of BSAFE for wireless OS Goal: Penetrate market/win marketshare ATG and PWC offer integrated solution for Insurance Industry Goal: Technology Revitalization Entrust and IBM enable mainframe OS with Internet PKI Goal: Penetrate market/win marketshare Moving to Volume Citrix launches Nfuse Elite -Industry’s first channel ready access portal server
- 23. Partner Assessment and Readiness Enable Successful Partners What to think about as the product moves from technical partnership to sales partnership Implications for the product
- 24. NorCal PDMA 25 Partner Assessment WIN-WIN-WIN Company stability — Do they have financial staying power? Do You ? Trustworthiness — Is there two way sharing of plans, openness? Strategic interests — Are you strategic to them and vice-versa? Strategic Fit — Are they capable of performing their role and you, yours ? Executional abilities — Will they be able to fulfill role on time and to spec, will you ?
- 25. NorCal PDMA 26 Partner Ready Checklist Business Model Technical Partners System I ntegrators VARs Distributors Needs Intellectual Property Dev Services Implement Services Margin/ Volume Technical Specs Product Documentation Early Access to Roadmaps Early Access to Product GA Access to Products Joint Eng Relationship Developer Support Installation/Config Service Designed in Service Technical Training Service Training Sales Training Marketing Support Packaging/Bundling
- 26. NorCal PDMA 27 Build, Buy, Partner: Strategies to Market Build: Technology Leadership Buy: Core to business & time is critical Partner: Fast time to market & reduce risk
- 27. NorCal PDMA 28 You’re OFF!
- 28. NorCal PDMA 29 Build, Buy, Partner Deborah Henken is President of Highland Team, a marketing management consulting company specializing in successful go-to-market strategies. Her team builds revenue enhancing strategic marketing, channel development and awareness and demand creation programs. Highland Team is an Authorized Implementation Consultant of the Global Software Partnering and Alliance of IDC, adding value to clients by accessing the specific services, research and analysts needed to build best practice partnering strategies and programs. Deborah has a BS from Northwestern University and an MBA from the Kellogg School at Northwestern University. She can be reached at www.highlandteam.com or dhenken@highlandteam.com. Norma Watenpaugh is the Principal of Phoenix Consulting Group, specializing in marketing for today’s challenging economy. Phoenix Consulting Group is an Authorized Implementation Partner of the Global Software Partnering and Alliance of IDC, complementing IDC’s research and analyst services with practical experience in partner strategy, program development and alliance management. Norma Watenpaugh can be reached at normaw@garlic.com.
Notes de l'éditeur
- What are the challenges faced ? What do product managers hear ? New products, added features, NOW Lots of demand on developers in response to competitive pressures, the drive to gain dominant market share, establishing technical leadership, and responding to customer needs.. So the bar is higher than ever on delivering And of course these demands need to be satisfied NOW!
- Product managers/engineers may realize they have a gap in building the technology and need to fill it Marketing or Sales may realize competitors have features that are causing loss of sales/ or that competition doesn’t have something the customers want. Need to play catch up or opportunity to leapfrog over competition and differentiate in customer’s mind. Marketing or sales or PM realize need new functionality in product or product line Analysts may tell leadership that customers demand more complete, integrated solution which extends beyond a company’s core product. A high value, risk reduced, whole product offer creates a sustainable market position. Interesting thing is that companies make different decisions at different times, use all three strategies. Ex: PeopleSoft acquires a CRM and other Enterprise applications. EXAMPLE: BEA has bought, built, partnered at various times
- BEA’s evolving product strategy is a case study that embraces all of the former objectives and means. In the beginning, BEA bought themselves into existence, buying products, engineers and distributors. They built on top of Tuxedo, then realized objects were going to change the landscape. Early 1998 BEA released a product of magnificant engineering. An object oriented application server based on the proven technologies of Tuxedo and the Corba standard. But it soon became clear that Java was fast becoming the programming paradigm of choice among developers. While Bea offered a “web” extender” and loosely partnered with the new style java web ap servers, it was clearly not how customers wanted to develop software in the Internet age. BEA was faced with some tough decisions: retool and retrain their engineers in Java and start over, Continue with partner strategy or acquire the technology.. Since the ap server market was clearly BEA’s technical domain, they had to own the IP and while their engineers were certainly smart enough, there wasn’t the time to start over. So they acquired. Late 1998 BEA acquires WebLogic and over time, it became the core of BEA’s product offering. BEA loosely partnered with complementary ISVs. For development tools, and other functionality. Early 2000 BEA repositions as a platform offering a complete integrated solution to web application development. Enterprises needed to connect with legacy applications and they needed to extend their applications to include customers, partners, and employees. BEA had developed some of this portal and an integration server in house but had to heavily rely on partners to complete the offer. Overtime, portfolio has changed as BEA moved up the value chain: Embeds RSA for Security HP Alliance to develop EAI adapters OEMed a workflow product Partners with WebGain to offer a Development environment Partners with many companies in Test & Deployment, Ops, Admin, Mgmt, Content Management Built the Portal, but partnered heavily for Portals Acquired Crossgain Not shown in this diagram is a community of other partners: Hardware, system partners SI’s Application ISVs who embed or Build on BEA (another build, buy, partner decision)
- Build: In house development Buy: Acquisition of technology Partnering: Resale of existing technology In part a buy decision; but you don’t own the Intellectual Property. Alliance partnering where you engage in light integration and joint go-to-market and selling strategies Buy or Partner only relevant if the technology exists. BEA example as why building can be risky—bet on CORBA, did not win in market. If industry standards are in flux and you are not a standard setter: partnering or buying may be a better strategy Informix/Illustra example of why Buying can be problem—market shifted-need for object database not as planned. HP/Canon –OEM partnering for laser jets In house development: offers the highest level architecture control and go-to-market strategy control but also highest exposure to competitive risks or changes in customer preferences due to the time to market issues. Buy model: technology acquisition. Initial time to market can be shortened with either resale or acquire. Costs of acquisition are of course higher than resale but may not be higher than product development. Product risks are less if you are diligent about acquiring proven technology. Once acquired, must make sure it works seamlessly with current product, spend time to develop into current product. Afterwards the risks and level of control are the same as the build model for continued investment in the product. Resale model inherits aspects of technology acquisition and in partnering. In a resale model the costs and technolgoy risks are much less and switching costs are moderate., but the trade off is in level of control of the product. Also, in resale mode, have to ensure sales knows how to sell, develop contracts, sales support plan, coordinate with other vendor. Alliance partnering is the low cost, low risk, and shortest time to market model. It also has the least control factor. Try before you buy. Fast speed to market, take advantage of partner’s development efforts, partner keeps the selling, sell as add-on, sales doesn’t have to learn product, can refer to current vendor who sells and supports. However, must do due diligence on company/product, since have least control over product/business. How to overcome “ religious” objections to partnering as company grows—Time is $$$$$, position in terms of revenue growth, revenues sooner, catching market as it emerges and grows. (Leaders get premium pricing, lower costs of sales, analyst attention, market awareness).
- Example: biotech companies No other companies doing what you are doing—pioneer, must build. If a product is core to your business (how you compete in the marketplace), you need the level of control of your destiny that comes with owning the intellectual property and determining its future course. Building and owning the IP gives the most control and also the most profit opportunity IF you have the time to get to market competitively. Clearly when a technology does not exist, you don’t have an option to buy and your only partnering option would be joint development. This may be an excellent choice when you need to supplement your own staff in expertise or capacity. An example: Amdahl and Sun traded code on early Unix development; Amdahl having mainframe experience with multi-processer scalability (remember Amdahl’s law) and other mainframe class features.
- Think Speed, Ownership. When technology/product is core to business and you want to own the intellectual property, yet you don’t have the expertise in house and time is of the essence, buying makes sense if there are other companies who have already spent the time and resources developing the technology. Partnering won’t work if company wants to own and have the technological leadership. Buying allows company to immediately being seen as having the expertise.
- 1.Partner when speed is important but products/services enhance your product, rather than being core to your business. You don’t need to own technology yourself. 2.You can partner to claim space in market or establish a competitive positioning while you build or evaluate a buy. 3.Reduce risk - especially if industry standards are in flux and you are not a standard setter i.e. Sun vs. Microsoft; 4.Market leaders are not clear and it is risky to make an acquisition bet. 5. Customers buy best of breed solutions, customer may buy some but not your entire product suite.You may have to partner with “competitors” to satisfy customer buying preferences and to reduce customer risk. Oracle + SAP even though a 100% Oracle sol’n is available.
- Companies partner, build and buy to gain competitive differentiation. Most recently, the purchase of Compaq by HP is an example of buying for competitive differentiation. Others partner, such as Network Associates announcing their work with Internet Security Systems to combat hybrid security threats on the internet and the network. Many companies in emerging markets would choose to build, such as biotech firms, currently, and this interesting firm, Vocent, which builds voice authentication solutions. Not just voice-activated, but actually knows if the voice has access to the solution, building, etc.
- HP OEMs Canon engines because: Quick entry into printer business rather than building their own PC manufacturers use Microsoft OS/Intel chips/ Quantum and Seagate disc drives rather than re-invest in building a better mousetrap—market leaders are already doing that, they just buy the components. BEA chose to partner with tools companies because valuation of platform companies are higher - but as it became clear the tools were part of the platform, BEA strategically partnered with WebGain, but eventually acquired Crossgain.
- PeopleSoft has gone through a series of acquisitions since 1998 to fill out both functional applications in their product strategy, but also vertical applications. Functional apps such Vantive for CRM, SkillsVillage for automating services. Verticals are Intrepid for retailing, Trimark -insurance and Campus solution for education.
- Let’s look at two methodologies for analyzing what to do in any situation :Build, Buy or Partner.
- <number> So if you start with your core product, referred to here in the circle,, in the IT industry it’s not likely to be the entirety of the end-user’s purchase. You must add to this the complementary products (software for a hardware product, hardware for a software product, telecommunications, etc.), and the services. Services such as consulting to develop the business objectives and requirements, and integration services to make the solution work. This we call the “solution”. But there’s still more to a product than that. The end-user needs to make sure that the product will work for them, or is the best match to their requirements. For a complex product, there will be a need for pre-sales support to properly configure, explain, size, etc. the product for each client. After the installation is made, there will also be a need for support services, and upgrades. Additionally, there is a need to support the transaction between the end-user and the seller, for things like financing, delivery, billing, etc. These final components are added to make what we call “the offering”. Or what is often referred to as the solution stack. No company has the capability to economically and competitively deliver the offering by themselves to all customer types. This of course, is one of the main reasons we use partners. So in each market segment, and for each product category, you need to understand the channels and alliances partners you need to bring the most competitive offering to market. You should build a template that segments your market, analyses buying behavior, and selects the partner types that can best “fill the gaps” in that segment. [Some customers don’t expect much support, other clients need a lot – it’s important to understand how this is packaged]
- <number> There are many products that can be added. Using the whole product model, companies need to decide which to buy/build or partner: Which would be a drain on company resources ? Which would slow time to market ? Which would be easy/difficult for sales to understand and sell ? Which would be better to buy or partner ? IDC NOTES: Let’s say you work for a software company that builds analytical tools for large volumes of data. How is your product typically deployed? Do you use consulting services to define the payback that can be achieved through data analysis? Will you solution require additional server hardware to do the necessary number crunching, database management, and data transfer? Will system software be required to manage to additional storage and backup requirements? Can the end-user take advantage of development tools that can enhance the capability of the solution by customizing it to the end-user’s needs? Are server applications, such as ETL (extract-transform-load) tools needed to support the gathering of data into a data warehouse? Will the end-user require Application development or modification services to do the customization? Is PC/client hardware required to support additional users or give more power to existing ones? Are there additional desktop applications that can enhance your solutions, and are there ones that apply to specific market segments? Is there a need for new or enhance network capability, that require LAN or WAN connectivity products? Will the services of a systems integrator be needed to make everything work together and perform the installations? Will the users and IT staff require training services to be able to use the solution? Who will perform the maintenance and support services on the entire solution? These are all questions a customer might ask, and all potential areas involved in a solution. Each one could represent a partnering opportunity or requirement to sell your product into a market segment. Each one could be an area where you are currently providing a product or solution that could be more profitably or successfully provided by a business partner, and may be draining resources from your core business. [How many of these would Dell provide to their customers?]
- In mid-90s,after growing quickly, Informix faced the following problem: Databases only have data, When applications are on them, you have information. People want information. Informix faced their core business changing but didn’t recognize it. Their solution was to partner with tool vendors and applications to provide more than the database. Partnering with influencers to have reference sales. Oracle on the other hand, partnered as well, while building their own applications, recognizing that the database was only going to be a secondary product in the decision-making on applications. (Since all the major applications must run on an Oracle database, they find themselves being both partners and competitors.) It took longer and more resources, but Oracle partnered to stay in the game, while building. In this case, building gave them the technological leadership they needed as the game changed. Another crucial decision- to buy an object oriented database. Informix bought Illustra. At the time, relational databases did not seem like a good choice for objects. People thought objects would use inheritance, and that is difficult to store in relational databases. In turned out that design turned from inheritance to inclusion, and relational databases were fine. Unfortunately, market did not move that way, illuminating an issue of building in emerging markets, standards may change. IBM acquired Informix to gain marketshare and to have a competitive challenge to Oracle.
- Use lifecycle as a model. Discuss how PMs can use lifecycle to understand where their product fits into the lifecycle, what kind of customers there are in each step and how it affects product needs and requirements as they move through the lifecycle. Sometimes product doesn’t start at beginning—company entering market during early adopter or majority, so can determine where product is when developing and what to do to match customer desires. Implications for products/implications for buy/build/partner IDC NOTES: The technology adoption life-cycle was developed by Everett Rodgers in the late 1950’s on how communities respond to discontinuous innovations. The peak of the bell curve bisects the customer community. The boundaries are at 1 std. deviation intervals. In 1964 Ted (somebody) from Harvard turned it into the “Product Life Cycle” Geoffrey Moore popularized the model in the early to mid 1990’s with three books: Crossing the Chasm Inside the Tornado (1995 - ISBN 0-88730-824-4) The Gorilla Game Question: What are the implication of technologies vs. product here? It shows the adoption of a technology or product over its life. Early on, the technology is used by those who think that they can gain a dramatic advantage over their competition through innovation. If the technology catches on, then it will be adopted by a large number of companies seeking to build advantage, then another large group will adopt the technology to catch up. Finally a smaller group who have lagged behind will gradually start to see the opportunity to use the technology once all the problems have been solved and the price has dropped to its lowest levels. The transition from “early adopters” to “early majority” is the place that Moore calls “the chasm”, which is the point at which a company either takes advantage of the rapidly growing adoption, or cedes the market to it’s competitors and/or a better technology or marketing strategy. The chasm applies to both to products and technologies. For the latter, some competitor comes along and takes the high-growth part of the life cycle from the company that introduced the innovation. Your strategy must change as the life-cycle progresses – so must your choice of partners. However, the model is also simplistic. There can be cycles within cycles, and cycles within market segments. Some life cycles are very short, others last indefinitely. The Revenue curve shows the resultant revenue stream (this is periodic, not cumulative) that would occur for a product which has frequent repeat purchases (Like the PC, for instance). The period of maximum revenue growth is in the early majority. If repeat purchases are not occurring, then the curve would head back toward zero. Without repeat purchases, it would be proportional to the adoption curve, but modified by the average sale value, which could well reduce significantly through the course of the life cycle. Geoffrey Moore definitions Innovators = Technology Enthusiasts Early Adopters = Visionaries Early Majority = Pragmatists Late Majority = Conservatives Laggards = Skeptics
- Motivations affect what buyers want from the products. 1. Innovators—can take some time to build, willing to work with vendor and partners to truly be innovative. Product need not be finished, stable, BETA testers. WANT PRODUCT CAPABILITY, FLEXIBILITY, TECHNICAL EXPERTISE 2. Early adopters—product should be more developed, more stable, willing to go with early proven products, work with vendor and partners to be competitive. Product must be stable, technical partnering important here. Can still take time to build products, but start to look at buying or partnering. WANT REFERENCES, EXPERIENCED PROFESSIONALS 3. Early majority—product needs to be more “whole”, market building, need fast time to market with new features. Products must be delivered quickly, very competitive marketplace Better to partner for new feature/functionality or competitive differentiation than to spend time building major new features. WANT PACKAGED SOLUTIONS, CHOICE OF SUPPLIERS, GOOD SERVICE, EASE OF INSTALLATION AND USE, PERFORMANCE GUARANTEES 4. Late majority: Need packaged product, must be packaged and integrated seamlessly with partner products/easy installation, support distributed by distributors-B to B, or mass merchants for B to C. LOW COSTS, EASE OF USE IDC NOTES: Early in the life cycle, buyers are motivated by the chance to innovate to gain a big advantage. The buyer is willing to assume a larger risk in return for a large potential reward. As the technology proves its worth, a larger group of buyers are willing to adopt it to gain business advantage. Once the technology is well-accepted, another large group (late majority), will adopt the technology out of fear of losing business to their competition. SAP in the late 90’s is an example of a product in this category. The laggard category adopts the technology once it becomes ubiquitous, low cost, and simple. This generally requires that the product itself be the solution, and can be used almost out-of-the box. Because of the different buyer characteristics, the requirements of the whole-product tend to be different, so the partner mix will need to be different.
- Technology is the most important at the beginning of the cycle. May build or partner. As cycle progresses, must build technology into product. As lifecycle develops, there is less need for technical partnering and more for logistics, customizing and distribution partnering. Channel marketing gets involved by early/late majority. Product development still involved, has to make product channel-friendly, decisions on adding new features and functionality, whether build, buy or partnering to do it.
- Let’s clarify the goals at each stage, what considerations at each stage for build, buy or partner decision and type of partners to consider, if not building or buying. As a product moves through the life-cycle, it tends to become better understood, and easier to use. This lowers both the sales and technical expertise required in the whole product. Early on, expertise in the technology, market and integration with complementary products is important, and will drive a large services component. Late in the cycle, moving volumes of product efficiently becomes dominant. Products need to be standardized, but “mass customization” through computers may be the key to success in moving your product to the late life cycle ahead of the competition – deriving early life cycle products and late life cycle volumes. In between, to drive a moderately customized product into a large and growing market, VARs are often used to provide customer intimacy and a local presence to smaller accounts. Products which become “legacy” – that is: users depend on them but there is declining sales volumes – may end up moving into “caretaker” mode, where services content begins to rise again to maintain aging systems in the customer environments that have not moved on to new technology. (this is outlined by Moore in his books, using CA as the prime example).
- Symbian was formed 1998 by Ericsson, Motorola, Nokia and Panasonic to set standards for mobile operating systems to enable a mass market. Marc Wice, VP of Product Management Symbian “ We knew from the onset that selection of a security vendor in the wireless space was critical to the success of our mission.” Challenge: full-strength encryption in a small footprint. By technical collaboration,RSA and Symbian can enable secure data access to web information with precisely the code size needed to performance without compromising security. By partnering with PWC, ATG gains access to a new market segment. PWC provides vertical industry access, integration services, ability to work with large clients in complex deals. Citrix claims: With simple, wizard-driven, installation and pre-configured roles, themes, and templates, Nfuse Elite will deliver on the promise of an “out-of-the box access portal. Product is available through Citrix 7000 VARs, Sis, ISVs and Distributors. Richard Schroeder, VP Consulting Services for Vector ESP “ To date, best of breed portal products have imposed implemenation complexities wan dpricing models which impeded Vector’s recommended approach: start small, gain incremental value, then accelerate. Entrust and IBM enable mainframes to keep up with the internet. Revitalizing and refreshing legacy technology to extend their useful life.
- Partner type follows progression of bell curve model. Business model shows how the partner adds value and drives revenue and therefore dictates the type of vendor support required. Early lifecycle partners need technology support and engineering relationships. As the partner types trend toward sales and marketing value, engineering support diminishes, services increase. These partners thrive on customer intimacy. Late cycle, technology is mature, service requirements are minimal and partners need marketing and sales support.