Why is documentation needed?

Implementing a new ERP system, or upgrading to a newer version of the software, is a very time consuming process for any business. More often than not, the time needed for various stages of Implementation are highly underestimated and undervalued, including time needed for training, documentation, and testing. Additionally, in efforts to speed up a go-live date, companies often forego essential areas altogether, such as creating End-User Documentation.
documentationOne of the biggest causes of ERP implementation failure is inadequate education and training. In order to avoid this, and ensure your team is fully prepared for testing and training in a new ERP system, it is recommended that companies create their own End-User Documentation. This documentation helps to ensure the new processes and tasks are understood, documented, and helps the team with testing.

Why can’t your Implementation team write your documentation?

Creating End-User Documentation entails knowing a company’s processes and procedures inside and out, and nobody knows this better than the client themselves. Additionally, creating the documentation helps to engrain the new processes and tasks in the memories of the team members and helps to further engage them in the overall Implementation.

What are the steps to create documentation?

Creating End-User documentation is a large and important task. The good news is that it can be broken down into smaller chunks over time, to become a more manageable project. Additionally, End-User Documentation is a work in progress and continues to grow and change as the Implementation project moves along towards go-live, and beyond. The steps below will help break out the various tasks into manageable pieces that should be integrated into the overall Project Timeline.

  1. Documentation Prep: This should be done at the beginning of your ERP project, before the Analysis/Design sessions. During this time, you should define your users and in-scope departments for the project. You may want to start breaking down each department into various groups. For instance, Accounting/Finance could be broken down into GL, AR, AP, etc.
  2. Choose a medium & create a template: Once you’ve finished with the documentation prep, you should have an idea of the overall outline for your documentation. You can now determine the medium for the document, whether it be printed or online. There are pros and cons for each medium, but for a complex implementation, such as ERP, an online format with links is a highly effective and useful format. You could use hyperlinks for key words, definitions, and graphics to help users navigate through the documentation. Finally, it is recommended that you create a template for the overall document. This will create a cohesive flow to the document with a more manageable look and feel to the end result.
  3. Design Work Flows & Test Scripts: After the Analysis/Design sessions in the Implementation, your new processes are set in place. You need to organize your new Work Flows and Processes and incorporate them into the documentation. A Work Flow is a series of related topics, presented in chronological order, as they occur in your business. An example would be:
    1. Create a Sales Order
    2. Create a Delivery
    3. Post Goods
    4. Create a Billing Document
    5. Enter Customer Payment
    6. These areas would then be broken down further into steps to complete each function, also referred to as Test Scripts.
  4. Testing: The goal for the “first draft” of the documentation should align with the Project Team Training phase of your project. You can have your team use the documentation created during their training sessions, and they can make notes accordingly on changes/revisions needed. This is also the time you want to test the system using the documentation created to ensure the Work Flows and Test Scripts are correct. If you’ve created online documentation, rather than in a printed format, you’ll want to test out the links you’ve created to ensure they are working properly as well.
  5. Modifications: After the Project Team training and testing, you should modify the documentation based on training/testing results and comments. It is also recommended to add a section, or incorporate “most common errors” or “common questions” into the documentation and steps to address those concerns.
  6. Final Testing/Review: After your modifications are complete, the Documentation is now ready for the End-User Training portion of the Implementation. It should be in place for their training and testing. Their comments and revisions should be incorporated as well prior to go-live. Ensure users are aware of documentation and know how to access it,
  7. Post Go-live: Processes and procedures change as a company grows. It is essential that the documentation is updated/changed accordingly as your business evolves.