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!
NOTE: The above information in no way is intended to cover an entire selection process (as you are aware, there is much more to it than just that). This blog is merely a glimpse at some of the important and crucial first steps of gathering or defining, prioritizing, and documenting your business processes and turning them into a feature-and-function set of capabilities that software vendors can understand.
References
1 – TEC Selection Services (Phase 1: Research)
2 – Your Guide to Enterprise Software Selection: Part Two - Bill Carson - December 28, 2007
3 - TEC Selection Services (Phase 2: Evaluation)
Nice generalisation article. BPM is perhaps not the best term to use to describe the process. BPM is only one phase out of five. Can you list the other four?
Hi Leslie, thanks for writing in. You can find more information about the phases of the software selection process here: http://www.technologyevaluation.com/selection-services/methodology/.
Not sure why you object to using the term “business process modeling” to describe the exercise of modeling one’s business processes. As you may know, the term is fairly standard.
Granted, the industry is plagued with acronyms and littered with BPMs in particular (”business performance management,” “business process management,” and even–most awkwardly–”BI and performance management”), which doesn’t help.
I’d be most interested to hear what you’d propose as a replacement term.
Hi David,
The process BPM has a definite meaning,as outlined in TEC’s RFIs for BPM. With BPM software, of which Bizztalk, and a few others are examples of implementations, we have a flow chart with if-then-else selection of actions to take, based on conditions.
Ms Fox’s reference is to an ever so standard procedure to follow to evaluate one or more in-house vendor softwares, is easily done with a spreadsheet and a column for each vendor.
My experience states that BPM includes logical decisions based on event triggering, where events can be occurrences of “data out of range”, “events occuring at the wrong time”, or “not occuring at all” and “date based logic” as well. BPMs would interface to SharePoint, as some now do. BPM is a process mainly to track business transactions and to insure each is correctly handled.
As a technologist, I see the RFI method used for “in-house systems” going the way of the doo-doo bird. Why I say that and why BPM has no real meaning in Ms Fox’s context has to do with technology enhancements.
These technical changes really force me to discuss SaaS. As of 2008 we have internet cards for PC hardware or ISP providers easily supporting speeds ten times to over forty times faster then what is currently in use (in most organisations). The networks are in place to match these increased speeds. CPU’s are multi-core providing reasonable low cost computing and virtual machine operation at a host). With SaaS, the host operating system or backend database is part of the service. Who cares if it is Oracle, or MS SQL, SQL server or IBM’s Z-OS (Linux).
What these technology boosts do is to heavily advantage the SaaS lines of business and cloud computing. (A peer and I wrote a paper about cloud computing, contact me for details).
Today we don’t run in-house generators for electricity or telephones, and now SaaS are software services that are purchased over the internet. Imagine, no staff, no computer rooms, and no in-house programmers and a great reduction in the number of business analysts. In all likelihood, there will be a marketing of SaaS applications with the best of breed concepts. I visualize CRM from one vendor,BI from another, Finance from another, etc. The true BPM concept is SoA at the Macro level, where a form of BPM would/should front end each SaaS application. The BPM model will hand over the transaction to the appropriate SaaS application. SaaS may bring on SoA, but that concept is not yet apparent.
What very high speed telecommunication does, is change the paradigm from in-house to hosted services. And it does away with many legacy business process models and the mis-defined term BPM as defined by Ms Fox.
If I drifted to SaaS, I purposely did not discuss security, recoverability, performance or quite a few other issues. It is because I see massive industry shifts taking place in the immediate few years, and why I feel that BPM is the wrong term to have used. I would have used Scientific method, as we learned in high-school. Your reference was to a “Standard method” procedure.
Hi again Leslie,
Thanks again for writing in. I just wanted to respond to a few of your comments:
1. Sherry’s post refers to business process modeling, not business process management. The two terms are not interchangeable.
2. Enterprise software evaluation is not “easily done with a spreadsheet and a column for each vendor.” That’s an irresponsible position to take. A business selecting an ERP system, for instance, may have upwards of 4,000 software features and functions to consider.
If you attempt to collate this information, which becomes exponentially more complex with every vendor you add to your list of alternatives, managing a spreadsheet is nothing short of nightmarish. Even if you do manage to discern which software solution is the “best fit” for your company, you still have not even begun to take steps toward ensuring the implementation is a success.
3. The decision to go with software-as-a-service (SaaS) vs. on-premise solutions does not eliminate the need to evaluate the software in question; nor does it eliminate the need for an RFI, as you claim it does. With all due respect, I can’t imagine why you’d suggest that.
4. Not sure how or why you’re attempting to differentiate “scientific method” and “standard procedure.” Certainly, using “scientific method” as a replacement term for “business process modeling” misses the mark.
Anyway, thanks again for writing. I look forward to more of your comments.
list the steps for the scientific method…
Published on this site…