.webp)
.svg)
Selecting and using software is a science, not an art. It is a thoroughly solid process with a start and hopefully a clearly defined result. However, this process presents many companies with significant challenges.
There are many “horror stories” about buying software. Sometimes the software does not work as it was previously advertised, or the targeted savings simply did not materialize. In these cases, software providers are quickly blamed. But is it really always their fault? A closer look is worthwhile, because the use of software is much more than an installation on a server, it is an organizational effort. Successful deployment often requires enormous efforts on both sides — providers as well as buyers.
Why do companies buy software?
Before a company intends to buy software, there is usually an internal event that triggers the process. These are often administrative bottlenecks or a non-functioning work process, which sooner or later leads to employee overload or frustration.
Common events look something like this:
- Drastic losses in productivity
- Lack of compatibility with new software
- Outdated lengthy work processes (e.g. double entries)
- Lack of connection and further processing of the data collected in the process
- Lack of opportunity for collaboration and global accessibility of data, e.g. from the home office
- Existing systems are no longer being supplied with updates
- Security concerns when using old software
However, there are usually a number of decisions between the triggering event and the actual purchase, which must also be made at higher levels of the organization. There in particular, the problem must therefore be understood and clearly documented, otherwise purchase inquiries are usually quickly rejected or postponed.
In the following sections, we will explain to you what happens before procurement and what three options there are to procure the software:
Before procurement
What problem do we want to solve by using the software?
Before a company actually gets around to buying the software, the team that is tasked with buying the software must complete a series of tasks. The first priority here is to determine the exact intention and future use of the software. It should also be absolutely clear for which problems the software should be used as a solution and does the solution fit the problem at all.
Can this problem be quantified with sufficient accuracy?
In view of the fact that a company's success is primarily measured by its profitability, it should also be possible to measure the underlying processes against this logic. The benefits of software must therefore be quantifiable and should make a positive contribution to the overall result over a period of one year. For this purpose, it should be possible to calculate the cost of the software, profit contribution and thus return on investment before making a purchase decision.
Teams that are tasked with solving problems, or want to put the purchase of software to solve a specific problem on the agenda themselves, should therefore always have at least the following points ready for the decision submission:
- The problem that the purchase is intended to solve
- Which software category comes into question here
- What alternatives are there
- Quantifying the current problem situation
- Software cost estimate
- Implementation costs
- Possibility of integration with other systems and the calculated benefits from this
- Implementation costs to communicate with other systems
- Training costs for employees
- Expected return on investment
The following points should be understood as a first milestone and should be further narrowed down through the following steps. Many software companies also offer advice through their sales team, which you can use to quantify the problem.
How big is the internal implementation effort?
In addition to the direct external costs for the software, it is essential for companies to quantify the internal costs of implementing and maintaining the software, as well as the costs of training employees. These usually significantly exceed direct costs. Other internal implementation costs:
- Training for employees
- Downtimes and delays due to start-up difficulties
- Integration into existing processes
- Required infrastructure
Especially for companies with large numbers of employees, a disruptive new technology, which was intended to improve work processes, can initially bring internal processes to a standstill. The reasons for this are often:
- Lack of acceptance of the new software due to low involvement of employees in the decision-making process
- Inadequate training
- The software's user interface does not allow intuitive use
- Sparse employee onboarding without support
- No consideration of required content in the software
- No consideration of necessary data transfers to other systems
In combination, this often means further costs, which should also be taken into account when evaluating the use of software.
Evaluation of potential solutions via demo and test versions
Once you've selected your potential software based on your research, take the time to attend a demo or use a free trial of the software. This will give you a better idea of how well the software is suitable for solving your problem. At this point, don't be afraid to ask yourself a variety of questions in order to quantify the value of the software in the best possible way.
Also, don't forget to inquire about the costs of implementation, employee training, and implementation in other necessary systems. These are often not part of direct software costs, but their value and scope should not be underestimated.
Software implementation only works with a good plan
Now that we have established that software is often complex and deeply interferes with existing business processes, it should no longer be surprising at this point that an introduction of software can only work well through a detailed plan.
1. Document your existing processes and procedures and note down necessary data formats
All parties involved should understand the existing processes and procedures that are affected by the introduction of the software and be familiar with them in order to identify potential obstacles at an early stage. In doing so, note possible software tools that are used as part of the process.
Also pay particular attention to process results and process inputs and in which format they should be available. This is particularly important when you need to assess the need to migrate data. Also consider the amount of historical data that may be necessary for processes.
2. Determine the impact of the new software on your business processes
After you have listed all processes that are affected by the software, it is important to understand what the impact of implementing the new software is on the identified processes. Weigh out effects that are particularly critical and determine what is necessary to heal this impairment in the short term.
3. Determine whether your current infrastructure is sufficient
Evaluate your current infrastructure and determine whether you need to make any further investments to successfully run the new software. Go into details when doing so. A new browser version may also require investments in infrastructure.
4. Does data need to be migrated?
Evaluate early on whether a data migration is necessary before switching to the new software. Data migration is quickly apparent if you also record the required formats for inputs and outputs as suggested as part of the process analysis. Please also note that some software must access historical data and that this must also be migrated.
5. Define the user roles and security levels of those involved who use the new software
It is important to think about who will use the software and which business areas and departments will be affected at an early stage. Ideally, you can assign roles and rights to users according to their tasks so that the flow of information through the new software can reach the right user groups without hindrance. A well-thought-out rights system reduces the risk of information falling into the wrong hands and at the same time saves costs, as restricting functionality usually means lower costs.
However, you should make sure that every user who works with the software also receives their own login. Traceability to the assigned user who is involved in the incidents can thus be easily established in order to strengthen the protection of corporate data.
6. With which other software programs does the new software have to communicate seamlessly and directly?
From the process analysis of existing processes (see step 1), it should be easy to identify the software programs used. In a further analysis step, it is now necessary to determine whether the data, which is processed in previous or subsequent process steps, must be passed on to the new software without system breaks, or whether other solutions are possible.
First of all, this is a question of costs and resources, because direct software-based integration usually requires resources to be set aside. However, the costs of direct integration should also be evaluated against the background of possible additional work - i.e. how much is the additional time required if there is no direct integration.
Once the interfaces, their integration costs and time savings have been quantified, you should prioritize them.
7. What goals should be achieved with the introduction of the software?
As described above, it is important to think very clearly from the start about which problems you want to address with the introduction of the software. In this step, you should quantify the original ratio as much as possible. This means that you define success criteria that should be used to evaluate the software. You can also set various criteria or target values for the various periods of implementation or degree of roll-out in the company. This ensures when the implementation is successful and when more work is required to achieve the desired result.
8. Completion of the entire implementation plan
Now that all the results of the internal analysis are available, the last step is to record all necessary work in an implementation and implementation schedule.
Also record a process for how to proceed in the event of deviations from the established plans. In this way, you can avoid attributions of blame right from the start and always know what the next step is and which people need to be involved.
