Margins, Efficiency, and the DuPont Formula, Part 1

I recently read an interview with Jeff Bezos (CEO of Amazon.com) where he talks about margins, and it got me thinking about how companies differ across industries and whether their margin is connected to their efficiency.

The quote is as follows:

"There are two ways to build a successful company. One is to work very, very hard to convince customers to pay high margins. The other is to work very, very hard to be able to afford to offer customers low margins. They both work. We’re firmly in the second camp. It’s difficult—you have to eliminate defects and be very efficient. But it’s also a point of view. We’d rather have a very large customer base and low margins than a smaller customer base and higher margins."

Later he says:

"We think it’s a unique approach in the marketplace—premium products at nonpremium prices. We’re a company very accustomed to operating at low margins. We grew up that way. We’ve never had the luxury of high margins, there’s no reason to get used to it now."

I agree with Jeff -- high margins are a luxury.  In a free market economy, companies with high margins should be rare, because new competitors should appear with lower margins which will undercut the high margin players.

However, high margin companies exist.  I can think of at least  a few reasons why:

1.            Monopolies protected by government regulations.  Historically, the telephone companies are a good example of this in Canada, as are the cable TV companies.  They are regulated by the CRTC and therefore can charge atypically high margins for their services as long as the government approves them.  Competition is not allowed under a government imposed monopoly.  In recent years, some competition has being permitted in the phone industry, but the CRTC still regulates some pricing and still limits competition by way of preventing foreign-owned companies from entering the market.  Think of Bell or Rogers.

2.            Successful marketing of luxury brands.  Some companies  succeed at marketing their brand as being higher quality than their competitors, and therefore some customers are willing to pay higher prices.  Because most people are unwilling or unable to pay for these high priced products, they become luxury status symbols for the few who can afford them.  Think of Porsche or Mazerati.

3.            Complex professional services.  Certain areas of expertise that require years to obtain can command high prices for their services.  While there is competition in these professional services industries, all the competitors tend to keep their margins high and compete on niche expertise  or reputation.  Think IT consulting firms or law firms.

But do high margins translate into higher profits?  I did a quick and unscientific sampling of a few companies with widely varying margins, and the answer appears to be a resounding NO.

I reviewed 8 companies from different industries that I chose arbitrarily and graphed their operating margin and their net income per share from their latest published annual reports.  The results are shown below.

Clearly, high margins (those companies at the far right of the graph) do not always translate into high profits (top of the graph).  In fact, the highest profit per share is from one of the low margin companies in my survey.

The 8 companies I chose are listed below.

Company	Fiscal Year	Industry	Operating Margin	Net Income/Share
Rogers Communications Inc.	2010	Telecomm	38.0%	2.65
BCE (Parent of Bell)	2010	Telecomm	39.8%	2.85
Sears Canada	2010	Retail	38.4%	1.40
Indigo	2011	Retail	40.6%	0.46
Amazon.com	2010	Online Retail, Computing Services	22.3%	2.58
Walmart	2011	Retail	24.7%	3.72
Loblaw Companies Ltd.	2010	Grocery	4.1%	2.45
Empire (Parent of Sobeys)	2010	Grocery, other	5.0%	4.51

(Net income per share is in $CDN, except for Amazon and Wal-mart which are in $US.)

The two telecomm companies, Rogers and Bell (BCE), both have high margins and reasonably high profitability.  However, two large retailers, Sears and Indigo, also have high margins but much lower profitability.  In fact, Indigo has the highest margin of these 8 companies and the lowest net income per share.  The grocery retailers, Loblaws and Sobeys (Empire) have significantly lower margins, but still manage to generate strong profits.  Empire has the highest profitability among these 8 companies despite its low margin.

So clearly high margin does not guarantee high profit.  So why does margin appear to be unrelated to profit? 

Variation in cost efficiency is one possibility.  If the margin is high and profit is low, then there must be a lot of expenses that are eating up that revenue.  If margin is low and profits high, then there must be high sales volumes and low expenses, which is how Amazon.com has built up its business.

