The economic downturn is hitting hard in Europe, but Business Intelligence endures its upward trend.  But, a danger lies inside projects and budgets. While still on the rise, budgets are no longer a comfortable fit. It's not bad, as a special care to avoid wasting time and efforts is welcome. Though, planning has become much harder.

Companies managing their IT environments have always acted upon a formal plan. Less structured companies have built upon existing structures, with little to no care for planning. Reacting upon business solicitations is sometimes called agile development just to justify the lack of planning (I know well that agile is not simply lack of planning. I just say that the name is abused for political reasons.) So how a BI environment grown on lack of planning looks like?

Data are not synchronized. Each single silo will be updated according to the natural pace of the source system. Those data will not match with other data, likely.

It replicates the siloed transactional systems background. It will likely feature an array of disjointed datamarts or unrelated tables. Few to no dimensions will be shared.

Technical design will be sub optimal. Often, while reacting to business requests, there's simply no time to properly integrate new data.

In my experience I have seen system which recall to memory baroque churches. They are based on different technologies, with no management features, scarce to no documentation, different people responsible for different areas, no master data or data quality etc.

So the risk is building, upon time, a less than optimal environment that doesn’t serve well the business. These systems, at same point in their history, become so unstable to force a global rewrite. In this case, those who sponsored their growth had better to have an escape hatch somewhere before suffering the dire consequences of having wasted money and efforts.

So, don’t be easy-going when you are requested for a new piece of analysis, stick to your global vision and strategy. Because you have a global strategy, don’t you? 

I have been silent for a couple of months: some of you solicited me about and I replied privately but I think I owe an explanation “Coram populo”, that is, in front of everyone.

As some will have imagined, something has changed. In this couple of months I was sick for a couple of weeks. When I emerged from the sickness, my company started suffering for the first strikes of the economic downturn. It is hitting hard here in Italy, and my “other” job is at risk.

What’s worse is that the new taxes levied by Mario Monti’s government make running a side job nearly impossible. We always had rather odd tax regulations, but the so called “Save Italy Act” and the following legislation, in place of facilitating entrepreneurship, punished it.

This is Viney@rd’s end. It has never been a money maker but the new fiscal policy turns it into a money waster.

The few who adopted it will not be left alone and I’ll safeguard their efforts, as a personal thank-you for those who believed in me.

I’ll keep posting on this blog and on the IE Group finance blog, because I feel I have many things left to be said.

I do not exclude that, somehow, I’ll resume the initiative; maybe in another country. For now, anyway, I’m done.

Devil is in the detail, an old saying that often proves true. It proves true in IT too; it’s a quite common experience. There are, anyway, cases when we do everything we can to meet the devil in person.

In my “other” job, I use a famous BI tool, well known within the community and outside. It massively evolved in the last 5 or 6 years, widening its scope and becoming a remarkable architecture.

One feature it used to support was placing breaks in a table based on a hidden column. It was clearly a residual feature. They implemented the breaks, than they implemented hiding a column and, since the application did not break, they left the feature to break on the hidden column in.

There’s no point in breaking on a hidden column, as breaks and subtotals are not immediately recognizable.

Unluckily, that hidden feature could be used to create elegant layouts, with no blank columns and sexy boxes for subtotals.

A marginal feature was abused and become a cornerstone of thousands of reports.

Until it was dropped.

A new development team, more concerned on the beef and the business, more dedicated to reducing costs and speeding up development came in. The feature was dropped in occasion of a major rewrite. Other, more concrete, features were implemented before that elegant but pointless eye candy could be worked around.

Converting existing reports to upgrade the sw version was a pain that many endured because of the large, existing, customer base. Churn costs were high enough to prevent a large drop off.

I’m not advocating that the feature should not have been left in, it was what users wanted and the developers should have had a better eye for the customers. I’m advocating that a lot of work has been done, based on what might be clearly considered a marginal feature, subject to changes and malfunctioning.

Exploiting the sw to the max, using all the advanced features, finding the intelligent trick that brilliantly fixes an issue will likely do more harm than good, in the long term. It will, because small changes disrupt the entire solution. A resilient solution can tolerate small changes with no harm, but tricky and smart solutions are hardly resilient.

