Quality Intake Service (QIS)

The application intake is the most critical component of the entire package process. It’s important to collect full details about the application in order to be able to create a good package. The more information, the better.

Because you’re the customer, you’re also the owner and user of the application, which puts you in the best position to supply this information. 

Of course, it would be ideal if you already had this information at your fingertips, but things often work out differently in real life. We frequently find that the information required is distributed amongst several people. Gathering and compiling this information takes time, because the various owners often have to find the time to do this alongside their normal activities. 

The intake phase will therefore almost always be decisive for the overall planning of the package process. Creating a high-quality package needs more than an installation manual. The application intake also results in the creation of a complete application file containing all features and above all dependencies.

In order to make the intake process transparent and plannable, ATS Teconomy offers its Quality Intake Service. The makes the intake process a shared process, whereby all you have to do is ensure that the right owners are linked to all applications and kept up to date with the process. 

We take care of the complete planning of the intakes and reporting on their progress. In view of the fact that the information still has to be supplied from within your own organisation, a number of conditions will be attached to this process.

 

Advantages of fixed-price intaking

  • Delivery of a standard application file per application for a fixed amount.
  • No surprises when it comes to costs.
  • Predictable progress of the intake process, which can be tracked in the portal in real time. 
  • High quality of the delivered application files, which keeps classic planning problems concerning ‘rework’ to an absolute minimum.
  • Optimal and efficient transfer of knowledge to the client’s organisation so that sufficient knowledge of the entire process can be built up within the organisation, even when maintenance is outsourced.
  • ATS Teconomy makes use of a permanent team of staff. The broad-based knowledge and experience of these staff creates the right basis on which to deliver application files that fulfil the previously agreed package guidelines. 
  • We are able to handle a high volume of intakes per week and can, if necessary, increase and decrease this volume as the situation requires. 
  • ATS Teconomy will never use in-house developed or proprietary tools. This means we don’t create any dependency.

 

 

Phasing

The intake process consists of at least 2 steps: the technical and the functional intake. It’s about documenting the application information needed for packaging.

 

Technical Intake

The first step is the technical intake, which describes the installation and also examines and documents all of the technical aspects of the application.

You will have to consider the following:

  • Back-end dependencies such as application servers and network shares
  • Licence model
  • Type of installation (client/server, network, web, shortcut etc.)
  • Required rights on the workspace and network.
  • Technical test script which describes how it can be tested whether the application has been correctly installed.

This information is essential for being able to build the package.

 

Functional Intake

This step looks at the functional aspect of the application. A functional test script is created and executed. This is needed because building a package can involve the conversion of an installer, which can lead to a loss of functionality.

The functional intake is therefore primarily intended to show that the installation of the original software works properly in the workspace. By creating a function test script from this, we can repeat this test in the test phase following delivery of the package in order to demonstrate that the package offers the same functionality as the installation of the original software. The functional test script is therefore the acceptance criterion for the package.

This information is essential for being able to test the package.