Customer Focus

A lot has been written about Jeff Bezos' laser focus on customer service.  (Here's one.)  The same can be said about Steve Jobs' unrelenting focus on user experience.  Kip Tindell of The Container Store has stressed in many interviews how he and puts employees first, which drive customer satisfaction.  There are other companies that focus on the customer as one of their top priorities, and it shows in customer satisfaction surveys - Southwest, Starbucks, and USAA among others.  All these companies take different paths, but the end result is the same.

I believe that, while not a guarantee, focusing on the customer is a huge factor in a company's success.

Amazon, Apple, and The Container Store all sell goods and services.  Focusing on the customer buying their products should come as second nature.  But as Operations practitioners or IT professionals, focusing on the customer may not come naturally.  We focus on process, and finding efficiencies, solutions and technology. 

As professionals who do not  sell on a day-to-day basis, we must strive to identify who our customers are and focus on them.  We must evaluate each policy, process, solution and technology with a focus on our customers: will it help, or will it hinder our customer?  We must not put policies in for the sake of policies, or technology because they are cool, or a solution that benefits somebody else, but burdens our customer.

This reminds me of an article I read many years ago about the idea that we are all salespeople at some point or another in our lives.  At a job interview, we sell ourselves.  In our jobs, we may have to sell an idea to a group.  In all those situations, focus on the customer, present what's in it for them.  What value will you or your idea bring to them?

Like a company selling its wares, while focusing on the customer will not guarantee your success, it surely will increase your chances.

Re-Evaluating The Reason for Periodic System Freeze

In a typical IT Application Management Policy, there are periodic system freezes, sometimes for mission-critical applications only, but usually for all applications.  This means that in the week or weeks preceding a fiscal month-end or quarter-end, and a week after, no changes are to be made in production systems.  An exception process will require higher management approval from both business and IT application owners.

The main reason was that any downtime, in order to make system changes, or as an unintended result of system changes, will delay or stop critical business processes, such as order processing or closing of accounting books.

In the days of applications hosted in-house, and even today with monolithic ERP systems, it makes sense to freeze entire applications.  Such applications may require entire servers, or at least application services to be restarted, even to deploy a fairly simple change.  In order to reduce risk of applications not starting back up, or behaving improperly after the change, or simply introducing bugs, change freezes should be imposed on the entire application.

With cloud-based applications like Salesforce.com, this policy should be tweaked depending on what is hosted in Salesforce.  For example, if Salesforce handles Opportunity Management and Quotation Management, a freeze must be imposed on objects that support those functions.  However, if it also hosts a custom application, for example, a partner locator, the freeze should not apply to configuration changes related to the partner locator.

Installing packages from the AppExchange should also be allowed if they do not affect the processes that are deemed critical by the organization.  As in the example above, if it does not affect Opportunity Management and Quotation Management, which are deemed critical in closing the quarter, an app, say for example, the EverNote App, can and should be installed, if the business need dictates that the new feature be available in the next quarter.  Applications published on the AppExchange have gone through a Security Review conducted by Salesforce to reduce the risk on all their customers' Salesforce orgs and data.

Here is an example of what isn't allowed: Do not introduce a new required field on a quote two weeks before the end of the quarter, because that will slow down users who have gotten used to completing quotes in a certain way.  Another example that should not be allowed is installing the DealMaker by The TAS Group.  This affects Opportunity Management.  While it is possible to install the app and not show it to any users yet, it still affects the Opportunity object.

It can be argued that any custom Apex code should not be deployed, as the deployment will cause all test classes to execute.  Some poorly written test classes may affect critical processes.  This author recommends that Apex deployment should be avoided during a system freeze.

A colleague pointed out an analogy: like remodeling a house, work can be done in the bedroom downstairs, and the rest of the house is still habitable.  There is no need to shut off the power or the water supply.

In conclusion, the reason for a system freeze in a cloud-based multi-tenant application, such as Salesforce.com, should no longer be about potential system downtime.  Rather, it should be a more business-focused one: system and process changes should not disrupt closing deals in the current period, or chasing revenue, or ensuring product shipments, or anything else that will adversely affect users and customers.