Tuesday, 29 March 2016

Business Analysis Front of House or Back Stage

When you go to a show you want to see the production. In fact the mystery of how things are done is part of the experience. Knowing the trade secrets often spoils the show. A stage show, or film for that matter, is about receiving the communication. 
Quite often these days a DVD or a streaming site has "how the film was made", or extra features. On Amazon Prime for example this "secrets first” is at the beginning of the list to see, if you don't watch it you can't use the next episode feature on returning because you haven't watched the spoiler - most frustrating.
The "how we did it" is about showing how clever we are in making the film and seeing it in advance to my mind spoils the communication experience. It takes away the magic and spoils the excitement.
I like to use this analogy when training analysts because what stakeholders want to hear or see is the messages and outputs not about how clever or more educated the analyst is.
Why is it then that a large proportion of time is spent selling method and notation to business stakeholders, when it is the outcome that is the interesting bit? The business stakeholder is pretty cynical about this methodology or that methodology, especially us older folks who have seen the latest panacea fall into obscurity time and time again. I’m not suggesting that the excitement and magic is the aim here or “smoke and mirrors” either. In a business sense that is going too far, but the avoiding obscurity of the clarity of the communication is not going too far.
There is a place for the back stage and a place for front of house. Keep the methodologies and lectures on notations behind the scenes.
Nobody likes a “clever clogs” who reminds a business person that they are intellectually deficient and that “we in I.T. or change know better”. As the years have gone by, many operations people have learned to ignore technical types as this cultural faux pas has embedded a sense of frustration and to be frank total dis-engagement. IDEF0 , UML, Prince2, TOGAF and many others do I need to say more?
So many times we lead with method based training and force everyone to conform and adhere to the latest mantra. “They have had the training so now they will perform; job done!” Invariably they don’t perform because it is a case of “here we go again”; last decades business process engineering becomes six sigma, then lean and now agile this and that. So, many times we lead with method based training and force everyone to conform and adhere
Outputs and outcomes are what the show is about, not trying to overtly, or even unintentionally, showing how knowledgeable or superior you are.
So, focus on the outcomes present the method driven results; if the outcomes hit the spot than the methodology can follow if really necessary.  Forget the business training on the latest approach; lead by example and produce successful outcomes then business people will ask you: “how is that done then”, that is the opportunity to provide the education. The sale has already been made.

Wednesday, 6 January 2016

Operating Models All Look The Same!

Operating Modelling
If you follow I.T based frameworks the you might think that. In reality a model serves a purpose and that purpose is more important than following a prescribed standard. Modelling languages and frameworks help give structure no doubt, but how do your stakeholders view them?

The reality is that most business people  don't have the time to get their heads around alien notation and ISO standards that so many people spend hours on linked in groups discussing and arguing about.

Stakeholders want clear messages and easy to consume material that is relevant to their needs as well as forming part of a joined  up picture - architecture!

If your organisation follows a cost leadership strategy then your operating model is likely to be process centric with lots of focus on squeezing out every "ounce" of waste and cost. The BPM vendors are all about this and some of them market excellent tools to help create such models but what if your business is different?

If your reason for existence is not about the lowest cost to provide a comoditised product; but is about innovation and differentiation a process centric operating model is hardly of interest. The processes probably change case by case, week by week  and keeping it all documented is going to be a futile waste of effort.

Operating models need to be structured to communicate the right things to the right people. So don't start with a methodology, framework or modelling tool and impose it on your colleagues. Start with stakeholders first and understand what is required.

If you want some more help in developing Operating Models then perhaps think about organising a seminar  or one to one mentoring programmes from Dever Solutions Limited
www.deversolutions.co.uk

Wednesday, 4 November 2015

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.

Tuesday, 13 October 2015

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.

Friday, 10 July 2015

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.