September 22, 2006

Choosing a ChMS – the risk calculation

As I alluded in the previous post, a huge consideration for me in choosing our next Church Management Systems (ChMS) is minimizing the risk of making a bad choice. The question of ChMS is the most strategically complex and the riskiest decision I’ve faced since becoming IT Director at Church of the Resurrection three years ago. Why do I say that? What makes this decision especially risky?

The risk is high mainly because Church Management Systems automate core processes. In business or church, whenever you automate core processes you set in motion a complex interplay between your operations and your technology. You adapt the automation system as best you can to fit your processes and you inevitably adapt some of your processes to fit the automation system. You train your staff on the system and over time they develop some deep expertise in its quirks. You purchase and integrate other technology with the system. Before long, the thought of changing the system becomes nearly unthinkable. Companies that build and sell systems that automate core processes understand this very well. Once they get a customer fully on board with the system, they know it will be very difficult for the customer to go another direction. The customer is “locked in” and they're happy (that is, the vendor is happy).

Going forward from the initial implementation, a ChMS is likely to become a two-edged sword. While your operations become more efficient, operational innovation can be held back if the automation technology can’t keep pace. Curtis Harris of Fellowship Tech asked at the Roundtable if it wasn’t possible to have a set of best practices that the system would automate, benefiting all churches that use it. I don’t believe that’s 100% the case (although we all can and should be learning from each other). The best senior pastors are the innovators. They zig when everyone else is zagging. So there’s bound to be some mismatches between what any particular system does and my particular church’s unique way of doing ministry. I strongly suspect that will be the case for other churches too.

Right now Resurrection is too dependent on Shelby. If Shelby doesn’t keep pace with new technology and new ministry models, there’s not a lot we can do because we’re “locked in.” If we go out and find a new system that “stinks the least” and change to that system, we might be better off than we are now, but fundamentally it’s the same strategy. Our risk of Shelby not performing simply changes to a risk of the new vendor not performing. And ultimately, I don’t believe it will be possible for Shelby or any vendor to perfectly, exactly meet our needs.

So what could ChMS vendors do to help me with this conundrum and reduce the risk that I’ll make a bad choice? I’ll share some thoughts on that in my next post.

5 comments:

Anonymous said...

This is a great discussion. As Perimeter has been looking over what direction we want to move we've realized that we don't want a 'built from scratch' system, but we do want a highly customized system. I guess that means we're looking for a highly customizable framework that integrates well with existing technologies we are using. We are a MS shop, and so my question to Tony is why don't we go with MS CRM 3.0. It's a much more stable and supported framework than any of the open source frameworks (although some could very adequately argue otherwise) and it integrates well with Outlook, Office, Sharepoint, MS Accounting...

Your conversation has me asking another question. What if we built our system on MS CRM parts. We customize existing parts that are already out there and then create a check-in part, a contributions part, and whatever other parts we need. We then document those parts and make them available to the community at large? With that type of model we really could have a system like you are suggesting.

I see two remaining questions with this line of though:
1) With the number of parts required for a church system, does this type of model make sense? This is the question I'm wrestling with right now. We may decide absolutely not and continue trying to make square pegs fit into round holes.
2) With a hundred other frameworks out there, why use Microsoft? Integration and Implementation. MS CRM is built on a framwork that is easy to build on and integrates well with your existing systems without having to buy additional plug-ins that will break with the introduction of Office 2007.

I'm just starting to think this through and so I may be making a number of assumptions and assertions that don't hold-up. I look forward to seeing your feedback.

Hal Campbell said...

Then best I can offer is an invitation to come spend the day with us at ACS Technologies and let us show you first hand what we can do for you. You'll get a chance to meet our staff, see our facilities and our commitment to this market. I'm sure Shelby, Fellowship Technologies and Microsoft would make the same offer. Well, maybe not Microsoft :).

Anonymous said...

Clif, you got me. I'm busted (again). RISK As I've spent the last few years looking for the right answer, there's always been the concern, the risk, of making a wrong choice (because there are so many wrong choices!) Thanks for the wake-up call...

As to using MS CRM, that's been on my interest list for a long time. I'm aware of at least two organizations that are considering CRM-based ChMS. How soon? I wish I knew...

Clif Guy said...

John: After talking with Tony at the Roundtable, Microsoft CRM 3.0 is back on my short list. Yes, it could be a vehicle for developing parts that could be shared among churches. Just today I heard that another large church here in the Kansas City area recently implemented Microsoft CRM. I will look into their experience and blog anything worthwhile.

Clif Guy said...

Jeff: Perhaps I wasn't clear that I'm not asking for a way to avoid risk altogether. (I accept risk every time I get in my car.) Rather, exactly as you are suggesting, I'm looking to reduce and manage the risk. (That's why I wear a seat belt.)

You're suggesting certain criteria I should use in selecting my ChMS product and vendor that would manage my risk. By contrast, I'm leading up to a proposal for a completely different way to manage my risk. (Stay tuned.)