Importance of Business Process Document in ERP!
Serpent Consulting Services Pvt Ltd is into ERP implementation since 8 years and have been actively working on various ERPs which mainly includes Odoo, Tryton, OpenBravo, ERPNext and TallyERP as main players.
As per our experience, 70% of ERP implementations fail. As an implementer, we see that the main reason is 'analysis' and transparency in showing up the complete business process. The other reason is, Bosses always want the ERP, but the operators/users do not!
Baseball great Yogi Berra used to say, “If you don’t know where you’re going, you might not get there.” This simplistic quote has survived through the years because it holds an undeniable truth – you need to have your direction and goal in mind before getting started or you’re likely to get lost and miss your target entirely. This saying can be applied to countless circumstances in life and an ERP implementation is no exception. Before you commit your time, effort, resources and money to a complex ERP project, you need to have a clear picture of where you want your business to be in the future.
The first step in determining where you want to be is to understand where you are. Knowing how your business currently operates and having business practices clearly documented is important for several reasons.
Knowing what you’re doing today and how it is done allows you to identify the unique differentiating factors that distinguish your organization from your competitors. This is important information to have when you’re headed into an ERP implementation because you can make sure you preserve the practices that provide competitive advantage. Without having your current state business processes documented, there is no way to ensure you are keeping the pieces that make your company stand out in the marketplace.
On the flip side of this equation, when documenting your current state business processes the inefficiencies involved often become obvious. The same exercise that allows you to identify and preserve the practices that give your organization its competitive advantage also gives you the opportunity to recognize areas where you can stand to improve operations. Ultimately, your business process documentation should serve as the foundation for the design of any new ERP software solution.
Even when inefficiencies are less obvious, having your current business processes documented helps to evaluate areas for process improvement. ERP vendors often have their software’s standard practices defined, which you can compare to your business processes by performing a gap analysis. Once you define the gaps between what you’re doing today and how the ERP software would handle a task, you can weigh the benefits and drawbacks to each method and make an informed decision as to how the process should be executed moving forward.
Another advantage of having clearly documented current state business processes is the reduction in the time needed to communicate with both internal and external parties. Whether you’re on boarding an outside consultant so they understand your business, training new employees in your company’s practices or proposing a new way to complete a task to your executive group, a picture (or well-structured, detailed procedure document) is worth a thousand words. This is especially true for complex business processes.
Being able to point to a standardized process document will also eliminate misalignment between individuals doing the same job. Without formal documentation, each employee in a certain functional area may have their own way to accomplish tasks, leading to arguments over the design of new ERP software. Such an inconsistency can wreak havoc on an ERP project’s timeline and budget.
Having clearly defined current state business processes is a distinct advantage that reduces the time, effort and cost associated with an ERP implementation. Clearly defined business processes can streamline communications, standardize system design and serve as excellent training materials. The upfront costs of putting together comprehensive process documentation will not outweigh the benefits.
From client's First: 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.
One 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.
- 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.
- 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.
- 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:
- Create a Sales Order
- Create a Delivery
- Post Goods
- Create a Billing Document
- Enter Customer Payment
- These areas would then be broken down further into steps to complete each function, also referred to as Test Scripts.
- 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.
- 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.
- 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,
- 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.
- Analyze the right processes. Focus first on the ones that are most important to the organization. Also focus on the processes that are broken vs those that are working. Others may have to be analyzed but having priorities will ensure the most value is obtained from the work performed.
- Start with a simple process vs a complex one. Use the simple process to refine your skills at analyzing and documenting the processes and move to the more complex processes as time goes on.
- Identify the key players. Make sure that the those key to the process are involved. We want to ensure their opinions are sought. Even the most clerical person may reveal elements to the process that senior management are unaware of.
- Identify bottlenecks in processes. It is important to try eliminate bottlenecks so they do not remain when moving to a new ERP. Significant value can be obtained from implementing a new ERP but often this value comes from eliminating inefficient processes that could have been improved with the previous ERP.
- Actually record and document the process. Create a process flow diagram using flow chart software or use a pencil and a ruler or just use text but document, document, document. Even if the information is not accurate to begin with the documentation will prove to be invaluable at some point in the future. Check out this document on creating business process flow diagrams.
- Test the above. Have an independent person test the above documentation. Have them walk through the process or observe other walk through the process. This ensure the process has been documented accurately and removes any unintended bias.
- Modify the process documentation based on the testing. Business processes change constantly and will need to be modified constantly. This exercise may have to be viewed as a long journey vs a short trip. For ERP implementation purposes there are many processes that will need to be document quickly so that changes in the processes can be evaluated before the new implementation.