Whether considering a CRM implementation or appraising the benefits your CRM does or should provide, one of the key areas to address is the application of business process automation (BPA) and business process development (BPD). Automation is often associated with short terms gains through efficient, low cost practices. Development, on the other hand, brings long term gains and high results by enhancing business effectiveness.

Typically reserved for management/consultant-speak, the terms, however, are often lost in hypothetical debate, leaving little to justify our acronym laden opening. And whilst it's always useful to have a few buzzwords included in a business case or a cost-benefit analysis, it's much more important to get beyond the acronyms and to agree what we're looking to achieve.

Simplistically, both BPA and BPD are ways in which the implementation or development of a CRM solution - indeed any technology solution or innovation – can bring benefits to the organisation deploying or enhancing it. When business cases are being made to stakeholders , there's a tendency to try to identify examples of how both methods can play a role in delivering the Return on Investment required. But in a not-for-profit, membership organisation, is this really practical?

In justifying the investment in a CRM solution, we need to look at what we do and how we do it, to identify areas where we can improve or extend the delivery of our services, and the manner in which we process the transactions and interactions which underpin them. For some, this means another acronym - BPR, or Business Process Re-engineering. For many, this means a new name for the long-established activity of reviewing what we do and how we do it, with the purpose of finding out what we can do differently and better.

Business Process Automation

When we review business processes, and scope the technology that will enhance them, we are probably looking at business process automation. We continue to do the same things but we'll use the power, capacity and capability of the technology to do them better. For example, a new CRM may be replacing information silos all around the company. We won't necessarily create new information, but we'll build connections and make it available to everyone. Everyone will be able to contribute information to our central corporate knowledge and everyone will be able to consume it. This typically results in the information being kept more up-to-date (as more people are able to share their updates with everyone). Additionally, the data is being more accurately categorised (ideally with a corporate glossary of terms and agreed language behind it), and consequently used more constructively. But whilst there are clear benefits, particularly in terms of efficiency and short term gains, what has really changed in terms of what we do?

Not a lot, if anything. The same people can be maintaining and using the same information in roughly the same way (though in a more consistent format), but now its accessibility means more people benefit from the same level of input, and there are more ways to use the information effectively. In fact, we'd also expect that the amount of effort required to manage our information will reduce as a whole, because a single update becomes available to everyone.

Business Process Development

Business process development, on the other hand, is far more difficult to achieve. However, a review of our processes can potentially bring to light certain information which opens opportunities for us to re-work what we do, especially if we find that things are not being processed as we originally thought! A CRM implementation may therefore allow us to introduce new business processes or to deliver new services to our members.

For those looking to claim achievements in process development, perhaps the single biggest change adopted by many organisations in recent years is the introduction of online portals, where members can self-serve. Whilst that may sound like an automation benefit, the core change here is actually in allowing our members and customers to update their own details in our databases, to book themselves onto events, to answer surveys, etc.

This is one step further than automating or improving the method by which they would previously have informed us of changes in their details or their intention to attend an event. Moving from paper forms to electronic was very much an automation benefit, improving the speed and hopefully accuracy of the information exchange. It could be argued that allowing the member / customer to self-serve is a process development.

However, a mature CRM often provides the framework upon which to base good business practices. Deduping comes as standard and complex contact relationships can be generated automatically. Anything of financial value, including events and services, is classified as a product and tracked universally. Workflows and wizards are used to model and automate your processes to a much greater extent, providing a basis upon which to remodel those processes as businesses evolve. It then becomes apparent that the difference between automation and development is not so clear cut and that both concepts can be used hand-in-hand.

Ultimately, there is very little that a computer system can do which we wouldn't be able to do without that system. What the system should do is to help us run processes quicker, to do them more accurately and more consistently, and to let other people do things we would otherwise have done for them.

It's highly unlikely that implementing a new CRM solution – or most new computer systems - is going to allow us to radically re-develop our business processes. That doesn't make it wrong to aspire to such heights. But when setting objectives for our projects – and the expectations of our stakeholders – it's far more important to be realistic and develop achievable goals than it is to feel we have to use both BPA and BPD in our business case.