Astea Alliance ERP Implementation

Statement of Work

We create an initial list of processes that the client wants to implement in Alliance, from a ChargeBook (if any) and with the Project Manager.

Prototype

We first work with the client’s functional expert, to create a first version of Alliance that can then be demonstrated in functional workshops with Key Users.

Together, we create in Alliance, with the real data where possible, the key processes to implement. This gives us a first look at the needs, and sometimes there is a need to make some small developments/workflows, so that the processes unfold in a familiar way to the users.

Functional Workshops

We invite each Key User for a first functional workshop. In this first workshop, the client’s functional expert is also present.

The Key User explains the business process, and we demonstrate in Alliance (using real data that they are familiar with) how it works. The customer-side functional expert explains, where necessary, the differences between the current system and Alliance.

If there are needs that cannot be made in Alliance – gaps or issues, we discuss the potential workarounds with the Key User. If acceptable, OK. Otherwise, we agree on the severity of the issue, taking into account the volume of activity impacted. Each discrepancy is identified as:

Analysis

Following the workshop, we analyse the gaps and reflect on potential solutions.

We engage with the integrator and, if necessary, the editor, on the technical elements (Bugfix, development) to make a first estimate of development time and delay / or to find out if the need is already in the Roadmap. We also consider similar requests from other Alliance customers if there are any.

The proposed solution is added to the central issues file, and we prepare a Decisions meeting.

Decisions Meeting

With the Project Manager and the client, in this meeting we review the central file and we discuss and agree on the proposed solutions. At this point the client has a global vision of any necessary developments and customisations.

Specifications

We write detailed Development Specifications for any additions or modifications that are required. As experts in the Alliance product, we ensure that these specifications are consistent with the standard functionality of the application, which will ensure that the system, once implemented, is easy to maintain and upgrade. The vast majority of developments are the automation of standard processes, or the modification of screens and “lookups” to ensure that the input is consistent with the parameters and the data.

Specifications are written in a “functional” language that can be understood by a Key User. Each specification is validated by the Key User.

Development

Together with the Project Manager and the Client, we prioritise developments according to the implementation schedule. For example, we will prepare Sprints that include all developments required for one or more business processes. This allows us to quickly move forward on validation, as we can start testing one process whilst developments are progressing for another process.

We are in constant contact with the development teams and we respond to questions, or needs for clarification, as necessary.

As soon as each development is ready, we conduct “factory tests” in the developer’s environment, with the exchanges as necessary until the development meets the specification. We drive the progress of developments and ask that the developer prepare a “package” of developments for installation in the client’s UAT (User Acceptance Test) environment.

Test

We will validate the development package in the client’s UAT environment. We conduct some additional tests in the validation environment, to ensure that the package installation is OK.

Validation

We invite the Key User to a Validation Workshop, to validate the system now that all gaps identified in the initial workshops have been resolved.

We ask the Key User to validate the system. If there are new gaps identified, they are treated in the same way as the initial gaps, but with additional priority analysis relating to how the gap impacts the possibility to start a “Pilot”. It is possible that a gap is blocking for a Go Live, but not blocking to start a Pilot.

Pilot

We work with the project team to prepare a “Pilot” – a live test in the production environment. We act as a Helpdesk, if necessary, in the first days and weeks, to support and accompany users in their first Alliance steps. We do one-off training if necessary, we analyse the pilot’s progress and the level of success and commitment.

Iterative Process

The implementation process depends heavily on the prior engagement of Key Users. It is sometimes the case that there are certain processes (for a specific customer for example) or bugs that only become known at the time of the validation or even the pilot.

The implementation could therefore be an iterative process, where the workshop / development / validation steps are repeated until all gaps are addressed.

Go Live

We participate in the cutover plan for the Go Live, and we act as a Helpdesk in the first days/weeks as needed.

Post Implementation

We can accompany the customer after Go Live, to ensure a good transfer of skills to the client’s team and that the customer can respond to new requests from users, or to implement additional functionality not being in the first phase of the project.

We can analyse Alliance usage and advise the client on how to leverage Alliance as much as possible, to achieve a return on investment.

We can advise other process changes, to gain efficiency. These changes may have been identified during the functional workshops, but the client chose not to implement at the same time.