Long Form Projects

Long Form Projects

We recommend four phases to an implementation project if you company size is greater than about 15 employees.

 

Prototyping One person (with the aid of others as necessary) to set up the system with at least one or two sample products and run the business processes through it. As necessary delete data and try different ways of working.   Configure system and system settings.   Document business processes.

 

Optional process development Improving business processes to benefit from the new system Planning of any complex data transfer   Report customisation   Possible co-development of features in the system

 

Piloting End user training   Process verification with samples of real data   Verification of people’s knowledge in using the new system

 

Go live Resetting system numbers and final data import.   Entering open order books and inventory values.   End user support and follow up.

 

Project Kick-Off (Long Form Projects)

A project kick-off meeting should involve all people whose jobs will be affected by the new system.

 

The top management should:

• Present the vision about where the company is going and why a new system is needed
• Introduce the key user and announce his authority to be involved in all parts of the organisation
• Introduce any other project team members and external consultants
• Outline the elements of the project, any scheduled dates and any changes in business processes either agreed or under consideration

A successful kick-off meeting will significantly reduce change resistance in an organisation and help ensure the success of the project.

 

The kick-off meeting should be scheduled neither too early that the basic elements of the project have not been identified, nor too late that the project is already under way.

 

Project duration

The duration of a project can extend from just a few days to even a year or more.

 

The factors affecting the duration of a project are:

Experience of key users in other ERP systems.

If the key people have had experience either from a legacy system or in their previous jobs, the project will be much easier. To make up for a lack of this, consider giving key users general training on business management or ERP systems.

 

Quality of the data to be transferred.

In some projects, significant data cleansing of a legacy systems data may be needed, or data may just not exist in any reasonable format. After starting the ERP project and learning the data structures, significant time may be needed to find out and create part lists and bills of materials etc.

 

Availability of key personnel.

A certain amount of work is needed to implement the new ERP system. If key personnel have too many other commitments, then the project may take longer.

 

External dates

Milestone dates may be set by external factors. A legacy system may have a significant annual renewal fee due, and the project will need to be completed before this. The system may be required to be available at the same time as the change-over of another system, for instance a linked cloud accountancy system.

 

Stage 1 – Prototyping (Long Form Projects)

Opening the account

Open the account from the Manu Online web pages. Because the account can potentially be used by the company in many years to come, it is wise to put some consideration to the initial naming conventions.

Create user accounts for any people in the project team.

While it is possible that different people open their own trial accounts, remember to keep track of which account is being used by the project.

 

Project group training

It is recommended that the person or persons in the project should immediately receive overview training in the system. This will typically be 3 to 6 1 hour training sessions depending on the range of features that are planned to be used. The objective of the training is so that the project people can focus on process design rather than investigating how individual screens are working.

The training can be based consultantcy services offered by Manu Online or by a third party consultant. hereIt is also possible to arrange individual training sessions based on specific business areas.

 

Connecting to the financial system

It is recommended that the account is connected immediately to the live accounts system for reading in the chart of accounts and tax code information. This will not affect or change any data in the accounts system, so can safely be done even in the evaluation stage. Optionally import any items and contacts from the accounts. It is possible to then disconnect the accounts system until later in the project.

Connecting to the accounts system will require a person with “admin” rights in the accounts system.

 

Licensing configuration, system settings and factory setup

Review system licensing configuration so that the appropriate Extensions are available.

Spend some time identifying the correct settings for the various system settings such as payment terms, delivery methods etc.

 

If routing is to be used, identify the work cells in the factory and enter them to the system.

Although the final configuration of these will be confirmed later it is normally not difficult to identify the correct values of these. It is much easier to understand the system and process trial orders if this data is available, and it will normally not need to be changed at any point further in the project.

 

Entering sample data

It is recommended to use real and correct data during the project, or at least a sample of this.

If data can be imported in bulk then it can be wise to import all data from the legacy system

 

Processes and process documentation

Prototyping is stage of setting up the system by one person with at least one product, and running through the business processes of the company with the standard system.

There will be at least one, and normally two or three business processes in any company. They will normally be defined by product family, so if there are no formal processes yet identified, start by looking at the product families and consider how these products are made.

 

The main manufacturing processes supported by Manu Online are make-to-order or engineer-to-order, and serial production (make to stock).

 

It consider how multilevel product assemblies are produced. For instance a final product may be manufactured to order, but different subassemblies may be produced in advance in batches. Remember that spare parts may also have their own processes.

 

When defining business processes, processes improvements can often be identified. Depending on the scope of these, formulate a plan to implement changes as described in the next section.

