l e n s b o x s t u d i o s

a geek’s mark on the wired world while exploring the gaming metaverse.
  • Home
  • About Me
  • Freelancing
  • Private Design Work
  • Contact

Seeing everyday events, especially business dealings, as metadata (Part 1)

24 04 2008

Let me start off by defining metadata…

Metadata (sometimes called metainformation) is “data about data”, of any sort in any media. An item of metadata may describe an individual datum, or content item, or a collection of data including multiple content items.

Recently, a self-initiated project, involving business systems at my workplace, got me thinking about the data we do collect about business… and the data we unconsciously collect but never record for later use. Such data, is usually metadata.

Metadata (sometimes written ‘meta data’) are used to facilitate the understanding, characteristics, and management usage of data. The metadata required for effective data management varies with the type of data and context of use.

All too often, we record data but we become selective in our retention and representation of the data, etc.

I’m of the belief that all data is important, to someone, somewhere, sometime…

Hence the title of this article.

Except I want to look specifically at business, especially the IT industry, and the way we deal with clients.

By now, most of you, in the wired world, should have heard the term, CRM or Customer Relationship Management.

To quote Wikipedia:

Customer relationship management (CRM) is a multifaceted process, mediated by a set of information technologies, that focuses on creating two-way exchanges with customers so that firms have an intimate knowledge of their needs, wants, and buying patterns. In this way, CRM helps companies understand, as well as anticipate, the needs of current and potential customers. Functions that support this business purpose include sales, marketing, customer service, training, professional development, performance management, human resource development, and compensation. Many CRM initiatives have failed because implementation was limited to software installation without alignment to a customer-centric strategy.

Let me draw an example for you… (bear in mind I’m an engineer, not a business guru)

A sales person calls one of his existing clients to let them know about a new technology/offer, etc. Let us say that the Client could respond in one of several ways:

  •  
    • Positive - sure, sounds great, please send me more information.
    • Hesitant - well, not sure we need this right now, but send me some details and I’ll take it up with management.
    • Negative - thanks but no, thanks. Don’t need anything now or we’re not purchasing anything until X date.

These are very simplified and I know there are many other variations, but for this example, I want to keep it simple.

So, depending on the feedback, the salesperson could begin the following processes:

  •  
    • Positive - sends the client more information and mentally adds a check next to that client’s name on their list, with a note to  get back to them soon.
    • Hesitant - proposes a possible meeting to discuss with management if need be or asks if there is possibly someone else they should chat to regarding purchasing/procurement.
    • Negative - Could try and persuade the client or may leave the issue be and move onto the next client.

On the surface, it seems pretty cut and dried. There has been an exchange and depending on the responses on one side, the other side can then adapt their responses accordingly. But even in the situations where the outcome is “negative”, there is value to be gained from the interaction.

Looking at any of the exchanges above, instead of simply mentally recording the fact that a client is still interested in business, or may be a potential lead, or is uninterested, we could expand on the knowledge we have about the client and his/her environment and thus readjust our approach. Here is some of the unspoken information we could glean from the interactions and some actions on them.

  •  
    • Positive - great, so what do we know, other than the fact that the client is interested in our offerings?
      • Well, we could probably assume that we’ve maintained a good relationship with the client or at the very least, are on cordial terms with them and that he’s happy to deal with us
      • He’s potentially in a procurement cycle right now, so it’s best to step up the process of quoting/invoicing or doing proposals
      • The client is potentially aware of the technology and may be open to other offerings of a similar nature. Have a plan B or C or even D with regards to offerings… offer him different scenarios and see if you can bait them further.
      • He’s potentially involved with procurement decisions.
    • Hesitant - Ok, so we’re don’t have  a foot in the door just yet, but what do we know?
      • He’s not directly involved with procurement but can put us in touch with the right people
      • They may not be in a procurement cycle at the moment or have a freeze in place with regards to infrastructure. Maybe we should inquire along those lines and try find a time at which to call again.
      • He may be stalling… try another angle and ask him what services they are in need of currently, perhaps we have something or can tailor-make a solution for him. Most good sales people will do this… The more information you can get out of them, the better.
    • Negative - Ok, panic stations! Is it us or them?
      • As above, but now we’re on the alert… what is our relationship like with the client? Have we done something to annoy them or failed to deliver on something?
      • If we’re on good terms, ask them when it would be a good time to call back. If you’re still rebuffed, time to do some damage control.

and so on…

Now, more often than not, all this information is not recorded centrally somewhere. It’s sitting in someone’s head, scribbled on some paper, in a journal somewhere. And generally not in a usable form.

If we could record all the information, or as much of it as our particular business needs dictate we capture, we could begin building a picture of the client, their needs, business structure, business cycles, etc. By filling in as many of the blanks, we gain a clearer picture of what we’re dealing with. It also makes it easier for someone else to take over that account and not have to do all the legwork all over again in order the build up an idea of where we stand with that client. At most, some politely phrased questions in a courtesy call to the client could confirm facts or raise the need to investigate further.

The same goes for more technical interactions, such as my recent field of investigation, vulnerability assessments. A comment overheard at a client site recently got me thinking that often we have all the answers at our fingertips but that we don’t correlate events from multiple sources that may provide a clearer picture about the situation.

For example, we may perform a Nessus scan on a client host and report certain findings (open ports, unsecured services, information advertisement, etc). The client then logs a call with us to make changes to correct some of the findings and we scan again to confirm that our changes have corrected the situation.

A while later, we scan again and find that some of the changes have been undone or new holes have appeared. We know that we haven’t done any changes to affect the status of that host, so we can then question the client, who would hopefully have some change control process in place to document their own changes. If they were not involved in the change, then we need to investigate further and rather urgently as all fingers point towards an external party making unauthorized changes!!

By recording the results from the various scans and having a history to compare against, we can track the evolution of the security solution, it’s improvement or degradation and have accountability in the form of our internal processes such as change controls, project sign-offs, etc. By mapping these together we could, for instance, prove that we were not responsible for a change that was detrimental to the client and therefore are not liable for damages, seeing as we had warned them before of the risk, had taken steps to correct the situation, then had those measures undone without our knowledge…

All of this, of course, assumes that the processes are in place to capture all the relevant data and store it. It also assumes that the data is in such a form that it can be recalled and manipulated. The degree to which it can be manipulated depends on the data types.

More to come later when I have time to type and plan.

Date : 24 April 2008 at 15:52
Comments : No Comments »
Categories : Information Technology, Security, Thoughts, Work

« Previous Entries

Afrigator

Navigation

  • Anime and Manga (7)
  • Design and Multimedia (10)
  • DVD's (2)
  • Events (7)
  • Food and Drink (9)
  • Freelance (8)
  • Gaming (18)
  • Information Technology (22)
  • Journal (46)
  • Movies (2)
  • Music (5)
  • Online Communities (4)
  • Personal (46)
  • Podcasting (3)
  • Rant (10)
  • Security (14)
  • Thoughts (44)
  • Webcomics (1)
  • Websites to visit (4)
  • Work (24)
  • World of Warcraft (11)

Archives

  • June 2008
  • May 2008
  • April 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • April 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • August 2006

Links

Meta

  • Register
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org


rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox