When implementing a new AMS (association management system), we typically see all value of the functionality it brings: Things like the ability to process online orders, or being able to capture key data in one system. But one of the greatest values of implementing a new association management software system is often overlooked: re-engineering business processes.

I know, it doesn't sound very exciting, but improving your business processes can be (should be?) a nice side-effect of implementing a new data management system. Any new database should force you to look at how you process everything, from adding records, to adding transactions, to running reports. Implementing a new system gives you an excuse to look at what you're doing now to try and determine if you could be doing things better.

The alternative is that you implement new software that replicates your old processes, which would be an incredible waste of time and money. So when implementing a new system, look for the opportunities to re-engineer, including throwing out processes you don't need anymore.

The ASAE Data Standards Task Force announced the release of a draft standard for expressing constituent records in XML. This standard will serve as a core for expanding into other data representations.

This first set of standards is absolutely critical for establishing industry-wide standards that all of the AMS vendors and other technology partners can adhere to. These standards will go a long way to making integrations from AMS packages to websites to other third-party services (think job banks, online registration, and grass roots).

So go to http://www.asaecenter.org/datastandardsreview and review the standards, and provide ASAE with feedback.

I spoke at a users group meeting a few weeks ago, and asked if anyone in the audience had a users guide or documented business processes for their AMS systems. In a room of about 50, I saw exactly two hands go up. Two!

Frankly, I don't know how an organization can successfully use an AMS over time if it hasn't documented how it processes data in the database. I suspect that in most cases, the organizations are relatively successful because one person on staff has all the processes in his or her head, and as long as he or she doesn't leave, everything is fine. But that's hardly a way to run a business.

Ironically, one of the attendees came up to me afterwards to explain that they are struggling with their existing database because the one person that knew how to run it has left. And now staff thinks they need to buy a new system. When I asked her if they had any documentation, she said "no." I was disappointed, but not surprised.

If you want your database to succeed for the long-term (meaning more than five years), you have document your processes. A new user needs to be able to look at that documentation and easily determine how to process things like new membership joins, membership renewals, event registrations, product orders, certification, fundraising, and the myriad other things your association does.

Are your processes documented? And if not, why not?

I was reading this article about the introduction of IBM's Thinkpad laptop and was struck by these two thoughts:

1. At the time, black PCs were not allowed in Europe because it was believed that anything other than off-white put too much strain on the eyes. So IBM put a sticker on the laptop that read "Not for Office Use."
2. IBM had a longstanding rule that forbade the use of red on anything other than the emergency power switch on mainframes, so they said the little trackpoint button was "magenta."

What struck me about this was how incredibly stupid these rules are, but more importantly, how stupid rules like that could have hindered the introduction of a great product, if not for the creativity of the inventors to work around the rules.

So ask yourself: How many rules does your organization have in place that hinders, rather than helps, you manage your database? And if there are rules like this, ask yourself why? Too often, the answer is "Because we've always done it that way." (Hmmm, sounds familiar…)

Don't let outdated, unused, or just plain bad business rules hinder your success. If you have a rule that can't be justified, trash it. You'll be happy you did.

I spent the day at the Users Group meeting for JL Systems last week. JL is introducing a new product, called "New NOAH" (as far as I can tell).

The system is fully browser-based (which is a change from their Access-based legacy system) and is based on the DotNetNuke development framework. This is significant because JL can now tap into a broad range of developers who are building "snap ins" for the DotNetNuke platform, which may allow it to bring new tools to its AMS more quickly.

There are some nice new features, including the ability to modify screens so that you're seeing the data that's important to you, in a way that is useful to you. This new product is a nice leap forward for JL, whose NOAH product was getting pretty long in the tooth.

Performance of the database during the meeting was abysmal. Screen changes took many seconds to refresh. I'm going to give JL the benefit of the doubt and blame this on 50 people sharing one wireless access point, and all hitting a development server. But like all browser-based applications, JL needs to pay close attention to performance and screen refresh speeds. This will be especially true of their legacy clients moving from relatively fast Access program to a browser.

Full disclosure: EDM is an independent third-party consulting firm. This means we have no financial relationship with any of the vendors mentioned in this blog. We provide unbiased opinions on what we see.

I was weeding my garden the other day, which is an activity I engage in exactly once per year. As you can imagine, with a year's worth of weeds to clean out, the job wasn't quick, or easy. I noticed that although I started out strong, by the end of the job, I was hitting only the high-points and trying to finish as quickly as I could. I had had enough.

