Introduction

The selection of an enterprise software is usually a complex undertaking. On the one hand, every company already has individual framework conditions and specific processes for service provision, which should be optimally supported by the new tool. On the other hand, there is a multitude of products with different philosophies and focal points, the effects of which are initially difficult for an outsider to grasp. In the selection process these two sides have to be brought together. The customer's representatives have to pre-select, understand and evaluate the products that come into question in principle with regard to their suitability. And the product suppliers must understand the customer's requirements in order to offer meaningful solutions.

In practice, the procedure described below is often used, which is divided into three phases here. This model can be applied to different types of enterprise software, whether it is a risk management application or a complete ERP system. However, if the scope or complexity of the software to be introduced and the processes to be implemented is greater, individual steps may have to be run through in more detail or several times than with simpler software.

In the public sector, certain procedures are also prescribed, so that the approach can be fundamentally different.

1. Project initiation

Clarify current status, problems and motivation, e.g.

  • Dissatisfaction with the process
    - too many manual activities
    - missing tool support
    - too many errors
    - insufficient cooperation across different areas

  • Problems with the current tool, for example:
    - individual system
    - operation or further development is too expensive or is no longer possible
    - runs out of maintenance
    - no longer meets the requirements

  • Changes in the organization or in the processes of the company or agency
  • Specifications of the group or superordinate institutions
  • new or changed legal requirements

Describe approach to solution

  • Restructuring of processes and tool support
  • Which processes should be addressed?
  • Which parts of the organization and which roles should work with them?

Benefits for the organization

  • What benefit would the solution bring to the organization?
  • Which processes would be executed faster or with fewer errors?
  • Are costs minimized?
  • Are risks minimized, e.g. by replacing old software?
  • Will it meet legal requirements or customer requirements?
  • What opportunities would arise for marketing and sales?

Supporting:

  • What are best practices in this area? (norms, industry standards)
  • Is it possible to draw on experience within your own organization?
  • Are there experiences in friendly organizations?
  • Experience reports, information from conferences
  • What are current trends?
  • Does such a tool already exist in other areas and could it be used?

Clarify basic willingness and ability to carry out such a project

  • Where in the organization would the responsibility for such a tool lie? Can it be introduced decentrally, if necessary, or is the responsibility centralized?
  • Is a budget available or planned?
  • Is there a conflict with other projects?
    A tool introduction requires efforts in selection, implementation and use. If other larger projects are pending at the same time, this can lead to a conflict in resources. If necessary, the projects must be temporally equalized.

Clarify goals and scope

  • What belongs in the project?
  • What explicitly does not belong to the project?
  • Examples:
    - Structure or automate manual activities
    - Replacement of old system
    - Transfer of old data
    - Digitize processes
    - Simplify / improve processes
    - Adapt processes to the changed organization (centralization/decentralization, M&A ...)

  • Dependencies to other projects in the organization
    - Goals and strategy of the company or organization for the next 3 to 5 years
    - upcoming organizational changes
    - upcoming process changes
    - upcoming other tool launches

  • Rather adapt the processes to the tool or the tool to the processes?
    Systems that are highly adaptable to given processes are usually more maintenance intensive.
    Therefore, it can make sense to orientate your own processes more towards the specifications of the software, especially if the processes are not in the core value chain.

Result: The project is sufficiently outlined and coordinated with the participants

Perform initial market screening

The first market survey is about getting to know current trends and currents as well as general capabilities of tools. The goal here is not yet to create as complete a list as possible of providers and products. Rather, the aim is to build up basic knowledge so that the subsequent steps can be processed reasonably.

  • What are current trends in this environment?
  • What possibilities do marketable tools offer?

Result: You know some providers and products as well as their approaches and approaches.

Define target state

At the target state you develop an idea of how your organization and processes should function in the future. If you really only need a new tool and you want to continue the processes as before, you can save yourself this step. Usually, however, there is always room for improvement and, due to the constantly changing conditions in today's world, there is also a need for adaptation - now is a good opportunity to do this.

  • Overview of the planned processes
  • Involved organizational units and roles
  • Role of the tool
  • Interfaces
  • Quantity Structures

Implementation projects often run into difficulties because they are torpedoed at a very late stage by other organizational units claiming that they were not included in the conception and that the software does not fit their actual working methods. For this reason, make sure that all relevant units are intensively involved and regularly give their commitment to system implementation.

Result: The future way of working is roughly defined and coordinated with all parties involved.

Putting together a rough concept

  • Description of the project
  • General conditions
  • Goals and Scope
  • Current status and problems
  • Approach
  • Target state
  • Benefits
  • Time frame