Good software should always be used according to its design principles, no forcing and no bending; bad software should not be used at all!

This occurrence is often overlooked, but I crossed it many times in my professional life, and caused a good deal of damage. What do you think about?

CIOs come in many flavors, I thought I smelled the bulk of them in my career.

Then, my Tweep Andy Bitterer (@bitterer) came out of the blue with this new breed of CIO

Have fun!

This article has already been publisged on http://finance.theiegroup.com/ . This is an updated version. Bear in mind it was aimed to a non- technical audience

There are some basic concepts, in Performance Management and in Management accounting in general that are hardly ever explained. They tend to be given for granted as they are, somewhat, intuitive. Yet they may lead to misinterpretations, if not understood thoroughly. We are going to go through the very basics, to refresh what Performance Management is all about.

The basic building block of every system is the “fact”. An invoice line is a fact. A payment order is a fact. The thick at the completion of a task in a list is a fact. A line on the payroll is a fact. An entry on the complaint filing system is a fact. The average power consumption of machinery is a fact,

A fact is an elementary piece of information with a number attached.

• The invoice line has quantity and price.
• The payment order has the amount attached.
• The thick on the task list can be interpreted as a one; the unchecked task can be labeled with a zero.
• The entry on the complaint list can count for one as well.
• The power consumption is a number.

Receiving an e-Mail is not a fact, is unstructured information (it may be cosmically relevant, though; unstructured does not mean unimportant). It becomes a fact if we record the reception in a table with some other data: in this case it may be counted and classified and then may become a fact.

While the notion of fact, as opposed to opinion, is intuitive, we need to attribute a mathematical quantity to it to make it measurable. Ideally, whatever is done within the company should produce a fact, somewhere, thus being measurable. The most commonly used facts derive from documents like invoices, packing lists or accounting entries, but reality is complex and relevant facts can sit everywhere.

IT collects (or can collect) huge amounts of facts, and they can be complemented with user defined data. The quality of a performance management system depends largely on the facts chosen to be included.

The numbers attached to the fact have a name of their own.

A measure is the quantity attached to a fact.

The quantity and the value of an invoice row are measures. The number of active customers is a measure. A single transaction value on the ledger accounts is a measure. The tag price of a product in line of purchase is a measure.

Usually we do not use measures as they are. From the CFO perspective, the single invoice line is hardly important. Usually we summarize or count the numbers attached to facts; the monthly invoiced total is a very relevant number to the CFO or any other executive.

The type of aggregation (sum, running sum, average, weighted average etc.)  and the summary level of the related facts are not relevant for the definition of a measure itself and may vary.

A derived measure is simply the result of a mathematical operation on simple measures, like average price or monetary cycle.

Please note that every P&L line is a measure, and every financial statement line is a measure. The procurement plan, however, features a single measure, the quantity to be purchased, broken down by purchasing item and time period.
There’s no unanimous consensus on how technically define a measure. The most followed rule is to define as measures quantities qualitatively different that describe different phenomena, like accounts receivables and payables or assets and liabilities. Sales by salesman or by product are the same phenomenon, just broken down differently. 

Measure aggregation over time can be interpreted in two ways. Some measures are relevant for their value over a period and their aggregation is mostly of positive values. Monthly sales are a classical example. From an accounting point of view, these quantities are typical of accounts which are zeroed at the end of the period.  Other measures are relevant for their value over time.  The classical example is stock (these measures are sometimes called “stock measures”). Stock is relevant by its level, which in turn is determined by additions and subtractions. Many financial measures are stock measures.

When interpreted over time, measures gain a specific meaning and a new name.

A metric is a measure sampled over time.

In other words a measure presented by showing how its value changes over time is a metric. There is the typical display of gauges with a slider which shows the metric over time but an excel table with weeks and the invoiced value per week is a good metric representation. A graph with quantities on the y axis and time on the x axis is a metric visualization either.
Often derived measures or broken down measures are used as metrics, but the overall meaning is the same.
While the measure has no privileged dimension for analysis, a metric is relevant over time first, and over other dimensions in the second place. 
Some might think that, from a strictly technical point of view there's no substantial difference in presenting a measure or a metric and the transition between the two is seamless; they're right.

