There was a discussion on a users group listserver a few days ago about the pros and cons of centralized vs. decentralized data entry. The question was, should all staff be able to enter and correct data in the database, or should that function be restricted to just a few? Several people weighed in, and the majority seemed to be in favor of concentrating that work to a few people.

Centralizing data entry is the easy choice, which is why most favor it. While I see the attractiveness of concentrating the data entry management into the hands of just a few, I think it’s the wrong choice.
It’s easy because ultimately, data management is about personnel (or staff) management. That is, your data management is only as good as the people who are doing it. So if you have fewer people doing it, that’s fewer people you have to train, keep up-to-date, and check on. Simply, it’s fewer people to manage.

But I think the downside is worse. Here are just a few:

1. Data is processed more slowly. By definition, a concentration of the data entry processing is a bottleneck. For example, if I learn of an email address change today and have to forward it to the fortunate few who can make data changes, how long will it take for the change to take place? I know it’ll be a lot longer than if I had just made the change myself.
2. Non-data entry staff stop caring about the data. Ownership of the data, by definition, now belongs to the chosen few, which means those who are not responsible for data entry will eventually stop caring about the data. Or worse yet, when there are problems with the data (there always will be), guess who will get blamed?
3. Too many eggs in one basket. If you have only one or two people handling all the data entry, what do you do when those people are out sick, or worse yet, leave the company? There is little “bench strength” when data entry is centralized.

As I said, centralizing data entry is “easier” than decentralized, because in order for decentralized data entry to be effective, you have to have good documentation of business processes, good and continuous trainin, and diligent remediation with staff that aren’t “getting it.” You also have to have very clear rules about who can change what data.

I won’t kid you: It’s a lot of work. But the long-term benefits (e.g., cleaner data updated more quickly and more accurately, because fewer hands have touched it) make it worth it.

One of the most significant changes to occur over the past couple of years in database management is the idea that the database must be more customer-friendly. Prior to Al Gore inventing the internet, when associations considered which database they might use, the only audience to consider was staff. That is, how would staff interact with the database.

Of course, all of that has changed. As a result, when considering a new association management system, associations must now consider not only how the staff interacts with the database, but how members and customers will interact with it, as well.

What this means is there is a dynamic tension between making something flexible enough for staff, while making it easy enough for online customers to use the system without needing training. In my experience, some AMS vendors do this better than others, but all of them struggle with maintaining that balance.

So when evaluating new systems, you have to be aware of this tension and be sure to evaluate the system from both a staffer’s perspective as well as the perspective of your members and customers.

By show of hands, how many of you have an “IT” person on your senior management team? Is the most senior IT person in your organization part of the executive management team, or do they report to someone else who is on the executive management team?

What I see far too often is organizations will have their chief technology person (say, an IT director) reporting to the chief operating officer. The COO sits on the executive team, but not the IT director. I think this is a mistake for three reasons:

1. It sends a not-so-subtle message to the rest of staff that IT is an afterthought, or not critical to the overall functioning of the organization.
2. It keeps the IT folks out of the information loop. Let’s face it, no matter how good communication is between the IT director and the COO (for example), it’s not the same as being at the table.
3. It keeps the IT folks thinking that their job is to “serve staff” like a mechanic taking orders, rather than a diagnostician helping to solve organization problems.

The most successful organizations don’t just give lip service to including IT at the table; they actually have them there. What about your organization? Does IT get the respect it deserves?

When I work with my clients on the implementation of a new database, there is a tendency to focus on everything that is not working. That’s human nature, of course. We want to fix it if it is broken.

Unfortunately, all of this focus on the “broken” tends to lead people to believe that the new system doesn’t work at all, or is a failure, or is “worse than the system we had.”

Which is why you should have metrics for any project you embark upon. That is, you should have some way to measure if you’ve achieved the objectives you’ve set out for yourself.

For example, I worked with a small association recently on the implementation of a new, centralized AMS. Their previous system was a homegrown access database that was not connected to their website and did not have strong accounts receivable functionality. They implemented a new system which gave them some serious headaches throughout the process. But when the system was finally live, they had a completely integrated database with strong a/r features and tight integration with their website. The result was that in just a few short months, the vast majority of their members were joining and renewing online, something that had never happened before.

Two of their metrics for success were centralizing their data and integrating the database to their website. They succeeded on those. It wasn’t easy, and it wasn’t fun, but it was successful. But had they not had those metrics, they might have assumed, based on their other troubles, that the project was a failure.

So do you have metrics in place for your system? Can you tell if you’re being successful or not?

I recently traded emails with an association colleague of mine, an executive director of a small association, asking him how his search for a new AMS was going. (He is not a client, but chose to do this on his own.)

He has called the process “a train wreck.” Here are just some of his comments (he agreed to let me discuss this as long as I keep his name and the product name anonymous):

“Goal was to have an all-in-one system that was both all the front-end stuff (CMS, forums, social networking, etc, etc) AND have a good enough back-end (ie, to avoid a separate hardcore AMS).

So, we wanted both, and it turns out that it is kinda good at neither once you try to start bending it to your specific needs.”

In other words, what they tried to get was a system that could do really good “Web 2.0″ and still provide solid association management tools. And in the end, from his perspective, he got neither.

