Latest blog described the many aspects, including critical success factors for successful process implementation. This blog focuses on the business process implementation technologies which enable to swiftly and sustainably implement the processes you (re)designed.
Maybe more important: it gives you recommendations – or at least some direction – on when to use which technology.
1. Organisation wide COTS software
What is enterprise or organisation wide COTS software?
These are so called Commerial Off-The-Shelf software packages like
- ERP or Enterprise Resource Planning, e.g. SAP, Microsoft dynamics AX or NAV, open source ERP like Odoo or Compiere, etc.
- CRM or Customer Relationship Management, e.g. Salesforce, Siebel (which was acquired by Oracle), open source CRM, etc.
- SCM or Supply Chain Management software
- MES or Manufacturing Execution System software, e.g. BrightEye, Siemens, Apriso, etc.
And others, which may either be a part of a larger business software suite, or being niche software for a specific (sub)functional domain.
Characteristics of enterprise wide COTS
Typical for those applications is that they are “off-the-shelf”, meaning that – at least in theory – you do not have to develop the software, but rather to “integrate” it in your organisation.
In reality, there is most often some development needed on top of the standard software so to cover your specific business needs.
Dependence on software consultants
These applications are so complex that you need to rely on specific software consultants, who have acquired the (software) expertise to implement them. Like SAP-consultants or Dynamics AX / NAV consultants, etc.
The first ERP software packages became quickly very popular thanks to their cross-functional nature. A sales order (e.g. from a sales department) was streamlined to planning, manufacturing or warehouse colleagues, etc.
Most probably the reason why ERP was a typical enabler – or even driver – for process-redesign during the last decade(s) of previous century.
Another big advantage, is that nearly all the processes – at least those covered by the application – were using one an the same database, forcing people from several departments to use the same, unique data and a common business language.
However, this “monolithic” characteristic also has some drawbacks, as you will read further.
Modules – a risk for functional silos
Unfortunately, what I also experienced, is that this kind of software might yet create functional silos. Consultants are often specialised in parts of the software – called modules and often associated with functional domains, e.g. finance, purchase, manufacturing, etc. A consultant can hardly know all the modules, so ignoring the capabilities of other modules. Which can be an obstacle for end-to-end business processes.
Advice for an agile, process-driven implementation
In 2011, I wrote a Master thesis on how to implement such organisation wide software the Agile way. The basic principle is to implement it process by process – considering business processes as “sprints” – instead of pure functional implementations, i.e. module by module. This obviously requires multi-disciplinary (teams of) consultants instead of module-specialists (alone).
When to implement enterprise wide COTS software?
Given their nature, it seems obvious that such broad spectrum applications are valuable when you identified the need to improve most of your business processes. More particularly when your information systems landscape seems very fragmented, creating silos that clearly disable well-streaming business processes.
A typical example is when your organisation grew quite well, though internal processes are not very efficient because you need to encode the same data twice or even more times. E.g. entering order data in a sales order management application, and again in a (detached) invoicing and accounting software ; and once again in a planning tool.
2. Process Engines or BPMS software
I have very often heard criticism about organisation wide COTS software. Not only because these used to be big implementation projects, too often failing in being delivered on time, within budget or even including many shortcomings according to their initial scope.
Also with regards to the uniqueness of organisations, this kind of software can be limiting. Indeed, to be – and stay – competitive, any organisation should be unique – by strategic focus. However, how does ‘common’ (COTS) software – which has been implemented with your competitors as well – rhyme with the uniqueness principle? Can you still differentiate from your competitors, using the same software that supports the processes nearly the same way?
This is where process engines or BPMS may help…
What are ‘Process Engines’ or BPMS?
Process Engines, or Business Process Management Systems (BPMS), are frameworks which enable the execution and monitoring of processes “as designed”. Indeed, thanks to BPMN 2.0 – nowadays the de facto standard in process modeling -, one can generate an executable business process from a (valid) BPMN process model using such a process engine.
How do Process Engines work?
Depending on the Process Engine you use, these are the steps you usually take to design and implement a process:
- Design the process – for most modern engines, this will be in BPMN 2.0
- Define the data (model) for the process you design. This includes data exchange between the process and other data sources the process will interact with, e.g. an ERP, CRM or whatever database already in place.
- Design the (user) interface through which process actors will operate.
- Determine the business rules within the process.
- Assign tasks of the process to resources – i.e. the performers or process actors like defined by the (swim) lanes in your BPMN diagram.
- Optionally, integrate the process with other applications – e.g. an existing ERP or whatever software which is already in place.
Although this video is from 1 specific BPMS-vendor, it clearly illustrates what the process engine does and what steps you need to take from design to execution – or even to monitoring. Particularly from time 1:10, you can watch the steps to design and to implement a business process.
An example – typical use case for a Process Engine
A (midsize) company just implemented an ERP and a CRM software. However, the quotation process for dedicated services was very specific and contained many – and moreover challenging – business rules. Developing this logic in the CRM software would have been not only very expensive ; the dependency on the CRM-integrator would have been paralysing the services company when it needed to adapt rules or any logic.
Designing and implementing the process through such a process engine allowed us to implement relatively fast, but also to keep a high degree of flexibility. Indeed, only the exchange of some data somehow created a dependency – say a relation – with the CRM. Though the entire process and its logic were independent from the CRM, so enabling easy changes to tasks, user interfaces, business rules, actors, etc.
Moreover, the process owner could very effectively manage the process thanks to an easy process monitoring, as all process data – e.g. event logs – were obtained from one and the same data source (the one of the process engine).
Though this list is not exhaustive (and hard to keep up-to-date), it may help to speed up your search : Activiti, AgilePoint, Appian, Bizagi, Bizflow, Camunda, Kissflow, Kofax, Newgen, PNM soft, Signavio,…
Mind also that next to these niche players, large vendors like ERP-vendors – e.g. SAP, Oracle, etc. – , also often offer a Process Engine in their software assortment.
3. RPA – Robotic Process Automation
What is RPA?
Robotic Process Automation software are tools which operate on the user interface of other computer systems, so to automate repetitive, simple tasks previously carried out by users. With the increasing AI (Artificial Intelligence) & ML (Machine Learning) capabilities, RPA might also deal with more complex tasks.
RPA is characterized as “outside in” approach of automation, because you do neither change, nor improve the “inside”, i.e. the existing information systems which contain the business logic, business rules, the data, etc. Hence, thanks to RPA you rather increase the efficiency by automating tasks which were previously – time consuming – user tasks. And people who were used to carry out these user tasks are often happy to get rid of boring work.
Benefits of RPA
- Improving value creation : by automating repetitive tasks, you can reassign your employees to more value adding tasks.
- Higher employee satisfaction : thanks to these more value adding tasks, capable employees will be more motivated, given the higher meaning of their work.
- RPA projects are usually lower risk projects than for example ERP projects, as it works more “on the surface”. Basically, it does not (necessarily) change the business logic.
- Improved data quality : among other less data (entry) errors. Particularly cause RPA is very appropriate for repetitive tasks, where humans tempt to lose attention after a while.
- Faster & more reliable service : unlike humans, (ro)bots can work 24/7 and usually do not get sick.
How does RPA work?
RPA tools operate by mapping a process in the RPA tool language, which the software robot then will execute as defined. In fact, RPA mimics human activities which are rather repetitive and programmable. So, mind that – as for process engines – you will need to map processes before RPA will be able to help you…
Some typical RPA value cases (examples)
Customer order processing
Imagine that you have an ERP software for managing customer orders, though it is – for whatever reason, e.g. for security reasons – not integrated with your webshop that generates customer orders. These orders are thus encoded manually in the ERP application by a user ; a little enviable user task. This may rather easily be automated through RPA software, instead of manually re-encoding the data.
Grouping data from several applications
Assume that your call center – or your internal sales people – must gather information about one and the same customer from several systems : sales orders from your ERP, correspondence (e.g. e-mails) from your mail application, unstructured data from your document management system, etc.
RPA could help you to view all relevant data from these different sources in one screen. It could also help to scrape websites with important information about this customer.
On this page you can find other typical examples (cases) for which RPA may help you.
Again, this is certainly not an exhaustive list, though it may simplify your selection journey : Automation anywhere, Blueprism, Kofax, Pega, Redwood software, UiPath, Verint, etc.
Conclusion – when to use which technology?
Before deciding which of the business process implementation technologies described above, you better consider following aspects:
Degree of business (process) innovation & process redesign
If you need to review quite in-depth many of your business processes, e.g. due to a new – or even disruptive – business model, then there is a greater chance that ERP (like) software will be helpful. Obviously after a thorough redesign of many – if not most – of your business processes.
Process engines may help either to tune processes which are quite ‘unusual’, thus the ones which deviate from the standard ones supported by the COTS application. Or when the process redesign is in-depth indeed, but for only a few processes, while investing in organisation wide software would be overkill.
There is little chance that RPA will be helpful for quite in-depth business (process) innovation, as your redesign will be at a more fundamental level rather than ‘on the (user) surface’.
Business agility / flexibility
Given the rather ‘monolithic’ characteristic of ERP (like) software, it is not known as – highly – flexible. Before making any change to the (many program code lines of the) software, a thorough change impact analysis is needed. And this is often very time-consuming.
Process engines, on the contrary, are much more flexible and yet enable a thorough process redesign.
RPA is surely also very quickly to apply, though it fits less well for a more in-depth process redesign like a change in business (process) logic, as it works more on the (user) surface.
Fast ROI and low project risk
If you are looking at quick process improvements, without (much) structural change of your processes – say not much process redesign -, then RPA is definitely the most appropriate technology.
As you know, ERP (like) projects are surely not famous for fast process improvements. Implementations of at least a half year, up to many years are no exceptions ; if they even get live (on-time)…
Another typical application of RPA is to manage “monuments”. In Lean, monuments mean large, fixed pieces of equipment that are difficult to move or hard to replace. Though this is also applicable to less physical systems like IT-systems.
Mainframe applications are typical examples of large applications which are hard to be replaced. Moreover, fewer and fewer people have the skills needed to adapt such applications - often written in an old programming language - to new business needs ; even though these monuments may still be important and may need to be kept alive.
In such cases, RPA is often the solution to keep the monument alive, though yet to replace the – often unfriendly, repetitive – user interaction in these systems by (ro)bots – like RPA.
Share your thoughts – or your experience – with any of these business process implementation technologies through below Comment box and receive an inspiring article about robotic and intelligent automation.
P.S.: Please share this information with your Facebook friends and fans, LinkedIn contacts, Twitter followers and Google+ circles, through the share buttons below. Thank you!