Stock measures are naturally presented in this way, conventional measures are usually presented as a running total from a “zero” point.

 Anyway, no number is relevant if it’s not compared to another number.

A KPI (Key Performance Indicator) is a metric which is included in a performance management system. That is, a metric with associated targets or oscillation boundaries or any other sort of constraint is a KPI. In a BI system there may be thousands of measures and metrics, but few tenths of KPIs.
The "Key" part of the term refers to the particular relevancy of the metric for the health of the organization. The "Performance" part of the term refers to the associated values that tell us if the metric value and/or trend are good or bad for the organization. The "Indicator" part of the name stresses that the metric chosen should be influenced by other metrics and measures and should give an overall view of an organizational segment.

Choosing the right KPIs and giving an exact definition of them, for example according to the Balanced Scorecard model, is the main point while designing a Performance Management System.
KPIs must be relevant for the business, there should be an adequate number of them (not too many to avoid confusion, not too few to avoid oversimplification) and must be tailored for their audience (different people are in charge of different KPIs and can influence them). 

Defining targets and budget is also a complex task. Stock metrics targets usually come in term of an allowed oscillation band over time. Normal metrics usually have a normal goal to be reached in a defined time (quarter or yearly objectives). Another popular targeting system is defining a trend and a slope to be maintained.

Applying these concepts, we can build a sound Performance Management system. These concepts also help us in understanding how IT tools can help automate the Performance Management System.

The customer is one of the business basic notions. It is also a subject of interest in Business Intelligence implementations. Nonetheless, the notion of customer may be very complex and counterintuitive, and it may depend upon the business nature and upon who is looking at the customer. So, implementing the customer dimension may prove to be very complex.

The most basic and immediate customer notion comes from invoices. The customer is who appears in the invoice. Usually known as the “bill-to” customer, this is also the customer recorded in the accounting ledgers. They are usually designated by the VAT code or a similar id.

Orders may be delivered to an address different than the address of the customer in the invoice. In some cases this can be sorted by managing an address for delivery, but not always.

Example: the owner of two restaurants wants all the invoices to be sent to an accountant, while the two chefs refill their kitchens according to their own judgment. The wine salesman of the same company has the two chefs as customers. From a sales point of view they are two different customers, and the common property is useful but secondary information. This is often known as the “ship-to” customer.

Orders may come from a central unit, but decision points are distributed. In this case decision points are the customer but there’s no reference in documents about.

Example: mass retailers with in house distribution based on regional warehouses. Orders are invoiced to a single company, deliveries go to warehouses but deciders are the local shops. Finding a way to capture the last destination is paramount to correctly manage the customer.

Orders may be issued by and delivered to the same point, but the commercial agreement is defined elsewhere.

Example: franchising chains often operate in this way. The franchisor sets the commercial agreement with suppliers and franchisees order at preset conditions. In this case, they can be both a customer, in the commercial sense of the term.

Order is placed by a point, is paid by someone else and delivered to a third party.

Example: car advertising on newspapers. The upper part of the ad is all about the car model and is paid by the manufacturer, the lower part addresses the customer to a couple of local resellers and those spaces are paid by the reseller themselves. The order to the advertising dealer is placed by the manufacturer, but money goes to the newspaper with a fee for the dealer.
Finding who the actual customer is can be a little discomforting, sometimes.

Orders are placed by different entities, though the service is the same.

Example: hotels receive reservations from single guests, travel agencies, internet aggregators or companies. Every order, though, produces a stay by individuals who are themselves, customers. In the commercial sense, the relevant customer is completely different depending upon who placed the reservation.

Many other combinations could probably be found,  but I think that the point is clear enough. Defining the customer is a complex task, sometimes overlooked on implementing a BI system.

