Business Requirements Document For ERP?

We've been writing business requirements documents for replicating our legacy system processes and procedures for the last few months. The document(s) created include a) summaries of the major processes; b) process flow diagrams; and c) the detailed narrative that basically describes who, what, when, where, why and how of each process flow. Outlining the BRD's requires that kind of business analyst mindset that thinks of the system from both a user and an IT/programmer perspective, and hopefully keeps in mind the overall strategic goals of the company. It's a unique skill set, and good business analysts are usually deeply familiar with many ERP systems (like SAP, JDE/Oracle) or platforms like force.com that are capable of being customized to the business or industry needs. The best BA's don't try to steer you in any one direction either! They analyze the business first, then evaluate the solutions best suited to meet the business requirements. Good luck on this project Mark!

Mark

two questions :

first - which industry do you operate in?

second - what criteria, or criterion, makes your business unique? Understanding this is key to selecting the best fit solution.

Accurate definition of the answers to these two questions will save you a lot of time, money and effort in selection, implementation and on-cost. They will both immediately crystallize what you need and eliminate those vendors who cannot provide it. The next stage is to drill down vendors who can provide your needs and to the requirement level of support you need. Not all vendors provide what they purport out of the box. Third party vendors, customization, workarounds, add-ons all represent additional costs and time that must be identified as part of selection. Not implementation.

Every business is unique in some way, so don't short circuit requirements by using a template applied to another business. Your solution - and how you use that solution - is unique to you. Cloning someone else's solution into your business is an expensive mistake to avoid.

Do not lose sight of the fact that ERP solutions are generic. A NetSuite Business Requirements Document (BRD) fits their understanding of your business. The only person who understands your business is you, not a vendor. Don't fall into that trap.

We have selected, evaluated and implemented enterprise software solutions for clients in North America and the United Kingdom for over 30 years. The tools we use include detailed requirements sets across a range of ERP solutions allowing you to quickly derive preferred and reserve vendor recommendations supporting a business case with detailed functional, technical and financial data. Typically it takes six months for the business to provide requirements and a vendor to provide functional equivalence to produce a recommendation acceptable to you. The tools we use include a proven selection methodology and pre-qualified functionality thereby reducing the timeframe and cost, resulting is a best fit solution for your business.

Regards
Mark

Mark Woolley
Corporate System Solutions

Hey Mark,

Thanks for your response. I would prefer to just keep the discussion public for the time being as I feel this could be a valuable insight for others needing this information. Here are the answers to your questions:

first - which industry do you operate in?

We are a hybrid e-commerence/manufacturing company printing and manufacturing of signs. The best examples of us I would say would be companies like Zazzle, Cafepress, and VistaPrint. We sell signs on-line and have two manufacturing pieces in two different states along with multiple websites.

second - what criteria, or criterion, makes your business unique? Understanding this is key to selecting the best fit solution.

Could you explain what you mean by this question. I'm sure how to answer it. Overall, we run a in-house production system that ques all our orders and functions as a quasi CRM system. We have no system count and inventory can only be determined by our inventory counts monthly. Most of the critical data you need for the COGS side is going to come from our SQL database. Due to this, we actually have a fairly large development team of software developers and the data can be very difficult to get because the SQL database is very customized. That is the biggest transition we will need to make. I would say our biggest problems to solve will be the production side, supply chain, and an establishment of a proper cost accounting system.

Hi Mark V

After reading your initial post and follow up, here are some comments, hopefully not too far off base for you (note: I am a former finance leader that now helps clients choose and use business software):

1. Firstly, I think you are more at the start of Evaluation rather than the Implementation of software (two separate phases of a larger project). So, what key questions are you wanting to answer and why are you looking at software (i.e. what pains exist today)? These questions should be agreed to by your top management - exec buy in is critical.Without a credible business case, be careful about the risks.

2. Secondly, establish some budget boundaries. That will drive if/how you use consultants and what packages fall in your $ range. You may not want to do that in a public forum if # employees, revenues, budget for software are to be discussed.

3. Lynne's comments above make sense. Determine your requirements first. Her BRD may differ from what a software vendor calls a BRD- the vendor is looking for info on how to configure their system, so it has already been selected. You need to evaluate first, which means something different- you should not pay attention to any specific packages at this requirements gathering stage. If you/your peers have not much experience in defining software requirements and evaluating software, hire someone who can help you. We frequently advise our clients that "An Ounce of Selection is worth a Pound of Implementation" because of its importance to the project.

4. If you are changing software, your processes are likely to change; so you should take an objective look at: your business goals and strategy, your future business model, what processes are important and how should they be performed using a new system that does not exhibit the constraints of today's systems in place - reference my # 1 above re " what key questions are you wanting to answer?" Your reference to "our biggest problems to solve will be the production side, supply chain, and an establishment of a proper cost accounting system" is pretty substantial, so plan this carefully.

5. Assemble a small team of SMEs (subject matter experts) who can spend some time on this project-you need org wide input and perspective, even if just it's 3 people. The team leader should be a good leader and somewhat knowledgeable about business software, not just the most senior person:).Change management is the MAJOR issue to handle during the project - it's not a tech/IT thing, simply installing software and "hoping" it will be better.

6. Use scripts of key business scenarios to evaluate how a shortlist of potential vendors can support your business requirements. Scripts help describe the way you plan to operate in future, they allow you to see HOW a package functions and whether that suits your business model/strategy.