[I wrote this back in 2011 on my old blog and recently needed to reference it so decided to migrate it here and make some small tweaks.] What kind of criteria are important to consider when selecting a COTS software package? This suggests that you should modify the business process to match the package rather than vice versa… which in turn suggests that you should generally not be considering packages for strategic business processes / capabilities. This also suggests that you want to be very clear about and enforce boundaries to prevent package features creeping into strategic areas. Just because the product offers a feature, doesn’t mean you should turn it on or use it. According to Capers Jones, at 25% customisation, it’s cheaper in the long-run to build a custom system instead and 15% customisation is a safer number to use. If the vendor is hostile, the number drops to 5%. If the package is like an appliance (e.g., Microsoft Word), it should just work. Initial selection and upgrades might be more about manual, exploratory testing. However, once we start introducing customisation, then the importance of being able to setup automated testing (as well as other development features) grows. Configuration, especially if extensive, should not necessarily be treated with any less rigour than custom development. This could be vendor alignment, testability, modifiability, etc. If the package does not require as much commitment (e.g., hosted service), we’ve maintained options to change our mind later and don’t need to worry as much about making an optimal decision up front. Don’t pick the right technology. Pick the technology which is cheapest to move away from. Chris Matts The factors that increase commitment are primarily the size of the initial investment and the cost of migrating data. The size of initial investment is about sunk cost fallacy which makes it a psychological/political factor, not an economic one. In a customisation situation you want to assess the modifiability of a package in a consistent way by providing several customisation scenarios and seeing how vendors are able to respond. (Thanks to input from Jonny Leroy, Tim Brown, Martin Fowler, John Hume, Ahrum Song, Scott Shaw, Evan Bottcher, Rebecca Parsons, and Aaron Erickson)
Does the pricing model, subscription period and licensing approach work for how your business is structured? Will the licensing model restrict your future use of the software? Does the license costs, along with all other costs enable you to prove a clear Return on Investment for the software. Will the licensing model become restrictive as your company grows? What shortcomings in the product are you having to accept in order to achieve lower licensing fees? Are the additional features of a higher license level worth the investment?
Does the software provide all the functionality you need to undertake your work processes. Is additional functionality superfluous, or are you likely to need it as any growth plans come to fruition? More functionality isn’t necessarily better. Consider how the system fits into your requirements now and how they might change in the future. If this system is crucial to your workflow, consider the benefits of a system which is targeted and simple, compared to a system which could be overly complicated to live with.
Do you need the software to integrate with other off the shelf software packages? If so, is full integration included, or if not, will manual integration be possible with imports/exports? If you’re looking to integrate two off-the-shelf systems or even into your own systems, we can help! Our experienced team of developers are often working on innovative ways that we can automate processes and move data between multiple systems. Learn more about systems integrations
What level of support will the company provide – email, chat or telephone? Are you purchasing from a reseller or the developHow will the company perform when you need them after you’ve made the purchase?
Do some due diligence on the company as to whether they have the maturity and finances to be around for the foreseeable future.
[I wrote this back in 2011 on my old blog and recently needed to reference it so decided to migrate it here and make some small tweaks.] What kind of criteria are important to consider when selecting a COTS software package? First the somewhat straight-forward things…
This suggests that you should modify the business process to match the package rather than vice versa… which in turn suggests that you should generally not be considering packages for strategic business processes / capabilities. This also suggests that you want to be very clear about and enforce boundaries to prevent package features creeping into strategic areas. Just because the product offers a feature, doesn’t mean you should turn it on or use it. According to Capers Jones, at 25% customisation, it’s cheaper in the long-run to build a custom system instead and 15% customisation is a safer number to use. If the vendor is hostile, the number drops to 5%. Customisation or extensive configuration highlights the need for deliverability.If the package is like an appliance (e.g., Microsoft Word), it should just work. Initial selection and upgrades might be more about manual, exploratory testing. However, once we start introducing customisation, then the importance of being able to setup automated testing (as well as other development features) grows. Configuration, especially if extensive, should not necessarily be treated with any less rigour than custom development. Especially with the typical COTS packages in terms of CRM, ERP, financials, the main options tend to have feature parity which means you should generally focus on other aspects.This could be vendor alignment, testability, modifiability, etc. It is better to reduce commitment than attempt to commit to a perfectly correct decision.If the package does not require as much commitment (e.g., hosted service), we’ve maintained options to change our mind later and don’t need to worry as much about making an optimal decision up front.
The factors that increase commitment are primarily the size of the initial investment and the cost of migrating data. The size of initial investment is about sunk cost fallacy which makes it a psychological/political factor, not an economic one. Scripted customisation scenarios may be even more important than scripted demos.In a customisation situation you want to assess the modifiability of a package in a consistent way by providing several customisation scenarios and seeing how vendors are able to respond. (Thanks to input from Jonny Leroy, Tim Brown, Martin Fowler, John Hume, Ahrum Song, Scott Shaw, Evan Bottcher, Rebecca Parsons, and Aaron Erickson) Does the pricing model, subscription period and licensing approach work for how your business is structured? Will the licensing model restrict your future use of the software? Does the license costs, along with all other costs enable you to prove a clear Return on Investment for the software. Will the licensing model become restrictive as your company grows? What shortcomings in the product are you having to accept in order to achieve lower licensing fees? Are the additional features of a higher license level worth the investment? Does the software provide all the functionality you need to undertake your work processes. Is additional functionality superfluous, or are you likely to need it as any growth plans come to fruition? More functionality isn’t necessarily better. Consider how the system fits into your requirements now and how they might change in the future. If this system is crucial to your workflow, consider the benefits of a system which is targeted and simple, compared to a system which could be overly complicated to live with. Do you need the software to integrate with other off the shelf software packages? If so, is full integration included, or if not, will manual integration be possible with imports/exports? If you’re looking to integrate two off-the-shelf systems or even into your own systems, we can help! Our experienced team of developers are often working on innovative ways that we can automate processes and move data between multiple systems. Learn more about systems integrations What level of support will the company provide – email, chat or telephone? Are you purchasing from a reseller or the developHow will the company perform when you need them after you’ve made the purchase? Do some due diligence on the company as to whether they have the maturity and finances to be around for the foreseeable future. 157. Identify the most common criteria for choosing off-the-shelf software. Which two criteria would be among the most important? The most common criteria are cost, functionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation. Cost involves comparing the cost of developing the same system in-house to the cost of purchasing or licensing the software package. Functionality refers to the tasks the software can perform and the mandatory, essential, and desired system features. While vendor support identifies the amount of support the vendor can be expected to provide, vendor viability examines the vendor’s marketplace strength. Flexibility refers to the flexibility of customizing the software. The documentation criterion examines issues relating to the user’s manual, technical documentation, and cost of acquiring additional copies of the documentation. Response time questions the length of time it takes the software package to respond to the user’s requests in an interactive session and how long it takes the software to complete running a job. The ease of installation criterion examines the difficulty of loading the software and making it operational. Vendor support and viability will be among the most important. 158. Briefly discuss generating alternative design strategies. The generation of at least three alternative solutions is recommended in the text. The three alternatives represent both ends and the middle of the alternative solution spectrum. A low-end solution, high-end solution, and midrange solution should be identified. Low-end solutions are conservative in terms of the effort, cost, and technology involved in developing a new system. This strategy provides all the required functionality users demand with a system and will meet every constraint. High-end solutions are potential solutions that contain many extra features users may desire. High-end solutions focus on functionality, not cost. High-end solutions will ignore most, if not all, system constraints. Midrange solutions are compromise solutions. 159. Identify several issues to consider in generating alternatives. Issues to consider when generating alternatives include such areas as whether the system should be developed and run in-house, software and hardware selection, implementation, and organizational limitations. Each of these issues must be considered and will impact alternative generation and selection. Decisions addressing outsourcing or in-house development must be made. Software can be obtained from hardware manufacturers, packaged software producers, custom software producers, enterprise-wide solution providers, application service providers, and in-house developers. The advantages and disadvantages of utilizing current hardware and systems software should be studied. |
When choosing off the shelf software the two most important criteria to consider are and
Pos Terkait
Copyright © 2024 kemunculan Inc.
