By now, the team at SynControl has helped tens of companies improve their QA/QC processes by implementing our quality inspection software. And I thought I would write about a few lessons we have learned along the way. I’ve condensed our best practices into 8 ‘rules’ for manufacturers and buyers to follow when performing new software implementation and process changes.
If you are planning to adopt software (e.g. a new ERP or PLM system) and digitize your processes, this will help you set the right expectations and staff the project appropriately.
(Note: this might be overkill for an expense tracking tool like Expensify, where there is very minimal process change.)
Rule 1: Only you know about your specific situation and needs. Start from that.
There are often similarities between the operations of different organizations, but there are also stark differences. It is crucial to clarify your needs in writing (use flow charts and swim-lane diagrams as much as possible), or to engage a consultant as needed for that purpose. As a bonus, you’ll probably want to check if your processes can be streamlined or simplified…
If you need outside help, you can hire a systems integrator (usually the best option to ensure your systems work well together), or a consultant with deep expertise in what the users will need (usually the best if you want to change your processes deeply at the same time).
Once this initial planning is done, you are in a much better situation to assess potential solutions and select the best fit for your needs.
Always start from your own needs. One common mistake is being seduced by a salesperson laying out a grand vision that might not be realistic or desirable for your company!
It often makes sense to document future (improved) processes at the same time as you look at ways existing solution would allow you to work. It is more efficient than working sequentially, and it avoids the trap of excessive customization (see rule 6 below).
Always start from your own needs. One common mistake is being seduced by a salesperson laying out a grand vision that might not be realistic or desirable for your company!
It often makes sense to document future (improved) processes at the same time as you look at ways existing solution would allow you to work. It is more efficient than working sequentially, and it avoids the trap of excessive customization (see rule 6 below).
Rule 2: You need to define special cases, and then arrange tests with real data.
This can be hard for your people, especially if they don’t have a view of your processes as a whole and if they have been working in your company for many years. Again, a consultant can help.
I found that many managers are not familiar with the way their staff work. When we speak with the people doing the work, they often ask “can it do this?” and “what if that happens?” types of questions. That’s great — they are thinking of special cases and telling you about them!
I found that many managers are not familiar with the way their staff work. When we speak with the people doing the work, they often ask “can it do this?” and “what if that happens?” types of questions. That’s great — they are thinking of special cases and telling you about them!
The software vendor will probably ask you questions along the way and guide you in the right direction, but your staff needs to be deeply involved. Which leads me to the next important point.
Rule 3: You need to assign key user(s) and free up some of their time.
These users need to be familiar with current processes and able to understand and accompany change – and you will have to free some of their time.
Yes, it means you need to pick some of your smartest people and re-assign some of their day-to-day work. In the long run, a well-thought-out system implementation will be worth gold for your company!
The number of hours to devote to this new project will vary. In the case of a standard SynControl onboarding in a midsize company, it is 8 man-days total for office staff, spread over 3 weeks. In case of a heavy ERP such as SAP, it is weeks of work for many employees.
These key users need to get training on how the new solution works in their functional area of the business, they will provide feedback, they will run tests, and then they will show their colleagues how it all works. Count some time in the first few weeks after the new system is in place, too.
Ideally, there is also a ‘champion’ assigned to the project — someone well respected who knows the organization and is highly motivated to succeed.
Yes, it means you need to pick some of your smartest people and re-assign some of their day-to-day work. In the long run, a well-thought-out system implementation will be worth gold for your company!
The number of hours to devote to this new project will vary. In the case of a standard SynControl onboarding in a midsize company, it is 8 man-days total for office staff, spread over 3 weeks. In case of a heavy ERP such as SAP, it is weeks of work for many employees.
These key users need to get training on how the new solution works in their functional area of the business, they will provide feedback, they will run tests, and then they will show their colleagues how it all works. Count some time in the first few weeks after the new system is in place, too.
Ideally, there is also a ‘champion’ assigned to the project — someone well respected who knows the organization and is highly motivated to succeed.
Rule 4: Think in stages, and beware of ‘big bangs’.
The last thing you want is a serious disruption of your operations, with users unable to do their daily work. Go for little steps and keep risk low.
For a simple onboarding such as those we handle, the following sequence often makes sense:
- Company shares their current templates, their current checklists (if any), etc. and describe the way they work. The more details, the better.
- Phase 1 – get 2-5 users to use the new system daily, to do the 1 or 2 types of jobs they do most often. Get that process to work from A to Z (e.g. from data import to statistics and issues management). Work out the kinks, document how it works.
- Phase 2 – ramp up to all other users of those 1 or 2 types of jobs, and handle another type of job. Again, make it work smoothly and document.
- Phase 3 – same as phase 2 on another type of job, as needed.
For complex implementations (costing upwards of 50,000 USD), the steps often look like this:
- Initial planning – workshop for clarifying the needs, getting to know key users, writing and approving the specifications & quotation, etc. This is usually the last phase of vendor selection (which includes some other, preceding, steps).
- Feasibility study – only in case the software vendor promises to (or is requested to) achieve something that is technically challenging.
- Pick the first modules to implement — changing all processes at ones is usually unrealistic. What is important, to keep users engaged, is to avoid any regression (e.g. giving them more manual work) compared to the current process.
- Customization & configuration — a systems integrator and/or the vendor and/or other systems that will have to interface with the new software need to make changes.
- Kick the project off, and make sure all involved parties understand the benefits of the new solution.
- Pilot project in team A – get a few users to run test data in the new system,
- Pilot project in team B, etc.
- Further customization & configuration, as needed,
- Testing – to be repeated in a loop until all basic processes can be run and all the frequent “special cases” can be handled.
- Training and ‘Go Live’ – everybody stops using Excel (for example) and uses the new tools — this often includes some troubleshooting,
- Stage 2 – for other modules to be implemented, start steps 3 through 10 again.
- Stage 3 – same as stage 2.
Rule 5: There is a need for project management.
When a consultant/systems integrator is involved, they typically spend 15-25% of their time doing project management: keeping the plan applicable and updated, reminding users of deadlines, checking that milestones have been completed, looking at issues and thinking of the best response, reminding people of the scope that was agreed on, etc.
Don’t underestimate the time this will take, and don’t think the software vendor will do this for free. For example, we allocate some time for this during the onboarding and during a limited period, and after that we still do some work for free but within certain limits and only if the customer is really doing their share.
Don’t underestimate the time this will take, and don’t think the software vendor will do this for free. For example, we allocate some time for this during the onboarding and during a limited period, and after that we still do some work for free but within certain limits and only if the customer is really doing their share.
Rule 6: Avoid heavy customization if possible.
Some customers like to ask “is this possible?”, and yes, generally everything is possible… yet, it doesn’t mean all ideas as good.
I want to make two points here.
First, when it comes to heavy software implementation (think: ERP system), more customization is more expensive and causes more need for re-work when the underlying code is upgraded. I have seen many companies stuck on an older version because “we paid for a lot of customization that didn’t work with the new version, and we’d have to pay all again and go through the pain of testing etc. again”.
I want to make two points here.
First, when it comes to heavy software implementation (think: ERP system), more customization is more expensive and causes more need for re-work when the underlying code is upgraded. I have seen many companies stuck on an older version because “we paid for a lot of customization that didn’t work with the new version, and we’d have to pay all again and go through the pain of testing etc. again”.
Second, good software usually has a logic — one could call it “an opinion on the way things should be done”. If you are evaluating a solution that will tend to gear you in a direction you don’t like, don’t ask them to accommodate a totally different logic. You have simply looked at the wrong system.
A corollary of this rule is, go for low-complexity solutions whenever the higher-complexity approach doesn’t bring much benefit. We see this all the time with direct pull & push interfaces into other databases. In 90% of cases, a very similar result can be reached by importing & exporting Excel files (no need to jump through security hoops, no need to have expensive ERP consultants do work that will need more fees to be adjusted down the road, and so on).
Rule 7: It is process change, and management needs to be involved.
‘Leading by example’ is a common phrase, yet I don’t see that behavior very often. If, as the manager, you don’t show much interest in the new tool, and you can’t even perform the most repetitive & basic functions in it, your team will take notice.
As I wrote above, pick smart people, and if possible people who have gathered experiences in several organizations, as key users.
Also, incentivize the team properly. Make successful adoption one of the users’ KPIs. Congratulate them formally or throw a party. There are many things you can do to motivate people.
You really want to avoid having a mandate come from the top and a team “too busy to work on this”.
As I wrote above, pick smart people, and if possible people who have gathered experiences in several organizations, as key users.
Also, incentivize the team properly. Make successful adoption one of the users’ KPIs. Congratulate them formally or throw a party. There are many things you can do to motivate people.
You really want to avoid having a mandate come from the top and a team “too busy to work on this”.
Rule 8: Define what is “success”, and measure it (before/after).
In the case of SynControl, our customers often want some tangible and direct benefits:
- Free up 1 person in the office
- Have much greater control and visibility over daily work
- Ability to pull out data and visualize them in a useful form with minimal effort
All these are easy to track and confirm, say, 3 months after onboarding is over.
When managers are ambitious, they also want to fine-tune their processes and show time savings (and direct cost savings). This is possible too, but the ‘how’ needs to be clear from the start to all parties.
When managers are ambitious, they also want to fine-tune their processes and show time savings (and direct cost savings). This is possible too, but the ‘how’ needs to be clear from the start to all parties.
As I wrote above, use these also as KPIs for the internal team. If they are not motivated to hit these results, will they help?
——
I hope all this is helpful. You may have heard, as we have, about failed implementations that cost hundreds of thousands of dollars in fees and major distractions for long periods of time. Following these rules will raise your chances of success.
Do you have any specific questions about handling new software implementations or process changes? Perhaps we can help? Feel free to leave a comment, or contact us for a confidential discussion.
