The American Society of Radiologic Technologists built its own association management system in house from scratch. Learn how the two-year project was executed and how it helped put control back into the organization's hands.
Managing data can be a daunting challenge for any association. The bigger the organization, the more data that has to be processed. As a result, it's no surprise that associations sometimes struggle to choose the best association management packages for their needs.
This was the case for us at the American Society of Radiologic Technologists in 2007. For more than 15 years, our 134,000-member organization used a series of different off-the-shelf, prepackaged association management systems. The systems did the job, but they required outside support to keep them functioning at a high level. Add upkeep and annual contractor maintenance fees to the mix, and ASRT had a system that relied on third-party support.
For years, ASRT designed its own add-on features to supplement its off-the-shelf AMS. However, by 2007, the association was growing at a rapid rate, and its existing AMS was forced to handle increased amounts of transactional data, including thousands of annual membership renewals, large volumes of product sales, and a plethora of financial data. The necessity to manage the abundance of incoming data was the impetus for the association to start working with a contractor yet again to expand the system's capabilities. Unfortunately, after years of specialized tweaks and upgrades to the AMS, it was almost impossible to incorporate the expansion. Our AMS had turned into a hodgepodge of modules and systems.
ASRT attempted to complete the upgrade, but after a series of meetings with contractors, the upgrade still wouldn't work properly. After more than three months of trying to integrate the upgrade, the association made the strategic decision to put on the brakes and re-examine its situation. And it all came down to one question: "Why can't we do this ourselves?"
"The off-the-shelf systems worked for us, but we always thought we could do better," says Greg Morrison, MA, R.T.(R), CNMT, CAE, ASRT chief operating officer. "There was no question that our in-house team of programmers could build a system that could meet our needs, but we also understood that it would require a lot of work."
Despite the potential hurdles, in late 2007 ASRT made the decision to scrap the off-the-shelf product and move forward with designing its own AMS.
We knew that developing an entirely new core AMS system that would interact with the existing financial system and all the other departmental transactions would be challenging. However, since the association previously created several add-on systems for the AMS, we had the basic knowledge necessary to get the ball rolling.
Before they could start designing the new AMS, the team of programmers and designers had to choose a logical starting point. Understanding that the most important component of any successful AMS is its ability to capture financial data, the team started the project by examining the association's current financial management system.
It was critical that the existing financial management system mesh seamlessly with the programming language that they planned to use for the new AMS, but that was easier said than done. ASRT uses Microsoft platforms for nearly all of its software and hardware needs, and even though it was using Microsoft's Dynamic GP financial management software, the new Dynamic GP was not written in a native language that would communicate properly with other Microsoft packages. Therefore, ASRT's programmers had to build all the financial transactions from scratch.
"We started to research our options, and we determined that we didn't have the option for direct transaction of native languages between Dynamic GP and our existing systems," says Morrison. The solution: The team started developing wrappers for the two systems.
Wrappers allow one system to talk to another. When a string of data needs to communicate with a system using a different language, a wrapper has to be developed. The wrapper allows incoming data to distinguish the recipient's language and communicate effectively. It's a systematic way to avoid having to constantly rewrite a programming language when a new software system is introduced to an existing package.
Following the development of the wrappers, it took about one month to develop the proof of concept for the system. A proof of concept is another research tool that determines whether or not the function works. Once the programmers determined that the wrappers worked, an initial plan was put into place.
Getting Everyone Involved
"Since we had end users involved every step of the way, almost everyone had an idea of how it would function and knew what the finished product would look like. We also had great communication among team members, so there were no big surprises when we went live." —Greg Morrison, CAE
Before a definitive plan was put into place, we realized that we needed to communicate to the staff about what was happening. After all, taking on a project of this scope required input from every department at ASRT because an AMS touches almost everyone in an association. As a result, a task force consisting of 15 to 25 staff members was assembled early on in the planning process to identify all of the areas that would be addressed with the new AMS. The task force was crucial because it allowed every department in the association to have a voice in the process.
Moreover, to eliminate any assumptions that might surface, a business system analyst (BSA) was brought in to impartially work with departments, so all staff members had an equal say in the development of the AMS.
For more than two months, the BSA interviewed individuals in every ASRT department to learn about the end results of each transaction completed. In conjunction with the interviews, the BSA took the process information and mapped out almost every major business process at ASRT. The mapping project included the development of process flowcharts and standard operating procedures. The information culled from the BSA's research allowed the AMS team to understand how each process worked and how they would work in conjunction with the existing financial management system.
It's also important to note that more than just programming is involved in creating a system that manages large amounts of data for an association the size of ASRT. It also has to be user friendly.
To address usability issues, ASRT hired a design consultant to provide guidance on how people use certain systems. Working in conjunction with the consultant, designers from ASRT's art and communications departments developed the user templates and the master page of the system.
Following the completion of the templates and master page, the programmers were able to drop in the elements that could perform business functions.
The next year of the project included developing the user screens, meeting with end users, and incorporating business elements. This was a critical period because it allowed the task force and programmers to outline the precise transactional functions that would be in the final version of the AMS. That 12-month period also included ongoing beta testing as pieces were completed, so end users could review what did and didn't work. It allowed the programmers to fix the errors early, so there wouldn't be a lengthy punch list of corrections requiring attention right before the scheduled launch date.
Getting Past Road Bumps
But with as much thought and attention that was put into the project, there were still challenges along the way. The project required a lot of participation from various groups, and everyone had to stay on the same page. In fact, managing the expectations for end users was an ongoing discussion throughout the planning and development process. The task force and programming team were steadfast in their belief that the final product should handle all the major business processes for an organization of ASRT's size but not reinvent the association's established processes and procedures.
According to Morrison, that was one of the biggest challenges. "It's normal for individuals to want to try and revamp processes along the way, but our goal was to develop a system that would effectively manage all of ASRT's data," he says. "So, we had to make sure we stayed true to our mission. Thankfully we had great support from the entire staff, so that made the job much easier."
It's important to note that regularly scheduled project meetings were occurring during the entire process. Since the project was an association-wide initiative, it was crucial for every staff member to have a finger on the pulse of the project since they would all eventually use the system. In other words, our goal was to avoid any surprises.
"Since we had end users involved every step of the way, almost everyone had an idea of how it would function and knew what the finished product would look like. We also had great communication among team members, so there were no big surprises when we went live," adds Morrison.
Getting Ready for Launch
After nearly two years of research, programming, and design, the ASRT Association Integrated Management System (AIMS) was launched in February 2009. Because the system was designed in house, ASRT owns all the code and can make modifications or streamline processes internally. Moreover, the system was designed so it can accommodate new processes as the association grows.
And according to ASRT Chief Executive Officer Sal Martino, Ed.D., R.T.(R), FASRT, CAE, AIMS will save money in the long run. "Now we can accommodate the wishes of all our departments. For example, if our marketing department wants to manage a campaign in a certain way, we can customize AIMS so it captures data that can help them evaluate the success of the campaign," he says.
In addition, AIMS manages all of ASRT's data, including financial transactions, merchandise sales, product inventory, meeting registrations, and membership data. It even tracks continuing-education credits for ASRT members and transfers them to the American Registry of Radiologic Technologists. Since ARRT mandates CE credits for radiologic technologists, it was extremely important for ASRT's system to transfer credits immediately to the registry.
Even more, AIMS includes a middleware system that allows the front end to be database agnostic. It does all the translations of the data. It communicates through web services over the internet to other systems. It doesn't matter what language the receiving system is programmed in, middleware will decipher the language and communicate with it.
But does the system work? It does. In fact, it's been highly successful since it launched. During the first 12 months of activity, AIMS processed more than $5 million in online membership renewals for nearly 44,000 radiologic technologists. Additionally, AIMS processed more than 1.3 million CE credits and transferred them to the registry.
Furthermore, the system has operated nearly error free. "We couldn't be happier with our system. We encountered a few glitches, but we addressed them immediately," says Martino. In fact, we're servicing our members better than ever. It was a risky decision to move forward with the AIMS project, but it's paid off."
Martino also believes that AIMS will help the association move forward. "Having our own system that allows us to customize it as we grow and expand is really a plus. It's a core component of our daily operations, and we look forward to expanding its capabilities."
Jake Buehler is the director of communications at the American Society of Radiologic Technologists. Email: [email protected]