Comparing cost efficiency across companies is difficult however, and cost efficiency is not the only factor that affects net income per share.  For instance, the denominator (share equity) could be causing some of the differences.  Number of shares alone could affect that measure.  Return on Equity takes the total equity value of the company instead of a single share value, so that may be a fairer comparison.

But even Return on Equity is driven by many factors, so it's challenging to compare companies' performance.  That's where the DuPont Formula comes in handy.  It takes the Return on Equity and breaks it into its component parts.

(Continued in Part 2.)

Innovators: How Do They Do It?

Today's Globe and Mail has an article that says Canada "suffers from a chronic innovation gap."  Innovation is a popular topic for economists, but fundamentally governments can do very little to increase innovation because fundamentally it occurs at an individual level.

I am fascinated by business leaders who are innovators and lately I've seen some articles that got me thinking about what it takes to come up with innovative ideas.

Obviously there was a lot written following Steve Jobs' death last month, and Steve clearly rates among the most successful and influential innovators of our time.  From inventing a computer with a mouse that was easy to use, to iPods, iPhones, and iPads, Jobs proved his innovation success by the number of companies who copied his products.

Jeff Bezos, head of Amazon.com, is another such innovator.  Wired has an interesting interview with him which is worth the read.  After taking the book selling business and putting it entirely on the internet, he expanded to selling music, toys, and electronics.  He then took his back office computer capacity and sold that as cloud computing services.

A less well-known innovator I recently read about runs an investment firm in Vancouver.  Chad Wasilenkoff has purchased a bankrupt paper mill in Quebec and is modifying it to produce wood pulp for rayon fabric instead of paper.

These guys are in different industries, but I see some common threads in their innovation.

1.    Innovators approach problems from a new direction.

Chad Wasilenkoff looked at the pulp and paper industry and instead of trying to solve the problem of how to make money from paper, he asked how he could make money from wood pulp.  That gave a bankrupt paper mill a new lease on life by producing rayon for the fabric industry.

Jeff Bezos looked at Amazon.com and instead of asking how to sell more books, he asked how to leverage Amazon's existing strengths to make more money.  That led him to sell other products instead of just books, and eventually led him to rent out his back-office computer capacity to the world.

Steve Jobs looked at personal computers and instead of asking how to make one cheaper or more powerful or faster, he asked, "How can we make a computer easier to use?"  Not many people were asking that question at the time.  Most of us assumed computers were difficult to use because that was just an inherent characteristic of computers.  Steve didn't assume that.

Which leads to my next observation …

2.    Innovators Break Assumptions

One way to approach a problem from a different direction is to find the assumptions that everyone else is making.  Once you've uncovered the assumptions, you can choose which one(s) you want to break.

Steve Jobs broke the assumption that computers will always be difficult to use and created the Macintosh.  He broke the assumption that music cannot be sold one song at a time and created iTunes.

Chad Wasilenkoff  broke the assumption that pulp mills can only make paper.

Jeff Bezos broke the assumption that online retailers only have expertise about retailing and he launched the cloud computing industry.

If you're going to challenge assumptions though, you will find yourself being challenged by those who hold those assumptions.  You had better be prepared to fight opposition.

3.     Innovators Fight Opposition and Are Willing To Go It Alone

You don't challenge established assumptions, especially assumptions that competitors have large amounts of money invested in, and expect to have huge crowds following you.  Innovators persevere through opposition and roadblocks and are confident enough in their convictions that they can go down their chosen path alone if necessary. 

I have a great respect for incremental improvement, and I've done that sort of thing in my life, but I've always been attracted to the more revolutionary changes. I don't know why. Because they're harder. They're much more stressful emotionally. And you usually go through a period where everybody tells you that you've completely failed. - Steve Jobs

Chad Wasilenkoff  had trouble getting funding for his idea, despite the fact that the price he had negotiated was less than the value of the land and scrap metal of the mill alone.

As a company, one of our greatest cultural strengths is accepting the fact that if you’re going to invent, you’re going to disrupt. A lot of entrenched interests are not going to like it. Some of them will be genuinely concerned about the new way, and some of them will have a vested self-interest in preserving the old way. But in both cases, they’re going to create a lot of noise, and it’s very easy for employees to be distracted by that.  - Jeff Bezos

