Building a Car? Build This!

Several weeks ago, Apple was in the news because they were rumored to be building a car.  The  rumor turned out to be false.  Everybody wants to be where people spend a lot of time.  Google wants to build completely self-driving cars.  Even the major manufacturers are working on something of their own.  Nobody asked me, but here are my thoughts anyway.  Enjoy!

First, let's start with the car to build now, with existing technology or something that can be developed in a short amount of time:

1. License Volkswagen's MQB platform.  In the same way that Tesla used Lotus' design for their first model, using an existing platform will save on development costs and accelerate time to market.  Also, the MQB is versatile enough be designed around.  Think about it: the Audi A3 and the VW Golf sits on the same platform but look very different. I'm pretty sure there is a Skoda that sits on the MQB as well.
2. Safety First.  Apart from the mandated seat belts and airbags, these additional safety features should come standard.  All of these are meant to aid the driver but not relieve him of his duties.  The car will be loaded with a ton of sensors:
• Adaptive Cruise Control - stays within 3 seconds of the car ahead of you, or the speed that you set, whichever is slower, and applies brakes when necessary; this will allow you to, literally, just sit in traffic.
• Collision Avoidance - applies brakes and increases tension to the seat belts when an obstacle is detected, and possibly, steering to the next lane;
• Oncoming Vehicle Warning - and similar to above, increases tension to the seat belts, maybe potentially accelerate or move out of the way.  The problem with today's blind spot detectors is that they beep or flash even if you are not changing lanes, or the other vehicle is going in a straight line.  With a few tweaks, it should be able to selectively warn you depending on whether you are in fact veering into their direction, or they are moving into your lane.
• Lane Departure Warning - detects if the vehicle is going wayward and out of his own lane without driver input; possibly also reading the driver's condition in conjunction with road sensors.  It may also self-correct.
• Active Headlamps - legislation needs to change on this one, but headlamps should automatically brighten, darken, turn off, turn right or left depending on conditions. 
• Heads Up Display - reduce the need to look down, display speed, and navigation on the windscreen, as well as warnings from the above features.
• Rear View Cameras and Sensors - today's cars only activate when the car is in reverse. These should activate on command.  It is still a good habit to check the rear view from time to time, and with bigger cars, or even smaller sports cars, the mirror just doesn't cut it.
3. Add these convenience features:
• The climate control system should learn the habits of the driver, and adjust the temperature and seat heaters as necessary.  It will record the settings, the driver's temperature, the outside temperature and the cabin temperature to infer future settings.  There will be no need to fiddle with the controls as you drive the car.
• Connected Car - either through Wi-Fi, cellular, or Satellite, receive traffic, music, news, podcasts, calls, and text.  It saves the location and driving information in a secure location, as well as send diagnostic information to the manufacturer.
• Voice Commands - allow more voice commands to avoid having to take hands off the steering wheel.

I do realize that a lot of these features are already in high end cars like the S-class from Mercedes, and some of Audi's more expensive offerings.  But if a tech company can make it cheaper yet reliable, I am all for it, as long as software updates are not too often and don't take 4 hours, rendering the car inoperable while in the process.

Now, in the next ten years, technology may allow us to have the following features:

1. Either go 300 miles on a single charge, or find a cheaper fuel source.  It has to preserve the "road trip" experience, meaning you can stop for 10 minutes to fill up, and be back on the road again and drive another 300 or more miles.
2. It may take the fun out of driving for enthusiasts, but more driving automation, with more of sensors and more intelligence, a car should be able to get you to your destination by merely entering (or stating) your destination to your navigation device.  The car will try to avoid traffic if you instruct it to, very much like your GPS today, but the car will actually reroute itself.  And equally as important, it will activate the turn signal early enough!
3. Beyond self-parking, self-valet should become available, either the car autonomously finds a parking spot after dropping you off, or uses signals and sensors from the smart parking garage.
4. In an ever increasingly connected world, besides smart garages, there will be smart roads that know the conditions, the speed limit, and the car will communicate with the road, as well as other cars.
5. There will be no toll booths, as your car sends its identity to the agency that collects tolls whenever you pass by their smart bridge, or smart tollway.  And the agency charges your bank.
6. And of course, with all this data available, it can personalize everything from your playlist to the ads that play in between.  It will play new music based on your past listening history.  It will choose routes based on your and other people of similar attributes' driving preferences.

I do realize two things.  All this automation may lead to the "Rise of the Machines" as foretold in The Terminator.  Secondly, it turns off the driving enthusiasts who have felt the loss of "connectedness" to the car with all the current electronic driver aids.  But for the rest of the driving masses who just need to get from point a to point b in the safest, fastest, most convenient way possible, they will trust the machine to do the work for them.

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.

  

Exploring The Limits of Parent Account Hierarchies in Salesforce

Salesforce.com started with the mid-market companies as their customers.  The last several years, they have been targeting larger enterprises and have been largely successful.  However, it has some room for improvement.  This IdeaExchange entry in particular explains the current limitations of the Parent Account Hierarchy.

Larger enterprises usually want to track different locations of the same company as separate accounts for one reason or another.  For example, the same company with offices in California and Florida may be owned by different account managers.  Or, resellers with offices in several countries may be managed by different channel managers.  However, the company itself would like to track opportunities and revenue for all those accounts together.

Salesforce does provide a standard field called "Parent Account".  If you have a one-level hierarchy, meaning all locations roll up to a single account, you can report by Parent Account to show that summary.  But as outlined in the above IdeaExchange entry, it has its limitations.

For one, as soon as you have multiple levels of the hierarchy, you can no longer report by just "Parent Account".

Secondly, if you have opportunities (or any other child object) related to that parent account, those opportunities will not show up in the report by Parent Account, as the Parent Account field is blank.  You lose the ability to use standard configuration to show report charts on your page layout, and have to resort to building custom VisualForce pages and Apex code to show the information at the parent account.

From a different perspective, an account manager who owns an account at a national level but has multiple locations, he now sees multiple accounts, even though he is really only dealing with people at a specific location.  This can of course be resolved by not assigning those irrelevant locations to that account manager.

For reseller accounts, a channel manager must now manage multiple accounts, and ensure each contact is tied to the right account.  This adds administrative burden for them, or for some other data administrator on their behalf.  And similarly, to get a complete view, you will now need custom VisualForce pages.

If the company is willing to limit itself to a single level hierarchy, there is a potential solution.  It is not completely standard configuration.  It requires that you create a parent account for all accounts for the sole purpose of tying all accounts together.  No other child objects will be related to this parent.  Also, even accounts that have a single location will need a parent account, potentially.  This allows you to still use the standard report charts on the page layout, as the chart can filter by "Parent Account Id".  You will still need custom VisualForce pages if you want to show record details as a related list.  This does require more resources to maintain, and sometimes it may not be worth it.  Each company will have to evaluate and balance its short term requirements and long term requirements against the available resources to develop and maintain such custom work, not only from an IT resource perspective, but a data administration perspective.

Saving Coca-Cola

In the latest news, Coca-Cola's stock is down 6%.  Investors did not receive the news very well - that soda sales are declining, that more and more people are waking up to the fact that sodas are not healthy drinks.

While still the most recognizable brand worldwide, Coca-Cola is in a decline.  Is it a reversible trend?  Maybe, or maybe not.  But with close to 3 billion dollars spent in marketing, it might make a difference in the outcome.

But when was the last time I saw a Coke commercial?  It has been ages.  I have not seen one while watching YouTube, or any ad-supported game I am playing.  I rarely watch live sports, and everything else is recorded so that commercials can be skipped.

I am a Coca-Cola fan and a shareholder.  I remember growing up with Coke.  I remember the truck stopping by our house to deliver a case of 8 oz. bottles to my grandmother.  I remember walking to the corner store to buy a liter to share with family and friends.  But, should I face the fact that it will never be the same again?

I also remember the great Coke commercials that tugged on your heartstrings: Friends, or
First Time.  Growing up, Coke was tied to good times.  All the birthday parties had Coke.  Whenever there was something to celebrate, there was Coke.  Whenever there is fun, there's always Coca-Cola!  Coke needs another campaign like these.

