Maersk Line – the world‟s largest ocean carrier, with over 325 offices in 125 countries -has implemented six core operational business processes using BPM technology across Global Service Centres (GSCs) and local offices, with the aim of driving standardisation of work, reducing reliance on email for process communication and collaboration, and improving the efficiency of very large enterprise-wide processes. In the deployed projects, efficiency improvements of 10-15% and quality improvements of around 20% have been recorded; but the BPM programme team is clear that with more work, greater improvements can be delivered.
Case study key facts
|Organisation||Maersk Line – the world’s largest ocean carrier, with over 325 offices in 125 countries. The company operates a fleet of over 600 vessels and is responsible for making around 65,000 port calls a year. It has around 25,000 employees (including seafarers) and delivered revenues of around $26 billion in 2010.|
|Current BPM goals||Implement six core operational business processes using BPM technology across Global Service Centres (GSCs) and local offices, with the aim of driving standardisation of work, reducing reliance on email for process communication and collaboration, and improving the efficiency of very large enterprise-wide processes.|
|Current approach||Maersk Line has completed the rollout of two core business processes across its GSCs and local offices, with two more implementation projects underway. Its implementation approach has been to start by focusing on co-ordinating high-level tasks between teams and offices, rather than attempting to automate processes down to a fine level of detail. This is partly by choice, and partly down to the fact that a programme to deliver an appropriate enterprise-wide IT integration infrastructure foundation was only started at the same time as the BPM programme.
The programme has trained project teams in BPMN and general technical BPM architecture principles, and it uses its BPM technology platform as a system of record for all requirements management and quality management work, as well as for process design and implementation. Based on initial learning, the programme team now insists on diverse project teams co-locating to deliver work.
|Outcome||In the deployed projects, efficiency improvements of 10-15% and quality improvements of around 20% have been recorded; but the BPM programme team is clear that with more work, greater improvements can be delivered. In 2013 the team plans to complete its implementation of six core business processes, and also move into a mode of iterative improvement on the processes already deployed, with improvement projects delivering new capabilities every 3-6 months.|
|BPM tools and suppliers used||Oracle’s BPM Suite. Education and consulting services from Avio Consulting.|
Maersk Line is the global containerised division of the A.P. Moller – Maersk Group, which first started operation in 1904. It’s now the world’s largest ocean carrier, responsible for over 600 vessels making around 65,000 port calls a year. It has around 17,000 employees working in over 325 offices in 125 countries around the world.
Maersk Line’s exploration of Business Process Management (BPM) started in 2007, following a strategic shift within the company to consolidate and centralise some core operational business processes – specifically, those relating to handling and processing documentation associated with shipments. The company created a set of Global Service Centres (GSCs) to operate these processes on behalf of the many local Maersk Line offices around the world.
However, in making this shift, the company realised that the technology estate underpinning its current operating procedures was going to be ill-suited to the new centralised environment. After the work was transitioned to Maersk Line’s GSCs, much of the necessary co-ordination of work across teams and geographies was carried out over email, and this quickly became a real burden for all concerned. With hundreds of transactions needing to be executed per shipment and 65,000 port calls being made by over 600 vessels per year, the efficiency and quality of these operational processes were crucial for Maersk Line to optimise.
There were three crucial factors that strongly influenced the way that Maersk Line started its BPM initiative, which sought to provide more structured and scalable support for these newly-centralised operations:
- The federated nature of Maersk Line’s operations (historically, individual offices would typically make their own IT investment decisions) had created a very significant degree of complexity in the company’s IT estate, with many custom-built and inflexible systems providing critical functions.
- Maersk Line had chosen to partner with a set of offshore IT services providers for all IT application development and management work; combined with the fact that responsibility for IT systems procurement was typically federated to individual offices, the consequence was that the company no central architectural oversight of IT developments and strategies performed locally in the countries.
- Since their creation the GSCs had quickly developed their own portfolio of tactical applications (based on spreadsheets, personal databases, and so on) to help GSC workers execute procedures and keep track of work progress.
Senior management within Maersk Line realised that something needed to be done to create more structure around communication and standardise the work that was being coordinated between individual offices and the GSCs. The company’s CEO and Chief Process Officer between them realised that using a BPM approach could help solve these problems.
Implementation characteristics and status
Three years after making an initial investment in what was initially AquaLogic BPM from BEA Systems (prior to BEA’s acquisition by Oracle), Maersk Line now has two core business processes in production on the platform, being used by between 500 and 1500 personnel across local offices and the GSCs. The BPM team is finalising delivery of its third and fourth core business processes for early 2012, and from that point it plans to deliver regular releases of updates to those processes every three to six months in order to deliver ongoing improvement. By the end of 2013 it aims to have six core business processes covering around 60% of its core business implemented on the platform.
The initial investment was spurred by a business application that was under severe stress and which needed urgent replacement. This provided a key selling point to senior managers; but the team leading the exploration of the potential of BPM also saw the transition to BPM approach would enable more work to be standardised and offshored – as well as reducing dependency on e-mail for communication and collaboration.
The processes being addressed in the BPM programme are characterised by a significant amount of system integration, large numbers of people needing coordination, and a strong requirement for document input and output management. The shipping business is a documentation-heavy one; in order to be able to share information effectively through the life-cycle of a shipment Maersk Line needs to be able to receive and send documents through multiple channels and formats. In parallel with the implementation of BPM, Maersk Line is implementing a global output management system. Until this is completed, document output is handled manually by workers – although document receipt and processing is now automated and delivered as part of BPM projects.
When it comes to systems integration, Maersk Line’s challenge is non-trivial. With a historically decentralised approach to IT investment and the belief that off-the-shelf systems couldn’t address its unique requirements, Maersk Line had created a large portfolio of custom-built operational systems. Over the past five years thinking has started to change and much more emphasis has begun to be placed on acquisition of commercial packaged applications; nevertheless new business processes implemented in its BPM platform have to integrate with a wide variety of custom-built systems – and this is a significant challenge.
Because of the complexity of the current systems landscape, and because until recently there’s been no overall architectural oversight of IT across Maersk Line, the BPM programme team has taken a very particular approach to implementing business processes using Oracle’s BPM suite. It’s started by modelling and implementing human aspects of workflows, and rather than focusing on implementing automated integrations with back-end systems it’s primarily providing guidance within human task implementations to guide participants to work directly with those back-end systems in the most effective way (though some limited automation opportunities have been addressed).
In other words the process applications that the team is creating start off by being purely focused on coordinating and standardising the handoffs and activities between workers. Once the human aspects of the processes are standardised and ‘bedded in’, the programme team then turns to the business of integrating human tasks with existing back-end systems through automation.
Maersk Line has a heritage of process analysis and design using Lean and Six Sigma techniques, and a significant population of trained people; a culture of process improvement has long been part of the company. BPM – as a specific technology-enabled approach to process improvement as an enabler of business transformation – is seen as strategic by Maersk Line’s CEO, who is a big champion of the BPM programme, but it’s too early to say that BPM is seen as strategic across the company today. As the outcomes of the company’s initial BPM work become more visible to a larger audience and the financial benefits get bigger, we expect there to be an opportunity for Maersk Line to develop its BPM capability as a source of strategic advantage.
A small-scale Enterprise Architecture (EA) effort was initiated within Maersk Line in 2007, but initially its remit was to help provide context to its legacy applications developed in-house, rather than to provide oversight to developments in the company’s GSCs. Since the company has started delivering BPM, Master Data Management (MDM), business intelligence and business rules-based projects in-house though, the EA team has had to take much more than an advisory role, following a steep learning curve to get the point where it can help set direction at the enterprise level.
Along the way the EA team has had to develop knowledge of key middleware technologies now being used: Oracle’s BPM technology, Informatica’s MDM technology, and IBM’s JRules Business Rules Management System (BRMS) being the three most important. At the same time the EA team has started to play a different kind of role, not only looking internally for skills and creative solutions but also working across the organisation at large in order to find the right subject matter experts for projects at hand.
Following the first implementation from the BPM programme team, in which the full complexity of integrating with Maersk Lines’ existing back-end systems was fully realised, a parallel effort has been set up to implement an enterprise-wide integration layer using SOA principles – again using Oracle’s middleware. This work has now been in place for around 18 months – it is beginning to bear fruit and is being tightly coordinated with a MDM project to deliver a ‘single source of truth’ for key business information types relating to customers, routes, cargo and so on.
Organisation and people
Maersk Line’s BPM programme team has been aided very significantly by the senior sponsorship it’s been able to secure from the company’s CEO: having the chief executive behind what the programme is doing makes business cases for individual projects and changes much easier to make. This is important because the group of business managers acting as business process owners – many of whom have historically made key technology investment decisions themselves – are determined to see tangible value for their own parts of the business. It’s also important because the company’s lack of experience with BPM technology means that hard numbers haven’t been easy to come by. By trading on the support of the CEO, and also by focusing on aligning BPM efforts with well understood strategic projects and enablers for those projects, rather than focusing on hard cash savings, the programme team has been able to make good progress in bringing the broader management community along with it on its journey.
When the first BPM project was initiated, the programme team had no option but to work within the constraints in place – that is, little experience of agile or iterative development (in historical offshore development arrangement, a very traditional waterfall style requirements management approach had prevailed), and little in the way of standardised integration infrastructure. This meant that even though the programme team knew that BPM technology they were using could enable an open, collaborative and iterative style of working they were unable to progress in that way initially.
However, at the same time as kicking off SOA and MDM projects to improve the integration infrastructure situation, the programme team has also re-jigged its solution development approach. Whereas initially it followed waterfall style development model, now it’s pursuing a highly collaborative and iterative model – and importantly, it’s enforcing co-location of cross-functional teams for each project that takes place.
Each project team comprises ten to fifteen people, of whom six to eight come from the business and the remainder come from the IT side. Business analysts, subject matter experts, business process owners, solution architects, IT coordinators and individual developers and administrators all work together in one physical location. Whereas previously requirements documentation would be written down in great detail in text form, project teams now use BPM tools to document requirements using models directly. As well as using the BPM platform to document requirements and carry out system implementation work, project teams also use the platform to manage use case definitions, test cases and user interface mock-ups.
As we’ve highlighted above, Maersk Line have had strong process analysis and design skills for some time. The skills that project teams have had to learn have been largely technical in nature – including those associated with BPMN modelling, BPM solution design and specialised requirements elicitation. Until now, process modelling and design within individual BPM projects has been facilitated and coordinated by BPM experts and process engineers with the support of business process owners and subject matter experts. Interestingly, that’s not because the business people participating in projects aren’t engaged in the work; rather, it’s because within Maersk Line, many business people are used to specifying technology implementations directly and quickly.
Those BPM specialists driving modelling work are responsible for steering business specialists away from making technology implementation decisions and assumptions too quickly, and first getting them to focus on the broader context of the issue at hand and specifically getting their process right. In other words, one of the significant challenges that the BPM programme team has, is to balance the sense of technical urgency that the business has regarding fixing issues with a longer term engineering approach to thinking about getting business processes streamlined.
The Maersk Line BPM programme team has started to implement a BPM centre of excellence (COE), bringing together a group of business analysts, lead developers, and other key IT personnel to own a methodology and governance framework that spans individual BPM projects and which is responsible for driving standards and asset reuse across those projects. The company feels it has further to go in formalising its BPM COE and putting it onto a more permanent foundation, but is keen to get more individual projects completed before it prioritises this work.
At the current stage of work within the BPM programme, the Maersk Line team hasn’t yet entered a phase where it’s driving continuous change and improvement to processes that have been implemented – this phase is just getting started and will ramp up in 2012. Therefore it’s not surprising that so far, although the team has put structures in place to help manage and prioritise change in the context of other planning cycles and structures, these haven’t been used very often.
Technology and infrastructure
To date, Maersk Line’s BPM programme has only focused on the core design and automation capabilities of the Oracle BPM platform; so far, there’s been no focus on simulation, for example. Although the team does perform analyses of operational performance within the BPM platform to diagnose work issues and uncover opportunities for improvement, it uses a SAP Business Objects implementation as infrastructure for this. Oracle Streams is used to pull operational data out of the Oracle BPM platform into an enterprise data warehouse, which is referenced by Business Objects XI.
Standards – particularly relating to integration of systems and data in support of processes managed within Oracle BPM applications through its SOA and MDM work – are absolutely crucial to Maersk Line going forward. The team is also placing a lot of emphasis on use and awareness of the BPMN standard within the company.
Prior to use of the Oracle BPM Suite, Maersk Line had used a custom-built workforce management tool to help balance workloads across teams; now, however, the team is looking at using the workforce management capabilities within the Oracle BPM Suite. This will give the GSCs much better insight into workload bottlenecks, which will help them respond to issues much more quickly.
The BPM programme team makes use of the JRules Business Rules Management (BRM) technology alongside Oracle BPM Suite to help manage complex decision rules which are subject to change and which need to be managed by business people.
With two core business processes now implemented through the Oracle BPM Suite and two more being implemented, Maersk Line has begun to see the fruit of its effort. The implementation strategy – which has favoured gradual automation of process, starting by primarily focusing on the co-ordination of high-level tasks – means that the BPM programme team feels it has much further to go in realising benefits: but at the same time, the team is confident that it has already achieved a 10-15% efficiency improvement, and a 20% quality improvement. Nevertheless, the team is still keen to work to demonstrate and quantify harder and more far-reaching benefits – in order to make champions not only of the senior company leadership team (which is behind the work in any case) but also of mid-level managers within individual offices. With the processes it’s currently working on implementing, it’s specifying processes to a finer level of detail that will deliver a much higher level of transparency, and therefore much more in the way of insight into where future improvements may be found.
After its first couple of implementation projects, the BPM programme team has worked to significantly compress its delivery timescales: whereas the first implementations followed a waterfall-style methodology and took of the order of 12 months to be completed, the projects now underway are set up to transition from the start of requirements gathering to working results within six months.
The Maersk Line BPM programme team is open about the challenges it has experienced on its BPM journey so far, many of which relate to the heritage IT investment practices at the company. However it’s worked hard to uncover the root causes of the issues it’s had (integration infrastructure technologies and architecture practice; engagement of stakeholders; and so on) and has made significant maturity gains as a result.
On top of the challenges already highlighted relating to integration infrastructure and architecture readiness, the team has been challenged to quickly and effectively analyse the existing tools and practices put in place by operational teams in the company’s Global Service Centres. In the absence of any centrally co-ordinated process improvement platform, these new GSCs built their own systems in ways that made sense to individual teams; in some cases, the complexity of the environment has made it difficult to analyse the best way to approach standardisation, simplification and improvement of processes. Rather than just replacing all existing systems with the new process management applications, the team has worked hard to discover situations where existing systems – though not perfect – enable a ‘good enough’ job to be done, therefore enabling them to prioritise improvement efforts in parts of processes that are truly ‘low-hanging fruit’.
Recommendations for BPM adopters
In carrying out this case study, we asked representatives from Maersk Line’s BPM programme team to share any recommendations they’d offer to other potential adopters of BPM. Many points were shared, but the following four points were highlighted as particularly crucial:
- No matter what the focus of your BPM project is, deliver something within 90 days or so – don’t create a project scope that will take 12-18 months to deliver on. Keeping stakeholders and team members motivated and inspired over 12-18 months is extraordinarily difficult.
- Try to ensure that business and technology resources on projects are all co-located – this will pay off in terms of time-to-delivery, the quality of the output and in creating a platform for ongoing success.
- Make sure that you have all necessary technology infrastructure in place before you start. In Maersk Line’s case the important pieces related to SOA-based integration, Master Data Management (MDM), and business rules technology. Starting BPM projects without the right technology underpinning slows down process improvement projects and breeds frustration.
- Make sure you have gemba representation on projects. Gemba roughly translates (from Japanese) to “the real place”; in Lean thinking, it refers to the place where value is created. Don’t run projects without significant representation from the teams whose work will be impacted by those projects – empower those people from those business teams to help analyse problems, suggest improvements and work to make them champions for the change you’re making.
Best practice insights
Through the ongoing implementation of its BPM work programme across its Global Service Centres and local offices, Maersk Line has demonstrated a number of best practice insights that you should think about in the context of your own implementation.
First, make a conscious decision about the implementation strategy you’ll use for your process improvement work, based on the organisational, cultural, financial and technical constraints and capabilities that exist in your environment. There’s no one right answer when it comes to implementation – for some organisations, it makes most sense to start work in a ‘broad and shallow’ way, perhaps providing automation support for only a small number of process control points but doing that for an extensive process or processes; for others it instead makes sense to go ‘narrow and deep’ – delivering much finer-grained automated support for just one or two narrowly-scoped processes, or for just one or two work teams. Maersk Line had to work within significant technology and organisational constraints, and tailored its approach accordingly.
Work hard to enlist teams of collaborators in projects from across the business-IT divide, and co-locate process design and implementation teams with broad representation to ensure that progress can be made and issues resolved quickly. As Maersk Line’s BPM programme team started to do this, they found that projects progressed much more smoothly, with the buy-in of more stakeholders.
If your target business processes are core operational processes, there’s a good chance that improving them through application of BPM is going to require significant levels of integration with existing applications and systems, across organisational and technology silos. In these situations it’s particularly important to ensure that efforts are made right from the start to engage teams responsible for integration and IT architecture. If these capabilities don’t exist in-house, you must make the case to secure investment to build them as soon as possible.