If you are easily discouraged or distracted, you are unlikely to succeed at your innovation.


Postscript:
The National Post has another interview with Chad Wasilenkoff here.

Predicting the Future Using Analytics

Prediction is very difficult, especially about the future.

~ Neils Bohr (1885-1962), Danish physicist

The purpose of any business intelligence tool or data analysis exercise is to adequately understand the past in order to give some level of understanding of the future.  The success rate of predictions based on such data can typically be pretty low, because as the mutual fund industry likes to say, "Past performance is no guarantee of future results."  Circumstances change, and the past performance was dependent on the circumstances in effect at that time.

However, if your analysis is on very recent data, it may actually start showing how circumstances are beginning to change and you may have time to react before they change again.  Timeliness of data and of analysis becomes key.

The internet has created the possibility of much faster delivery of data on consumer behaviour than traditional company data warehouses permit.  Google makes its search engine statistics available for free under the Google Insights For Search banner. A recent study by the Bank of England looks at using Google search volumes to monitor unemployment rates and housing prices.  The authors found that both could be inferred quite well by monitoring certain search phrases, providing a much more timely measurement of the economic situation than current indicators do.  The difficult part is discovering which phrases to monitor.  For instance, searches on the word "unemployed" or on the UK unemployment benefits program ("JSA") tracked the official unemployment rate remarkably well, but searches on "jobs" alone did not correlate.  The only way to discover those search terms that are predictive is by trial and error.  Further, once you find a phrase that works, there is no way to know how long it will remain predictive, as new terms could emerge in the future that supersede it.  While this method of near-real-time economic tracking looks promising, it is not without its challenges.

Another fascinating approach to using the internet to predict the future in near-real-time is www.recordedfuture.com. Like Biff in Back To The Future II, this company seems to admit the true motivation for predicting the future: getting rich!   In the movie, Biff finds a record of horse race results from the future and cashes in by betting big.  Recorded Future monitors news feeds, databases, publications, and websites and summarizes events on the topic you want (such as a particular company).  Based on historic behaviour, its analytic engine tries to predict where the trends are going.  The main customers seem to be stock investors who want to know the direction a company's stock will be heading in the coming days and weeks.

For instance, if the analytic engine sees an increase in discussions about a possible dividend increase, it will interpret it as positive sentiment and predict an upward trend.  If it sees more talk about missing revenue targets, it will interpret it as negative sentiment and trend things downward.  Sometimes lack of activity is also predictive.  If two companies in the same industry stop issuing press releases for a couple weeks, could it mean they are in merger talks?  It's a fascinating use of the internet and analytics.

The whole thing leads me to ask a couple questions:

1)  If Recorded Future's analytic engine is so good, why didn't they keep it to themselves and get rich, like Biff did?  If they felt they could make more money selling the IDEA of predicting the future, it suggests the engine is not as precise as one might hope.

2)  If many people have access to this predictive power, doesn't it defeat the purpose?  Biff got rich because he was the only person with the future horse race results.  If everyone had those future results, no one would get rich because they'd all bet on the same horse and reduce the payout odds to nothing.  If everyone in the stock market knows at the same time that a stock is going up, it's too late to make money on it.  The ability to get rich depends on knowing a stock will go up when everyone else in the market thinks it's going down.

Despite all our progress in the internet age, I still think Neils Bohr's quote at the beginning of this article remains true: Predicting the future is still very difficult.

And if I invent an amazing algorithm to predict the future, you can be sure I'm not telling anybody about it!  And if I stop posting on this blog, you can assume I've succeeded with my invention and I'm busy getting rich!

You can just call me Biff.

Zachman Framework, New and Improved

Last week John Zachman released v3.0 of his Zachman Framework (ZF).  More on that shortly, but it certainly closes out an eventful year for John.

Last summer, John Zachman created some waves by suing his long-time Canadian colleague Stan Locke for $10 million.  Stan initially said he would close up shop and retire, not wanting to challenge the lawsuit.  At the time, there was some musings in the industry about the future of the framework, and especially the value of the certifications Zachman had been issuing.

