- ✔ - Finance
- ✔ - Sales
- ✔ - Purchasing
- ✔ - Fixed Assets
- ✔ - Business Intelligence
- ✖ - CRM
- ✖ - Inventory
- ✖ - Manufacturing
This is an “off the shelf” solution, pre-configured with industry best practice settings and ready to go quickly. This approach works fantastically for businesses which may not have established formal processes, are looking for a more efficient and streamlined approach to business, or simply a return to a more refined business management solution.
“Kickstart” is a framework methodology: A method of delivering ERP using an existing project template as a framework to provide structure and control to a project, but allowing for a degree of variation based upon business needs.
An ERP project can be a large undertaking; especially for a business which is in a high-growth phase, or one which has never implemented a major business system before. A key objective of any ERP project is to successfully go live on time and within budget. These are the 5 most common causes of ERP projects running over time or budget:
By using a standardised delivery approach, like Kickstart, the above risks can be mitigated; by controlling the scope and reducing the opportunities for “drift” we can significantly increase the probability of project success.
Being phase motivated, adopting a framework and applying a best practice option (whether the default configuration, suggestion of the consultant, or existing internal process) can help to accelerate process implementation and adoption.
An agile project management methodology starts with a “big picture” of what success looks like, but allows for moderate changes of direction along the way; this methodology allows for small “tweaks” and tuning, with consistent monitoring of priorities, activity and change control. The Association of Project Management has extensive materials on this approach to help you determine whether it is right for you.
Having a standard framework to start from eliminates much of the “undifferentiated heavy lifting” of a project and helps reduce cost. By identifying the commonalities in a typical ERP project we can duplicate common outputs, therefore reducing the input required; helping us speed up implementations and deliver a solution with proven success, rather than encouraging excessive diversity of process and trial and error improvements.
A structured framework is a starting point, with the skeleton of best practice already in place, however, best practice is different for each business. Not all warehouses need handheld scanners, not all finance departments need automated invoice scanning and processing – and while both of these may be “best practice” for Business A, both may be redundant in Business B (perhaps due to low volumes). Not all businesses are at the same stage of their journey, a rapidly growing start-up will not have the same entrenched processes as a mature business.
Typical ERP projects last between 6 and 24 months. This is a broad range, with ERP meaning different things to different businesses, therefore comparing your project against “typical” may not be helpful. However, it can be assumed that the faster that you can get started on the new system (with the desired benefits being delivered) the faster your business will be receiving value from the project.
By using a standard approach many “unknowns” are removed or controlled, as it brings previous project experience into the template and bridges gaps where unknown-unknowns can often sneak in. This helps to address many of the failure points detailed above.
As the age-old adage goes: Time is money. The cost of an ERP procurement has been speculated on for decades, with metrics of software:services being estimated at 1:1, 1:1.5, 1:2, etc. However, supplier costs are only part of the cost of the project, internal costs often exceed the external expenditure on long projects.
Each passing month on a project not only elongates the supplier cost, and the internal resource cost, but also the opportunity cost of having received the benefits of a new system.
There are some specific measurable benefits that can be seen; even when other services are not being delivered, even when a project is in hiatus, there is likely to be a project management overhead for every week/month that elapses. In order to re–plan & restart project activity the PMs must be involved throughout, even in low-activity periods.
There is also a general rule of human forgetfulness, long projects tend to require repeated phases of testing and training as the users tend to forget the new system if not “touching” it regularly. This repeated activity also drives up project costs.
Being able to look back at the origins of a project and clearly identify that the pain points have been ameliorated, the desired outcomes have been achieved, and stakeholder goals have been reached is an ideal result for a project. This is, self-evidently, only achievable if the goals have been identified, the desired outcomes mapped, and the pain-points documented.
By starting a project with these things, and then implementing scope control (using the mantra “does _______ help us achieve the stated aim of ________?” in control meetings), will allow one to measure success at the end of a project. If everyone knows on day one of the project that the CEO wants dashboard reporting then it should come as no surprise at the end of the project that if the dashboards are not delivered the the CEO will not see the project as a success. The likelihood of this occurring if the aim becomes integral to the project (i.e. this outcome is kept in mind as the project continues e.g. asking the following throughout “are we capturing the data for a dashboard?”, “do we have a way of measuring x?”, etc.).
Project success can only be achieved if your business knows what success looks like. Similarly, scope can only be controlled if a) scope is known, b) desired outcome is known.
There are clear benefits to adopting best practice, those being: modernisation of process or introduction of process, and standardisation of processes across the business. The problems in different businesses may be different, however they can be viewed in the same way, with the same solution.
This is not a glib suggestion that the ERP supplier knows best, but rather pointing out that a large amout of time can be automatically saved by cutting out extraneous dialogue and prevarication over what the best approach to take is. If in doubt, start at “best practice” and go from there. This has the benefit of saving internal and external resource time, and can take the “heat” out many decisions by removing personalities and introducing an objective start point.
A hidden, but non-trivial, benefit of adopting a standardised delivery methodology is that the supplier is more capable of swapping resources within a project, flattening the learning curve on a new project, allowing easier hand overs, and collaboratively improving the framework.
This significantly increases the resilience of this project by bolstering the supplier resource. This interoperability of resources also allows for the introduction of new ideas/best practice from other consultants/PMs, etc. as more people can be easily involved in the project.
Service days: 80
Delivery timeline: 6 Months
Service days: 110
Delivery timeline: 9 Months
Service days: 140
Delivery timeline: 12 Months
© Copyright Mysoft Ltd – 2024