Designing an ERP from Scratch with Ken Randall

There comes a time in the life of a young and successful manufacturing firm when disconnected homegrown systems and spreadsheets aren’t enough to keep up with the volume of demand. That’s when people like Ken Randall come into the picture. A business analyst, Ken helps companies create ways to streamline the way they do business and make sure their high-quality products are delivered on time—every time. A couple of years ago, Ken was called in to do just that for Element Designs, a manufacturer of custom cabinetry based in Charlotte, N.C. He and his team’s solution was to customize and implement an enterprise resource planning (ERP) system from the ground up. The system he envisioned pulled together many different parts of the company, from handling tailored customer orders to managing raw material inventory levels to manufacturing to shipping. For a small company like Element Designs, this was a daunting project. Here’s how Ken and his team at Flying Bridge Technologies, along with partner iFensys, did it.

The Project

Element Designs makes high-end custom cabinetry. Their products are made to order from highly precise specifications provided by architects and builders. The company was facing year-over-year growth but there was no way their manual processes could handle the volume and maintain their attention to quality details. From handling customer and manufacturing orders to managing raw materials inventory levels to shipping, it was clear the company needed to implement an Enterprise Resource Planning (ERP) system.

The Challenge

This ERP implementation was an extremely large undertaking for a small and relatively young company. They had committed a good deal of their limited resources—both dollars and time—into the success of this project. So the pressure was on to get this right the first time. Failure was not an option for this company.

The Team

Because this project was so critical to the company, we had a team of 14 people. That included the company’s entire top leadership team of six executives, along with four key department heads. We also had a lead consultant, a process engineer, a technical architect lead, and myself as the senior business analyst. I was involved from the beginning, helping to identify the business case and developing the initial needs assessment. There were other people who floated into the project as needed, but they were not involved in the design, modeling, mapping, decision processes. That said, 14 people on the same page was no small feat, which meant that we needed a tool that would help communicate all the complexity of an ERP project. We chose Axure because it let us communicate with everyone in the company, and it was a tool that we could use throughout the project lifecycle.

The Kickoff

Once we got buy-in from the company’s leadership, we started the project with a workshop consisting of six clear-the-decks days, spread over two weeks, to get a clear picture of the current state of the company’s way of providing products. We started by taking apart the business processes and documenting them in Axure. We had configured a number of templates and had organized the page hierarchy for the various processes and sub-processes to use for this workshop.

Moving from page to page and creating links on the fly in Axure, we were able to model in real time, at the pace of the workshop discussion. So there was no need to go back at the end of the working sessions and try to capture what was said, because we already had it captured during the sessions. At the end of the day, we just published the working models to Axure Share. As everyone already had the project link bookmarked in their browsers, it was a simple matter of refreshing the page to see the latest process models.

Improving the Flow

Process flows are the stock and trade of business analysts. We use them to define how something gets done and communicate that with practically everyone on the team—executives, business users, process engineers, tech leads, developers, QA testers, implementation teams and operations, to name a few. We also use business requirements documents to clarify the mission (the why), specifications (the what) and wireframes (the how). In the past, those elements were presented in separate documents, often in different formats—spreadsheets, illustrations, text, slides and so on. This made cross referencing information a big challenge, and created situations where documents sometimes had contradictory information.

For this project, we decided to produce a single file in Axure that would convey the information normally contained in many of these deliverables. Our document had process models, often separated into functional flows via “swim lanes,” systems information, and high-fidelity screens that with entry forms. The file also contained a functional prototype of a new online tool that customers could use to configure their custom cabinetry to exact specifications.

Business teams can see at a glance the interaction of systems and process. Along the process, they can drill down by clicking through to see more in-depth information, such as the screens and forms, user personas, the relevant business rules and so on. Or they can stay on a high level to get the big picture. Either way, stakeholders don’t need to hunt down another document to get the information they need.

Getting Everyone on the Same Page

As we laid out the end-to-end process in Axure, we found a number of instances where the left hand of the organization had a different mental picture of the business process than the right hand of the organization.