Now that a year has passed, I can’t find any statements from either party as to what has transpired.  From my reading of the California court records, it appears Stan did in fact fight the lawsuit and had it dismissed on jurisdictional grounds.  John and Stan’s names appear side by side again on the Zachman International website, and over the past few weeks John and Stan have been teaching ZF courses again in Toronto, although they appear to be teaching separately.  It would seem that they kissed and made up to some extent, and life goes on in the ZF world like nothing ever happened.  And if that’s the case, good for them.

Almost a decade ago, I took a course on the Zachman Framework taught by both of these gentlemen.  The ZF has developed a bit of a cult following in the enterprise architecture world, but in my travels I have yet to work in an organization that is deriving any real benefit from it.  That doesn’t mean such organizations don’t exist – but it probably means there can’t be too many of them!

What Is The Zachman Framework?

The Zachman Framework is a grid that organizes different types of modeling artefacts, and is helpful in terms of clarifying how those different models relate together within an organization.  John Zachman created the grid while working for IBM in the 1980’s.  Across the top, he put the 5 W’s (and 1 H):  What, How, Where, Who, When, and Why.  Down the left side, he placed five levels or perspectives within the organization:  Planner, Owner, Designer, Builder, and Sub-contractor.  The premise is that a sub-contractor working on the minutiae of a system will require different models than a high-level planner would.  For instance, a low-level detailed model of “who” might be a user list for a particular computer system, while a high-level view of “who” might be a management organization chart or a list of competitors.  Both are valid models of “who” but they fit into different slots on the grid.

There have been a few versions of the framework, including last week’s brand new version 3.0.  All of the original cells of the framework are still there, but additional descriptions have been added around the edges and some names have been revised.  For instance, the What column originally contained Data artefacts, which limited the perspective to what data architects typically worked with.  Now it contains Inventory artefacts, which is a different perspective on an organization’s answer to the What question, but it’s equally limited.  The original Builder row is now called the Engineer Perspective (which I like), but the models the Engineer makes are now called Technology Physics.  I have no idea what a Technology Physics model is!  It sounds like what my university physics professors built in the machine shop when they wanted to measure cosmic rays or microgravity.

Given the structure of the model can never really change (unless you create a new question word to make it 6 W’s), all that John can do is describe more clearly what’s already there.  I’d say version 3.0 only brings partial progress towards that goal.  There is still a need for a version 4.0 someday, and Technology Physics should definitely not be in it!

Strengths and Weaknesses

So what is the Zachman Framework good for in an organization?  I’ve found it helpful to see how the various types of models in an organization fit together, and which models haven’t been built yet.  It is a simple structure so it’s easy to remember, unlike Scott Ambler’s modified version of ZF which is far more thorough but also far more difficult to understand.

After taking Zachman’s course, I immediately realized it wasn’t going to help my organization with the challenges we were facing.  Developing more models, or slotting the models we already had into the grid would not change how our organization functioned.  While it gives the data architects and modellers a false sense of progress in filling up the pigeon holes with models, it doesn’t affect the troops on the front lines.

Ultimately, the Zachman Framework is just another Dewey Decimal System.  As Melvil Dewey helped organize information in libraries, Zachman helped organize models in an organization.  Dewey organized all the knowledge contained in books, but it did not specify any methods for transmitting that knowledge to people.  That required education methodologies, and Dewey’s system wasn’t a methodology.  Neither is Zachman’s.  As he now puts at the top of his v3.0 diagram, it’s “The Enterprise Ontology™“.  An ontology is a structure for organizing concepts, not a methodology for improving an organization.

In order for models to change an organization, they need to be operationalized.  The easiest way to do that (but not the only way) is to embed the model in a computerized process.  For instance, if you have a policy to control spending by getting everyone’s immediate superior to approve each office equipment purchase, you can implement an organization chart (a “Who” model in ZF) into a purchasing system so that whenever an employee enters a request for new furniture, it looks up their name in the org chart and automatically sends the request to their immediate boss for approval.  An implementation of such a model might eliminate some unnecessary spending, but having the organization chart alone will not save the company anything.

