SOFTWARE SELECTION
How do I make the right decision in software selection? Which software is the most suitable?
Once the “make or buy” decision has been made in favour of “buy”, the next question arises: which software is the most suitable? And most of the time there is not only the choice between a suitable and an unsuitable software. Our years of experience show that the question of whether a software is suitable is a very customer-specific question. Therefore, it is important to be aware in advance of the aspects on which your organization would like to place the most value (e.g. functionality, user-friendliness, integration possibilities, etc.).
SOFTWARE SELECTION IN 4 STEPS
To help you and your organization ask the right questions on the way to choosing the right software, we outline our proven 4-step model below:
- Determination of the framework conditions and procedure
- Requirements gathering and prioritization
- Toolevaluation and -assessment
- Preparation of the decision document
01
DEFINITION OF THE FRAMEWORK CONDITIONS & APPROACH
In the first step, it is necessary to narrow down the professional and technical area for which a new tool is to be sought. In other words, which processes should ultimately be supported/accelerated/automated with the tool. The question of the operating model also arises more and more. Should the solution be able to be operated from a cloud or is an infrastructure/platform/software as a service model favoured.
Fundamental objectives, such as the development of the a degree of automation, minimal deviations from the standard, technology changes, etc. are decisive for the subsequent steps. Finally, the further procedure must be agreed with all stakeholders. Only if all relevant contact persons are identified, picked up and involved, the new tool will get the chance to be accepted in the own ranks.
02
REQUIREMENT ASSESSMENT & PRIORITIZATION
To ensure efficient design, we offer your identified requirements owners a predefined questionnaire with requirements that should be formulated for your future tool. As some customers find it difficult to assess what possibilities new tools bring with them, we are happy to help you and also provide impulses as to which requirement fields may still be incomplete (e.g. information security, data protection, etc.). Here it is essential that those making the requirements also mentally put themselves in a “to-be” position and not just reflect the existing tool (“as-is”). With the help of a glossary, we agree on a common wording to avoid misunderstandings. It also helps at this stage to think in terms of use cases and structure requirements based on these. Finally, the individual technical, nontechnical and organizational requirements need to be prioritized. This helps with the subsequent project planning and with reducing complexity to a manageable level. At the same time, the requirements also form the basis for the evaluation criteria, such as functionality, integration capability, system ergonomics, degree of maturity, security, costs, etc., which play a key role in the next step.
03
TOOLEVALUATION & -ASSESSMENT
In the 3rd step, our software experts first create a shortlist of possible tools based on a market analysis. These are then ranked based on the evaluation criteria (which, as mentioned earlier, are derived from the requirements) and weights.
For this purpose, we draw on our proven toolexpertise and, if necessary, also give the manufacturers themselves the opportunity to comment on the evaluation criteria. Depending on the time frame, it is also possible to build or test smaller prototypes. Our advantage is that we have already successfully implemented a large number of tools and can therefore also take into account stumbling blocks in the subsequent implementation project. For better comprehensibility, we naturally document strengths and weaknesses on clear summaries.
04
PREPARATION OF THE DRAFT DECISION
As a basis for your final decision, we will be pleased to prepare a meaningful basis for your decision, which can be accompanied by system demonstrations. Again, all relevant stakeholders should be involved, as they will be working with the solution later. If this aspect is underestimated, employee satisfaction can suffer.