3rd Annual Pharmaceutical Meeting Planners Forum

I participated in a panel discussion on "The Future of Meetings Technology" at the Center for Business Intelligence (CBI) 3rd Annual Pharmaceutical Meeting Planners Forum on March 27, 2007 in Philadelphia. My co-panelists were Michael Boult (CEO of Starcite) and Rick Borovoy (CTO of nTag). Gaze with me into our crystal ball...

Question 1. Why hasn’t the meetings industry adopted technology tools at the same rate as other industries?

My perspective (since Internet tools became available in 1998) is that meeting professionals have adopted "public-facing" tools such as online registration, event web sites, email marketing, and web-based meetings (webinars) as quickly as other industries. They have not adopted "back-office" systems, however, at nearly the rate seen in other service departments such as Travel, Finance, Procurement.

I think this adoption pattern has several causes:

• The traditional event planner has been a "people-person" who loves to focus on the attendee experience rather than learn new technologies.


• Available tools have not been both powerful enough and simple enough to meet most planners' needs.


• Investment in and development of back-office tools for meetings has lagged that of Travel, Finance, and Procurement because there was not a critical mass of centralized corporate meeting departments and large meetings organizations willing to spend on IT at the same levels seen in the other areas. This situation is changing rapidly.

Question 2. Is the current electronic RFP system working for hoteliers?

Michael Boult took this question from the audience. His view is that current web-based RFP systems (such as Starcite's) are simply digitizing the existing RFP-based sales process. Some planners or companies may have abused this efficiency gain on their end by increasing the number of facilities who receive their RFPs (in hopes of driving costs down via competition), but most systems like Starcite have learned and now send an RFP to an average of 7-8 hotels (which are previously matched against the event criteria). This shouldn't create more burden on the hotels' sales offices than they had before the Internet.

His question to the audience was why don't meeting planners move away from the RFP process and move to a "shop & transact" marketplace, for example, one similar to the manner with which you purchase plane tickets or shopping carts of books and electronics. None of the attendees had a good answer, but my perspective is that both sides of the industry are averse to such a marketplace being controlled by a single company, like Starcite, who would profit handsomely from transaction fees, while all of the suppliers would be forced into a cost-cutting mode that would commoditize the products (hotel services and meeting experiences) which the industry is determined to keep unique. I believe that such a marketplace built upon open standards such as APEX will have a niche in the future.

Question 3. Why is integration so key to meeting management technology?

Most meeting professionals realize that event management applications will not be primary data tools from the perspective of a large organization, relative to enterprise applications such as Customer Relationship Management (CRM), employee databases (HR), Finance, Procurement, and Corporate Travel. Thus meeting management applications will either have to work with these primary systems, or their users must continue to manually export/import and re-enter data from the primary systems.

Question 4. How will Web 2.0, Second Life, etc. affect the way planners hold meetings (if at all)?

Web 2.0 is vaguely defined as the "Internet of You" -personal web sites, Blogs, social networking, and online personas that in some cases are better known than your physical self.

People often ask why video-conferencing isn't more widely used, after all, AT&T created the PicturePhone 40 years ago. Anyone who spends a few hours a day on webinars and conference calls knows that it isn't because the video quality is too low (it still is) but rather it's because we simply don't look as good as we think we do.

Enter Second Life - a virtual world where you create an online persona who interacts with others for you. I can see a future where you combine Internet telephony, instant messaging, webinars, and a realistic computer representation (at the quality of Pixar movies and video games) of yourself into a "Second Life" meeting room. This is being done on the fringes of technologists, but it could become mainstream. I would much rather have a moving representation of my best picture making a presentation in a webinar than to have an actual live video-conference picture of myself - and the technology is easier without the live feed anyway.

Here is a great picture from the September 28, 2006 issue of The Economist, showing grandmother Donna Meyer and her Second Life avatar. Which would you rather watch presenting a seminar on punk rock music?

Question 5. Do you any of you share the opinion that the use of technology in site selection and social networking (before and at meetings) affects the human interaction and will evolve or come full circle (driving more person-to-person interactions)?

I think that the quality of the face-to-face meeting experience is going to increase. Otherwise, there is no point in spending the travel time and costs to leave your office, when you can have a basic meeting of minds via conference calls and webinars. As work teams become globally distributed and people have more choice about where they want to work, face-to-face meetings will be reserved for the most valuable personal interactions and experiences. I think the overall number of physical meetings will stay about the same, but the value (and cost) per person is going to grow in order to deliver this higher level of quality.

Question 6. How do you see the APEX initiative entering planners’ everyday lives?

I've spoken about APEX repeatedly, and I see it being the plumbing that makes the water flow. Meeting planners won't know what APEX really is until they see the technologies that come out of its implementation - the elimination of "Changes Reports" (because planners and hotels will keep their systems in synch electronically and automatically), an electronic marketplace of events and services (see Question 2), and event resumes stored as "e-books" on your PDA instead of 3-ring binders. When these things become commonplace, event planners will appreciate that the water is indeed flowing, even though most still won't care about the plumbing that got us there. And then, of course, after a few years they'll just expect that the water always flowed when you turned the faucet handle.

Question 7. What are the "next big things" coming for meetings technology?

• "One system for all meetings" - big conferences, small meetings, all different event types will be managed within a single system


• Integration - behind the scenes your "single system", which works seamlessly for you, will be tightly integrated with many other systems both inside and outside of your organization


• Simplicity - technology will just work, or you won't use it (we'll see...)