Zachman often repeats this platitude in his courses and articles:

“Someday, you are going to wish you had all those models made explicit, Enterprise-wide, horizontally and vertically integrated at excruciating level of detail.”1 

The only problem with that assertion is that the “someday” never comes.  I’ve been in departments and organizations that have gone through some major crises, and no one has ever said, “If only we had all those models!”  A lack of explicit models can sometimes cause challenges, but the cost of building and maintaining all these models “at excruciating level of detail” across the organization is simply not justified.

The Zachman Framework is a helpful structure for organizing models, but not for transforming organizations.




1 John A. Zachman, “Enterprise Architecture Artifacts Vs Application Development Artifacts”, © 2000 Zachman International, downloaded from http://www.hl7.org/documentcenter/public/wg/secure/Zachman%20Enterprise%20Artifacts.rtf

The Gmailman Video

Microsoft recently created a video for their sales force to mock Google's Gmail and promote their new cloud strategy, Office 365.  

I've been a Gmail user for years now, and am a fan of how Google provides free services in exchange for a few discretely-placed ads.  Still, the video is funny.  

My favourite line:  

"Hey, mailman, are you reading our mail?"

"No, I'm reading EVERYONE's mail!"

Microsoft fails to mention that their Hotmail contains far more ads than Gmail, nor that businesses who pay for Gmail get no ads whatsoever.  Therefore, there is actually no reason for a business to switch to Office 365 based on this argument.  Pretty weak sales pitch.

So, in the end Microsoft is still more evil than Google, but at least they made a funny video!

Risk Management: Connecting Consequences with Decisions

I came across two articles recently whose themes on risk management intersected nicely.

The first article called “Avoiding Another Great Recession” is by a professor at London Business School named Julian Birkinshaw. He correctly attributes the market crash of 2007 to a huge failure in decision-making at some of the largest US banks, and that this particular problem has not yet been addressed. The risk of it repeating therefore remains high. His solution is to personalize the risk evaluation process in large companies. In his words, personalization “involves pushing the responsibility for evaluating and making a judgment around risk to those individuals who are making decisions – and requiring them to live with the consequences of those decisions.” He cites Goldman Sachs and JP Morgan Chase as examples of banks who have this personalization culture in place, and how they fared much better through the crash than other banks.

The second article in the Financial Post had the catchy title, “Why Swiss Banks Don’t Go Broke.” Richard W. Rahn explains how Swiss banks, particularly privately-owned Swiss banks, rode through the financial crisis so much better than banks in other countries. “Banks that are organized as general partnerships have had fewer problems because the partners have a very strong vested interest not to take on risks they do not fully understand because it is they who take the hit if something goes wrong.” Rahn goes on to propose an impractical solution called “mutual fund banking” but the rest of his article stands on its merits.

Bottom line: If you personally stand to lose everything from a careless investment decision, you tend to make fewer careless investment decisions!

As simple as this concept appears, it apparently has not been considered by governments when it comes to fixing the banking system. Governments prefer to believe that increasing and formalizing bureaucracy around these risk management processes will somehow reduce risk. The track records prove otherwise. Managing risk by increasing bureaucracy rarely seems to work. The Basel Accords are a good example.

Global central bankers set up the first Basel accord in 1988 to measure credit risks and to ensure banks retained sufficient reserves to cover those risks. Apparently this higher reserve requirement prompted JP Morgan to use credit default swaps to practically get around that requirement, and later those types of swaps played a significant role in the Lehman Brothers collapse in 2008. Warren Buffet predicted this danger in 2003, calling these swaps and other derivatives like them “financial weapons of mass destruction.”

Basel II was released in 2004 in an attempt to not only tackle credit risk, but other types of risk such as operational market, pension, and liquidity risk. It also failed to prevent the meltdown of 2007.

So, the solution to these regulatory failures? Basel III, currently in development. Just close your eyes, click your heels together three times, and it will be sure to succeed where its predecessors failed!