In this project, for example, this cropped up when we discovered through our flow analysis that some products had to be sent via expedited shipping to meet a deadline, even though it was the customer who had not approved the order in a timely manner. This was often because the up-front process was not being done in the right order. The Customer Service team set an expected ship date first and later asked the customer to approve the final order. More often than not, the customer approval was a day or two late in coming back, but the ship date was already established, and customer expectations were already set. For the Production Team, the only way to make up the time was to use express shipping – which added cost to the project and cut into the profit margin of the project.

We find that putting the details of the business rules and UI on lower-level pages, allows us to keep the process flow diagram clean and readable. The details are abstracted into separate pages, but when published on Axure Share, are just a click away.

The Customer Service team did not know that this was happening until we walked through the end-to-end process. Once it was laid out for all to see, everyone came to understand the underlying complexity—a key first step in simplification. We were able to surface several instances like this where one process had unintended repercussions elsewhere.

To get everyone on the same page, we use the second major tool of the business analyst—business rules. Business rules are the logic and the rules of thumb that we use every day to make decisions in our jobs. Most of the time we don’t even think about them; they are decisions based on our experience or gut feelings. Business rules automate that process with the goal of helping everyone be consistent and improving efficiency. As business analysts, our job often boils down to identifying the need for such rules, defining them, and then documenting them in a way that’s simple enough way for non-technical team members can easily read and understand.

This is accomplished through flowcharts for the logic and decision, matrix tables to show conditions and options, and screenshots of the UI to show how users would see the information. In the past, that meant having to jockey multiple documents to see the entire picture—a word processor for a high-level summary and description, a spreadsheet to see the list of rules, a diagram depicting the flow, and image files to show screenshots. We were able to consolidate our documentation into a single file, using Axure. From a page presenting a process flow diagram, you could click an icon that lets you see the relevant business rules. Another click takes you to the UI mockup. We find that putting the details of the business rules and UI on lower-level pages, allows us to keep the process flow diagram clean and readable. The details are abstracted into separate pages, but when published on Axure Share, are just a click away.

In this particular instance, we designed better visibility into our process flows, which called for earlier and better information provided by the ERP solution to what was. This allowed the Customer Service Team to help set customer expectations before orders were committed, while allowing the Production Planning Team to have a more time to make priority changes in the production schedule.

Takeaways

Simple presentations are key for engaging executives in complex ERP projects. Element Designs had never modeled its processes before, and they were frankly leery of the need for such an up-front step. A great experience was required to prove the time spent would be worth the effort. Having the text, data, diagrams, UI, and related information in Axure RP as a central repository for all requirements, we were able to streamline the process and simplify it greatly for our client.At first, the publication of the process and screen mockups was thought of as an internal capability, between the business analyst and the development team. We quickly learned that the ability to publish to the client for feedback and validation turned out to be a huge win – saving a tremendous amount of time. At the end of every session, we were able to instantly publish the session’s work. And since the client already had the Axure Share URL bookmarked, all they needed to do was refresh the screen to see the changes.

Having a single file allows us to collaborate in real time. This saves us the need for us to gather as much information offline as we would have had to otherwise. As we collaborate, we’re able to make the changes in the document right then and there.

Business rules are key to communicating with developers. If you take the time to write and document the rules properly, the logic you create during the process can be easily translated into a series of case statements and if-then statements in the ERP software code, making the job of the programmer much easier and faster.

Specifications often can be reused as training documents. We were able to create a final overview version of the process that was used to train the production team on what the process looked like from 30,000 feet. We had not planned to do this at the beginning of the project, so it was a good win-win reuse of the definition requirements.

In the end, having a single document capable of communicating relevant information to all stakeholders saved us a lot of time, and it helped to make sure everyone from the CEO to the production manager were aligned and, quite literally, on the same page.

About Ken Randall

Ken Randall has over 25 years of experience developing enterprise business processes and technologies. Throughout his career, Ken has been called on multiple times to resolve crisis and turnaround situations, as well as lead strategic initiatives. His expertise has evolved from client/server-based solutions to n-tier collaborative web applications and he has worked with many of the major technologies deployed today. Ken is currently Vice President of Business Process and Workflow Strategy at Wells Fargo. Prior to joining Wells Fargo, he was Vice President of Business Development at Flying Bridge Technologies Inc.