Here too, make sure that you coordinate with all relevant organizational units.

Result: There is a rough concept for tool introduction and use. It is written in such a way that tool providers can get a comprehensive picture of your current situation and the goals you want to achieve.

Create project plan

  • Phases and deadlines
  • Resources for tool selection
  • Resources for tool implementation
  • external support, e.g. consulting, project management
  • Estimated expenses
  • Estimated internal costs
  • Estimated external costs (SW license/maintenance or SaaS fees, services)
  • Risks

Result: There is a first version of a project plan with ideas about deadlines, efforts, costs and risks. The document is intended for internal use, so that the vendors initially do not receive any information about your " thresholds".

Review

All work results should be checked by a third party not directly involved in the creation. Criteria are among others: Logical connections, plausibility, consistency and completeness

Result: Examined and, if necessary, revised documents that make a continuation of the project appear reasonable.

Create a decision template and submit it for approval

In this step, the project should be confirmed according to the organization's specifications and the required capacities and funds should be approved.

In addition to the formal route, it can be useful to involve the decision-makers at an early stage through unofficial channels and to win them over to the project. In addition to the benefits for the organization, the associated prospect of achieving personal career goals and special recognition can increase the willingness to approve the project. So it often depends on which of the already existing aspects are stressed in which context 🙂

Result: Approval for implementation, budget and resource commitments.