The failure of the Basel Accords is not in its content or a lack of expertise that went into it, but in its fundamental assumptions. Like Rahn points out, forcing banks to increase their reserves does not reduce the risk of their investments. To be safe, reserves must exceed the level of investment risk, which varies between banks and over time. There is no arbitrary reserve percentage that is safe enough. Safety comes in avoiding poor investments.

As a self-employed business owner, managing risk involves one person so it's not complicated. However, we're not immune from bad financial decisions either. I recently heard about a self-employed contractor who traveled a lot, but did not stay in the expensive hotels that his fellow self-employed contractors did. His comment: "They're spending money like it's not their own company."

And that's what it all boils down to: People have to make decisions like it's their own company, and then they have to experience both the rewards and consequences of those decisions like it's their own company.

Self-Serve BI Challenges

Cindi Howson has written an interesting article for Endeca called The Five Myths of Self-Service BI, which is summarized on her blog at BIScorecard.com.  You can download the report for free from Endeca after registering your email address.  It's short and concise, and worth a quick read.

What Is Self-Serve Business Intelligence?
The article defines self-serve BI as providing users "with direct access to all the data they need to make critical business decisions."  In my experience, self-serve is broader than just direct access to data.  It also includes more user-friendly approaches, such as allowing users to modify or create reports based on a template or within a certain set of defined attributes and facts.  In essence it involves enabling the users to serve as many of their changing decision-making needs as possible without being dependent on the IT department to do it for them.

While I like the good intentions of self-serve BI, I have always had reservations about some of the presumptions surrounding it.  I certainly concur with Cindi's first two myths, and have seen them demonstrated in the real world.

Myth 1:  Business Users Will Create Their Own Queries
I would expand that myth even further:  Business users will create their own reports using the BI tool.  Very few users are interested in writing their own reports or queries, especially given the complexity of some of the BI tools and data models they have to navigate.  The few users who are interested in writing queries are already doing it, so giving them a new BI environment is unlikely to bring huge improvements in their decision support capabilities.  The majority who are not writing queries now will still not be doing it after you build them a data warehouse.  Count on it.

Myth 2: BI Is So Easy To Use, Even Casual Users Will Embrace BI
I think this myth might be caused by IT managers believing the marketing hype from the BI companies.  Unfortunately, many BI tools are not as easy to use as the unofficial benchmark that all business users measure against:  Microsoft Excel.  As Cindi says, "respondents identified BI tools as one of the hardest category of office tools to use."

Ouch!  I remember as a data user when the data warehouse folks showed up with their much-hyped BI tool.  I couldn't believe how user UN-friendly it was.  I preferred using Excel, SQL, and SAS any day.  Those tools always got the job done.

Self-serve BI must be targeted to the different needs of the business users.  Some will want self-serve as direct access to the data, so they can write their SQL queries themselves.  Some others will want pre-built reports that they can modify slightly whenever necessary.  For the remainder of users, self-serve BI functionality will never be touched.  Our plans for self-serve BI implementations must incorporate these realities.

Business Analyst vs Business Systems Analyst, part 2