So, while designing the solution, special attention should be devoted to defining all the customer types required for managing the business.
The worst case occurs when a relevant customer is not recorded anywhere in the systems. In this case, modifying the systems and changing business processes to record it is unavoidable.
To implement all these customers the easiest path is to add the key directly to the facts and make them independent dimensions. While it may seem natural to think as the invoicing customer as a group of delivery points, commercial rules are not always enforced. For example, the delivery point that often routes orders through a central point, in emergency, could place direct orders, thus risking questioning the hierarchy/grouping. Making them independent dimensions has the side advantage to highlight all these exceptions for further management.

We, as BI professionals, should always be aware of these possibilities while implementing a system. Do not trust the first person, whom you speak with; chances are that her customer is much different than her coworkers’.

Enjoy.

Before a new long and articulated post, some melancholic poetry.

They have given us into the hand of new unhappy lords, Lords without anger and honour, who dare not carry their swords.

They fight by shuffling papers; they have bright dead alien eyes;

They look at our labour and laughter as a tired man looks at flies.

And the load of their loveless pity is worse than the ancient wrongs,

Their doors are shut in the evening; and they know no songs.

A.K. Chesterton

I've been silent on the blog since the 18th of december.

Partly because I enjoyed quite a long holiday period.

But mostly because I've been honored by the fine people at the IE-Group with a place on their finance blog. Here is my first post. 

This is the second part of a story. The first part can be found here.

In our second anecdote we see the CEO of the Italian subsidiary of a large, American, corporation in the area of CPGs, complaining that “quarters are always on the rollercoaster, they can start good than drop; or they can start really bad and recover on the finish line“. Actually, given the modest seasonality and a large, consolidated, group of customers, quarters should have been rather simple to manage.
Sales force was told to start the quarter by visiting the “Gold” customers, to collect the largest orders in the first couples of weeks. This was a good commercial practice and had the collateral advantage to improve quarter predictability.
Despite this directive, many (not all) quarters kept being irregular. Orders profile by customer and volumes seemed to be coherent with the market segmentation, so I was tasked to find a rationale through the issue.

I ran many reports, observing the quarter build-up against the targets, and, indeed, they showed that bizarre behavior. I tried various segmentations, till when I sorted a single salesman’s orders by the first input date. That was different than receipt date (a salesman was allowed to “withhold” a customer order before sending it to the company, to make corrections, for example).
I spotted two patterns. First, he didn’t visit his Gold customers first; he just visited those closer to his residence. Second, he withheld some medium sized orders just to have a “reserve” in case the Gold and Silver customers were below the expected quantities. A non-negligible number of orders also, were originated in the quarter before the one being examined.
I checked the entire sales force (about 100 people, a tough job) and spotted similar patterns in a large majority. As in the previous case, handling this information was rather painful and my popularity suffered from that.

They could have spotted that before, but that tiny date field was never used in reports and overlooked. Though, we diligently included it into the data warehouse even without a clear perception of its usefulness.

Now, lesson learned.

1)      Assumptions must be verified, even if they originate from the CEO, the CFO or any other C level executive.

2)      Learn to recognize assumptions when you see them. Some seem just natural, so they appear not to require any further justification, but they do.

3)      Managers’ mental models are hardly accurate because they focus on what matters them most, costs the most, and consumes more time but, not necessarily, affects the most the bottom line. They’re also human, and their focus may be not entirely rational.

4)      Managers’ mental models are more accurate than mere drillable reports, which are designed along the lines of database design. Whatever they use to consume data, it should include their view, not the simple database view.

5)      Points 1, 2, 3 and 4 are the reason why people like me keep being paid. This is somewhat reassuring, isn’t it?

Enjoy!

Every manager I met in my career knew her business. At least she said so. Every competent manager has a business vision that drives her decisions. Modern managers are used not to rely any more on gut feelings, but have a good bias toward a fact based decision making. This is positive because we all sell our BI solutions to them.

 As I often said before, all these managers have their own personal mental business model and want it translated into actual solutions. Good BI solutions usually comply with models, till when there’s a surprise somewhere.

 Those managers, often, ground their actions on assumptions that are never verified and actually “are” true till they’re proved wrong. I make just a couple of real life examples, changing few details to make the actual characters unrecognizable.

 A luxury goods manufacturer/reseller had always thought that their magic number was the number of retailers which featured a show-room. A huge amount of time and effort was dedicated to designing pleasant expositive areas, to stimulate purchase and stand out from the competition. Salesmen were given a target in terms of newly acquired show-rooms, architects and designers were available at no cost to retailers to help set up the areas.

Retailers were actually segmented in “show-rooms enabled” and “small dealers”.
This was fine till I was tasked to make evident the advantages of having a show-room. First I had the idea to calculate the average time between the first retailer sale and the show-room set up date. It was -88 days, minus eighty-eight days. I checked it twice but it was correct. The first sale occurred far before the show-room was set up. So I went on, and checked the retailer’s weekly sales volume. No particular variation occurred before and after the show-room being available, just statistical fluctuations with no visible pattern. Then I confronted the average and the median “small dealer” with the corresponding show-roomed retailers, and the “small dealers” used to sell slightly more than the upper segment. Given the show-room costs, I lacked the heart to estimate retailer profitability.

It was a delicate and painful matter, disclosing those figures. A marketing manager was forced to resign for that, and I’m not particularly proud.

 They actually could have made these calculations well before, but reports and dashboards used to list resellers individually, but lumped small dealers together. They knew that small dealers sold more than the show-roomed, but there were also more of them, so they never bothered. Sales force actually knew better, but their commissions and incentives were more closely tied to show-room retailers than the others.

Anyway an undisputed assumption, and a pivotal one, was challenged by the numbers and proved wrong.

 In the next post, I’ll make another example and I’ll draw some conclusions.

 In the meanwhile, stay tuned!

Just for one time, I dismiss my usual business attire to publish a very technical post, rooted in the real life of my “other” job. I hope it could be of help to someone.

Few days ago I had to implement a new conformed dimension. For reasons too long to describe here, I couldn’t load a table but I had to use a view from existing tables in a SQL server linked server.

The dimension hierarchy was available as a string, with separators among the elements.

For example “Food/Fruits/Peaches/Nectarines”

Also I had rows like “Food/Mineral Water”

There were also rows like “Food/Confectionary/Desserts/Pudding/Chocolate Pudding”

In a word, the hierarchy was unbalanced. So, to add it to a conformed dimension, I had to split the string and balance the hierarchy to look like the table below; and I had to do it on the fly.

My solution was to implement a function in T-SQL.

USE [<your database>]

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE FUNCTION dbo.[H_Element_Get]

(   

    @RowData NVARCHAR(MAX),

    @Sep NVARCHAR(MAX),

    @Ord INT

)

RETURNS  NVARCHAR (MAX)

AS

BEGIN

    DECLARE @Iter INT

    DECLARE @sstring nvarchar (max)

    SET @Iter = 1

    DECLARE @FoundIndex INT

    SET @FoundIndex = CHARINDEX(@Sep,@RowData)

    WHILE (@Iter<=@Ord)

    BEGIN

        IF @FoundIndex>0

                  BEGIN

                        SELECT

                             @sstring = LTRIM(RTRIM(SUBSTRING(@RowData, 1, @FoundIndex - 1)))

SET @RowData = SUBSTRING(@RowData,@FoundIndex + DATALENGTH(@Sep) / 2,LEN(@RowData))

                        SET @FoundIndex = CHARINDEX(@Sep, @RowData)

                  END

        ELSE

                  BEGIN

                        SELECT @sstring = LTRIM(RTRIM(@RowData))

                  END

        SET @Iter = @Iter + 1

    END

    RETURN @sstring

END

GO

The [H_Element_Get] function accepts 3 parameters:

@RowData = the string of chained elements

@sep = the separator

@Ord = the hierarchy level to retrieve

The maximum hierarchy depth is known, of course, and it is not subject to change without notice.

The select statement for, say, a four level hierarchy may look like the following:

SELECT

      H_Element_Get(<string>,<separator>,1) as [Level 1],

      H_Element_Get(<string>,<separator>,2) as [Level 2],

      H_Element_Get(<string>,<separator>,3) as [Level 3],

      H_Element_Get(<string>,<separator>,4) as [Level 4]

Let me know if I can be of further help.

See you next time.

In the previous posts (here and here), we described in short what the Balanced Scorecard is and how it may be implemented. Now let’s see how we can design it.

Some BI professionals think that the business side of their systems doesn’t actually matter. It’s just not up to them. I do not agree, because a business failure implemented in systems translates into a systems failure, and that matters.

So, it’s useful to know how the business side actually implements the process of defining a sensible Balanced Scorecard.
At the roots of the BSC we have the KPI notion; the BSC just suggests the areas covered by these indicators.

A good KPI should measure the effectiveness of a strategy. Strategies, in business terms, are what you are going to do on the market. They differ from operations as they usually portray a broad view, a high level landscape and picture a course of actions across many years.
At lower levels, smaller units have smaller, low level, strategies that implement the higher level strategies; low level strategies end up defining progressively what operations should be carried on and how. Once again, a high level strategy is not an aggregate of the lower level strategies; actually “aggregate”. referred to strategy, means nothing.

Even if there’s no aggregation, strategies are all linked, hierarchically and sideways, among the Balanced Scorecard areas. The graphical representation of the company strategies, with their links and constraints, is the Strategy Map. The strategy map is often complemented with the KPIs related to each and every strategy. This representation is often misinterpreted as being the Balanced Scorecard itself. This is a bad mistake, as the BSC, I repeat, is simply a way to organize KPIs to measure the company performance.

In terms of evolution, the strategies should be the place to start from. Just decide what you are going to do (“Just” is a TV commercial word, actually; strategic planning is a discipline of its own).

Defining what to do makes you define targets (some of these, in a business environments, are the company budget).

Than define your KPIs to measure actual results versus targets.

Than tweak strategies and/or operations according to the performance.

Rinse and repeat.

This short series covers the very basic of the Balanced Scorecard, but Performance Management is a wider topic. When it is taught to MBAs, it neglects all the efforts required to implement it as a company system. When it is explained to BI professionals, it is given for granted and the discussion revolves around fancy graphics.
So, immodestly as usual, I’m going to unify both visions in the next posts line.

Stay Tuned!

In the previous post we gave a clear definition of the Balanced Scorecard. In this post we discuss the usage within the organization and some implementation perspectives.

As we have seen, the Balanced Scorecard is a schema to arrange KPIs. In a whole company/group/corp. perspective, it’s quite clear how the indicators should be defined and why they’re relevant to management. The upper management should define them in detail, targeting all the four areas, identifying all the relevant aspects. These may well differ from company to company, from business to business, but they all share one feature: they are all companywide indicators. If they’re not companywide indicators, they target some very relevant, large areas.

If we drill through the company, though, we may incur in two cases.

If a company is organized in business units (i.e. almost every function is replicated for each BU) than the BS can easily be applied to the BU level. The same could apply where various autonomous entities are present, for example, a retailer with different shops, or a hospitality corp. with many hotels.
Otherwise, if the company is organized along functional lines, the BS will soon cease to be relevant as we go into smaller organizations. It’s hard to imagine how a Customer or a Financial area indicator could be relevant for the manager of an assembly station on the manufacturing line (this point is controversial, but I stick to this interpretation).

From an implementation perspective, there are some consequences. The company BS is not some sort of aggregation of lower level BSs. If lower levels BSs exist, they may include different indicators than top level and their granularity is going to be rather low.

So, the performance management model can be rather messy, and it’s a management task to sort it out. How to do that is the topic of the next post.

Stay Tuned!

In a previous post, I said that the performance management model should not be treated as a school report because some KPIs combinations can lead to unstable results.

When a company builds a performance management model, chances are that it will create a Balanced Scorecard. BS is something that is often talked about but hardly thoroughly understood.

The Balanced Scorecard is a schema to arrange logically your key performance indicators. 

The idea was born at the beginning of the ‘90s but it was formalized and gained world popularity in 1992 with a paper written by R.S. Kaplan and D.P. Norton.

The BS doesn’t tell which the KPIs to monitor are; it just tells that KPIs have to span four areas:

• Financials
• Internal Processes
• Customer
• Learning and Growth

This is the core of the BS system. If a performance management model does not explicitly implement these four areas, it can’t be dubbed a BS So, from the BI professional point of view, be prepared to classify your existing KPIs in four areas, because there’s no Balanced Scorecard if no indicators are in place.

Financial indicators may be the indicators we are used to, like ROI, ROE, various margins types, the added value etc.

Internal Process indicators may or may not be of economic nature and they target how efficiently operations are performed. These indicators are well known too.

Customer indicators measure the impact of the company on the customer. Satisfaction, claims, brand knowledge; all refer to this area.

Learning and Growth encompass indicators on the quality of the people who actually operate for the company. Culture and innovation should be treated as key topics, at the same level as financials

The new point made by Kaplan and Norton is that all these areas must be equally traced and balanced if the company has to stay on the market. This is not everything, of course, but this is the key point.

 There’s much more to say about the level at which the BS may be implemented and the process behind defining a sensible BS and aligning it with company strategy; but it will be the subject of another post.

Stay Tuned!

As work is progressing, here is a little anticipation of Viney@rd next version.

This video explains how to create a dimension (i.e. a reference table) in Viney@rd.

Key Performance Indicators. We have already discussed them but let’s recall that a KPI is a metric (i.e. a measure sampled in time) which targets have been set for.

Maybe the most common of KPIs is the income/target ratio, good when greater than one.

In a coherent Performance Management System, there are tenths, or hundreds, of indicators like that, tied to targets and objectives, but each one is a single indicator, a single number.

Why? I mean, why a single number?

The question might appear weird to the people who do not have a scientific background, but it’s more than legitimate.

Mathematical models are designed to make forecasts; the best known example is weather forecasts that produce maps like this. The actual output s more complex but is always drawn in map format; otherwise the computer generated numbers sequence would be non-human readable.

Why business models like Performance Management Systems are made of, comparatively, much fewer numbers?

It might seem rather natural but the roots of this diversity can be traced in the idea of value. The human mind naturally gives a value to everything, and uses the idea of value to rank things and actions. This is a concept that lies at the roots of capitalism, and I’m not going to discuss it here (I’m not the best person to write a treatise on it). The key point is that every KPI maps to a value that, somehow, influences the economic results of a company. Actually, KPI’s are often ratios of values, to measure the performance against a goal, but, once again, it is a matter of comparing values.

The human brain instinctively judges the value of things if it is given a single number to deal with. Thus a KPI is a manner to implement this facet of human thinking.

Is this good or bad? None of the two, it simply explains why a manager is given a limited set of KPIs to be accountable for. It also explains why performance management systems can be rather simple even in a complex company. As usual, things should be as simple as possible, but not simpler.

Nonetheless, there is a subtler enemy ready to strike.

The most common company mental model is about small chunks of value, with a plus (revenue) or a minus (costs) attached. All these chunks together make the company financial statements.

This, in terms of performance management, may be deceitful as there are many inherently non-linear effects on the system. For example, dropping production efficiency below a specific level could trigger a late delivery wave that could drop customer satisfaction rates that, ultimately, jeopardize sales. So, a small chunk of missing value could potentially bring a company on the knees.

There’s a lot of exciting mathematics behind the scenes but I won’t bother you. I just use this example to state that the central point of the post: the performance management model should not be treated like a school report.  Being good in 8 out of 10 subjects is not necessarily a good performance. Relations among the indicators are as important as the indicators itself and often they’re not linear, i.e. not obvious. Every manager knows that some economic indicators are paramount, but the inner relations among all the indicators should be investigated too.

Are you confused enough? OK, I reached my target. I’ll be back on the subject in the coming future.

Have fun!

Dear Friends, Relatives, Neighbors; this short message is addressed to all the people I love or simply I know BUT to my coworkers and online friends.

