Software sellers need to consider training as much as the software itself.

Selling software as a service is a growing business model as software seller’s move from one off license sales to ongoing revenue through pay for use. In this so called “Software as a  Service  (SAAS) model”  customers pay per month for the use of the software generating a stream of potential ongoing income. The end result is a business with a forecasted revenue stream. This makes a software company more attractive valuable to potential buyers.

This model is great if you can ensure your customers spend as much in successive months of “pay for use” than they would have done on paying up front for a perpetual license. There is therefore a breakeven point that at minimum must be achieved to make the model fly.

The whole marketing effort in a SAAS model is about a two way approach, firstly to on-board as many new users as possible and then to keep the ones you have so that they continue to supply revenue. The rate of loss and replacement of clients is called “churn” and the aim is to lower the churn percentage as much as the vendor can.

When people buy software they often use it for a project and then often put it to one side for a while – this is the weakness of the SAAS approach as a cancelled direct debit or credit card payment is not what the vendor wants. It is in the interest of the vendor to help the user to identifying projects that the software can help add value to. More value means ongoing use and ongoing SAAS payments.

Marketing material with ideas to stimulate people to use a software product is vital. Many companies do this well and that’s because they have realised the importance of encouraging use because use means ongoing monthly subscriptions. However, others see the provision of advice as a revenue opportunity in itself. In the B2B market “Professional Services” are often sold at consulting day rates and the business model is specifically around the professional advice revenue stream, or a mix of licensing revenues: maintenance and professional services. 

There is obviously a bit of a conflict here and balance between consulting revenue and maintaining low churn rates within a SAAS model is required. If the business model is poorly thought through then disaster awaits!

Training in the product needs to be addressed too. If you sign up for a SAAS product and you have difficulty in getting it to do what you want, then there is a very high chance of you stopping to use it. The benefit of SAAS as sign up and try from a customer perspective can be seen as attractive but conversely a disappointed frustrated client is a rapidly lost customer. When getting the customer on board costs more than the first six months of revenue then there is a problem.

Some companies report a direct correlation between training uptake and the degree of churn. People trained to use applications get: less frustrated with them, generate value quickly and advocate the use of the product to colleagues and others.  

The question here then is “should training be a revenue stream at all?” or should it be provided at cost because its value is achieved elsewhere in advocacy and lower churn rates – training is therefore part of the business model of SAAS retention.

One line of thinking that some vendors have is that: “we need to charge for everything we do and at professional levels of margin”. This approach is seen often when professional service teams and sales teams are targeted separately. Training is seen as revenue that has to fund itself. When opportunities to inspire, provide advice and leverage investment are held back until the customer signs an order then this has potential strategic consequences.

This behaviour is problematic enough in a license sale model, let alone a SAAS software offering. When customers who buy products and then fail to leverage them  get frustrated and stop using them. This is a lost customer and a lost cause. They tell everyone they know how rubbish the product was and how they couldn’t get on with it. A disaffected user damages your brand.  Keeping a customer using the product and generating value month on month is essential.

If a vendor tries to make consulting type rates out of training their product are they dooming their future revenue stream? When you consider the high sales and marketing costs to on-board a software user in the first place, then a strategy of maximising revenue from training services can’t be a good business strategy, so what do you do?

What is needed is cost effective user content that stimulates use and cost effective training. The two together create delight in the use of the product with the user telling everyone about it. E-learning plays a role here as we can apply the build once and use many times idea This tactic brings down the individual cost of training delivery and creates a good return on investment ROI where the benefit is seen in reduced churn and creating productive supportive clients who go on to rent month after month.

With e- learning scenario based modules that solve real business problems and show how the software can be used to deliver those solutions in a step by step practical way, then we end up with users who use software more and more productively; if they are productive and see ongoing value then they will continue to provide revenue. 

Check out www.e-confident.co.uk for e-learning solutions.

Using Levels in Business Architecture

One of the most frequently asked questions on business modelling is how many levels and what should be modelled at each level. The Zachman framework gives us some basic clues on this suggesting that the higher levels should be conceptual and the lower levels physical detail. This good indicative concept sets the scene but no more.

I wish the answer had a a simple framework reply as so many students of business architecture expect "painting by numbers" templates and it takes some level of experience of delivering architecture to realise why this is not possible. I find myself replying with the dreaded phrase " It depends"! The reason is that levels relate to the output and motivation for that output and one size doesn't fit all.

Zachman gives us a clue on the rows and that is where the stakeholder audience sits to the left in many depictions. Each and every level should relate to a stakeholder alignment, in that the model at the chosen level should provide information on the relationships appropriate to the stakeholders needs. This is because business architecture is about communication and its artifacts respond to a demand for clarity and information. The "it depends" then relates to the reason for the model and the stakeholders involved.

The first stage in determining levels therefore needs to be a stakeholder analysis with the stakeholders and the communication messages defined first; this should give some indication of the nature of the levels and the number required, This also stop wasteful modelling of either items that don't add to the needs of recipient which clouds clarity, or modelling of detail for modelling detail sake i.e. stop drilling.