In my previous post, I referred to an article by Vongsavanh and Campbell discussing the differences between Business Analysts and Systems Analysts, and I stated that Business Systems Analysts (BSA's) possessed both sets of skills.  In this post, I want to look at the specific skills required by each type of analyst.

Vongsavanh and Campbell's research produced the following list of skills for business and systems analysts:

• Elicitation
• Presentation
• Leadership
• Communication
• Business Knowledge
• Creative Thinking
• Problem Solving
• Technical

The top of the list represents those skills most common to business analysts, and the bottom those skills most common to systems analysts.  There is no explanation for how they arrived at this particular list or how they determined the ordering.  In the diagram in their article, Communication is shown as the skill closest to the middle.

The first thing that appears strange in the ordering of these skills is that Business Knowledge is on the Systems end of the scale.  While some of these skills could be debated exactly where they should fit on the list, Business Knowledge should clearly be shown in the realm of Business Analysts.  Systems Analysts need to understand the systems, and Business Analysts need at least a general familiarity with the business functions.

Since Presentation is separate from Communication, it appears the authors intended Communication to mean documentation or one-on-one verbal communication.  That is a strength required by both Business and Systems Analysts, but Presentation would be more important for the Business Analysts.  The order looks appropriate, but any analysts who are only mediocre in their documentation skills will never excel in their jobs.

Data analysis is missing from the skills list, but it probably fits under Technical or Problem Solving.  From my experience, when the business and technical experts disagree on some detail, it is the analyst's job to find some relevant facts to clarify and focus the discussion, and data analysis is a means to discover those facts.  "One accurate measurement is worth a thousand expert opinions."  -- Admiral Grace Hopper (1906-1992)

Research ability is another skill missing from the list.  If the organization is mature and system documentation exists, it is the analyst's responsibility to understand whatever relevant information is contained in that documentation.  If little documentation exists, then data analysis will have to compensate for that gap.  Sometimes the documentation is out-of-date, so it must be validated with data analysis.  Research and data analysis go hand in hand.

Leadership is helpful in any role, but leadership implies some people skills that often come in handy when working with the business staff, so I agree with placing that on the Business half of the scale.

I cannot guess the difference between Creative Thinking and Problem Solving.  Both have to do with Solution Design, but if you have no creativity, you will solve very few problems.  I would consider those skills as one.

My revised list of skills is diagrammed below.  

Of course, one of the essential skills not mentioned is flexibility.  Every client and project is different, and analysts need to be able to adapt and respond to the unique needs of the situation at hand.  That just means that it should be easy to find a situation that doesn't fit the skills list above.

Such is life for a BSA!

Business Analyst vs Business Systems Analyst, part 1

I market myself as a Business Systems Analyst (BSA).  I think it's the best description of my skill set and the work I typically do with my clients.  The only problem is that Business Systems Analyst doesn't mean the same thing to everyone.

I have always understood a BSA to be a combination of a Business Analyst (BA) and a Systems Analyst (SA).  I bring both skill sets to a project in one convenient package.  The advantage to the client is they get a flexible resource that can wear either hat over the course of a project, and can avoid extra hand-offs between the BA and SA tasks.  The advantage to me is that I should be able to charge a slight premium rate over a pure BA or SA -- at least in theory!

However, there are some who use the term BSA to identify a specialized type of SA who specializes in Business Systems, as opposed to manufacturing systems for example.  There are others who just use BSA as a synonym for BA, arguing all good BA's must have some systems knowledge as a basic requirement.

My experience shows that BA and SA roles are distinct but related, and fortunately a couple people who are smarter than me agree.  Australians Alan Vongsavanh and Bruce Campbell published an insightful article in 2008 entitled "The Roles and Skill Sets of Systems vs Business Analysts."  Their research shows the two roles have overlapping skills, and they present them along a spectrum.

My simplified version of their skill spectrum is that the BA has strong skills on the business side of the spectrum, and decreases in strength as you move towards the systems side of the spectrum.  The SA is strong on the systems skills and decreases in strength as you progress towards the business skills.  Both have some skills on each end of the spectrum, but their strength lies on one end only.

By extrapolation then, Business Systems Analysts should be strong across the entire spectrum.

In the next part, I want to look at the specific skills that lie along that spectrum.

No Such Things As Data Rules?

I found an interesting blog entry by John Owens titled There Are No Such Things As Data Rules.  I find John's articles compelling and much of his material I agree with, but not quite all of it.  This article of his is in the second category for me.

I think I know where John is coming from in his approach to this subject.   Data quality analysts who spend all of their time with their heads buried in the data making decisions on what records are "right" or "wrong" are not what data quality improvement is about.  This approach can create as many new data problems as it resolves.  However, I don't believe we solve this problem by going to the other extreme and assert that simply looking at the data for problems accomplishes nothing.

I want to focus on a few of John's specific points, some of which are found in his follow-up comments after his initial article:

a.   "There are no data rules …. [There are] business function rules."

      "The only reason any attribute would have rules ... would be to support a known, documented business function."

In order for these statements to be true, every last data rule would have to be documented as part of each business function that uses it.  For instance, every business function that required an email address would have to restate that all email addresses must have one and only one "@" symbol somewhere in the middle.  Why would any business want to duplicate that definition all over its business functional documents?  What value does it create?

Further, there is no business need that requires email addresses to have one and only one "@" symbol.  The business requirement might be to communicate with a client quickly and electronically, and nothing more.  The fact that the chosen solution to meet that need is email does not introduce a new business rule.   It introduces a technical rule specific to that solution, namely that email standards must be followed in order to complete a successful email communication.  If a different technical solution is chosen (such as SMS text messaging via wireless phones), the technical standards would change accordingly, but the business requirements and rules would not change.

Shared technical standards are best documented and evaluated centrally, and calling them "data rules" may not be the best name, but it's certainly more accurate than calling them business functional rules.

b.   "If you want to understand the data, you must understand the business functions."  
"Data only has meaning ... when viewed in the context of supporting the business functions of the enterprise."

      "Data can only be said to be erroneous if it fails to meet the needs of the business function(s) that utilise it."

These statements are partially true.  There are certain data questions that require business context in order to arrive at the right answers.  For example, one can never answer the question, "Is this data precise enough?" without putting it into a business context.  However, not all data questions require business context.  Meaning can sometimes actually exist in the data alone.  More importantly, meaninglessness can sometimes be determined from the data alone.

For example, postal codes are a mandatory part of any Canadian mailing address, such as K1A 0A6 (the Prime Minister's office in Ottawa).  The business purpose for capturing a customer's postal code may be to send the customer's bill to them by mail, or it may be to assign the customer to a geographical location for a mapping analysis to set regional boundaries for salespeople.  For the first purpose, all 6 digits of the postal code are required or the bill doesn't arrive at the address.  For the second purpose, the sales department only uses the first 3 digits of the postal code (called the Forward Sortation Area) which provides sufficient location accuracy for assigning sales region boundaries.  Therefore, a partial entry of K1A in the Customer Postal Code field would be insufficient precision for mailing purposes, but sufficient precision for assigning regional sales boundaries.  Answering the precision question requires business context.

However, because Canada Post has defined that no postal codes shall begin with the letters I, O, or D (to avoid confusion with the numbers 1 and 0), we can be sure any entry in the Customer Postal Code field beginning with I or O or D is meaningless, regardless of the business purpose.  Answering the validity question sometimes requires no knowledge of the business purpose whatsoever.

c.   "If a business function requires [data] to be collected ..., then it must enforce all applicable data rules at the point of creation."

I wish this could be true in the real world, but it in many situations it simply cannot be implemented successfully. 

Implementing it technically is easy -- design your system to force the sales person to enter a valid customer postal code before moving to the next screen.  However, if the customer who is standing with the sales person recently moved and hasn't memorized his new postal code, does that mean you should prevent that sale from occurring?  Is a valid postal code more important to the company than a sale?  Probably not, so the employee will enter a fake (but valid!) postal code just to get to the next screen and complete the sale.  It doesn't take long for frustrated employees to realize that Santa Claus has a completely valid postal code -- H0H 0H0.  Suddenly a lot of the company's customers seem to be living at the North Pole!  Therefore, an enforced business rule at the point of capture may improve the validity of postal code data, but it does not guarantee improved quality of the postal code information.  It may instead just frustrate both employees and customers.

The situation is a bit riskier if your organization is a hospital, and the postal code being captured is the patient's at the point of admission in an Emergency Room.  Do you really want to prevent a patient from being taken off the ambulance because he is unconscious and can't tell you his postal code?  If the registration clerk cannot leave the patient postal code blank in the registration system, then you can be sure a fake one will be entered so the intake process is not delayed.  The hospital's postal code is both valid and familiar to the registration clerks, so a lot of patients will appear to live at the hospital.  Oh, and Santa has lots of ER admissions too!

Given the complexity of technical data standards that have no direct relation to the business processes that use the data, and given the challenge of preventing erroneous data at the point of capture, data rules can play a helpful role in managing an organization's information assets.