You’d never ask a nutritionist to cure your aching spine even if she’s medical doctors.

You’d never ask a woodworker to sculpt a statue, even if he deals with wood.

You’d never ask a professional stuntman to repair your car, even if she knows cars.

SO

WHY YOU KEEP ASKING ME OPINIONS/CONFIGS/REPAIRS/ASSISTANCE FOR EVERYTHING THAT LOOKS VAGUELY DIGITAL?

I eagerly help you all but you must understand that “computers” is not a subject of its own; it’s like “medicine”; too a vast territory to know for a little man like I am. So ask me at your own risk. You are advised.

Cheers! :o)

Inc.com is a famous and interesting review and, few days ago they came out with this article about How to Recession-Proof your workforce. 

It suggests a few tactics that can be summarized in the “have good communications” mantra.

As usual, conventional HR misses the point entirely.

Good communications are not good hr management but they are the blood running through company veins. Good communications are a must, not a choice. Bad communications hinder productivity. They’re just a tool and have no effect on morale, save when they’re missing.

On the contrary, the most efficient morale lifter is the certainty that hard work will be rewarded. People who work long hours, on weekends and sacrifice part of their personal lives, beyond their contractual duties, to the success of the company must be sure that they’ll get a reward from that. Career opportunities are not an appropriate compensation because only few among the hard workers can be promoted, though they’re not certain. Pats in the back and appraisals are not enough, as it should be normal that good work is appraised.

There are only two compensations that actually work: money and time off. What about a company that, after cashing a lucrative contract, distributes the 5% of the income to the people who made it possible? What about a company that, after month of uninterrupted 15 hours days, pays for an additional 10 days off?

There are other things that you might want to do to lift the morale, but without the two above, your workplace will be as miserable as usual.

Enjoy.

The work for version 1.3 (at last I named it) is going on. It will be the stabler and most refined Viney@rd version ever.

Before the beta, I just drop some bits of the new features. In this case, below, you find the old and the new administrative interfaces. You will agree with me that the new interface is much more modern and elegant, even if the basic idea is nothing differnt. Notice the new commands for managing queries and security.

(download)

Click here to download:

viney-rd-new-administrative-interface-pntsyogfGlsoFoerAEzw.zip (658 KB)

I invite you all to join the beta testing gang. Please subscribe below or e-mail me at vineyard@straysoft.com. 

I'm back from a long week in the middle of Austrian Alps.  You'll hear soon news about Viney@rd, but, in the meanwhile ...

In all my years as an IT person before and as a business, but technology oriented, consultant after, I always asked myself a question.

 Why a manager is required to know some business fundamentals and share a common business language but is not required to know anything about how IT systems work? Managers are required to know things like budget, finance, corporate goverance but no IT? Why? IT is increasingly pivotal in any business area, so, what are they waiting for?

Personally, I were satisfied if a manager only knew enough on how to manage the business side of an IT project. But, often, they don’t.

 This sort of knowledge is overlooked in most business schools. When is not overlooked, it is covered very superficially.

Why a manager can understand that production lines may fail, sometimes, and some outages cannot be avoided and it’s no man’s fault, but they can’t believe that computers do fail as well and it’s not the ITs who are playing Assassin’s Creed in place of working?
Why managers understand that a new product must be carefully thought out but they do not understand that building a new IT system is pretty much the same?
Why managers realize that, under the hood of production, research and logistics, there are a lot of complex processes that they don’t know thoroughly, but think that the IT must only keep e-mail and blackberries working?
Why managers realize that company standards and internal regulations are a necessity while they do not understand that a full erp client can’t run on an iPhone?

 I could go on for hours, but I think I made my point.

The new generation of digital natives is just going to worsen the issue. They are used to work in a pervasive environment where information is at hand. Probably the discovery that the solution is not a few clicks away will strike them much more than the previous generation.

Actually I see no solution, this is just another reason why aligning IT and business is never an easy process. At the end of the day, there’s no choice: the IT must take the burden to make IT understood and accepted. It is sad, but often true.

What do you think of this?