It is recommended to make simple process documentation for each of the processes. This documentation can be used together with the system documentation for the basis of training new employees (“This is how we use Manu Online in our company”) and can also form the basis for a Quality Manual.

 

Planning the implementation roll out

After identifying the processes, create a plan for how the system will be implemented. Document this plan and get it approved by the relevant people.

 

Planning data migration

Data migration can be simple or complex depending on the data quality, the rate of data change, data quantity, the data entry method and scope of data migration.

• Data quality: is existing legacy data correct? Do all parts have unique identifiers?
• Rate of data change: is data sufficiently static that it can be imported once, or does it need to be deleted from the trial system and re-imported before the project goes live. If data changes very quickly, customised code may need to be developed to get the data moved quickly enough to the new system.
• How much data needs to be moved? Can some data be entered manually, or do all need to be moved using files such as Excel.
• Scope of data migration: will old orders and invoices be moved across to the new system?

Stage 2 – Optional business process development (Long Form Projects)

Now that the key user and project group members have a basic familiarity with the system, focus is turned to matching the business processes of the organisation with that of the system. Because Manu Online is a focused, line of business system and the system has been selected to closely match the business needs of the company, then this stage can be optional.

 

However, the project group may decide that any number of business process improvements may be taken into use to benefit from the features of the new system.

 

Own process development

The concept is that there are two things meeting here:

• Your company’s existing processes and organisation
• Opportunities and efficiencies presented by the new system

So the question is whether or by how much to modify your own businesses processes as part of the ERP implementation project.

 

If it is impossible to get these things to meet, then you should be selecting a different system or buying a customised ERP system. However the best and most cost effective result will come from configuring Manu Online so as best to meet your needs and then establishing the best practices to use it.

 

In most projects we see, the companies have few formal processes, only established practices. So the project will be about own process specification rather than own process development.

 

Data cleansing and data migration

Data cleansing can sometimes add significant time to the overall project schedule. The decision needs to be made whether data cleansing needs to be done or not, and whether the cleansing needs to be done manually or not.

If data cleansing can be done by rules it will be much faster. The rules for which data is to be migrated can be for example “all items with transactions in the last two years”, or better “all items contained in the product structures of our current product offering”

 

Normal data to be migrated are three:

• Items
• Partners (contacts)
• Product structures (bills of materials)

Additionally consideration should be given to whether and how the following are to be migrated:

• Open sales and purchase orders
• Open sales and purchase invoices
• Historical sales and purchase orders
• Historical sales and purchase invoices
• Inventory
• CRM data relating to customers

Historical orders can be imported with a status of “Complete” without having to also import the transactional data associated with them.

 

Data can be imported manually by a technician if it is only to be imported once during the project. If data changes quickly and manual importing would not be fast enough, consideration should be given to developing customised importing code.

 

Numbering systems

Both items and partners require unique numbers. In Manu Online we refer to “Item ID’s” and “Partner ID’s”. Other common terms are part numbers or SKU’s (Stock Keeping Units) and Partner numbers.

Partner ID’s are commonly specified as integers in most different systems. The existing numbers can be imported, or new sequential numbers given as the system is used. The starting number is specified in system settings.

 

In the ERP industry there are two lines of thought regarding items ids. Whether to use significant numbering or not. A significant number is one that includes some form of number that is structured according to the item. So for instance H-1 and H-2 are both hammers and SD-1 and SD-2 are both screw drivers. Manu Online supports both forms up to 25 characters. In practice significant numbering helps the people who are using and entering the numbers, but at some point when there are very large number of items it can become exceedingly troublesome to develop the numbers for new items. Grouping of numbers can also be achieved by using item families.

 

Avoid using customer or supplier numbers as part of your own numbering system. There is support to enter these associated with an item elsewhere.

 

Unlike most data related to an item, it is not normally possible to change and item id after it is created.

When choosing numbers, be aware that these may be used in barcoding later in the use of the system, and potentially by other systems than Manu Online. So it is recommended to not use non-standard characters or symbols are part of the item id.

 

Factory layout

In some projects, a company has redesigned their factory layout to benefit from the processes that they design as part of the implementation project. Typically the layout will consider having specific goods-in areas and inventory locations that are convenient for picking items for production.

 

It is also necessary to consider the location of work stations in the factory. Typically there will be at least one work station dealing shipping and receiving, and one work station in each work cell if work order routing or work time data collection is being done.

 

The company discovered that Manu Online is a process orientated system. They decided to change their own processes from handling orders one by one in the same space to a small continuous production system. The factory was completely emptied and a new factory layout was implemented with a small roller system for building the product in a continuous flow.

 

Report customisation

It is normal to make customisations of reports during a project.