• Migration from RFPs to "Shop & Transact" - at least for some products and services


• "Web 2.0" - technology will customize your events to you


• Social Networking - computers will aid person-to-person interactions and introductions, allowing you to collaborate locally and globally in an online community that is an extension of your physical one

APEX TAC Monthly Meeting Minutes - April 2007

The APEX TAC held it's monthly Virtual Meeting on April 19, 2007. Here's what we did.

APEX TAC Monthly Virtual Meeting

Host: Rick Borry (Certain)
Meeting number: 484 326 154
Start Time: Thursday, April 19, 2007 07:56:04 PM(GMT 00:00)
End Time: Thursday, April 19, 2007 08:43:47 PM(GMT 00:00)
Meeting URL: https://newmarketinc.webex.com/newmarketinc

Attendee List:
Rick Borry (Certain)
Sujal Shah (Starcite) - NEW
Jeremy Keller (SiteVisit)
Buck Downs (Columbia?) - NEW
Jane Melville, Julie Graff & Marshalle King (Hilton) – NEW, replacing Bob Horn
Scott Rudberg & Andrea Campbell (Passkey)
David Collins (Syllogy Design) - NEW
Kyle Bricker (Lenos) - NEW
Rob Wilson (Meeting Sites Resources)
Ali Tabatabai (Avectra) - NEW
Rooji Sugathan (Ungerboeck)

Agenda

1. NEXT MEETINGS:


1. Meeting calendar available at: http://apex.dataapp.com/Calendar/tabid/224/Default.aspx


2. May 17th virtual 3rd Thursday at (4:00pm EST to 5:00pm)
   MEETING NUMBER: 484360851
   PASSWORD: APEX051707
   *** Please sign in with your name as “First Last (Company)” so that it’s easier to take attendance.
   
   
3. The next face to face follows HITEC in Orlando. The TAC meeting will be held on June 27th and 28th. We have a room block of 5 for $149.99 each at Embassy Suites Orlando - Lake Buena Vista, 8100 Lake Ave., Orlando, Florida 32836. Attendees can call the main number 407-239-1144 and ask for the Reservations Dept. (Mon-Fri, 8-4pm). Please have mention "CIC/APEX".
   


2. STRATEGY REVIEW (from the Ft. Lauderdale meeting last month)


1. See http://registrationdoctor.blogspot.com/2007/04/apex-implementation-pilot-q1-2006.html




3. PROGRESS UPDATE:



Take inventory of where the 4 groups are: ESG, FSO, Rooming List, RFP.



1. OTA_HotelRFP_MeetingRQ.xsd

Jeremy (LEADER) ~90% complete (need to merge Rob’s files and review)
Rob, Junior
Julie, Marshalle, Jane (Hilton)