But as I weeded, it struck me that weeding the garden is much like "weeding" your database. In order to keep your database clean, you need to clean it frequently. Sure, you can clean once per year, but it will be tough work, it will take a long time, and the longer it takes, the less likely you are to clean well. I've written about this in the past here and here.

But if you "weed" your database frequently, the job will be smaller and easier. And you'll be more likely to do it well. So don't let the weeds get too thick in your database.

I'm working with a client who has a custom database application to manage their website and database. It's actually a pretty slick system. But the problem is that it was designed by web developers who have a great sense of managing web things, but no sense for managing finances.

I see this time and time again from web-development companies that expand into the AMS space. While they may develop great data and website management systems, they frequently overlook one of the most important aspects of a traditional AMS: financial transactions.

Your AMS has to be able to track all money coming in to your organization, and keep track of who actually owes you money (accounts receivable). Too often what I see in custom designs is a simple checkbox that says "Paid" or "Unpaid." But there's nothing there to generate invoices, track whether and how payment was made, and track which general ledger account the money should be applied to.

One of the advantages that most off-the-shelf products have over custom products is that they've already addressed the issue of managing the money. They have in place the tools to manage invoicing, refunds, transfers, g/l accounts, and the rest of the financial minutiae that most of us hate, but all of us need to best keep track of our financial status.

So when you're considering off-the-shelf versus custom, make sure either system you consider has the ability to fully manage all of the a/r accounting functionality you'll need. And of course, as I write here, most associations shouldn't be in the custom software business anyway.

Full disclosure: EDM is an independent third-party consulting firm. This means we have no financial relationship with any of the vendors mentioned in this blog. We provide unbiased opinions on what we see.

I had not seen these stats before, but they are striking.

From a 2004 Gartner report entitled "CRM Demands Data Cleansing" (http://www.gartner.com/DisplayDocument?ref=g_search&id=463228) a survey of 600 major enterprises in Australia, the UK, and the US:

• 75% of respondents reported significant problems as a result of defective data
• More than 50% incurred extra costs due to the need for internal reconciliations
• 33% failed to bill or collect receivables

That last one is absolutely amazing to me. Fully 1/3 of the respondents had some billing or collections issue due to bad data!

The good news is, you're not alone. Everyone has problems managing their data. The bad news is, everyone has problems managing their data.

As organizations, we must do better than this. For the vast majority of associations, there is no excuse for failing to bill or collect receivables. When I've seen this happen (and I have, believe me) it's more likely due to bad process than bad data.

Take a look around your organization. Are you having these kinds of challenges? And if you are, what are you doing about it?

I was recently called by a potential client who was looking to move from their existing software to another AMS package. As I talked with them, I learned that they're using what I consider to be a really good AMS package, but they are not happy with it. They find it too cumbersome, not flexible enough, and hard to understand. What's interesting about this particular situation is that the association received the software for free. The challenge they face is that they don't want to spend a lot for a new AMS package. The one they have would be way out of their price range if they had to buy it a street value.

The question is: What should they do? Should they trash a really good product and try to find a less-expensive product that staff finds easier-to-use? Or should they work with the vendor to try to learn how to use the system better? Or is there yet another option they haven’t considered?

What would you advise?

I received a complimentary copy of Global Knowledge's IT salary survey a couple of weeks ago. The survey covered over 1,600 IT professionals, and there were some interesting tidbits that may be relevant to the AMS world:

1. Average salary for the title database admin/analyst was $74,263.
2. Average salary for a project manager was $83,668.
3. Overall for all respondents, base salary was $71,556, plus an average bonus of $3,963.

The survey broke out salaries by industry, but associations/non-profits was not one of the categories. The closest was perhaps Education and Government (state/local), with average salaries for these of $57,544 and $61,535, respectively. Taking that state government average, that's a full $10K less than the overall average!

I don't know how this compares to actual association numbers (I don't think ASAE has done a salary survey in a couple of years) but if associations refuse to pay as high as the for-profit market, they're very likely to get below-average performance from their IT staff. I know, I know, there are exceptions to this (I've met many smart association IT folks. Some are even smart enough to hire me!), but overall, if you're underpaying, you're getting what you pay for.

How does your association stack up?