And more importantly, Coke should start serving 8-oz bottles again.  I grew up on 8-oz bottles.  That was the perfect size, not 12, not 7, not a liter nor two.  8-oz is the personal size Coke.  If people stuck to drinking one 8-oz bottle a day, they would probably be fine.  I distinctly remember the 8-oz Coke also tasting better, better than the 12-oz, or the half-liter, or even the one in cans.  (Our Coke had sugar, not high-fructose corn syrup.)

To the management team of Coca-Cola, I say, bring back the 8-oz Coke with sugar!

Relating Air Conditioning Systems to Business Applications is a Stretch

HowStuffWorks has a good introduction on how air conditioning systems work.  Whether it is a house or a car, the components are similar.  I'm not going to go into too much detail as there is a ton of information available with a quick Google search.

The A/C system has a few main components: the evaporator, the condenser, and the compressor.  There are other parts mentioned in the HowStuffWorks article, but let's focus on these three.  Let's add a fourth component: these three are connected via hoses.

If you have a problem with your A/C, or you simply want to upgrade to a more energy-efficient unit, you will most likely work on one or more of these components, but not the hoses.  Hoses are, at least in a modern house, tucked inside the walls and are hard to replace.

If you had a problem with cooling, you will most likely refill your system with refrigerant from the outside unit, or in the case of an automobile, on the valves along the hoses nearer to the compressor.  If you wanted to upgrade your compressor and evaporator, you will be working on components outside the cabin of your car.

While the technician is replacing components or recharging with refrigerant, he may notice that there are leaks in your hoses, or the connections in between hoses.  But this does not necessarily mean that the new components are defective, or that the refrigerant is bad.  A different component is failing, not the ones he is currently working on.

Similarly, business applications, for example, one for Customer Relationship Management and one for Order Management, are connected by "hoses", in software terms, "Middleware", or more recently "Enterprise Application Integration" software.

If you are making changes on one or both applications, and expect messages to be passed between them, it is entirely possible that the "hose" is broken, and not necessarily that the applications you have changed are broken.

Of course, it is necessary to fix the "hose" in order to test that the messages with the new or updated information is being exchanged.  But, if after a few messages have been successfully sent, and then it breaks, and no new changes were introduced to either application, then the "hose" has a problem, not the applications.

The point is that it is possible that the application changes are correct, and can be considered successful.  The changes can be put into production, while the problem with the "hose" can be addressed separately.  In the A/C world, the technician can still continue to replace the components, and deal with the hose issues separately.

Account Name Complications

In a less complex setup, Salesforce Accounts are used solely to track and manage a sales rep's accounts and tie his opportunities to them.  There are less stringent naming conventions, less emphasis on data quality, especially around account names.

Typically, a sales rep will refer to their accounts by their commonly accepted name, or "Trade Name", like Salesforce, or Apple, or Starbucks.

As soon as companies add on certain processes into Salesforce, for example, Quotes and Contracts, a more formal process for names is required.  For example, Quotes and Contracts will typically need the full legal name, like Apple, Inc.  It even gets more complicated when their legal company name is totally different from their common name, or "Doing Business As (DBA)" name.

Start doing business in countries with local languages and special characters, the local sales reps will prefer to record their local language name, as that is their common name, but it becomes a headache for HQ Operations who want to manage and cleanse the information.  And when it comes time for Quotes and Contracts, HQ will most likely require Western character company names.

My current thinking on this is that in Salesforce, the standard Name field will always be the common name, or their DBA, or their local language name.  This makes it easily searchable for the bulk of the field users who are local.  This also means that data cleansing should be handled by local administrators.  Who else would be better to determine whether two records are the same company but a local person?  Alternatively, give the field users the ability to request for merges.  That way you can have a centralized data administrator.

In summary: use Name as the common name or DBA name, and add another text field, Legal Company Name, and maybe a third field for Western Language Name, although you could probably get a way with using the same field if the label is clear enough.  Unfortunately "Other Name" is very vague.