Workshops, project planning and change management
Our applications are designed to be part of your business and to evolve with it, so it should be part of a planned revision and improvement cycle.
​
Sometimes the implementation of our services is given, e.g. when the customer only want the supplier invoices or time module. But often the implementation is part of a broader business process rengineering, and our customers would like to create a vision of what their business should look like in the future, how we can help - and how to get there.
​
The workshop also serve as a basis for project planning and implementation guide. And as usual we focus on the critical parts, the pitfalls, and not the "off the shelf" parts.
​
Implementation blueprint
Our blueprint (or recommended process) for implementing our solutions to our customers is simple:
-
Run a workshop to identify the full scope of the project, options and customer expectations and main facts for the setup.
-
Set up a project group with covering the required knowledge - ERP systems/integrations, customers process manager/application owner, a small super user group (normally the accounting people).
-
If needed, make a project plan for the implementation with the main variables identified (like ERP systems, integrations, users and roles and main setup options). We normally recommend to leave the practical details and advanced setup until after the system is in test (or production)
-
Install and start testing, go live when it's good enough and the users have received the required training.
-
After 3-4 weeks of use, meet again to find out how to improve the setup and workflow. It normally takes a few weeks to learn the system good enough - and it's always much easier to make a list of things to change after using the system for some weeks.
-
Make the changes
-
Meet again after 2-3 months and do the same - normally now it's optimizing and fine tuning that is on the table.
Lifecycle management
To make sure you get the most out of your investments, your IT systems should be part of a regular maintenance schedule like any production tools.
-
New technology offers new possibilities. New versions, functionality or framework technology like PEPPOL
-
Changes in the organization and how you work
-
New demands from authorities or customers
-
Changes in production, logistics, supplier and customers all should be part of the IT system review
-
New ideas and good questions asked - "Why do we need to enter the same values in both systems - and why do we need this on paper?" always are good question
​
​
