|Publisher:||BCS Learning & Development Limited|
|Product dimensions:||6.75(w) x 9.62(h) x (d)|
About the Author
Read an Excerpt
INTRODUCTION TO OFF-THE-SHELF SOLUTIONS
'There is nothing so useless as doing efficiently that which should not be done at all.'
Peter Drucker (1909–2005)
1.1 WHAT YOU CAN LEARN FROM THIS CHAPTER
Appreciate that major software implementations are heavily intertwined with organisational strategy.
Understand the impact that off-the-shelf solutions have upon IT.
Be aware of some of the common myths, false assumptions and pitfalls that you might meet. This includes recognising some of the ill-advised reasons to buy an off-the-shelf solution.
1.2 INTRODUCTION TO OFF-THE-SHELF SOLUTIONS
Off-the-shelf solutions have had a profound impact upon IT (Bray, 2014). They are part of a trend away from bespoke or tailor-made software that is intended for only one organisation. Off-the-shelf software products are often called COTS, for commercial off-the-shelf. This means a developer (usually a software house) creates a software product that is specifically intended for deployment by multiple user organisations. Their customers may be commercial companies or public sector organisations (such as a fire service buying an HR product).
Within the public sector, a variant termed GOTS stands for government off-the-shelf. This is where one government agency or department builds (or funds) a software product, which is made available to other parts of government – sometimes without cost. Several national governments have stipulated that their agencies or departments use COTS or GOTS solutions whenever possible and often as first choice rather than last resort – for instance the US Cloud First policy (GSA, 2014). As well as the costs and risk of the initial build, bespoke software carries the whole burden of continuing maintenance. Organisations have often found that shortages of skills and money means they own a system that is not adequately supported or maintained. Procuring a solution off-the-shelf avoids in-house construction (or funding one-off development by external software authors). This spreads both development and maintenance cost and improves resourcing because a broader customer base creates a better-funded and more sustainable development environment.
Indeed, there are now areas where off-the-shelf solutions dominate to such an extent that is out of the question for an organisation to write its own software.
AREAS SERVICED BY OFF-THE-SHELF SOLUTIONS
(See the Glossary for acronyms). A list of areas where off-the-shelf solutions are available might be shortened to 'almost anywhere'. There is some form of COTS available for most things. Uptake often grows with more cloud-based working. While this list is not exhaustive, note that evaluation projects using this method have covered all these software areas.
finance, general or nominal ledger, contracts or project ledger, job costing, fixed assets and depreciation;
asset intelligence, asset management and service management;
sales, marketing, CMS and CRM;
procurement, inventory, MRP and ERP;
demand planning, SCM, distribution, warehouse management and EDI;
CAD, building information modelling, stress analysis and visualisation;
PDM, requirements management and PLM;
HR, payroll, resource planning and rotas;
ID cards, access control, time, attendance, work-booking and time charging;
training, LMS and LCMS;
document management, content management and DRM;
web retailing and eBusiness;
desktop tools, reporting, management information and business intelligence;
CSCW, support desk and service desk;
operating systems and middleware.
1.3 INTERACTION OF STRATEGY AND SOFTWARE
Strategic decisions change the business, responding to external forces and the internal planning process. You should recognise that some of your current, and most of your proposed, software solutions are wide-ranging and have a powerful effect on the operation of your organisation. Such software is generally called enterprise software or enterprise-class software. Adopting enterprise software is a strategic decision; it heavily influences your organisational strategy; it makes this strategy concrete. Consequently, strategy and enterprise software are inextricably intertwined, meaning that the installation of unsuitable software will set back your strategy (Galorath, 2012).
When selecting off-the-shelf solutions, a solid frame of reference assumes that this is not an IT project, but a business project to select IT, which keeps the project rooted in the organisation. As argued in Good To Great (Collins, 2001), good technology will not make you great, but bad technology will hamper your operations – meaning that software that fits is not enough by itself.
The method presented in this book will help you avoid bad technology, because an approach driven by requirements, with progressive shortlisting, is intolerant of unsuitable candidates. The process to find suitable technology also helps successful implementation (see Chapter 13).
1.3.1 Organisational strategy and new software
A new organisation-wide solution (enterprise software) is a major investment in, manifestation of, and commitment to your organisational strategy. It is an expensive part of that strategy. It is highly significant to your organisational strategy, especially when adopting software that cuts across multiple organisational silos. It is also highly significant to your IT strategy in that it will consume a significant portion of your IT capital budget. It will deliver a significant lump of the automation requested by your organisation (Frese and Sauter, 2003). This means that you had better get it right.
1.3.2 Organisational strategy and incumbent software
Alternatively, your organisation may have made an earlier considered decision to replace the incumbent software, because it no longer fits your organisational strategy, and to replace it with an off-the-shelf solution. However, the gap between your incumbent solution and the best available off-the-shelf might be close. If so, it is generally not worth the disruption to change a major piece of software. It will be better to invest in your incumbent solution to improve it. See Chapter 9 for gap analysis and Chapter 13 for implementation.
This means that, during your evaluation, you may decide to longlist one or more of your incumbent (current) solutions and it might even go all the way through your process to win. This is discussed in more detail in Chapters 7 and 9. By formally evaluating it, you are not revisiting or overturning the earlier decision, but formally checking whether your incumbent system meets your strategy. This is to validate the strategic decision in case it was misinformed by poor understanding of your current software. It might be much better than its reputation. There might be a newer version that you have not yet adopted.
1.4 IMPETUS – THE PROJECT PRE-CONDITIONS
Organisations have many motivations to change software. Such change is often dreaded, painful and deferred as many times as possible. Enterprise-class software that is embedded into your organisation is usually the most painful to replace. One or more of the reasons that follow will usually apply in providing the impetus. They are generally either major changes to your organisation or inadequate IT.
1.4.1 Changes to strategic direction
Your strategic direction as an organisation may have changed. For a commercial business, it may be an acquisition or perhaps the major expansion of a branch network. For a public sector organisation, it may be a significant change of legislation, departmental structure or reporting needs.
1.4.2 Changes to requirements for compliance
There are external pressures when legislation changes. Improving statutory reporting usually needs more detailed tracking. This directly affects how capable you consider your incumbent software to be.
Also, there may be changes to your approach to compliance. Your external auditors are increasingly aware of the impact of software on the organisation. Their financial and quality checklists will include entries to test aspects such as data integrity or the segregation of duties. Whether you adhere to such principles can often be found out from the set-up of your IT solutions.
1.4.3 Changes to technology or adoption policy
As part of a wider IT strategy, or seizing a specific opportunity, your organisation may decide to adopt specific technologies.
You may face a new policy on provision, for example for certain areas of your organisation to adopt cloud subscriptions (software as a service, SaaS).
1.4.4 Replacing inadequate processing
Your organisation may have recognised that it is time to replace current processing and IT solutions. Technology is often the last aspect to catch up with strategy.
Processes may have become too labour-intensive, making them expensive, not responsive enough and prone to human error. Therefore, your organisation wants more work automation. A common indication of this state is the need to replace semi-manual IT processing, such as spreadsheets, with a more automated solution that can carry out rules without being driven by an operator.
Legacy software may be nearly obsolete. It may have become uneconomic to maintain, or it may be formally at end of life because your external supplier has announced the date it will become unsupported.
You may be replacing ineffective IT. Whatever its age, the solution does not meet your needs. Possibly, it never did because a software development or selection fell short.
EXECUTIVE PERSPECTIVE: AN IT MANAGER'S EXPERIENCE OF MAKE VERSUS BUY
Often IT is challenged with the decision to either build its own software or buy something in. I work with a large population of engineers, so you will always get 'nobody can build this better than us!' Which may have stood true at some point back in time.
The software market has matured enough for good solid off-the-shelf software to be available. The problem is how do you bring the diehard in-house engineers along with you in the decision that off-the-shelf is the right answer. When faced with exactly that problem, the IT selection process in this book involved all key stakeholders. It let even the most troublesome people have their say and know their input will go into the final decision.
Developing in-house software is like a never-ending story with too much temptation to change, over-ambitious developers and constant bug fixes and maintenance. If we had gone down the development route, I am sure it would have ended in disaster, as a later and unexpected reduction in our capital programmes meant we would have never been able to complete a multi-year development project with anything meaningful to use.
The software selection process enabled us to really put the software vendors to task, comparing apples to apples and putting us in a very strong negotiation position. We had all the benefits of spreading the enormous development costs over multiple customers by buying off-the-shelf. Having been involved in this process from end to end, I can honestly say that you will never have any second thoughts of whether you made the right decision as this process puts the decision in everyone's hands.
1.5 WHY BUY AN OFF-THE-SHELF SOLUTION?
Some of the main motivations for adopting off-the-shelf software products include cost savings, improved quality, greater reliability (because other customers have tested it), better documentation, greater sophistication (than you could otherwise afford), faster implementation and the continuing upgrades.
1.5.1 Development costs are spread
An off-the-shelf solution means you are adopting software with a high development cost that is spread over a large customer base. The customer base has funded original development (for major software products this may be decades ago) and all subsequent enhancements.
The funds available have also meant progressive adoption of modern construction tools with up-to-date software development and test environments. This matters because modern tools usually build a more modern user experience.
1.5.2 Extensive specialist knowledge is encapsulated
You are buying encapsulated knowledge – a type of Economic Complexity (Center for Economic Development, 2014). The developers, to be effective, need to understand their niche, such as the business vertical market or the public sector field. They also need to understand the software development process, with professional design, coding, testing, documentation, distribution and training.
You are avoiding the risk of internal 'gifted amateurs' creating DIY software, sometimes called under-the-desk (in contrast to off-the-shelf). With modern tools, it can be dangerously easy to start constructing unique software, but discover too late that you do not have the resources, skills or authority to build a good solution.
1.5.3 Infrastructure for support and maintenance
When you buy a software product, you are also connecting to an extensive support infrastructure. Like the initial development, the cost of supporting and maintaining the product is also spread over a large customer base. There will be dedicated support infrastructure as well as the original software development environment.
This infrastructure aims to keep all installations of the product (including yours) healthy and protected from disaster. It will have automated processes, such as 'harvesting' snapshots of your working environment.
As well as the teams of coders and testers, there will be an extensive network of implementation consultants and support desk staff. As well as their knowledge of the product and previous customer issues with it, you are also benefitting from their support technology, such as knowledge bases or remote support and monitoring tools.
Of course, a crucial part of support is the release of updates. These will respond to changes of regulation, compliance needs, technologies and norms in your sector, as well as fixing bugs. With the right supplier, you can rely on an external team to keep on top of these changes.
Software renewal involves great experience. While software does not 'wear out' like a mechanical device, it does eventually become unmanageable. It reaches end of life when it is no longer economic to maintain the code base.
This is why you expect superseding major versions, which possibly exploit much more up-to-date construction technologies, such as to build apps for smart phones.
1.5.4 Teams provide safety in numbers
You are seeking safety in numbers. Adopting a large software product avoids a single point of failure. You avoid the situation where the person who developed an application (and is the only one who understands it) goes on holiday or quits. Behind the off-theshelf software product, there are multiple teams – teams to develop it and teams to support it.
1.5.5 Standards and best practice are imported
You are adopting a standardised approach. Assuming the software product encapsulates best practice, your organisation is 'importing' good processes. Since the standard interface is used by a large pool of workers, you can recruit staff who already understand how to work your main IT solution. This makes ownership cheaper.
1.5.6 More choice is available with provision
Off-the-shelf solutions usually have more options for provisioning – meaning the hardware platform to run them. Also, up-to-date software products can often run in multiple environments. For instance, some are designed to connect to more than one database product, so you can stick to technologies where your organisation has mature skills. Alternatively, products may be designed to install on the desktop or server, but optionally run web-based.
Adding these alternatives is technically complex and more expensive. However, such options are attractive when they allow you to choose the platform that is most relevant to your organisation, such as the cloud. Once again, because the product has a sizeable market, the overhead of developing the product for multiple platforms is spread. An in-house software development probably could not afford to carry such overhead.
1.6 AVOIDING COMMON PITFALLS WHEN PROCURING OFF-THE-SHELF SOFTWARE
An off-the-shelf solution can bring its own temptations. As you are buying a pre-existing solution, there is a significant risk of false assumptions. The following points will help you make good choices on your project.
1.6.1 Complex software is not a simple artefact or project
Adopting a software product that has been created by an external supplier does not give you the right to abdicate customer responsibilities for a successful project and a quality IT estate.
Your organisation might assume that technology delivers benefits – it does not; people do. Your project will simply give them tools that are more powerful. Your project process should ensure that the required benefits are clearly articulated and the team are motivated to use the tools to deliver those benefits.(Continues…)
Excerpted from "Off-the-Shelf It Solutions"
Copyright © 2015 Martin Tate.
Excerpted by permission of BCS The Chartered Institute for IT.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
List of figures and tables, x,
List of executive perspectives, xii,
Abbreviations and glossary, xix,
INTRODUCTION: PURPOSE AND PRINCIPLES, 1,
1. INTRODUCTION TO OFF-THE-SHELF SOLUTIONS, 16,
2. TALENT MANAGEMENT: SUPPLIER PSYCHOLOGY (with Cathy Humphreys), 27,
3. INITIATION: SHAPING AND AUTHORISING THE PROJECT, 39,
4. REQUIREMENTS ANALYSIS: CAPTURING THE ORGANISATIONAL NEEDS, 56,
5. REQUIREMENTS DOCUMENT: DOCUMENTING AND AGREEING REQUIREMENTS, 68,
6. TRAWLING THE MARKETPLACE: ESTABLISHING THE LONGLIST, 86,
7. ASSESSING LONGLIST CANDIDATES: SELECTING THE SHORTLIST USING THE RFI, 96,
8. DETAILED EVALUATION: ASSESSING THE SHORTLISTED CANDIDATES, 120,
9. SCORING: ESTABLISHING DEGREE OF FIT AND RANKING, 135,
10. DEMONSTRATIONS: PROVING THE FIT, 163,
11. REFERENCE SITES: REAL CUSTOMER FEEDBACK, 182,
12. CONTRACTS: NEGOTIATION AND AGREEMENTS, 192,
13. IMPLEMENTATION: PREPARING THE GROUND, 217,
14. VIEWPOINTS BY THEME, 231,
15. CONCLUDING - RECOMMENDATIONS AND RESOURCES, 237,
APPENDIX 1 SIZING QUESTIONNAIRE: TO SCOPE A SELECTION PROJECT, 242,
APPENDIX 2 COMPARATIVE METRICS: EXAMPLE PROJECT PROFILES, 245,
APPENDIX 3 CHECKLIST: DETAILED METHOD STEPS, 247,