Business Process Automation – a contextual evaluation Part 2 of 2

In this concluding post I thought I would tackle the notion of manual vs. automated integration and the advantages and disadvantages of either approach.

Manual Integration

While this may seem a contradiction in terms, the reality about manual integration is that this largely talks about agile integration. The ability to build, adapt and rework integration according to a changing set of factors and variability in processes. This variability largely comes from the data integration model that you use, the specifics of your SAP configuration and the number of process branches that are present in any given process. While it is somewhat artificial to consider a mining company that sells coal, sells newspaper subscriptions and has fashion stores and also operates a utility company; this model is becoming increasingly prevalent in diversified business entities. A high degree of automation or integration may not have been the original objective but the data volume demands an automation and therefore something needs to be constructed.

Of course SAP supports all of these types of businesses and all their processes and sub processes but almost invariably recommends that a given SAP installation be either compartmentalized on a client basis or on a separate instance. This approach can be very complex and very expensive and integrating these solutions to provide a single consolidated and unified business can be very challenging. An example of this that comes to mind is the pertinence of assortments to mining. In the apparel industry and retail, assortments are quite normal. Different shoes of the same basic style and design but in different sizes and colours. These combinations would typically be seen as assortments. In the mining industry the idea of crushed aggregate dimensions and grade could be considered an assortment; why wouldn’t you use a model that has assortments to cope with this?

In the early stages of integration you may not be exactly sure what combination would be most effective for your business. If you are embarking on SAP for the first time this could be even more of a journey of exploration than you bargained for. In addition, this all presupposes that your consulting partner or independent consultant implementing MM, SD or whatever, really understands and gets your business and how best to configure SAP for your use. Your requirements are pretty solid and crystallized but your solution may still be relatively fluid. Additional factors to consider, might be discard(able) integration pieces. You may be migrating data until you eventually shut down some data capture component or you may be reworking a business process with loosely defined parameters.

Under all of these circumstances, building long tail ABAP and JAVA widgets to do the automation may be very time consuming and very expensive and especially in the realm of stuff you plan to discard, may be seem very wasteful. Under these circumstances you might consider script based automations instead. The same fundamental logic will be used but the objects are created are relatively lightweight and do not take a lot of time to create or modify.

I would also say that this approach invariably uses what other members in the SCN community largely refer to as relatively ‘brittle technology’ namely BDC’s and the flow logic of transaction recordings.

Execution of these integrations can be automated or manual, again this is not so much a trait of the characteristic of the integration as the method for invocation. I like to distinguish the creation and maintenance aspects from the execution or invocation aspects because technically complex integration widgets can be built that are never invoked in an automated fashion; be example support pack or support stack upgrades. An upgrade script may have some very complex logic built into it but it is highly unlikely that it will ever be executed on a schedule. A backup on the other hand, is also a highly complex object but may run on an automated schedule. 

Automated Integration

This is not, in my mind, as the title suggests, an automatic integration between two end points, one that auto-magically builds the integration between SAP and some other data source. It could be, however this is not necessarily a requirement for this integration object to exist.

In this arena I typically think of the use of APIs and standard Interfacing objects like web services, enterprise services etc. By their very nature they are relatively rigid in their form and inflexible. Such objects may have a lot of capability but this shouldn’t be interpreted as being the same as flexibility. Their structures are defined and relatively unchanging.

My expectation is that if you have very mature processes that have been clearly defined and established and there is not a lot of change expected in this particular arena then you may well want to consider using an automated integration approach that uses a technical object.

Typically the use of functions like IDOCs, EDI processing, BADIs and APIs like BAPIs and remotely enabled Function Modules are the technical elements that you might use though certainly these are not mandatory.

You additionally, may consider wrapping these in ABAP or building .NET objects that have very specific objectives in mind and will be robust enough to handle the most complex as well as the most basic scenarios and will in particular, handle high transactional or data volumes.

There isn’t as you may have guessed, a standard template for defining such things but in my experience some of the commonest scenarios that these cover are things like accounting functions and processes, planning and logistics functions that depend heavily on data to determine logic branches and perhaps some master data management functions  – ultimately these aren’t processes that are in a state of process definition flux they are, for the most part, well elaborated and fixed.

Using standardized objects in these scenarios will lead to rapid implementation cycles and potentially scores the benefits of stability and above all consistent predictability in terms of outcomes. In many instances these are ‘implement once’ and ‘never touch again’ automations. They are very purposefully engineered to achieve a particular integration and meet that objective from the get go.

Using automated integration objects means that the integration is well defined in your landscape integration map. Not all integration is, but these definitely should be.

Irrespective of whether their invocation is automated or manual, they are considered a part of the complete solution. The disadvantage of these objects understandably comes from the level of effort required to implement them. Usually, the establishment of these objects involves enterprise class integration considerations with dedicated resources either in terms of equipment or technical resources. By their very nature, they require technical competency to implement and monitor and may be very expensive to adjust or maintain.

When you embark on your next automation project consider some of the attributes articulated above and in the preceding blog post and determine whether you should be asking your developers or consultants, or yourself for that matter, some hard questions about what kind of integration you really want to build. You may surprise yourself with your own answers.