2. OTA_HotelRoomListRQ.xsd

Michael (LEADER) - (Dave - Mike seems to be the best owner) ~70% complete?
Dave, Scott, Andrea


3. OTA_HotelEventRQ.xsd – ESG

Rooji (LEADER) ~40% complete
Rick


4. OTA_HotelEventRQ.xsd – FSO

Jessica (LEADER)
Chip, Bob (phasing out, to be replaced by new Hilton members after RFP is completed)


5. Volunteers - David Collins (will join a group but wants to look at them first)


4. THIS MONTH’S TASKS


1. The leader for each group should coordinate with EJ to schedule working meetings (~2h webex and conference call) with their team in order to complete the XSLTs before our next meeting (May 18th)


2. Rich Mattes (Newmarket) can coordinate scheduling of working meetings if you need to use their Webex


3. We need to drive these to completion by May so that we can try to get pilot implementation in someone’s database by the June meeting.


4. Discuss common issues teams are facing and decide how to resolve them on the Forums at: http://apex.dataapp.com/Forums/tabid/226/ctl/Edit/mid/624/ItemID/6/itemindex/0/Default.aspx


5. Sujal (Starcite) said that they previously tried to implement APEX internally, but were not successful due to several reasons:


• The sheer size of the XML message
• They weren't sure where to map their database fields in the XML standard
• The standard included a large number of fields that weren't useful to them
• We hope to address these issues with our current project of producing validation and translation standards.



5. NEXT MEETING (Virtual May 17th)


1. Powershop beta demonstration (Chip Meyer)


2. XSLT Demonstrations by working groups

APEX Implementation Pilot - Q1 2007 Update

On March 21-22, an intrepid group of pioneers met in Ft. Lauderdale to figure out how the meetings and group travel industry will use this APEX stuff. Like all explorers, we discovered that the path before us will be easier than we thought it was before we started, but harder than we had hoped for.

Time to Test the "Exchange" part of APEX

As the name (Accepted Practices Exchange) says, APEX is about exchanging data between trading partners in the meetings and group travel industry. As described previously, last year we developed three XML specifications within the Open Travel Alliance to help event planners exchange data related to:

• Request for Proposals (RFP) - meetings in search of a facility
• Hotel Rooming Lists - attendees who need rooms in a group block
• Event Specification Guide (ESG) - meeting information for the planner to share with the hotel

This year, our goal is to implement pilot programs with specific industry partners who will use these XML standards to electronically transfer data from one proprietary system to another.

The Plan

First, our group (the APEX Technology Advisory Committee) reviewed our options and selected a strategy. We decided that each trading partner (meeting planners, CVBs, and hotels) would be responsible for creating their own "translator", or software routine that converts data from their proprietary database format into the standard APEX XML.

Notice that the APEX standards do not specify the infrastructure surrounding the XML exchange. Eventually, we expect to provide guidelines about this infrastructure, which may consist of SOAP web services or https GET/POST methods. We expect the data exchange methods will require an authentication layer, in order to make sure the other application should have access to the requested data, and a version control layer, since the OTA standards are published twice a year and will undoubtedly undergo changes as the community learns from experience.

Next, we agreed that we want to offer a human-readable version of the (machine-readable) XML documents. This will make the XML useful in situations where only one trading partner adheres to the APEX standards, and it should help developers validate their XML translators.

For now, we decided to not tackle the Exhibitor versions of the Event Specification Guide (ESG) or Functional Setup Order (FSO), and we decided not to produce an XSLT standard for the "page layout" of the Rooming List standard, since this is legacy report format leftover from the days before Excel and e-mail.

The Preparation

Before starting a software development project, you should define how you will validate that the result meets your expectation. For APEX, we agreed upon a validation method for trading partners to test their translator routines that produce XML documents:

• The XML must be well-formed. Any XML editor (or browsers like Internet Explorer) will tell you if the resulting XML document is formed correctly according to the W3C standards.
• The XML must validate against the OTA XML schema (XSD). Good editors like XML Spy will compare XML documents to an XSD standard and instantly identify areas of non-compliance, e.g. if an email address is not in the correct format.
• The XML must have data in the correct fields. Developers will be required to download the sample XML documents from OTA, enter the data into their application database, and then produce XML using their export translator. The resulting document should match the sample that you started with, otherwise, for example, you may be putting a person's first name into the last name field and not notice the error during the first two tests.

The Path

After discussing our past experiences with XML data transformation and exchange, the team selected the Altova MissionKit Enterprise Edition for the implementation process. (The enterprise edition is required because the OTA schemas are complex "nested" xml schemas, which aren't supported by the professional edition.)

• XMLSpy - OTA uses this editor to produce the XML standards, and it offers simple validation of XML documents against XSD schemas.
• StyleVision - We used this editor to produce XSLT files that map "machine-readable" XML documents into "human-readable" HTML or PDF formats.
• MapForce - This tool will allow each trading partner to map their proprietary database fields to the XML Schema standard fields, which is the first step to building a "translator" for the APEX standards.
  

The Journey

Well, if only you could imagine how excited this bunch of computer geeks were after producing a Plan, Preparation, and Path on the first day. After dinner and a couple of drinks at the Irish pub that night, we actually thought we might knock this thing out on the second day. Unfortunately, reality set in after about 2 hours of struggling with Stylevision, but we created enough transformation tools to confirm that we are on the right path.

The journey continues - contact us know if you want to join it.

Why be PCI Compliant?

I've spent three weeks discussing PCI Compliance, but why am I so concerned about protecting financial and personal information? Because there are a lot of bad people in the world, and the Internet has given them access to the more trusting (or "gullible", from their perspective) audience in relatively safe countries like the United States. Here are two recent experiences that could have led to financial loss.

Scam 1: "Please refund my other card"

I heard this story from one of our clients during a recent Performance Analysis.

An attendee registered for a training conference and attempted to use several different credit card numbers to pay for his tuition. (He eventually completed payment with a Visa card.) Weeks later, he sent an email to the event's registration support contact explaining that he would be unable to attend the conference, but that he had recently switched credit cards and would like the refund to be posted to his new credit card number. The support contact decide not to do this, because (1) PCI Compliant systems like Certain Registration don't support this process and (2) the request, combined with the number of failed payment attempts using multiple credit card numbers, "smelled fishy".

Later, the client found out that the Visa card used for tuition payment belonged to a older woman in Arizona, and after piecing this puzzle together, they refunded the full amount to the original card. Our contact notified their corporate security department, who in turn contacted the FBI's Internet Crime Complaint Center (IC3). It turned out that the "attendee" was a Ghana national involved in a fraud operation much larger than this incident. Fortunately for our client, because they listened to their instincts instead of immediately trying to satisfy the attendee's request (and because they were using a PCI compliant system), the investigation could be turned over to the FBI without financial loss for either them or the credit card victim.

Scam 2: "Sorry, but I wrote the check for too much"

The second experience hit closer to home. I recently moved and listed my previous townhouse for rent. I received an email from "Marcus", who informed me that he was placing a colleague in the north Dallas area for a year and would like to rent the house, and would it be okay to pre-pay six months' rent in advance? My suspicion was raised by the poor grammar in his email, but you can't argue too much with cash up front, so I accepted the offer.

Two days later I received a DHL overnight package from Dubai, United Arab Emirates with a cashier's check for $35,300 drawn on JP Morgan Chase Bank in Florida. Great - except that six months rent plus deposit was only $11,200. He then sent me an email stating that he had accidentally cut the check for too large of an amount, but he was not able to change it so could I please cash the check and then wire transfer the difference ($24,100) to his bank in the UAE?

Well, that was the end of the business deal for me, but I have learned that this con is common enough to get it's own FTC warning, and successful enough that the FBI IC3 is only interested in your case if you actually lost money. A few mornings later, I received a phone call from "Marcus" (which showed on my caller ID as originating from a Dubai country code) and from the background noise activity it certainly sounded like he worked in a call center operation as busy as that of any medium-size business in the U.S.



It's a jungle out there

The Internet has brought the world together, but unfortunately much of our world is still the Wild West. Be careful out there, and follow best practices like those of the PCI Standards.

PCI Compliance Part 3 - Don't lose that credit card data!

Two weeks ago, I discussed what PCI Compliance is and where it came from. Last week, we reviewed the first 6 requirements of the PCI Data Security Standards (DSS). Today we'll finish this series with an explanation of what requirements 7-12 do to protect your clients' cardholder information.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

This sounds like a page out of a classic spy novel, but the principle of "need-to-know" is a foundation of good security. Only users who specifically need access to credit card data should have access to the system that contains that data. If a user has access to other parts of the system, then by default they should not have access to unencrypted, sensitive credit card data. Lastly, administrators should grant access to cardholder information only to the minimum number of users who specifically need to see that information for a legitimate business reason that has no alternative.

In Certain Registration, for example, some meeting planners still collect credit card numbers from their attendees in order to "guarantee" their room reservation. These planners need to deliver the unencrypted credit card number to the hotel if the registrant is a "no-show" for the room, thus they have a legitimate business reason to view the full credit card number and their User access can be granted permission to see those numbers. However, all other users will only see the last four digits of the credit card number if they attempt to view the same reports.

In the near future, as more companies adopt PCI compliance, I suspect that no hotels will be willing to receive a list of unencrypted credit card numbers and will thus require room blocks to be guaranteed against the master account. Then the current "legitimate business need" to view these numbers will disappear, and such access can be ended. In this case, the planner can still store the credit card information in encrypted, unreadable format, and they can charge the registrant's card if they are a no-show without any human being able to read the cardholder data.

Requirement 8: Assign a unique ID to each person with computer access

If you are going to restrict access to data via an authentication scheme (such as username/password), then each individual person must have their own authentication. If multiple people share a single username, for example, then the system cannot audit which person made specific actions, only which username made those actions.

In order to make sure that only the intended user has access to a given username / password combination, PCI places multiple restrictions on systems:

• Passwords must be at least 7 characters long, with a combination of alphabetical and numeric characters
• Every 90 days, passwords must be changed and inactive user accounts must be removed
• The user must be authenticated prior to changing or resetting passwords, e.g. by sending a temporary password to the User's email address
• User sessions without activity for 15 minutes must be automatically timed out and require login to re-start

Some of these security requirements, such as the 15-minute timeout rule, can be annoying for users who don't need access to credit card information. Thus our system gives those users the options to adhere to a less restrictive security policy - but they cannot view credit card data. Any user who can view cardholder data must adhere to the PCI guidelines and live with its inconveniences.

Requirement 9: Restrict physical access to cardholder data

PCI requires companies to control physical access to cardholder data; this includes access to the database servers, backup media files (which are often stored offsite), paper hardcopies, etc. Modern Network Operations Centers (NOC), such as ours at NTT Verio, provide this control through 24/7 security, photo-badges with biometric hand scans, individual cages and cabinets, and constant video monitoring.


Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

PCI requires us to log all activities related to accessing cardholder data, plus all activity related to controlling access to that data. So everytime an Administrator creates a new user with access to cardholder information, we record the action in a log. If a user runs a report with cardholder data, the action (and content of the report) is logged. These logs cannot be deleted by Administrators, and are available online for a year after the action occurred.

Requirement 11: Regularly test security systems and processes

Periodically, security vulnerabilities appear due to new techniques discovered by hackers or researchers or software updates. PCI requires adherants to monitor critical files for changes, scan internal and external network vulnerability quarterly, and perform annual detailed security tests on all systems.

In addition, networks need to have an "Intrusion Detection System" (IDS), which is basically an observation post that watches the data traffic flowing through your network and looks for patterns that indicate malicious data attacks or a security compromise.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Companies that collect cardholder information must publish written security policies that adhere to PCI compliance. The policy should be known by all employees and contractors, and any outside vendors who receive cardholder information must also be PCI compliant.

Since most data security breeches are caused by internal behavior, all employees who have access to credit card information in bulk format must be screened prior to hiring. For example, we perform credit checks and criminal checks on employees as part of the hiring process.