{"id":151,"date":"2014-02-05T21:05:38","date_gmt":"2014-02-06T02:05:38","guid":{"rendered":"http:\/\/waife.com\/home\/?p=151"},"modified":"2014-02-05T21:05:38","modified_gmt":"2014-02-06T02:05:38","slug":"not-at-your-service","status":"publish","type":"post","link":"http:\/\/waife.com\/home\/not-at-your-service\/","title":{"rendered":"Not at Your Service"},"content":{"rendered":"<p>For many years now, it has been fashionable to work on corporate processes by encouraging a \u201ccustomer-vendor\u201d relationship between departments. I have probably been as guilty of this as other consultants have been. In listening to the problems facing clinical development departments recently, however, I have come to realize that this concept is either mis-applied, mis-understood, or simply a mistake. Unless great discipline is exerted on all sides, \u201ccustomers\u201d are poorly served and \u201cvendors\u201d are exploited.<br \/>\n<br \/>\n<strong>You are My Customer, I Suppose<\/strong><br \/>\nThe original concept of treating each other like we are each other\u2019s customers is drawn from many good intentions. And it converges from many process improvement philosophies and techniques. At my company, we use a \u201cvoice of the customer\u201d technique, for instance, which emphasizes this style of thinking. TQM (Total Quality Management) teachings of various flavors use this terminology. Process Mapping \u2013 the visualization of complex workflows \u2013 is sometimes presented in this fashion: Who is your customer? Whose customer are you?<br \/>\n<br \/>\nIn many ways, talking about each other as customers is not unlike the Golden Rule: treat your organizational colleagues the way you would want to be treated. Using terms like \u201ccustomer,\u201d \u201cvendor,\u201d and \u201cservice\u201d puts a warmer face to \u201cinputs\/outputs,\u201d or talking about \u201cdeliverables\u201d.<br \/>\n<br \/>\nThe customer orientation as a corporate process concept was long overdue when it first appeared. Most corporations \u2013 pharmaceutical companies among them \u2013 desperately needed to overcome the detrimental effects of \u201csilos\u201d (departments with their blinders on), eliminate the pointing fingers of blame, and get people to see the interdependencies they share in a complex organization.<br \/>\n<br \/>\nExamples of such poor relationships at pharmaceutical companies were (and still are) legion: between clinical operations and clinical data management, biostatistics and medical affairs; regulatory affairs and product marketing; investigative sites and monitors (CRAs); chemists and pharmacologists; informatics and everybody; and so on.<br \/>\n<br \/>\nBut there are problems with this kind of language and way of teaching process improvement. For instance, if everyone is everybody\u2019s else\u2019s customer, is anybody \u201cmaking\u201d anything or are we all just \u201cbuyers\u201d, expecting to be served? In fact, not everyone is a customer of someone else. Sometimes, for instance, people are other people\u2019s bosses. Sure, you can treat your boss as a customer, but it may be more important to follow her leadership rather than think about delivering her a service. Sometimes our colleagues are simply sources of money, or information \u2013 neither customer nor vendor. And sometimes, we have nothing to do with each other, but if the mantra of customer-vendor is too ubiquitous, the corporation may be insisting that these folks develop a time-wasting connection in the blind pursuit of popular jargon.<br \/>\n<br \/>\n<strong>Happy Customers, Missing the Boat<\/strong><br \/>\nMore importantly, there are two fatal flaws in the everyone-is-a-customer approach. First, even given the legitimacy of the concept, the true \u201ccustomer\u201d of our work may in fact be at a much higher level than who we are trained to serve. For instance, the customer who is worthy of that name may not be the next person in the handoff chain, but rather the Clinical Development function as a whole, or your biopharmaceutical corporation, or the regulatory agencies, or even the patients you hope to help. Unfortunately, the customer focus approach almost exclusively encourages a pragmatic, heads-down, make-the-next-guy-happy mentality. This may not actually help your organization at all, if the focus should be at a much higher plane.<br \/>\n<br \/>\nSecondly, there is the mis-use of the concept of \u201cservice\u201d. If we have customers, it is assumed that we are supposed to \u201cserve\u201d them. This is where the customer concept can get really deadly. When we start to think about \u201cproviding a service,\u201d and then turn this into \u201cbeing of service\u201d to our customers, if we are not careful we can end up being \u201csubservient\u201d. These words all sound pretty similar, but subservience means being a servant; it implies that the customer is better than we are, or more importantly, subservience means the customer\u2019s needs are more urgent than ours. It doesn\u2019t have to be this way, but when we overlay the customer focus superficially and without diligent rigor on age-old interdepartmental rivalries, that\u2019s what we end up with.<br \/>\n<br \/>\nLet\u2019s look at some clinical research examples:<br \/>\n<br \/>\nClinical Data Management takes the customer focus philosophy to heart and concentrates on serving the clinical study manager. In doing so, they are forced to choose between losing their carefully built-up standards, structures and efficiency, for the sake of serving the study team with flexibility.<br \/>\n<br \/>\nMonitors focus on sites (their customers) to such an extent that they allow consistently poor site performance in enrollment and data quality for the sake of \u201csatisfying\u201d that Key Opinion Leader.<br \/>\n<br \/>\nClinical operations is intimidated by their site \u00a1\u00aecustomers\u2019 into paying them more to use EDC (electronic data capture) &#8212; a tool which will in fact lower site workload if everyone sticks it out to the end (and uses the right tool to begin with, with the correct processes).<br \/>\n<br \/>\nBiostatisticians give their physician customers in Medical Affairs everything they ask for, despite what this does to the timeline, or despite the fact that the data may not yet be properly cleaned or of sufficient volume, or despite the fact that the questions the physicians are chasing are taking the company\u2019s eye off the ball.<br \/>\n<br \/>\nClinical operations tries \u201cserving\u201d CDM, and in trying to meet CDM\u2019s stringent view of data cleaning, ends up with an inefficient monitoring schedule and that classically unnecessary task: 100% SDV (source data verification).<br \/>\nIn fact, having customers and serving them are not inextricably linked. It is possible to be customer-focused and yet not be subservient to your customers. \u201cThe customer is always right\u201d does not mean that the vendor is always wrong.<br \/>\n<br \/>\n<strong>Customers as Equals<\/strong><br \/>\nThe other way of looking at this, at preserving the idea of \u201ccustomer\u201d without the idea of \u201csubservience,\u201d is to see each other as equals, not servants one to another. After all, if everybody is somebody\u2019s customer, we are equal. And equality brings several characteristics into play which are very healthy for a corporation: mutual respect, boundaries, expectations with limits, and a common multilateral goal, not a linear production line goal. It allows the Clinical Development department to focus above the level of the next handoff, and to focus instead on the plan, the submission or the patient. And it ensures that each profession can determine which of its values are corporate-critical, and hold onto them, while, yes, \u201cserving\u201d the needs of other professions within clinical research.<br \/>\n<br \/>\nHow do we get to be equals? Good will and strong leadership are certainly essential, but human behavior and entrenched practices often require a little extra help to change. Fortunately there is a well-established concept in this regard: the Service Level Agreement (SLA).<br \/>\n<br \/>\nSLAs are an invention of our service economy, and while they have been used in many industries for many years, the concept is not widely applied yet in pharmaceutical companies, especially in Clinical Development. An SLA looks very much like a contract. It spells out responsibilities, timelines, expectations, deliverables, authority, change procedures and problem resolution. As such, it documents what one may have documented in a Process Mapping exercise or similar, but does so in the language that societies have developed over centuries to bind people to a common purpose.<br \/>\n<br \/>\nInitially, people often react badly to this concept. Why do we need a contract when we have worked together for so long? Why don\u2019t you trust me\/like me anymore? Spiteful behavior can ensue: \u201cwell, if you\u2019re going to write that down, I\u2019m going to write down this!\u201c \u201cIf you want this done on time, how about you doing this for me on time!\u201d And as petulant as these sound, this is exactly the point. The SLA becomes a tool to generate an open dialogue that, without it, simmers below the service. The SLA\u2019s formality uncovers flaws, resentments, or missed expectations that were never articulated otherwise.<br \/>\n<br \/>\nIn the end, by going through this process, you may not need the formal document \u2013 the process of trying to write one may be therapeutic enough. But because we are so increasingly interdependent across Clinical Development, and indeed across all pharmaceutical company departments, the documentation of how that interdependency will be managed to the corporate good, and to the successful treatment of patients, may be necessary, at least for a few years, until old habits die off, and mutual respect and understanding become second nature.<br \/>\n<br \/>\nWhen your waiter tells you \u201cI will be your server tonight,\u201d he or she represents in fact a range of products and services, a range of outputs &#8212; the chef\u2019s creativity, the cook\u2019s execution, even the delivery truck that brought the raw materials. And you have your responsibilities as well \u2013 to arrive at the restaurant on time, to know what you like, to treat the staff well. The delicate flavors, the perfect ambience, a lovely wine are all the result of a combination of lots of people providing you a terrific meal, plus your ability to be ready to enjoy it. They are not your servants, and you are not burdens for them to bear. And as equals, server and served, customers all, we can go home well satisfied with a meal, and a job, well done.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>For many years now, it has been fashionable to work on corporate processes by encouraging a \u201ccustomer-vendor\u201d relationship between departments. I have probably been as guilty of this as other consultants have been. In listening to the problems facing clinical development departments recently, however, I have come to realize that this concept is either mis-applied, mis-understood, or simply a mistake. Unless great discipline is exerted on all sides, \u201ccustomers\u201d are poorly served and \u201cvendors\u201d are exploited. You are My Customer, I Suppose The original concept of treating each other like we are each other\u2019s customers is drawn from many good intentions. And it converges from many process improvement philosophies and techniques. At my company, we use a \u201cvoice of the customer\u201d technique, for instance, which emphasizes this style of thinking. TQM (Total Quality Management) teachings of various flavors use this terminology. Process Mapping \u2013 the visualization of complex workflows \u2013 is sometimes presented in this fashion: Who is your customer? Whose customer are you? In many ways, talking about each other as customers is not unlike the Golden Rule: treat your organizational colleagues the way you would want to be treated. Using terms like \u201ccustomer,\u201d \u201cvendor,\u201d and \u201cservice\u201d puts a [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[50],"tags":[],"class_list":["post-151","post","type-post","status-publish","format-standard","hentry","category-recent-columns"],"_links":{"self":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/151","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/comments?post=151"}],"version-history":[{"count":1,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/151\/revisions"}],"predecessor-version":[{"id":152,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/151\/revisions\/152"}],"wp:attachment":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/media?parent=151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/categories?post=151"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/tags?post=151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}