the WORKS

S. I. Inc. Up and Running in Florida

In the last issue of the WORKS (the Winter 2005 issue as we announced that there would be no Spring issue) we explained that S. I. Inc. was moving to Palm Beach, Florida. The move happened in early June and we are now established over looking the Atlantic ocean at latitude 26° 35' N. Unlike the Jimmy Buffet song, there will be no changes in attitude with the change in latitude! As we were leaving Dedham, S. I. Inc. acquired a new client. This is an executive search firm that desires a new Customer Relations Management system. They have no problem with our being 1,500 miles away. Please read the next article for a more complete description of this engagement.

While we are always interested in gaining new, local, clients, this move gives us the opportunity to try out technological solutions to the problems of distance. We have a web cam set up in the shop. This can be used with MSN Messenger 7.0 to provide a tele-presents at any time. The audio side of communications utilizes Skype. This seems to be better than the audio portion of MSN Messenger 7.0. It is interesting to observe that this combination finally fulfills the promise of 1960s “picture phone.” We will be experimenting with other tools during our current engagements and will undoubtedly report our findings in upcoming issues of this newsletter.

Pace is very important to me personally, and therefore S. I. Inc. I have no desire to have employees, although I would be interested in perhaps partnering with others. Therefore, S. I. Inc. will be very selective about the number and types of project with which we engage. They need to be interesting, of such a scale that they can be completed by one person in a reasonable amount of time, and involve only a limited amount of travel. S. I. Inc. has developed, since its founding in 1981, along lines favorable to me personally and this will not change. I have reached a point in my career where I have desirable choices. In that respect I have been very fortunate.

As a result of the above explanation, we will spend the summer working on our new client’s needs and possibly doing some more work for High Tide Software. Some time around Labor Day, we will begin to look for new engagements. While I expect to be casual about marketing S. I. Inc., in no way are we casual about the performance of work on our projects. Once the firm commits to an engagement, they can count on S. I. Inc. being fully committed to the work.

New CRM Engagement

We have just begun a new engagement with an executive search firm. For concerns of privacy and not all of the concepts here presented are going to be incorporated into the final product, we are concealing the name of our client. Let’s call the company Matchmaker, Inc. Currently Matchmaker works with large directories (folders) of resumes in Microsoft Word format (.doc files). When a client firm has a position to fill, Matchmaker constructs a query and searches through tens of thousands of resumes to come up with a list of candidates. This procedure has a number of problems:

As the number of resumes on file increases, the search time becomes longer and longer. It has already reached the point of being impractical.
The resumes are “static.” If Matchmaker learns something new about a candidate, there is no way to incorporate this into their firm’s base of knowledge save creating a new resume and deleting the old one. The history of a changing/developing candidate is lost.
No electronic audit trail is kept on the client organization.

For all of these reasons, and many more, Matchmaker has asked S. I. Inc. to design and build a CRM system. Space does not allow us to go into detail about the new system, but here are some interesting ideas and concepts that we intend to develop. The base for the CRM system will be S. I. Inc.’s lead tracking system that has been in use since 1996. It will start out as an Access application and may be “upsized” into a SQL Server system before the engagement is completed.

Probably the most important concept in the design is a separation and generalization of two key entities: People and Organizations. Too often there is confusion over these two entities when moving from a manual CRM system to a computer based one. It is not that clients mistake a person for a company, but that they think of their client as both a firm and a person at that firm. Matchmaker treats a client, say IBM, and the HR Manager at IBM with a position to fill, as the same thing.

In building the CRM system, there will be two major tables, one for Organizations (like IBM) and one for People. The Organization table is very straight forward. This is information about the firm. In concept there should be one record for the firm’s headquarters, but in practice for small companies like Matchmaker and S. I. Inc. there would be one entry for each location. For example there would be separate records for IBM, Armonk, NY and IBM, Boston, MA. Each position, for which Matchmaker was doing a search, would be “threaded” on the Organization table. Suppose that Matchmaker was retained to find a VP of Research and a Director of Transportation at IBM, Armonk. Both of these engagements would be rooted to the IBM, Armonk record.

One of the interesting distinctions of the way Matchmaker thinks of its clients is the difference between the “client” and the “manager.” The client is a person, usually in Human Resources (HR). This is the person who retained Matchmaker to do the search. The “manager” is the person in the client’s organization who has the need for the candidate. Both of these people are entries (they are attributes of) in the Position record. As will be explained below, what the entry actually consists of is the “key” to the People table. For uncommon names like Schuldenfrei, it is simply the last name. For common names like Jackson it is probably something like Jackson35. As explained in the next paragraph, all people (candidates, clients, and managers) have entries in the People table. This is a unique feature of the CRM system. Over the last 30 years that we have been developing these systems, we have always placed people in a common pool of names regardless of how these people are structured into the systems we have built.

The most important table in the system is the People table. Every table, the People table included, has a unique Primary Key. As explained above, this usually is the person’s last name, but it is totally up to the user. We have tried to put as much information as we could on one screen so that the user can have access to as much data as possible without jumping from screen to screen. Some of the important elements of information contained on this screen are:

Name and address data.
Urgent notes that must be visible when looking at the screen.
Brief career history displaying the current job and the last three jobs.
Data about the next interaction with the person.
The file containing the stored resume and a button to open that resume.
A thread of notes recording anything important about this person.

Not all of these data elements need to be filled out for every person. For example, the resume field might be blank for a “client” unless we placed this person in the past. In a similar manner, the career history of a “manager” could be blank for the same reason. However firms like Matchmaker would do well to keep as much data on file about every person with whom they have had contact, because you never know when today’s manager might become tomorrow’s candidate.

One of the most interesting aspects of this system is they way notes are stored and displayed. In order to keep as much information on the screen as possible, textual information is stored in four areas that are tied together on the People screen. First, there is a link to the latest resume with a button to open this file in Word. Second, there is a 255 character “Note” field that works together with the date of the next contact. This is a “tickler” to remind the user about the substance of the next meeting. One very useful report is a listing of all of the records that have a next contact date and note. Matchmaker can list all of these records between two dates. Thus you can plan your day, week, or any time period.

The third note field is the Urgent Note. Although it can be of any length, the People screen displays about four sentences such that Matchmaker can view all of the critical data pertinent to this person. The fourth note field is a thread, in date order, of the history of all contact with this person. These notes are of unlimited length so as to document the relationship in detail.

Space does not permit us to go into any more detail, but one final point should be made. At this point in the engagement, nothing has been finalized about searching. Currently, Matchmaker does a key word search of the resumes. Much of the same data will be on file in the Access database. One additional set of data is the skills inventory of the candidate. Nothing is set about how this data will be entered and stored in the database, but we have discussed a number of techniques. One is a program that reads resumes and isolates skills. For example, the program would key in on words like C++, CPA, PhD, etc. These would be stored as a “bit-string” in the candidate’s record. This would make for very efficient searches.

For additional information:

bob@s-i-inc.com
Phone: (561) 582-3340

     Or send USPS mail to:
     S. I. Inc.
     3450 So. Ocean Blvd. - #616
     Palm Beach, FL 33480