Point-of-Sale (POS) is a familiar notion in the world of commerce.  A well-engineered experience at the point-of-sale has obvious benefits both for the customer (a positive buying experience) and for the business of the supplier (real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, customer profiles, etc.).  An equivalent customer-supplier event exists within a business concerning knowledge -- particularly guidance and know-how (business rules).  I call this critical event point-of-knowledge (POK).

In the world of commerce, we often say that customer and supplier are parties to POS events.  Each of us is a customer in some POS events, and many of us act as suppliers in others.

The same is true about POK events.  Each of us is a 'customer' of knowledge in some POK events, and many of us act as 'suppliers' in others.  Sometimes we switch roles in minutes or even seconds.  For POK events, at least one of the parties is always a knowledge worker; often both of the parties are.

Much has been written about the emergence of the role of knowledge worker.  Far less, however, is understood about the engineering of effective POKs.  This is where the business rule approach comes to bear.

I should clarify that POK events are not the kind that occur in rapid, collaborative development -- for example, in the cultivation of customer prospects, or in the engineering of complex product/services.  You would not use Lotus Notes or other such knowledge messaging/retention tools to support POKs.  Instead, POK events center on events where corporate guidance (a.k.a., business rules) are developed, applied, assessed, and ultimately retired.  In other words, they are really about corporate governance and the application of the company's specialized know-how.

The customer/supplier 'experience' at POK events is crucial to worker productivity and job satisfaction.  In no small measure, this is the real challenge of POK support.  After all, the product/service for POKs is knowledge -- something you can carry only in your head, not in your hands.  Some of the most important critical success criteria in such engineering are the following.

• All communication in a POK must be in the language of the business, not IT.
  
  
• Interactions in each POK event must be gauged to the knowledge level (and authorization) of the individual parties.
  
  
• Less-experienced workers fulfilling the supplier role in a POK must be enabled to perform at the level of the company's most experienced workers.  (Remember that in a world of constant change, even the organization's best workers are frequently thrown into time-sensitive roles for which they are not fully prepared.)
  
  
• The elements of guidance (business rules) relevant to any given POK must be presented and/or applied in succinct, highly-selective fashion.
  
  
• These elements of guidance must also be presented and/or applied in timely fashion (i.e., 'just-in-time') to accommodate fast-paced refinement and change in business policies and practices.
  
  
• POK support platforms must be in the form of knowledge companions, enabling never-ending, on-the-job training of the knowledge workers.

Well-engineered POK support platforms also have obvious benefits for the business of the supplier -- for example, real-time intelligence about the 'hit' rate of rules, patterns of evolving customer (and supplier) behavior, emergence of compliance risks, and so on.  The business rule approach is clearly how to get to the real point of knowledge!

# # #