Best Practices For Software Application Packages
The phrase ‘best practices’ as applied to software applications is relatively new. In the twenty years I was associated with the software industry, first as a programmer, then as an analyst and eventually as consultant and product manager, I never used or heard the phrase. There were good reasons for this, but before I can explain them, I need to establish some background.
If you thought about the title of this post, you might well ask yourself, “What do you mean – practices? What does that have to do with software? You mean – written the best way? Or – the most bells and whistles?
What the phrase ‘best practices’ alludes to in relation to a software package is something that I stress in my MBA classes because it surprises many people – the fact that ‘practices’ – business processes the dictate what your company’s employees will do and when they’ll do it – are ‘baked into’ any non-trivial piece of software. When you buy a software application – let’s say your company has decided it could benefit from a Customer Relationship Management (CRM) package – then you are locked into the processes, the practices that are built into the software. If you use the package, then you WILL feed it the information it needs, in the format it requires it and in the sequence it wants it. This is so whether or not you work that way now, whether or not you currently have the required information available and whether or not the process fits your company’s culture.
Well, you say, software can be modified, right? Right – for a price. The first price you pay when you modify COTS (common off the shelf) software is that you defeat the reason you bought the package in the first place – it was written, debugged and ready to use. The second price is Yankee dollars, lots and lot of them. It is widely known that the cost of consulting and modification for most ERP (enterprise resource planning) installations is greater than the multi-million dollar cost of the software itself.
Thus, it is critical to the success of a software package installation to thoroughly investigate the practices built into the application before you buy; and this brings us back to the notion of ‘best practices.’ Almost no software is developed, even by very large software companies such as Oracle or SAP, without a client. The client supplies the specifications for the application – the screens it should show, the information it needs, the reports it should produce and so on. Of necessity, the software mirrors the processes needed to satisfy the requirements. Because the early clients of a newly developed software application are typically large, successful organizations, the marketing arms of large software companies began, about fifteen years ago, to promote these ‘baked in’ processes as ‘the best practices of the best corporations.’ Applications developers are thus able to develop the software once and sell it multiple times – a very profitable undertaking. To understand the marketing coup that this was, it is necessary to understand the many circumstances under which ‘best practices’ are actually a detriment.
What is wrong with doing my inventory the way Mercedes Benz does it, you may ask. Or, why shouldn’t I want to handle my accounts receivable the way Nestle does? First, issues can arise due to disparities of size between your organization and Mercedes. Organizational size breeds process complexity, complexity that leads to high cost and long learning curves for software to support it and likely to a multitude of reports and functions that smaller companies will never use. Even more importantly, standard processes make it impossible to achieve sustainable strategic advantage from your software enabled process. A highly advanced, non-standard logistics process is what gives Wal-Mart a strategic advantage over competitors and the ability to grow market share and sustain growth. A very non-standard computer supported order fulfillment process is exactly what has enabled Amazon to become a major player in multiple retail marketplaces. As you may have already surmised, the software that supports Amazon and Wal-Mart, at least in the critical areas mentioned, is (and has to be) as non-standard as the processes themselves.
The key to determining whether the ‘best practices’ of a software application package are really the best for you lies in understanding what aspects of your business model are core competencies, activities that distinguish your business from others in the same marketplace. A close second in importance is performing a process audit during the purchase cycle of any large software package in order to determine just how different the embedded ‘best practice’ is from your current processes. The need to make large adjustments to existing processes in order to accommodate a new software application is one of the most widely acknowledged sources of installation failure.
William L. Kuechler, Jr., Ph.D.
William Kuechler is professor of information systems and chair of the information systems discipline at the University of Nevada, Reno. He holds a bachelor’s degree in electrical engineering from Drexel University, and a Ph.D. in computer information systems from Georgia State University.
His academic career follows a successful industry career in information systems development and consulting. His work experience brings insight to his teaching of both IS management and technical material and brings a wealth of practical background to his research. Kuechler’s two primary research themes are the cognitive bases of IS use, development and education, and design science research in IS. He is on the editorial advisory board for the Journal of Information Systems Education and is an associate editor for the Journal of Information