Software Evaluation for Small Business
- June 14, 2018
- Category: Business
Three out of ten companies that implement software projects end up with successful implementations. This means that most software implementation projects will end up failing in some manner. This is true regardless of the type of project; however, large-scale system projects have a greater probability of failure. Nevertheless, there are some commonalities between the failures and ways that companies can minimize the risk. By using software evaluation that begins with developing an understanding of organizational processes, businesses can improve the failure rate by ensuring that the software being purchased fits the overall characteristics of the company and avoids other characteristics that contribute to unsuccessful investments.
Common Errors and Common Methods
The most common errors that small businesses commit when purchasing or implementing software include the following: not taking into consideration future growth, lack of user buy-in, confusing desires with needs, forcing automation on an incompatible structure, incorporating invalid data, not measuring total cost of ownership, lacking budget, having unrealistic expectations, and lacking training. Furthermore, small business owners are generally the evaluators and may not understand the complexities of information systems.
In the small business sector, software is generally evaluated using a few methods that are decades old. The most common type is a Request for Quote (RFQ). The basis of this methodology is for organizations to develop a comprehensive and complex document that lists all organizations requirements. Vendors review the document and determine whether their software meets each characteristic listed and generate questions regarding the features. Other methods that small businesses use to purchase software are less complex. Mainly, small firms will either look at the characteristics of each software option and evaluate feature requirements and budget or may ask friends or colleagues for referrals. Some may combine the three methods and use the internet for suggestions.
The issue with traditional methods is a lack of comprehensive detail on how each system will fit the different business processes of the company looking to implement software. Therefore, the business may not be set up to operate the way that a system is designed to function. For example, some businesses may base invoices off pre-established quotes. Therefore, the business process begins with providing customers with a quote and pushes the process forward after the quote is approved by generating an invoice.
The intricacies of the business process, however, may include emailing the original quote and receiving a signed approval via email, fax, or text. A small firm may have been functioning this way for decades. If a business generates an RFQ or develops quick characteristics, both evaluations may determine that the software does, in fact, create a quote and generate an invoice based on a quote. However, the other factors that contribute and are integral parts of the business process are not considered or evaluated. Even though the example is trivial, this can happen with each different operation within the business’ internal processes. Therefore, users may find that the system lacks too many of the small details needed to operate successfully and may refuse to use the software, leading to failure.
To successfully implement software, businesses need to develop a team that is representative of the organization, empowered to make decisions, autonomous, and user-diverse. The development of this team is necessary regardless of whether a business is evaluating software for managing truck repair shops or hiring an agency that builds websites for lawyers. The team should first evaluate each business process and such evaluation must include a description of the activity based on information compiled, processed, or generated. Generally, the team follows a paper trail that includes documents that support the operation. The team must then generate an initial diagram of the activity and optimize the process for eventual automation. The resulting optimized business process is what the team will use to evaluate against the proposed software. This should be done for each of the business activities.
The idea of automation is to produce a process that is as free from human intervention as possible to reduce the possibilities of errors when possible. However, business processes that are automated by software need to be redesigned to incorporate the automation. Failure is imminent when the business process and the software are incompatible. This occurs either because users refuse to use the product, the product does not automate the correct process, or the process is not optimized for automation. Understanding this before investing will greatly reduce the probability of failure.
Share this article: