ERP Implementation

Documenting Your Current State Processes

Documenting your current state processes is a critical step for ERP projects. This will not only help inform how the business functions, but through the documentation, you will expose all kinds of inefficiencies and pain points that can be used to paint the story of the value of the project. To sit on this point for a minute, in order to proceed with the execution of your project, you will need to be able to provide concrete, quantifiable financial savings the project will bring. This will be difficult without understanding the "as-is" processes.

The Underrated Benefit: Trust

When people trust you, they work with you because they want to.

Another key, underrated benefit (omitting the obvious need to understand business processes before jumping into the project) is making stakeholders feel heard early on and gaining their confidence that you understand them and their needs. This will greatly improve your change management overall, as well as project participation. When people trust you, they will work with you in a much better way. It won't matter that their boss tells them they have to. They'll want to. That's a big deal.

How Much Is Enough?

Deep enough to capture what makes the business unique. Stop before the meeting rooms.

There's a good deal of discussion on how much to document and at what point you are in analysis paralysis. Many vendors nowadays focus on showing how the new process may look in the system, then asking the business what's missing to identify the gaps. The problem with this is you still need some baseline understanding of the current state processes to execute the program and, as mentioned, gain trust with the business. Focus on documenting deep enough to capture what makes the business unique and where key pain points lie, and stop before you're capturing how to book a meeting room. But avoid feedback that nothing needs to be documented. That will lead to people who don't understand the business trying to implement an ERP system by asking "why won't this work?" The issue isn't the method, but the fact that the conversations will be endless if they don't have a global view of how the business functions.

Building Your Checklist

Cover the core, cover what makes the business unique, and check what already exists.

As you build a checklist of what should be documented, think about a few things. Firstly, core business processes that directly relate to ERP should be captured. These include things like invoicing, payables, and core business operations. If you are at a manufacturer, cover the manufacturing process. If you are any business that handles physical inventory, include that. If you're a lessor, document the process to go from opportunity, to quote, to assignment of equipment. And so on. And lastly, be sure to check with the business on what kind of materials they already have so you can have a jump start! Just mentally prepare for nothing to be available.

The Six-Step Process

From confirming stakeholders to formal sign-off.

Below, you will find the process I like to follow to document current state. Use what you like, but there is certainly some opportunity to adapt your own preferences based on how you like to work.

1. Confirm the stakeholders you should be talking to. You may get this information from someone who has a good read on the organization, or the team in question's lead. Be sure you are actually getting the person who is hands on, doing the work. They will always know things the leads are not aware of. And those details will often be the key details you need to know for your project. On this, bear two notes in mind. The team lead will likely appreciate your heads up / request prior to their employees spending working time with you. Second, strive to only have people involved that can provide value. The more people you bring in, the more difficult the sessions will be to run.
2. Send an introductory email to your stakeholders (again, after having confirmed with their lead). Explain what you are doing (including the process) and why. On the why, subtly work in why it is in their interest to spend this time with you. Be sure to also give a general estimate on how much of their time you will need. In most cases, it shouldn't be more than a few hours in total.
3. Schedule the first session and plan ahead. Get a plan in place for what details you need to gather. You must know how you want to visualize the information in your diagrams. A few key things to capture in these steps are things like persona, technology used, inputs / outputs (this could also just be at process level, not step), and so on. Most commonly, swim lanes are either tech or persona. Without knowing everything you want for this, you may not run the session smoothly and you will likely miss key details you need, requiring additional conversation.
4. Execute the session. Have them talk through the relevant process. If they can show a demo, absolutely do this. It will seriously enhance the information you are able to draw. During the session, take notes. I have two primary ways I like to do this. Usually if I am completely fresh to the process, I like to set up some quick columns in Excel and track the steps there. That way, I can make sure I am catching all the relevant details for each step because if I miss something, I will have a blank cell in a row. Sometimes, I will take notes directly in the design tool. I especially prefer this route if it is a more complex process with a lot of decision points because that is more difficult to capture in my linear Excel method. And don't forget to record!
5. Build and refine the diagram based on what you captured in the session. If you executed the prior steps properly, this should be the easiest one, as you copy from your note taking method to the design tool.
6. Review the flow with the stakeholders. I usually handle this one of two ways depending on complexity. If the process is relatively simple, I will usually just send it out and request confirmation of accuracy or key points to fix. When the process is more complicated, I schedule a review session to go through it live. After this, I will email the final result and request the same formal sign-off.

Follow these steps for each of the processes you need to capture and you will have an inventory of well-captured processes in no time.

Organizing Your Outputs

These documents will serve the project for a long time. Treat them that way.

The last thing to consider here is organization. I can share from experience that these processes are many and will be used for a long period of time to cover many needs of the project. This means thought and care must go to how they will be organized.

Obviously, they should be easily accessible to whoever would need them. But the question is, do you keep them in the design file formats, or take the time to copy them into PDFs then share in a folder? If most of the consumers will have a license for the design tool, I simply keep them in the file format. Converting to PDF just adds a step for when you need to go back and make edits.

What I will end with on this topic of organization, is if you have more than a few processes captured, I strongly recommend producing an Excel inventory that makes it easy to find processes based on key variables (persona, business function, business unit, etc.) to make them self-serve and easy for others to find.

The Payoff

The effort you put in now pays dividends for the life of the project.

Put a lot of thought, time, and care into this process. The processes you document will be used for many purposes on the project, from onboarding the vendor to conducting fit-gap analyses, identifying pain points, and measuring process improvements. Oftentimes, the stakeholders even like to take them back and use them for training new team members. The more effort you place into it, the more effective your outputs will be.