Conference over, jetlag fading, time to reflect on my takeaways from the Building Business Capabilities conference 2011.
My keywords are: Common sense, business value, processes and business rules, stakeholder participation, architecture and structure, skill development, process testing, capabilities.
Common sense
Technology plus the ever increasing number of available methodologies could be regarded as a complete or at least sufficient toolset to deal with any number of process issues companies are facing. In fact the opposite is true: Too many toys to play with distract from what should be done and only lead to confusion. Several speakers pointed out this danger and stressed the importance of applying common sense and a ‘back to the roots’ approach. The role of business analysts and process experts should not predominantly lie in developing new methods but in solving business problems and making use of opportunities.
Business value
Really the key issue of the conference and at least during the keynote sessions the most often used phrase was ‘business value’. Does what you do and how you do it create business value? How do you demonstrate added value before you implement your solutions? Many comments by business analysts indicated that this is an area they are most uncomfortable with and pointed out that their inability to reach stakeholders and management is partly due to not knowing how to communicate the business value of their proposals, i.e. making the leap from process design to a business proposition that captures the imagination of decision makers.
Processes and business rules
This is still one of the great challenges in that both fields have progressed over the last few years albeit mostly independent of each other. But when the application of rules invokes processes and processes contain rules, independence and isolation is not the order of the day. Business analysts need to get a better understanding of business rules and rules experts need to come out of hiding. If you want processes to work and deliver you need both in combination.
Stakeholder participation
This is a subject I’m currently writing a longer piece on, so I’ll keep it short here. Business analysis, process analysis and process design all need to serve a purpose or else they are reduced to meaningless fooling around with tools. The only way to provide meaning is by getting results taken up by the business and for that stakeholder involvement is critical. I witnessed a couple of discussions along the lines of ‘we need to get management to read and understand our process models’. Wrong! You as designers or analysis need to tell the business value story and ensure that the main points are covered by your design and solution. Embed them in context, provide meaning. You may well have the best intentions for your business at heart but if you’re unable to show how stakeholders and decisions makers will directly profit from your suggestions the business as a whole will never get to see what you dreamt up.
Architecture and structure
The sessions at the business architecture summit provide some good examples of how the business can benefit from structure but they also showed some of the practical difficulties: When setting out, do you create an empty structure and try to fill it later with process, data, service and information content? Or do you base your architecture on existing processes (data,….) and build it up from there? Does architecture provide a framework for a running business or should it work primarily as a guideline for projects? There are no right or wrong answers to these questions but you do need to make sure that you have a consistent approach.
Skill development
One of my pet subjects and bbccon11 has done nothing to tell me that we are anywhere close to the skill levels demanded by the issues we’re dealing with. True, proficiency in handling and using tools is at a higher level than 10 years ago and tools and methodologies have a much broader user and fan base nowadays. But being able to drive a car when you have no sense of direction is not the smart solution. Process and business awareness should be foremost on everyones mind. Train people in process thinking and not just in how use the latest user interface. Reduce the time needed to discover current processes by making people process- instead of system- aware.
Process testing
OK, so I’m biased as this was the topic of my presentation. Doesn’t make it less important though. If your processes contain errors that will prohibit implementation, IT will need to design workarounds which in turn will increase project costs which in turn will not put a smile on stakeholders faces. The same goes for processes which may work but don’t deliver. And even if they do, if stakeholders and other interested parties had a different understanding of the problem and solution at the outset, you will not have provided them with what they expected. Process quality has as much to do with delivering capabilities as with delivering to expectations. Validation may therefore be key to your success. Likewise process dynamics. At a rough guess, every second presentation mentioned ‘global markets’, ‘changing conditions’ and ‘agile ability’. Designing a business solution without validating it against a real-life dynamic environment (simulation and stress test) means that your design brings with it the risk of limited usability. Test and check before you implement was the message I tried to get across. Of course, that’s why we set up the Process TestLab in the first place.
Capabilities
This is what the conference was all about. What capabilities do companies need? (Luckily, I didn’t get to hear any general meaningless answers but often very individual, company-specific input). How do process capabilities feed into business capabilities? (Depends on what the business capabilities are and there’s that tiny problem of translating business strategy into process strategy). What skills and employee capabilities are needed? (see above).
Summary
A lot of the issues I’ve mentioned here do not require a general state of the art solution. There already are many (too many?) tools and methodologies available. The secret lies in being smart: Smart in deciding what you need and how to create a solution using what’s already available. Smart integration. Smart processes that people want to use. Smart solutions that can be managed. We already have most of what we need but it takes brains to figure out the smart combination for smart businesses.