Results
  • Rough concept
  • Project plan
  • approved decision template with budget and resource commitments
  • Team for the tool selection

    2. Defining requirements

    In order to find the most suitable software for your organization, you need to know exactly what your needs are and what the general conditions are. Since the processes in companies and public authorities are usually complex and can involve different internal and external organizational units, the collection and structuring of requirements can quickly become a complex matter. However, it is worth the effort and care required to avoid unpleasant and above all expensive surprises at a later date. It would be fatal if an important requirement was only recognized after the software was acquired and this requirement could not be met by the new software.

    Define software requirements

    • What are the use cases in the application?
    • IT requirements or operational requirements
    • Expected quantities?
      - Users: power users, occasional users
      - Number of interactions per time unit
      - Data volumes, number of data records

    • Specifics of the organization, the processes
    • What are the requirements for the software derived from this? → List of criteria
      - General requirements
      - Functional requirements
      - Technical requirements
      - Quality requirements

    The requirements should be explained in a meaningful way so that the providers have a good understanding. The explanation can also help internally to understand certain things.

    Create criteria catalog

    The criteria catalog is a structured representation of the requirements for the software, to be filled out by the providers. It can be used to query the degree of fulfillment and link it to evaluation figures, so that at the end there is a number for each product that expresses the degree of compliance with the criteria and makes the offers comparable. However, this figure should be viewed with appropriate caution, as the questions often offer room for interpretation and can be understood differently by the providers. In addition, the products usually have different strengths and weaknesses, so the formal suitability for a task may differ from the actual suitability. Such differences can usually only be found out in a practical test.

    • Often as spreadsheet, possibly online in a special application
    • Suggested structure:
      - General requirements
      - Functional requirements
      - Technical requirements
      - Quality requirements

    • All requirements should be clearly identifiable by an ID
    • Classification into mandatory and optional criteria
    • Degrees of fulfillment, e.g. "in standard", "by configuration", "by customizing", etc.
    • Providers should always have the opportunity to comment. An application may have a completely different concept for a requirement and it should be possible to describe this circumstance.

    Result: A structured catalog with concrete requirements for the software. The document is designed in such a way that it can be filled out by the vendors and that allows a comparable evaluation of the various products with regard to the fulfilment of the criteria.

    Update rough concept and project plan.

    In this phase you will have gained important insights into your processes and your needs. This is normal and this is good, so you should update the rough concept and project plan in the relevant points.

    Result: The documents are up-to-date.

    Review

    Also the results of this phase should be reviewed by a third party not directly involved. Especially the catalog of criteria can become extensive and should nevertheless be consistent, since it goes to the vendors and is the basis for further evaluation. Special attention should be paid to this.

    Result: Checked and possibly revised documents.

    Approval

    Results
    • Rough concept
    • Project plan
    • Requirements
    • Criteria catalog

      3. Selection and contract conclusion

      Create a longlist

      • Include vendors that are expected to meet the requirements
      • Basis: market analysis, analysts

      Planning the process

      The following steps should be planned carefully, as appointments must be coordinated with both internal staff and multiple vendors.

      • Queries of the vendors:
        - Period of time during which questions can be asked
        - How can the questions be asked? (e.g. by mail to a specific address)
        - How are the questions and answers passed on to all other providers (anonymized)?

      • Submission of the information by the vendors
        - Date
        - Procedure (e.g. by mail)

      • Presentation dates: Dates for the individual vendors should not be too far apart, so that the products can still be compared.

      • Time for evaluation and decision making

      • Always to be considered:
        - Vacation plans
        - Periods with high workload, e.g. inventory, annual financial statement
        - available meeting rooms

      Please plan fairly towards the vendors. Although they are service providers, there are also people working there who would like to go on vacation with their families or celebrate Christmas. Therefore, avoid situations where, for example, a tender is sent to the providers shortly before Christmas to expect the offers to be returned on January 2nd.

      Obtain information from product vendors

      • Cover letter
      • Description of the process according to the planning
      • Expected results
      • Rough concept
      • Service description
      • Catalog of requirements
      • Rough project plan

      Evaluate responses from providers

      Evaluate the answers and criteria catalogs sent in by the offerers according to the evaluation scheme and bring the vendors and/or products into an order of precedence.

      Vendor presentations

      Invite the suppliers in question to a presentation. This should be taken into account in the planning:

      • Determine participants from your own organization.
        - It may not be necessary for all participants to be present the whole time, some only during their topic.
        - Consider vacation periods and periods with high workload (e.g. year-end business).
        - Determine representatives for short-term absences (operational emergencies, illness, etc.)

      • Set agenda.
        - The agenda should be defined in blocks of one to two hours.
        - Allow enough breaks
        - Schedule buffers for unforeseen difficulties

      • Set appointments.
        The dates should not be too far apart because of the comparability. But it is also best not to have 2 or 3 appointments on one day. In real meetings the different providers should not meet each other.

      • Set the working mode.
        - Who is a moderator?
        - How are questions asked?
        - Who is allowed to talk to the provider outside the official part? (important especially for public contractors)
        - How and when does the evaluation take place? (e.g. 5 minutes time for evaluation after each section)

      • Organization at real meetings
        - Send invitations, including agenda and directions
        - Reserving rooms and technology
        - Determine seating arrangement if necessary
        - Organize refreshments/drinks and lunch
        - Register visitors at reception

      • Organization at virtual meetings
        - Create and send invitations for web conference, including agenda

      Conduct presentations and evaluate vendors

      Create shortlist

      After the presentations, an interim evaluation is prepared for each provider, taking into account the results from the criteria catalog and the presentation. From this a ranking is provided and only the leading n offerers come a round further.

      The ranking should be discussed with the internal participants despite the actually "objective" score. Because by at first unhappily selected weightings and by insights won in the procedure, results could formally arise, which are not goal-prominent. If the organization has the freedom to deviate from the agreed procedure, this possibility should at least be discussed when there are good reasons. On the other hand, this should not be used to bring forward a special tool that is purely guided by interests but which only insufficiently meets the requirements.

      Testimonials

      Speak with the references named by the provider and get an impression. With good discussion conduct the referring party should be encouraged to speak very openly, also about weaknesses of the system and/or in the project execution. For this reason such a reference discussion should always take place without the vendor.

      Proof of concept

      • Define and describe use cases that are to be demonstrated, taking into account specifics in your organization that the tool must be able to cover.
      • Schedule appointments
      • Set a realistic and feasible agenda

      Test version

      A test version of the product is used to get a hands-on impression of the tool:

      • What is the general impression and operation?
      • Are the logical structures and the concepts of the software understandable?
      • How easy is the handling? How often do you have to click for a task? Are important control elements immediately findable?
      • How is the mass input? How easily can 100 new data sets be created?
      • How easy is the software to configure or customize?

      Test systems, on which the prospective customer can test alone are viewed critically by some vendors. The possibilities of today's software systems are often extensive and first you need to learn the underlying concepts and operating models before you can use a system meaningfully. The fear of some vendors is that in a "quick" test without training the software will not be understood by the testers and therefore be judged as unsuitable. Nevertheless the software should be tested hands-on. Even if one will not understand every detail of the individual system, the comparison over all products will provide important insights that should not be missed.

      Narrow further down the vendors

      • Evaluate results from the proof of concept and the test
      • Based on this, reduce the considered vendors to the two or three best

      Negotiations

      • License metrics of the vendors, modules
      • Support levels and conditions
      • Project effort for the introduction

      Final offer presentations

      Here the vendor should deal with the last open critical topics, bring in suggestions for their solution and make a "best and final offer"

      Decision template for the introduction of the tool and approval

      Contract conclusion

      results
      • License agreement or contract of use for the tool
      • Maintenance contract
      • Service contract for introduction