Collaborating with 360 ERP

Know what to expect by reading this leaflet

You're considering or already made the choice to start working with 360 ERP as your dedicated Odoo implementation- or support partner. Congratulations! We know we still have to prove our value to you and this is our goal for the upcoming period. What you can count on is decisiveness, expertise, empathy and constructive discussions - being a bit stubborn is one of our strengths. We believe that the best results for your company can only be achieved in an open and honest collaboration. We have our clients' best interests at heart for both the short and long term. That is in our DNA and what you can expect from us. What else you need to know about our working method can be found below.

Read the leaflet before use: "Standard" side effects

Before you read on, we have an important message for (new) customers: we are going to challenge your ideas. After all, we love standard (Odoo), and there's a reason for that. The closer you stick to standard functionality the more you'll benefit in the long run. Lower startup costs, less complexity, and easier migration to new versions of Odoo. Our experience on many other projects has taught us that.

So when we challenge you because we think things can be done differently and possibly better, we ask you to listen. Even if it's not exactly what you had in mind. We do it because we care about your company and we want you to continue to benefit from the solution we create. That is what we are all about! So do you want to create a true best-of-breed solution? Bring it on!

Final note: We are certainly not averse to good customization and deliver the best quality you will find. 

Project approach

How we work

360 ERP likes a phased and pragmatic approach in which we divide the project into building blocks. Each building block contains one or more Odoo Apps that automate one or more of your company's processes. This approach spreads the implementation pressure on the organization and allows for more attention to be paid to the individual design of the Apps. It also allows us to gain progressive insight about the processes and apply it directly to the next building blocks. This way, the company quickly benefits from the possibilities of Odoo and the final result is better. 

Start: Project initiation Document

Most projects at 360 start with a Project Initiation Document (PID). In this document we map out the project without going into exact details of the implementation. We look at your company's requirements, the possibly existing or future landscape (technology stack), a possibly desired best-of-breed structure and describe the outline of the solution. We also define the building blocks in which the project will be executed with a scope on lead time and budget.

Example structure of a 360 PID:
  • Project definition (motivation and objective)

  • Elaboration on the solution

  • Project approach and resources

  • Definition of the building blocks

  • Lead time and budget

  • Information about SLA

  • Acceptance and conditions

Phasing

Different building blocks, same stages

1. Functional design

For complex processes and customizations a functional design is made. For a relatively simple building block this step might be skipped.

2. Realization

Modules are configured and the necessary setup is done. Any customization is developed and data is migrated.

3. FAT

The Functional Acceptance Test: the delivered functionality of the building block is tested by the organization's project members.

4. UAT

The User Acceptance Test: after a building block is approved in the FAT, end users test the processes that have been delivered.

5. Training

Following the principle of 'train the trainer' the key-users have already received instructions from 360. Now it's their turn to train the end users.

6. Go-live

The moment of truth: everything has been tested, agreed upon and the end users are ready. We deploy the building block for real usage.

Roles at 360

Who does what?

Architect

The designated architect at 360 is responsible for outlining the big picture. Determines a possible best-of-breed design and is responsible for the structure of the technology stack. Collaborates with the customer and consultant(s) and decides what the solution will look like. Participates in realization where complexity is high. Is mainly present during project initiation and design, then moves to the background. Is present at all steering committee meetings.

Consultant(s)

The 360 consultant(s) are most present and responsible for the practical implementation and setup of the project. Depending on the project's size and versatility, multiple consultants can be allocated to contribute within their own field of expertise. Daily point of contact for the customer during the project. Collaborates with the architect for support when and where needed. 

Developer

The 360 developer writes the code for any customization that needs to be created. Listens to the architect and consultant to fully understand the functional and logical requirements of the required output. Works with the consultant to test finished customizations and finetune small details. Is not normally present at the customer's site but is sometimes asked to be the guest of honour at a meeting when a topic's complexity is high.

Happiness Controller

The happiness controller, a.k.a. project manager, maintains a satellite view on the project. Regularly checks in with the client and involved team members of 360 if progress and interpretation is to their satisfaction. Point of contact for the client in case of exceptions. The link between client, architect and consultant(s) when the chain needs lubrication. Excellent company for a cup of coffee when everything goes smoothly.

Roles at the customer

360's sparring partners

Project leader

The client's primary point of contact during the (implementation) project for all stakeholders. Acts as decision maker and sparring partner for the 360 architect, consultant(s) and happiness controller. Provides direction and context to the 360 team and key users. Intermediary and liaison in (best-of-breed) projects where multiple vendors participate. Present at meetings of steering committees and project groups, optionally joining working groups.

Functional administrator(s)

The final administrator(s) of the delivered Odoo solution(s) within the company. Trained by 360 on management aspects such as user/permissions management, setup, configuration, workflows and optimization. First point of contact for internal users after go-live. Usually the appointed contact for 360 for post-delivery SLA support.

Key users

The designated people within the organization who have a high level of knowledge about and responsibility for a (sub)process and/or department. Most often team leaders or managers. Actually work with (part of) the software themselves in daily practice. Give detailed input to the team of 360 about the design of a (primary) process. Receive training from 360 and responsible for testing delivered functionality within a building block.