If you’re currently involved with your company’s software selection and implementation project, then I’m sure you can appreciate how difficult this process is. From figuring out what you want your new system to accomplish, to “go-live”—and everything in between—enterprise software selection is no easy feat. In fact, it can be downright grueling.
To start your software selection project off on the right foot, you must first define all of your current business processes—and then document them. This task alone can take months. However, with the right methodology and tools, the time spent doing this can be cut down significantly. If you are using your own methods for gathering requirements, your list of business processes must be structured in such a way that allows vendors to easily apply them to their products and determine whether they can support certain functionalities.
Again, no easy feat!
Many organizations often start a software selection by first choosing a vendor and then working in tandem with the vendor throughout the process of identifying and modeling their business processes on software capabilities. This is all fine and dandy—but who knows your business better than the people who perform these processes day in and day out? You, your department managers, and IT staff. Why put the onus on the vendor to perform this task and then risk not being certain that everything your new system may need has been identified? Not to mention the cost this type of vendor service could carry!
So what’s a software selection project manager to do?
Let’s take a look at how you can build a comprehensive request for information (RFI) by first reviewing the basics principles of business process modeling (BPM) and how it correlates to the RFI.
BPM Made Simple
Review Your Existing Systems and Business Processes
This process starts by documenting your business process workflows across all departments and functional areas. Knowing the capabilities of your current software is important in understanding where you need to add and improve functionality. It’s also important for you to review systems currently in place in order to gauge whether it’s worth upgrading your current software, as opposed to acquiring a new system. At the same time, reviewing your business processes can help you pinpoint areas where you can replace inefficient practices with best practices that will be supported by your new software.
List and Prioritize Your Functional and Technical Requirements1
Functional requirements are capabilities that you need the software to have. BPM ensures that all functional requirements are included in your RFI and eventual request for proposal (RFP). It helps you identify your customization requirements early on and make them part of your decision. It allows you to map your business processes to features and functions so that vendors can understand and accurately respond to them.
Technical requirements are things that the new software needs to support in order to integrate smoothly into your existing IT infrastructure. Assigning initial priorities to the functional and technical requirements will help you sort out what is important—and what is not.
Creating Your RFI
Now it’s time to map your processes onto a software feature-and-function model that will allow you to clearly communicate your needs to software vendors. Great! But how do you explain those processes to the software vendor in a language they can understand?
RFI, Anyone?
The process of building an RFI can be painstaking for an organization. A traditional RFI is primarily used to gather information to help make a decision on what steps to take next in your software selection project. In addition to gathering basic information, an RFI is often used as a solicitation sent to a broad base of potential vendors for the purpose of gathering information, developing a strategy, building a database, and preparing for a RFP or request for quotation (RFQ).
Why TEC’s RFIs Can Help You
TEC’s RFI and RFP templates do a lot of the tedious work for you. They are created in a manner that allows an organization to easily define which features and functions it would like from the software and how important each of those features and functions are to the business.
These industry-standard RFI and RFP templates also help ensure accurate responses from vendors. The RFI templates contain thousands of functional and technical criteria that have been vetted by TEC’s analysts. TEC’s RFIs on average cover about 75 to 80 percent of a business’s functional requirements. These RFI documents can also be customized to meet your company’s own unique requirements.
The RFI and RFP templates help you obtain accurate information from vendors that can then be compared with your business requirements.
Making Your Software Evaluation Easier
Once your RFI is complete (having added your custom functionality and prioritizing what features and functions are important to your business), it’s time to go after some vendors to see what they have to offer and how well they can support your business processes.
Sending your prioritized RFI to a long list of vendors and gathering their responses could take several months. Do you have that kind of time? Probably not.
TEC has developed a structured methodology that, within a complex selection project, narrows down the list of potential vendors to only those that match your business model, priorities, and special requirements. How? With TEC’s online decision support system (DSS), ebestmatch™. By taking advantage of our knowledge bases (KBs) to compare the vendors on your long list, you can quickly—and easily—see how well each vendor addresses your specific requirements. You can also use ebestmatch to create “what-if” scenarios that show you how well each vendor’s solution will scale as your business evolves.3
The Choice Is Yours
Time is of the essence when it comes to selecting software. The process can be long and drawn out, so why not arm yourself with some methods—and tools—that will help move it along more smoothly and quickly? The choice is yours. Good luck!
To start your software selection project off on the right foot, you must first define all of your current business processes—and then document them. This task alone can take months. However, with the right methodology and tools, the time spent doing this can be cut down significantly. If you are using your own methods for gathering requirements, your list of business processes must be structured in such a way that allows vendors to easily apply them to their products and determine whether they can support certain functionalities.
Again, no easy feat!
Many organizations often start a software selection by first choosing a vendor and then working in tandem with the vendor throughout the process of identifying and modeling their business processes on software capabilities. This is all fine and dandy—but who knows your business better than the people who perform these processes day in and day out? You, your department managers, and IT staff. Why put the onus on the vendor to perform this task and then risk not being certain that everything your new system may need has been identified? Not to mention the cost this type of vendor service could carry!
So what’s a software selection project manager to do?
Let’s take a look at how you can build a comprehensive request for information (RFI) by first reviewing the basics principles of business process modeling (BPM) and how it correlates to the RFI.
BPM Made Simple
Review Your Existing Systems and Business Processes
This process starts by documenting your business process workflows across all departments and functional areas. Knowing the capabilities of your current software is important in understanding where you need to add and improve functionality. It’s also important for you to review systems currently in place in order to gauge whether it’s worth upgrading your current software, as opposed to acquiring a new system. At the same time, reviewing your business processes can help you pinpoint areas where you can replace inefficient practices with best practices that will be supported by your new software.
List and Prioritize Your Functional and Technical Requirements1
Functional requirements are capabilities that you need the software to have. BPM ensures that all functional requirements are included in your RFI and eventual request for proposal (RFP). It helps you identify your customization requirements early on and make them part of your decision. It allows you to map your business processes to features and functions so that vendors can understand and accurately respond to them.
Technical requirements are things that the new software needs to support in order to integrate smoothly into your existing IT infrastructure. Assigning initial priorities to the functional and technical requirements will help you sort out what is important—and what is not.
Creating Your RFI
Now it’s time to map your processes onto a software feature-and-function model that will allow you to clearly communicate your needs to software vendors. Great! But how do you explain those processes to the software vendor in a language they can understand?
RFI, Anyone?
The process of building an RFI can be painstaking for an organization. A traditional RFI is primarily used to gather information to help make a decision on what steps to take next in your software selection project. In addition to gathering basic information, an RFI is often used as a solicitation sent to a broad base of potential vendors for the purpose of gathering information, developing a strategy, building a database, and preparing for a RFP or request for quotation (RFQ).
Why TEC’s RFIs Can Help You
TEC’s RFI and RFP templates do a lot of the tedious work for you. They are created in a manner that allows an organization to easily define which features and functions it would like from the software and how important each of those features and functions are to the business.
These industry-standard RFI and RFP templates also help ensure accurate responses from vendors. The RFI templates contain thousands of functional and technical criteria that have been vetted by TEC’s analysts. TEC’s RFIs on average cover about 75 to 80 percent of a business’s functional requirements. These RFI documents can also be customized to meet your company’s own unique requirements.
The RFI and RFP templates help you obtain accurate information from vendors that can then be compared with your business requirements.
Making Your Software Evaluation Easier
Once your RFI is complete (having added your custom functionality and prioritizing what features and functions are important to your business), it’s time to go after some vendors to see what they have to offer and how well they can support your business processes.
Sending your prioritized RFI to a long list of vendors and gathering their responses could take several months. Do you have that kind of time? Probably not.
TEC has developed a structured methodology that, within a complex selection project, narrows down the list of potential vendors to only those that match your business model, priorities, and special requirements. How? With TEC’s online decision support system (DSS), ebestmatch™. By taking advantage of our knowledge bases (KBs) to compare the vendors on your long list, you can quickly—and easily—see how well each vendor addresses your specific requirements. You can also use ebestmatch to create “what-if” scenarios that show you how well each vendor’s solution will scale as your business evolves.3
The Choice Is Yours
Time is of the essence when it comes to selecting software. The process can be long and drawn out, so why not arm yourself with some methods—and tools—that will help move it along more smoothly and quickly? The choice is yours. Good luck!
Hi banglore,
ReplyDeleteThanks for your interest in our blog post. I do request, however, that you properly attribute authorship of the post to Sherry Fox. See http://blog.technologyevaluation.com/blog/2009/05/27/that%e2%80%99s-no-ordinary-rfi%e2%80%94why-bpm-and-the-tec-rfi-are-so-important-to-your-software-selection-project/.
All the best,
David Clark
Managing Editor
Technology Evaluation Centers
www.technologyevaluation.com