Further issues around modelling layer choice are about the size of the diagram and item consistency. You need levels to keep the size sensible and if having more levels allows further stakeholder segmentation of the information then that is good too. The final issue for this post is that items have to be a the same level of importance in that grouping say " Perform Strategy Planning" with " Create invoice" would be ridiculous albeit that is an extreme example but it does illustrate the point. So, if you have items of obviously different levels then you need extra levels. People get really hung up about levels but it is just common sense.

Process or Outcomes?

Having worked a fair bit in the business process management world I have myself, and have certainly worked with others, who get a bit obsessed with process. Process is important, no doubt, in many organisations, but is it ubiquitously necessary?

Many operations just do what they with everyone doing it differently; this is particularly in where applying professional knowledge is key rather than following a step by step workflow. In step by step workflow process management stands out as being the "best practice " way and in particular in businesses whose strategy is differentiation by cost leadership.

Your average process person will say " every operation has a process" if that operation replies by saying "well it depends" the conversation usually continues to the point where the parties get fed up with each other and any improvement opportunity has gone out of the window as a consequence of the conversation.

Process centric thinking permeates modelling too, and certain vendors can't again get their heads around modelling using any other hub other than process as a modelling approach which is really frustrating to business architects who like flexibility in their choice of modelling approach.

Actually, what is equally important as process is outcomes and there are many compliance regimes that are now outcome based rather than process based, because the previous focus on process delivered good process, but poor outcomes.

What today is growing is the concept of case management which groups together a web of connected activities rather than a straight line process flow. case management reflects particularly well in an application of human skill deploying professional knowledge to a case or event.

Process has its place but the outcomes are what is really important and this is why some are arguing "business process management is dead" I think this is a bit extreme to be honest but I can see where it is coming from.

Strategy to Execution Business Architecture +

I have been leading business architecture courses now since 2008 and in  the main this  delivery has been around the development of target operating models. This has stemmed from a demand from senior business analysts to move into the business architecture space which is in essence internal business consulting.

However this year there seems to be a demand for learning about the end to end process of developing an strategy, creating the architecture and then deploying the transformation.

Strategy, Business Architecture and Project and Programme Management.

Historically the approach was to specialise and train in each of these three disciplines but the need is now to join them up in an end to end transformation process. I suppose this was symptomatic of why transformation was potentially so troubled because it was siloed. Some of the siloed thinking and methods deployed such as Prince 2 may have let us down here; best practice was more of "common" practice than "best".

With much more focus on benefits realisation, due to effectively overstated business cases, the setting of strategic objectives and providing traceability of those objectives through to delivery and beyond is in focus.

This presents a learning and development challenge as this end to end approach to transformation cuts across skill sets and departments however this is a challenge well worth taking up as the results are potentially seismic.

Organisational Charts Problematic?

In some companies, ask a manager what their department does and instead of a capability model or a process model out pops the org. chart out on to to the desk. It represents to them a statement of their power and influence and the political pecking order.

The organisational chart is what a lot of people think organisational design is about. It is thought by some to be a key artifact in enterprise and business architecture. I think it has its place but probably as the last thing you do prior to implementation of transformation; certainly not the first.

Why do I feel so strongly about organisational charts?

• They often perpetuates the "AS IS" by not disconnecting today and today's politics by inhibiting the lifting of thinking up into conceptual models.

• Thinking devoid of current players and organisational structures helps to identify root definitions, prior to evaluating the needs of tomorrow and then designing the new physical model with its new organisation fit for new strategies/ goals supporting by the redefined capabilities  and business services to satisfy the new customer experience.

• If you focus on the org chart in designing the future accountability and control will be divided out based on current personalities and their influence, not on what should logically be wrapped in a functional container. 

Many organisational designs seem illogical until you realise they represented the growth in a personalities power and the "land grab" in the past as they climbed up the corporate ladder.

Leave a "TO BE" organisational chart as late as possible in my view, as it constrains thinking.

Autocratic Leaders and the effect on culture innovation and growth.

From pricing of offers to clients, to the cost of  coffee cups, to paper clips: "I can't say yes to that I need to ask the MD." - when this is said on nearly every issue  then an organisation has a potential problem.

When that controlling behaviour is at the centre of the company than what does it mean.

Kurt Lewin describes autocratic leadership style as one of the three types of leaders he uses the word authoritarian as opposed to autocratic but the meaning is the same. It means that decision making is centralised and control is the "name of the game".

On a positive note you definitely have control - there is no doubt about it with accountability remaining centralised and clear. In times of financial hardship, where watching the pennies and keeping the big picture in one head is required then it might be justifiable.

In an organisation that cries out for innovation, agileness and empowerment then an autocratic style becomes a disaster. The culture of non delegation, the fear of making decisions without the say so of the leader suppresses "get up and go", saps the environment of energy and disengages staff. With higher paid knowledge workers the higher levels of Maslow's hierarchy of needs get erased by the leaders behaviour and the employee gets "hacked off" fast and leaves.

