EA
now browsing by category
Architecture
The glue – process and architecture
We continue to see challenges when technology is utilised in silos to solve point problems across the enterprise. Its an attractive proposition to find technology that appears to solve a problem and focus on implementing it! Experience shows that this rarely delivers the supposed benefits either short or longer term because the implementation decision has been made in isolation of an overall method that can align the enterprise wide stakeholders to common, prioritised goals.
Sadly many teams of hard-working people sacrifice themselves to the implementations of these projects and then become disillusioned and demoralised when the results are not as expected.
What is the answer? Of course books have been written to discuss this question but a holistic methodology could be broken down into a series of steps:
1) Determine the enterprise core mission, such as selling goods to consumers or producing components for car manufacturers
2) Document at a high level the processes that have to be in place to carry out the core mission. At some level this revolves around Plan, Buy, Move, Sell
3) Assess the enterprise competencies for these core processes and determine if and where improvements should be made. This is executive level decision-making which naturally includes a level of prioritisation that becomes a shared vision. The expected benefits of these improvements should be built into the business plan
4) Architect a roadmap for the improvements. This has to consider capacity, capability, more process detail, change management and organisational implications as well as availability of capital investment.
5) Align the current technology and data state with the roadmap and identify particularly the application level changes that may be required. This level is still considering the enterprise as a whole and so cross functional opportunities and implications should be uncovered
6) Looking at the process, application and data roadmap the infrastructure can now be considered. Here we can identify how much change can be supported and what kind of infrastructure solutions are appropriate including cloud solutions
7) Organise the roadmap and its associated information into programmes and projects keeping a strong focus on how these contribute to the benefits expected in step 3
8) Focus on delivery of the planned projects including managing the wide range of stakeholders and regular reporting of progress against the agreed roadmap and priorities
9) Hand off completed projects into business as usual teams ensuring that tools the enterprise uses to record organisation, process, benefits tracking and delivery performance are updated
10) Never expect the enterprise to stand still! Real world internal and external factors can cause in-flight changes to many of the steps above for both positive and negative reasons. Prepare stakeholders for this, expect change and have management tools in place to accept, identify and facilitate corrections. Keeping this expectation and agility is key to remaining competitive as customer expectations increase and strategic cycle times shorten.
More details and opinion on the points above will follow in future blog posts……
Architecture
Business Process Modelling – Goals
Before we can determine pros and cons of the various BPM languages that we identified in the first post in this series, we need to understand why we might want to do modelling at all. At the Gartner Enterprise Architecture Summit 2013 it’s been interesting to hear from BPM practitioners of why they have embarked on a process modelling initiative. Two examples stand out
- A major UK banking organisation has built and is managing a huge library of process models which serve thousands of internal stakeholders. Their first goal is for training which means the models are intentionally kept simple, very limited shapes and colours and generally 1 process per role. Their second goal is to comply with regulatory requirements which mandate version controlled process documentation that can be audited by financial authorities.
- Second we have seen how process modelling can be used as part of an Enterprise Architecture that links business outcomes to capabilities which in turn are delivered through processes using applications on technical infrastructure! The process model acts as the glue in this scenario that shows how systems and infrastructure relate to business goals which is a powerful way to frame communication about the impact of changes or investments.
We also saw a keynote presentation from neuroscientist Beau Lotto which amongst a discussion on reality versus perception proposed that process management is useful as part of efficiency, which in nature is good in the short term, but is triumphed by agility when dealing with change. Interesting food for thought!
Architecture
Business Process Modelling
We are currently researching the area of business process modelling (BPM) with a view to forming an opinion on how the various modelling notations and techniques can be used effectively in a small or medium-sized business context. We are also on the lookout for any accelerators or standards that apply to the retail industry such as the maps developed here by the Association of Retail Technology Standards (ARTS).
We’ve seen BPM initiatives struggle to gain traction and over time fall further down the priority list until they stagnate. Reasons for this are complex but include lack of understanding on the value of a business process model, unclear goals for what to do with a model, missing context to a model and wrong choice of modelling notation for the desired outcome.
Delving into this topic further necessitates a wider understanding and definition of key pieces of the jigsaw. On the list are:
- Enterprise Architecture which may be a useful starting point in giving context to the overall strategy, goals and layers that make up the business. This discipline has its own modelling language ArchiMate
- IDEF0 which we have used at the beginning of BPM activities to provide a scope and boundary for BPM. However the high level of abstraction from time and process logic in this technique can make it hard for functional experts to untilise
- Modelling notations including Event Driven Process Chains (EPC), Business Process Model and Notation (BPMN) and Unified Modelling Language (UML)
Our research is not focused on the tools which implement BPM as first we need to have an opinion on the value and use of the techniques! However we will comment in a later posting on some of the tools we use and our perceived strengths and weaknesses of these.
If you have experience using BPM in small or medium-sized business and particularly in the retail sector then please share your thoughts by commenting on this post!
D5 Creation