Reports are either pdf reports or analysis reports (excel). Both can be customised. Report customisation needs to be carried out by someone with experience of the specialist report design tools. Because of this, reports are normally customised by the Manu Online professional services team.

 

The most commonly customised report is the work order traveller. Also customisations are commonly made to order confirmations and invoices. Analysis reports have a data sheet and can have multiple pivot table sheets. In order for the pivot table sheets to be configured by default in the required way, it is necessary to store a customised version of the template in the system. This needs to be done by the support team.

 

If any custom properties have been added to items or manufacturing templates, then to include these in reports will require report customisation.

 

Co-development

Co-development may be needed if the system does not have some specific feature that is needed for the business operation. Bearing in mind that Manu Online is a standard system and does not support extensive end user customisation. Any changes that are must follow the logic and style of Manu Online. The results of any co-development work will also be available to other customers after it is completed. Typically a significant co-development work will be packaged as a new extension. Please see separate terms and conditions for co-development work.

 

Data migration processes

Data migration can be divided into 4 kinds of data:

1. System configuration and system settings. These are set once in the project and are not normally imported or changed.
2. Static data such as items, partners and product structures.
3. Dynamic data such as orders, inventory quantities.
4. Historical data

In most cases static data is not completely static but may be slow moving. How quickly this data changes will determine whether it needs to be imported several times and possibly may need tools for import when going live.

 

Stage 3 – Piloting (Long Form Projects)

The piloting stage is when all future users of the system become involved in processing a sample set of orders according to the processes determined in the previous stages.

 

End user training

Before piloting can begin, the end users need to be trained in the system. The training can be made by a consultant trainer or by the key user. It is possible to arrange general training for everyone, or different training sessions for different functions e.g. sales training only for salesmen. Depending on the skill sets of the people, it is also possible to train one-on-one as the orders go around the organisation.

 

At this stage, having documentation of the business processes is very useful. The documentation of the system by itself will of course help to a certain extent, but the own process documentation will tell “How Manu Online is used in this organisation” and will be clearer to end users because it will refer to products and processes with which they are familiar.

 

Piloting the processes and final system approval

Before going live the system should be verified by taking a number of real orders and “walking” them through the process in real time together with the people who are involved in handling them. Depending on the transaction volumes, this may be all orders over a period of time, or just a certain percentage of them.

Also test the connection to the accounts system. By default invoices transferred to the accounts are transferred as “draft” and so can be deleted after the transfer.

 

Stage 4 – Go live (Long Form Projects)

Implementation plan

The system may go live in stages. It is important to clearly communicate with all staff the time table for implementation.

 

This covers also staff who may be away on sickness, maternity leave etc.

 

Plan also to remove, or change to read only, the user rights of staff to the legacy systems. This is to avoid staff accidently processing data in the wrong system.

 

A woman returning from maternity leave had not been told of the new system going live. She naturally proceeded to enter all new orders to the legacy system. It was some time before production staff started to wonder why demand for the product had so suddenly disappeared.

 

Creating user accounts

Create user accounts for all staff with the appropriate user rights. If necessary allocate the permitted login IP addresses and the company to which they belong if a multi-company system is in use.

Ensure that each user is able to login to the system.

 

Data deletion and final data transfer

Delete the data from the system at the level required. For instance if static data is now correct, then just delete the dynamic data such as orders and invoices.

 

Disable the data deletion feature (Admin – Start-up Wizard).

 

If static data needs to be transferred again (i.e. because it is not that static) then the procedures for importing data established in the previous stage need to be executed again.

 

On the day of going live, the key user found that there was no data in the system. On investigation it was found that the CEO had misunderstood the project planning and had deleted all data from the system the evening before. After 2 hours, the data was restored and the go-live process continued.

 

Entering the open order book and inventory values

If the objective is to have inventory control working immediately from going live (i.e. purchase orders and receipts, sales orders and shipping, and production work orders) then it will be necessary to have open orders and current inventory values entered to the system in a short time. Inventory values can be entered manually or by using the inventory transfer excel. Open orders need to be entered by hand. If this is unrealistic due to the amount of data, then open orders need to be extracted from the legacy system and sent to our support team to have the data inserted directly in the system.

 

Resetting system numbers

The open order book is typically entered with the order and invoice numbers generated by the legacy system. After all are entered, go to Admin – System settings and set the next document numbers to the appropriate values, typically one greater than the highest currently existing.

 

Project review and continuous development

Special review of the business processes should be made during the weeks following going live.

Future development should be identified and second stage processes planned with new projects similar to the above. For instance if the first objective has been to get inventory and order books correct in real time, the second stage may be to implement work hour data collection from production.

 

Get in touch about your manufacturing challenges today.