Traditionally, when a business wanted to automate a process, it would turn to the IT department, which would work on a formal specification.
Once the specification had been signed off, IT would go away for a period of months to develop some software, which would then be delivered to the business. Job done. But not quite.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Projects delivered in this way often fail to match business expectations. Why? Because the business does not stand still while IT develops the software it requires. There is also the risk of scope creep: a project that followed a neat formal specification on day one can quickly become an amorphous mess if extra functionality is added without the due diligence that took place at the project¹s inception. Going agile has been IT's answer. And there are many successful projects that are run in an agile way, where the business and IT work much more closely together, and the software development cycle comprises short, iterative steps. But agile methodologies fall very much under IT's control.
Business process automation (BPA) represents a different approach to developing software, in which much of the upfront work is undertaken by the business, rather than IT. Neil Ward-Dutton, research director at analyst firm MDW, says people typically do BPA because they realise their IT systems are not aligned to the way the business gets work done. "They may have siloed IT that does bits of business process, but no common way for people to engage totally, so people send internal memos, email and spreadsheets," he says. There's loads of rekeying, latency, and work gets redone. "Turnaround time and delivery times are getting faster, but companies realise they are very inefficient because there is no clean flow of work. Often there isn't a system in place that maintains a memory," says Ward-Dutton. "The customer goes on a journey and you need to support them, so systems need to be designed this way, with a thread tying the customer journey together."
Making business process automation work
- Business process automation (BPA) is not just about application development. It is about improving a process, so you need to understand the work you are trying to do.
- BPA is almost a paradigm shift in how applications are developed
- Make sure the business accepts the overhead involved, because people across the business need to collaborate
- The business and IT must be prepared to working differently
- Not every company can take advantage of BPA . There will be some that are stuck in old ways for developing applications
However, traditional enterprise IT that has been developed over time is not capable of maintaining such a memory of the customer. Ward-Dutton adds: "Instead, we have siloed systems, designed for very specific people, and they are very transactional. They are big buckets for information."
What is missing from traditional enterprise systems, according to Ward-Dutton, is a way to co-ordinate work so it gets done in a consistent fashion. "Knowledge share is the missing layer [in traditional enterprise IT], he says. BPA co-ordinates work and enables sharing of knowledge." For instance, in retail or the service industries, where the least-well-paid people are facing the customer, BPA can be used to make sure they have the support they need to get the job done, says Ward-Dutton.
Carphone Warehouse has been using Tibco since 2005 to support its business process for signing up customers to new mobile phone contracts. David Byrne, CIO of Carphone Warehouse, says: "Once we understand the business process, we get real business value." Using instrumentation, he says, Carphone Warehouse can see where customers turn away in the sales cycle. "It is very important for us to see the route they have taken, so we can understand performance of staff in-store and can see if the process is being followed and whether the process can be improved."
The architecture Carphone Warehouse has developed is now being used to power its Connected World subsidiary, says Byrne: "We recognise many of the services within our business can be transferred to other businesses, but much of the know-how is difficult for other businesses to acquire." In retail, for instance, selling devices with mobile connections has a steep learning curve, he says. Connected World provides software as a service (SaaS), which offers system-to-system business process automation to enable retailers to buy network connectivity for mobile devices.
Rather than attempt a big bang rollout, Carphone Warehouse used Tibco for back-end integration, allowing it to modernise enterprise applications as and when there was a business need. "We decided to extract business functionality when there was a need by the business to carve out monolithic code [from the legacy applications] and make them available to other applications," says Byrne. Carphone Warehouse uses service-oriented architecture (SOA), a service registry and lifecycle governance for SOA services. New applications are built using a componentisation architecture, where developers reuse services published in the service registry.
You need to bring in input from management, which requires a different mindset from business
Teresa Jones, Gartner
From an IT perspective, Byrne says the architecture has simplified licensing, improved code quality and has allowed Carphone Warehouse to benefit from the R&D that Tibco puts into its industry-proven platform. Also, Byrne has been able to move offshore software development to another supplier relatively easily. "It has been much easier to communicate what our applications do so the incoming [outsourcer] organisation can come on board quicker," he says.
Byrne says the architecture enables Carphone Warehouse to locate components of its IT systems in different parts of the world, based on business requirements. "We can run common services that require a high level of security in our own datacentre, but other components can be run in the cloud," he says.
Gartner analyst Teresa Jones says: "Previously, business process automation tools were deployed to automate manual work, such as opening a bank account. But now, organisations are using such tools to differentiate." For instance, it may be possible to use a mobile device to change the business process, allowing the business to operate more efficiently, says Jones. Gartner describes this as the 'business moment', and Jones adds: "To do something cool and different, you need a platform that is very quick and be able to reuse what you have in a well-controlled manner." The challenge for IT departments is that BPA is not the same as software development in the traditional sense, says Jones. "You need to bring in input from management, which requires a different mindset from business."
More articles on business process automation
It is about getting crowd-sourced business process ideas, and this is not the way IT functionality is developed in many organisations. The most common way is to get the requirements, code in a traditional environment, test, then go live, says Jones. But in BPA, everyone uses the same tool.
Business people need to interact with a visual metaphor to see the business process, while developers need to take the layers of the supplier¹s platform and do the development work. The experts Computer Weekly spoke to agree that BPA requires a change in mindset. Ward-Dutton says: "A process automation tool is not general-purpose, but for domains like workflow, it gives you a huge amount of stuff out of the box. So there is significantly less work to do than when you use .Net or Java perhaps 30-40% less work." But he warns that not all organisations will find it possible to use BPA. MWD has developed a business process maturity tool to help organisations measure their readiness, he says. It is difficult to automate everything, but as Byrne at Carphone Warehouse has shown, a big bang approach is not necessary. Processes can be automated over time, and new services can replace legacy code as and when the functionality needs updating.