Login
We recently underwent a long-overdue, company-wide review of our standard operating procedures, key role definitions and other key documents. A painful exercise, much hated by everyone!
One realization that our executive team shares is that the gap between tacit knowledge of employees and documented knowledge is still really wide. One key reason why every new employee takes at least 1 month to learn, and 3 months to be productive.
While our documentation is mostly MS Word and Excel spreadsheets saved on shared folders... we are divided on whether the use of more sophisticated tools (like Wiki, or paid SAAS solutions) will lower the erosion of knowledge during documentation, make it easier to maintain and eventually make us more agile.
Thanks for your thoughts, and Happy Thanksgiving!
Transforming Ordinary firms into Extraordinary firms by Turning Roadblocks into Roadmaps
The problem is not is the medium but the methodology. It is not the tools but the techniques. You need to approach this like any other "process improvement" initiative:
1) what is your end game or goal;
2) who is the "Process Champion" who will drive this regularly from the 30,000 foot level;
3) who is the "Process Owner" responsible for leading the team who will document all processes, procedures & metrics;
4) prioritization as to what comes 1st, 2nd...;
5) a "Document Manager" as a central control point for the database & who handles version control.
Start here and the future of your SOPs will become brighter.
We do a lot of process improvement and knowledge management projects for clients and your experience is not unusual. To keep it easy to maintain and to have good version control, we normally maintain the process documentation in MS Word and MS Visio, but publish it out as PDF (to prevent users from modifying it).
If the process or procedures are changing a lot, then I can see using a Wiki or other more flexible solution as you've noted. However be careful about empowering employees to change a process without oversight; especially if the process is related to governance or internal controls (financial, operational, or compliance) because it can introduce risk into your organization.
Another technique that we've used is instead of publishing a single PDF for Standard Operating Procedures (SOPs), is to break up the SOP into logical chucks and pair these with links to the actual systems where the tasks are performed. This can be a basis for providing just-in-time guidance and learning for a new hire. This does however generally require that your systems are delivered via the web or that they an be invoked from a web page.
Consider a supplement to the documented procedures, worksheets and process charts: VIDEO.
We once conducted 20-30 minute interviews of a client's accounting staff as a test to ascertain how much "documentation" can be captured from current employees. If organized properly, an employee can sufficiently summarize and detail, with visuals, the amount of "work" they perform on a daily, weekly and monthly basis.
Because this client was in a very competitive staffing market, his turnover was higher than normal. New hires would view the recorded videos of their predecessors and their learning curve shortened measurably.
Senior Management Consultant, Cascading Risk Management (CRM) Expert, Trainer, Speaker and Writer
I was the worldwide VP of Engineering for a large international automotive safety restraints design and manufacturing company. We designed, engineered and tested advanced seat belts, air bags and crash sensors for almost every car company in the world. It's not the kind of stuff every engineer learns in college. It is very specialized knowledge. One day I was struck with the realization that, like you, we did not have the right documentation to cover the tacit knowledge of about 17 different high-end experts I had in one R&D engineering group. Some of these people were about to retire and I needed a solution to capture their undocumented expertise that everyone was afraid to ask them about.
I mandated that these 17 irreplaceable "experts" immediately start to write a 2-5 hour class about their undocumented expertise. I was not worried about how pretty or casual the class training manual was but I wanted them to write one for each class. Classes were scheduled and video-taped so we had their knowledge on record. New hired engineers were told which specific taped classes to study. Other employees could watch the recorded classes any time to hear the tips and tricks of the experts.
As a department head at the time, I slept much better at night after this process was completed. Key knowledge not documented in SOPs was finally documented and safe for future use.
I might suggest focusing less on what % is documented vs applying the 80/20 rule to onboarding.
Here's the approach I've found has worked:
1) identify key roles - which roles are critical to onboard folks most quickly? (which roles lead to the greatest sales or productivity increases?)
2) identify the "must know" info from the "nice to know" by week or month post start. Your current team can build this for you.
3) Develop an onboarding schedule with key training conducted by a combination of the manager, functional managers, and subject matter experts. Training materials can be developed by current team members.
This approach will allow you to prioritize the development of new onboarding processes and materials by job resulting in the greatest business impact. I would also advise you set KPIs for each job so you can measure the success of your new onboarding. For sales, it could be time to close the first sale or size of sale. For marketing, time to build a communication plan or execute a key campaign , for IT key SLAs, etc.