In an organisation that is based on a cost leadership strategy it may well have its place, but in a model that thrives or needs to thrive, on invention and differentiates through doing things differently then life is going to be tough. In fact there is a high chance of terminal failure.

One of the key problem with this issue is that often autocratic leaders grow within businesses that were once small and have grown up and out from the one man bad SME world. Often the leader that was needed at set up isn't the leader when things get a bit bigger, more complex  and the skills required are at a different level. Of course large businesses have autocratic leaders too but you do see this so much in family or small businesses that have outgrown their origins,

In a history book "The Rules of the Game" by Andrew Gordon he describes the flamboyant independent leaders of the 1805 British Navy where ships captains had to innovate and think on their feet because communication between vessels and command was impossible. He contrasts this to the 1916 British Navy at Jutland when central autocratic control had in his view emasculated the innovated and independence of junior leaders resulting in a battle of indeterminate results and attrition, where even today, scholars debate who won. I like this different way of looking at leadership and often we can learn much from different areas of study. http://www.amazon.co.uk/The-Rules-Game-Jutland-British/dp/0719561310

The message from this post is that leadership types or styles need to be appropriate to the business you are in and the *generic strategy you choose.

* Generic Strategy   "Competitive Advantage: Creating and Sustaining Superior Performance." Michael Porter in 1985

More on who is the customer in the business model and how confusion can lead to big problems.

I became re-acquainted with the "who is our customer dilemma"  in two instances in recent times.

Firstly in a government institution who provide a facility to members of the public, but the facility was a requirement based on  legislation not on consumer need. Secondly in a financial services company selling its products through intermediary parties.

The stakeholder tension and confusion in both organisations creates complexity in applying normal models and tools. The proposition dilemmas of either, a proposition to an end user but where revenue is generated by a different stakeholder who perceives value differently as in the case of the government example, or where a complex and cultural commitment to selling a proposition to a third party introducer like an IFA both make using tools like the business model canvas much harder.

Of course the important problem is not tool or technique related but the confusion and communication issues that arise as a consequence within the organisation itself. In the case of financial services potential regulatory conflict. What is good for the IFA may not of course be good for the consumer and this tension between stakeholder conflicts is a difficult thing to manage.

I spent a lot of my early career in asset finance where we sold  finance through the manufacturers of equipment - vendor finance. The perennial problem was that the dealers wanted: low rates, everyone accepted for credit and for the finance company to fall on the side of the seller in disputes. In the industry, over a period of time, this inevitably resulted in "tears"; with finance companies lending incorrectly, some going to the wall on occasions, and incidents of mis-selling by finance companies, manufactures and their dealer networks. This was all created by a poor understanding of who is the customer? the dealer, manufacturer or the the borrower (lessee). The business model was not clear and not communicated correctly into daily operations; the culture and messaging was poor with staff behaviours affected as a consequence.

How can business architecture help this?

We need to use views that clearly explain the roles of stakeholder and define the propositions that are aimed at particular customers or stakeholder groups with clear linkage that shows how intermediary partners fit into the flow of value. We need to show who creates the value and how the value is enabled though partner engagement and partner management. These double facing approaches can be applied through  popular techniques with a bit of thought and adaption, so don't just dismiss an approach because it seems to only to fit a B2C simple business model. Create clear business models to communicate to all staff what your business is about and how the relationships fit together to make your business what it is.

If you want to hear more and learn how to do this properly through our learning offerings contact us via  mail@deversolutions.co.uk

The Constraints of EA and Biz Arc Tools

Having spent some time working with a tool vendor over the last year I have come to the conclusion that tools for creating the models in business architecture are a double edged sword.

Clearly the ability to create relationships between business components and then present views appropriate to stakeholders is good, particularly when the meta-model as it always is, is complex and multi-dimensional. However, tools are prescriptive. Tools may or may not support particular methodologies; often they support one or two as the vendor has to pay royalties to the owner of the methodology which pushes up the development cost and ultimately the cost to the purchaser. Some methods like TOGAF are aligned to I.T. architecture and are weaker on the business front and therefore the tool mimics the weaknesses.

Other tools come from a perspective bias like process centric modelling where process sits in the middle and everything connects to it. Process centric tools are designed with keeping a library of processes for the operation controlling and presenting those to business users. In more advanced business process tools other business components are mapped to the process with the process being the hub. This is all fine if the objective is operations mapping and control but what if it isn't?

The trouble with tools is that your thinking gets constrained by what the software tool was designed to model. Invariably most tools are built by I.T systems people to model hard components close to systems requirements. Marketing biased items and HR biased items are invariably absent. Try modelling customer segments, propositions, channels, skills and learning development to link to the more traditional items and then the issues start to appear.

Some tools are just so complicated it takes a week or so of training to get going and then explaining what is going on to business stakeholders becomes a nightmare. In many organisation the purchase and adherence to a tool becomes more important than anything else, architects focus on their tool and the tool becomes the role not the architecture. Adding on to this the serious price per seat for many high end tools means they sit in I.T. hidden away in an ivory tower whilst business architecture needs to be a the "coal face".

I like multidimensional modelling tools but I have learnt not to become obsessed by them.