Questioning Stability
A key question regarding a fast-changing business world is how we can rapidly respond to the need to change when everything is connected, and end-to-end integration is mandatory for processes to deliver value to customers. Many organizations have proven that process-based solutions that must work across the organization, people, technologies, and sites can’t be changed quickly unless the infrastructure itself is architected for change. They must know what aspects of their capability can provide stability and what must be designed for adaptability. They must also know how to make sure that stable and adaptable aspects don’t become interwoven in a convoluted mess in which a change to anything automatically means a change to everything.
Clearly, most products and services have a very short life now when compared to the past. They must change quickly and easily. Also, our customer/consumer and other stakeholder expectations will be much shorter lived than previously. Products and services must be understood and updated frequently because the bar is constantly being raised by the competition and technology continues to advance. Keeping things the same through inactivity will result in an ever-decreasing level of fit with stakeholder expectations.
Because so much of what we do is now supported by software, it’s impossible to effect changed processes and deliver new products if the software change constrains time to market. My experience in telecommunications was often frustrating because there was never any shortage of good ideas for rate plans to support new customer expectations. These new telecom “products” were easily conceptualized by marketing and customer segmentation strategists. They weren’t easily implemented, however, because it was nearly impossible to update the billing systems with the new algorithms, rules, and formats in a short time frame. Instead, massive, risky system development efforts had to be launched, which included significant analysis just to find the code to change. Alternatively, a new, redundant billing system would be built from scratch. When these systems were initially designed, no one thought beyond the stated needs of the functional users. They just deeply embedded all the day’s logic, not anticipating that it would change. Software designers focused on getting an accepted specification and didn’t look beyond expressed needs to distinguish the stable from the changeable. Neither did they attempt to separate the two and cross-reference them.
As we now have with Data Independence, Normalization, and Separation, I expect that within a few years we will see the total adoption of Rule Independence, Normalization, and Separation from the software. Processes will invoke the rules, and businesses will act on the derived results. Technologies now exist to allow rules to be declared outside of computer programs, and rules to be generated into referenceable software. Rules will become another corporate intellectual asset to be managed like data and business processes. We can’t adapt otherwise.
Some organizations maintain that everything is in flux all the time, and that nothing can be planned. Experience has shown, however, that some things shouldn’t be changing all the time, that there must be some unchanging base to start from. If businesses can isolate these stable aspects, they can avoid chaos and thrashing. They can concentrate on handling the other more changeable aspects with less complexity. What remains to be dealt with is simpler because the number of variables is reduced, and the number of interfaces is significantly fewer.
I believe that an organization’s principles and values, fundamental trust relationships, culture, and architectures all hold great potential for remaining relatively stable.
As Collins and Porras showed in Built to Last,[7] those organizations that have sustained superior performance over decades and centuries have one thing in common: They exhibit an unwavering commitment to their core principles and values. Collins and Porras observed that more than 50% of the companies listed in In Search of Excellence were “excellent” when the book was written, but, less than two years later, they wouldn’t have qualified according to the criteria of authors Thomas Peter and Robert Watterman.[8] Collins and Porras showed that principles kept organizations working in the long run. They also observed that excellence wasn’t about having principles as management wallpaper for all to see but living them day to day. Especially important was adherence to these principles in times of difficulty, when short-term pressures could have led to short-term fixes but long-term pain, probably for someone else. The best companies didn’t do this. The authors also found no correlation between the actual content of the principles themselves and long-term success. Sony’s principles are different from GE, and both of them from 3M. As has been shown with commitment to the company’s stakeholders, it is the living of the commitment that makes the difference.
[7] See note 2 earlier in chapter.
[8] In Search of Excellence: Lessons from America’s Best-Run Companies, Thomas J. Peters and Robert H. Waterman Jr., Harper & Rowe, New York, 1982
As an example, one of my consulting clients has a principle named “mutuality.” This principle states that a mutual benefit is a shared benefit, meaning that, in all relationships, both parties must be treated fairly for the long-term health of their organization. I knew of this principle when I first met this client because I saw it on the wall in a nice frame in the office lobby. I had assumed that it was a noble statement among other noble statements and thought no more of it until we agreed to put in place a global contract for our services. When I first sat down with the contract officer, I was prepared for the usual negotiation wherein I would have to argue for and defend my company’s position on ownership and confidentiality on our intellectual assets. I fully expected to see such clauses for the client organization but was surprised to find that there was two-way acknowledgement of this important aspect of our relationship. Furthermore, the contract officer offered unsolicited, ongoing support to our organization if we felt that the mutuality principle wasn’t being upheld. For more than 75 years, this company has been successful and continues to be successful, partly because of its strong relationships with all its stakeholders. It lives its principles.
This doesn’t mean that principles and values are never stressed or violated, even in the best companies. It does mean that they are always there to provide consistent guidance and the right pull.
One thing that any lasting organization will want to establish for the long term is the nature of the relationships it has with its customers/consumers and other stakeholders. For these relationships to be stable, they must be built on trust. Trust simply means confidence that whatever commitment is made, it will be met according to the expressed, implied, or inferred conditions associated with it. It means making commitments relevant to the value perceived by the recipient and then doing what you said you would do. It’s not hard to define, just hard to do when other pressures abound. For some relationships, it means keeping on doing what you are doing so well; for others, it means quickly changing what you do but still doing it efficiently, on time, politely, and so on. The model of trust that I believe explains the issue but doesn’t lose the essence is one originally defined by Terry Winograd and Fernando Flores in their groundbreaking book Understanding Computers and Cognition.[9] I have adapted this model to more of a customer-relationship management view (see Figure 2.1). With this model, you can establish some stability of relationship management while the instances of the relationship can remain flexible. It assumes that each relationship has two prime types of participants: the customer and the supplier.
[9] Understanding Computers and Cognition: A New Foundation for Design, Terry Winograd and Fernando Flores, Addison-Wesley, 1993
This customer/supplier protocol, which works for any relationship or partnership, implies that the customer’s criteria are paramount, and that determining and managing expectations throughout is most important. You can measure the strength and health of the relationship in terms of an asset that I will call relationship equity. The customer holds this equity in trust, in an “account” in the supplier’s name. There’s also a corresponding account for role reversal. There could be a high account balance in one, but a low balance in the other. For example, the customer might believe that the supplier provides incredible service and reliability and, as a result, the customer is always happy. On the other hand, the supplier might be disillusioned with the customer, who gets away with unreasonable demands and is very difficult to deal with.
How is the equity built and maintained? Table 2.2 explains actions taken and the debits and credits made to the accounts as the protocol is traversed.
This trust/commitment cycle never ends. The relationship doesn’t sleep. The equity built is spent when you ask someone to trust or when you enter any step in the process as well as request or agree to a change or if you withdraw from the situation. You can build up reserves through consistently keeping your promises over time, by doing what you said you would do. Relationship equity doesn’t collect interest; without action, it erodes.
Every individual relationship must be thought of in these terms, and each instance or interaction must be managed to build equity as a measure of the important outcomes of the long-term objectives. Consequently, all processes should build in these steps, and all service deliverers and service recipients should be trained on this model as well as measured by it. It’s the only stability possible as everything else about the business is changing.
This model is critical, businesses often ignore it in establishing partnerships and outsourcing. The corresponding agreements and workflows should incorporate this model while at the same time leaving flexible the specifics of the situation so that they can change.
As an example, I witnessed one manufacturing and service organization fall into the standard trap of mistakenly doing the job faster without building relationship equity and trust through consistent attention to the customer. The organization manufactured drink machines and supplied the drink mixes to be dispensed. Each client had the choice of a number of models and machine configurations, and the drinks could be changed at any time. Clients had good flexibility of choice and could change their mind about the coffees, teas, and soups of choice. This was a positive feature of the redesign to a mass-customizable product and service. The only problem encountered was that to “improve service,” the organization set a target of delivering machines in less than 48 hours and evaluated itself on this measure rather than on understanding customer needs. Shortly after the new measurement targets were established, the reports of compliance to delivery standard came in very high. It appeared to be a job well done; however, customer satisfaction went down, not up. The real issue was that most customers wanted their machines to be delivered after water and electricity were configured for the site where the machine would be located. When machines were delivered early, they were often misplaced or broken because of improper temporary storage. The company rectified the situation by adding a simple question when the order is taken: “When will you be ready for the machine?” It then built its manufacturing and distribution schedule around customer-driven requirements. Trust went up, and business grew as a result.
Culture
Whenever the word culture is associated with a business process or organizational renewal, it usually has a negative connotation. Companies tacitly recognize that when their culture needs to change, the culture’s inertia can become an impediment. If we look at it more positively, culture is an organization’s basic way of doing and approaching things that can give great advantage because it’s so hard to steal or replicate it quickly and smoothly. It can add stability, but it also can become a challenge when the organization decides to move away from a traditional value proposition. For example, companies with a track record of operational excellence typically struggle when moving toward a customer intimacy model. This is because the emphasis has always been on making the best product available and believing that this is what the customer should value. Instead, in a customer-intimate approach, the value might be more in how customers are treated than in the product’s specific attributes. This requires a different set of behaviors and a change in staff beliefs that might have been built over decades.
Organizations should view this scenario as moving from one stable state to another. They should treat culture change as a serious aspect of transformation that adjusts human beliefs and behavior over a period of time and then stay the course. Culture change can’t be a rapidly moving target; culture moves from one state to another infrequently. Without some overall cultural stability, chaos or paralysis is inevitable, as is a falling off of performance.
The culture change process must be tied to major process program transformation that seeks out those who aren’t aware of the need to change and educates them. It looks for those who aren’t capable of performing new jobs and trains them. It ferrets out those who aren’t willing to give up traditional methods and changes their personal incentives.
Architecture
It seems like an oxymoron to refer to flexible architecture in a day of incredible transition on many fronts. At first thought, it’s tempting to abandon all higher-level integration models because, traditionally, this has taken too long and has resulted in rigid definitions of target end states that are ignored because of later irrelevance. I would propose that many early attempts to do this were misguided because they didn’t have adaptability as their prime requirement and measure. When this design objective is set, the rules change, and the resulting architectures actually help deliver reuse and speed of implementation, rather than constraining them.
The best way to get this point across can be through an example. This will be a banking example, but the situation might be frighteningly familiar to those in other industries.
A key driver in business banking today is the cost and speed of processing a payment and the ability to record the appropriate tracking information for consolidation of accounting and billing. One major international bank operating in more than 50 countries developed a number of different, yet redundant, payment-processing methods over time. This occurred because the various countries had already developed their own accounting methods, based on central banking regulations and local needs. Different processes, technologies, organizational structures, policies, regulations, stakeholders, and so on all drove the countries to maintain unique practices. The bank had to adopt each country’s practices quickly to do business there.
At best, there was some commonality of practices within regions comprising a number of countries. At the same time, new forms of banking kept cropping up. In addition to branch banking, ATMs, kiosks, telephone, and Internet mechanisms arrived quickly, each bringing its own total solution and more redundancy and disintegration to the bank’s operations.
Why did this happen? Simply because there was no common vision of the target state nor a roadmap of how to get there that would ensure easy, local individualized approaches. This has led to the scenario that places the bank at risk of losing its global customers. They want one way of doing business, anywhere and anytime, and each individual customer wants to be treated as one entity with one set of rules to manage its global financial assets.
When this bank came to deal with the ever-degrading relationship with its global customers, it concluded that several of its fundamental ways of working were flawed. For one thing, regardless of country, customer, and technology, a payment is a payment governed by international standards. Hence, payment processing should stand alone architecturally and be done once for all customers as a central, shared service.
Furthermore, all the different technologies are merely mass customization channels into the central mass production capability. Consequently, building new front ends and replacing old ones is easier if all interfaces to the back office are set up according to set rules, standards, and protocols. Without an agreement and strong commitment to an architecture that delivers better infrastructure, this would be impossible. The result isn’t less flexibility; it’s more.
The bank is now extending this model of common back-end mechanisms and rules to customer billing and reporting. It provides not only transaction control, but also a customer integration capability without kludging together unworkable disparate solutions internally.