Unfortunately, this is not an uncommon experience for a lot of organizations. We focus on some really cool or powerful features (e.g., web 2.0 tools) and neglect to determine if the basics are being taken care of (e.g., standard AMS functionality like accounts receivable).

My experience suggests that the “old school” AMS vendors (those that have been around for 10+ years) do the basics of AMS very well. And that the new kids on the block (those that started from a web- and broad-community-of-users- perspective) do the Web 2.0 stuff really well. The problem is trying to get one system that does them both well.

So far I’ve not come across any system that does both exceedingly well. But if I had to choose, I’d choose the AMS functionality over the Web 2.0 functionality, because in the end, managing the money will be most important.

The traditional AMS vendors will catch up on the Web 2.0 stuff eventually. And the new guys with their newfangled 2.0 tools will eventually have stronger AMS back-ends. But for now, it’s the classic definition of compromise: A compromise is where neither party gets what they want and neither party is happy.

If you are an association staffer or executive, I’d appreciate it if you could answer my one question survey. It will take only a minute or two to reply. Last year at this time over 100 of your association colleagues responded to this survey, and the results were fascinating. You can read about that here: “What’s plaguing associations now?”

Take the survey here.

Yes, you read that right. When selling anything online, whether it’s membership joins, renewals, event registration, or product sales, you should collect as LITTLE information as possible. What I mean by this is that your sales process should be as simple as possible and present as few hurdles as possible to making the sale.

Too many organizations believe that while they’re asking for the sale, they should just go ahead and ask for some additional information. For example, I’ve worked with associations which, as part of the membership application process, ask for dozens of demographics data points (e.g., size of organization, focus of work, etc.) that are not relevant to whether or not the buyer can become a member. In other words, the association would accept the organization as a member regardless of what the answers to these questions were. But the association figures they might as well collect that information now, while they’ve got the potential member online.

I think that’s a mistake.

The first rule of a sale is to get the money. Everything else can come later. As I always tell my clients, the ideal sale is when a customer says “I want that,” and you say “Here you go,” and they pay. If you really need to gather that other information, gather it later, once the organization or individual is already a member.

The same goes for event registration. Why can’t we take the event registration now, and then follow up with questions about dietary needs, physical limitations, and free events? Other than things they need to pay for (e.g., primary registration and ticketed events), why do we need all that information right now? Can’t we get the registration and then follow up later? How many sales are we losing because we’re making the process too cumbersome?

I’m often asked by my clients, when pulling data, if they should use a report or a query. The answer, of course, is it depends on the final use of the information that is output.

A simple rule of thumb is that if you need to present the data externally (e.g., a membership listing, an event registrants list, badges, or name-tents), you should use a report. Also, if it is data that you pull consistently and frequently over time (e.g., monthly membership data), reports are better than queries.

If the data is only going to be used internally, you can probably use a query.

However, having said that, I strongly encourage my clients to use reports, rather than queries, whenever possible. There are two primary reasons for this:

1. Reports force you to correct the data at the source. Because reports present data that is “static” in the sense that the output cannot be modified (think pdf), if there is an error on the report (e.g., a name is misspelled), then the data must be changed in the database, rather than directly on the report. The result is that the data is correct for the next person that needs it.
2. Different users using the same report should get the same result. Reports typically don’t allow you to change the query source, other than perhaps allowing for certain criteria to be changed at runtime (e.g., entering a date range on a dues renewal report). Because the report is using the same criteria each time it is run, the results will be consistent. Contrast this with a query tool that allows you to change any and all criteria, and you can see where queries can create a lot of consternation among staff if even one query line is different.

So look at the data you’re pulling. Are you using queries more than you should?

As I noted here, I was pleased to see an AMS vendor provide client access to their online help system. In a nutshell, the online help that is available from the vendor can be modified by the client to include client-specific business rules. This is a great concept and one that is long overdue.

I’m pleased to report that I sat through two demos last week where both vendors allowed for the same thing: Protech and Aptify.

In the case of Aptify, the online help can be modified by the client and is protected through upgrades. In addition, Aptify allows for field-level help as well, which is very cool. In their case, you can hover over a field within the database and call up help on that specific field. Nice feature.

I’m very pleased to see more vendors offering this option, and I hope in the near future it will become standard industry practice.

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 sitting in a consulting workshop a few weeks ago being led by Alan Weiss. Alan was making the point that the most valuable consulting is the kind that focuses on transformational behavior, rather than transactional behavior. That is, there is more value in helping an organization move to a higher level of performance (transformational) than there is helping an organization to better manage its current state (transactional).

The same applies to managing your association management system. For most organizations, the focus is on the transactions taking place in the database (e.g., sales being made, is the contact data correct, etc.). But to really get value from your database, you have to focus on the transformational. By that I mean leveraging the data within your system to really transform your organization. One way to do this is through business intelligence.

At the recent ASAE Marketing and Membership Conference, I spoke about business intelligence and how associations are using BI to leverage the data they have for improved marketing and membership activities. I presented four case studies on associations successfully using BI, and I’m going to use those four case studies as examples of moving from transactional to transformational. Stay tuned…