![]() |
![]() |
||||||||||||||||
![]() |
When
you purchase a software package, your re-seller will assign a project
manager to plan and coordinate their personnel who will be part of the
delivery of your project eg installation, training etc.
So what value does mooooch bring that is not part of the re-sellers project manager's brief? We have a great deal of experience managing implementations and sit on your side of the fence rather than the re-sellers. You are running your business at the same as the implementation is progressing and it will impact on your employees time at some stage. We make certain this is kept to an absolute minimum. The re-seller is also trying to run a business, but their business is software implementations and as such it is important they understand your needs and to work to your time lines not theirs. We also bring considerable expertise in writing validation reports and ensuring your data is put through a series of trial transfers into the new software's database, way before your 'Go Live' date. We organise and tailor your training programme with the re-seller to reflect your business processes, working on your data, rather than a demonstration database. Keeping your employees in the loop on how the implementation is progressing, canvassing their opinions and informing what is expected of them. In a nut shell we want your new software to hit the ground running, to give it the best chance for maximising its value for your business. Here are a few guidelines we use when managing a software implementation for clients. |
||||||||||||||||
Manage the project to fit your timescales rather than the re-sellers. Most re-sellers have multiple projects running at the same time, consequently their projects are competing with each other for resources. It is important that a regular dialog is maintained with the re-seller's project manager to ensure your project is reflecting your time lines. Do not purchase modules in the software package that
you are not going to use immediately, if they are needed they can
be bought later. You will be too busy familiarising yourself with
the basic package at the start and not have time for learning any
specialist modules.
Review the situation again after 6 months after all the systems have bedded down and everyone is comfortable working with the package, to see if these specialist modules would be beneficial to the business. You must make time for your employees to learn how
to use any specialist modules, or you will not be maximising the value
of your investment. All modules will have a support contract attached
and any you don't use or use ineffectively will be a waste of money.
We have seen too many software investments fail by organisations not allocating enough time for a package to be completely understood, don't make this mistake.
Try and resist purchasing bespoke changes to the software from
day one. Many organisations once a software solution has been purchased
have a tendency to want it to reflect their working practices, or
alternatively the working practices dictated by the previous software.
We can help you examine your processes to see if they can be easily changed to reflect the new software, the package will most likely do what you require, but in a different way. We would recommend using the system for 3 months and if a particular business process is still causing a problem then investigate whether a bespoke change is warranted. It is worth noting that bespoke changes nearly always impact the release of a new version of the software. Quite often the changes will have to be reflected onto the new version. Taken overall, keep these customisations to an absolute minimum, they can be a version upgrade headache you can do without. Involve your employees on the progress of the implementation,
canvass their opinions, identify business process inefficiencies and
see if there are ways the new software can resolve them.
If people are felt to be part of the implementation process, they will work towards its success, and it will be a success! Here are two real life examples of software solution implementations, one good and one bad. Bad - A solution was purchased and all operators were given training, there was no consultation with them regarding how their business processes they were responsible for, would be handled by the new package or how any processes could be improved. After 'Go Live' they continuously gave reasons why the software was no good, change is bad thing when forced on people, in addition everyone likes a good communal moan and this was it. Good - Same system, same set of operators. They spent a lot of time each month producing reports to their line manager, and a new set of automated reports were being proposed. This time they were asked opinions when the data could be retrieved, how its accuracy could be improved. Change is now a good thing because they were part of the decision process, if the project fails it reflects badly on them also. As a consequence they were very pro-active in putting forward solutions and made it a success. This time they had to have a communal moan about something else ! Training for the new software should start early on and be a continuous
process throughout the implementation, gaining in detail as the
'Go Live' date approaches.
Once the software has been purchased give your employees who will be using the new system (targeted at each operative work group) an overview of what it is going to achieve and also what their functions will be. Give monthly updates on how the implementation is going, both good and bad. A month before the 'Go Live' date, give details on how they will perform their tasks within the new software. Use data from any practice data take on's that have been completed, to make your training as real as possible. Two weeks and also one week before the 'Go Live' date, detailed training should take place on how to perform their specific functions on the new system. The take on of data for a new software solution
(populating the new database with for example, customer information),
is one of the most underestimated tasks regarding time. Whatever your
re-seller allocates for this task in reality it will probably take
twice as long.
At mooooch we have accumulated a lot of knowledge in this field and we never underestimate the complexity of a data take on exercise. We understand what tools will be used and how to use them and would encourage the re-seller to start the data take on well in advance of the 'Go Live' date. Depending on the type and volume of data, it may be quicker in the long run to key the initial data directly into the new software package, so take a view on each type of data. Run some time trials on how long it takes to key in say 10 items. However, beware keying the data will almost certainly have input errors, so include some time for validating your data in your time trials.
Whether your data has been transferred manually or electronically,
you will need some quantitive way of measuring and/or reporting
that the data has transferred from your old system to the new correctly.
In the case of financial ledgers this is a relative simple task
(eg for a sales ledger sum the total debt), however for other data
it will most likely be reports.
Ensure you have these reports written and tested at least a month before your 'Go Live' date |
|||||||||||||||||
Give your new software the best start for maximising your investment by letting mooooch manage your implementation. | |||||||||||||||||
|