One of my colleagues frequently uses what he refers to as the buses versus trains analog to describe some of the options that companies have with regard to some of the integration enabling technologies that are available for use with SAP.
Depending on the characteristics of the conversation that you are having the analog works well on a number of levels.
On the one hand you have the idea that a bus has a maximum capacity of around 100 or less people, on the other hand, commuter rail or even light rail has much larger capacity with some trains or trolley buses accommodating several hundred passengers simultaneously. When considering why this is possible you have to look to the infrastructural requirements associated with railed versus wheeled transportation. Railed transportation is often selected where a clearly defined commute route has been defined and services the majority. The choice between light-rail versus commuter rail is often bound up in the distances to be traveled and the speeds to be attained, the number of stops etc. You can interpret this in a business process as being somewhat akin to variance or logic complexity. In the ABAP world you would look at IDOCS, PI/XI integration and perhaps even other complementary technologies like EDI, Biztalk, Tibco etc. The point here is that these approaches typically require some degree of heavy lifting to establish.
Heavy Capital Investment is not a prerequisite for SAP Integration
Defining a data route, putting down the supporting technology and then establishing a marshaling yard for trains of data that have issues or risk failure for any number of reasons is another aspect of the overall design that adds another layer of complexity. For this reason, SAP’s Solution Manager monitoring and third party solutions from companies like Seeburger exist, to help the business keep track of what their integration layers are doing.
Another approach might be to deploy custom ABAP programs to achieve the integration. Many companies that have long established SAP infrastructure use this approach to integration developing a combination of ABAP, web Dynpro or Java applications to keep the data flowing from the many possible sources to the final target system. In the case of these programming intensive approaches, the ability to pivot the process and adapt to a changing set of business requirements is relatively difficult. As with anything programmatic; it of course can be done. The question is how quickly and with what sort of levels of commitment. Changing the technology that supports a given process also brings significant risks with it, if certain scenarios or outcomes are unforeseen and arise.
Is support for SAP collaboration automation without programming really possible?
With that said, buses on wheels offer some significant advantages over railed transport in terms of the flexibility they afford a city to service areas of public transport that are either not easily serviced by rail or which don’t justify the capital investment in rail. Additionally, buses support the ability to service a smaller volume of transportation objectives without major expense. However it gets to a point where buses may not be a practical approach when the requirements have demanding throughput expectations. Too many buses on the roads can lead to congestion that is exacerbated when more buses are added. If a bus route services too few requests the transportation authority can reevaluate the route, pivot the service area or discontinue the service. Under such circumstances the consumers of this service are forced to either self-drive or engage in lower level effort like cycling or walking depending on what is most practical.
There are a couple of technologies that support the bus scenario when looking at usability and automation with collaboration in the SAP space but these technologies all have varying strengths and weaknesses. Some technologies that you can look at in this area are Winshuttle, K2, Blackline, Promenta.
In your evaluation process though consider some of the following factors and determine if these are important as selection or buy criteria:
- Support of secondary technologies like SharePoint and Microsoft Excel – the ability to incorporate Microsoft Excel based data gathering processes may be important in the scenarios that you are looking to automate with collaboration
- Ease of deployment and maintenance
- Technical versus a functional focus – can this technology be deployed without major IT involvement? In this era of shrinking IT operations and support budgets a technology solution that requires extensive IT involvement may not meet your agility objectives. Is a “no programming” approach important to you?
- Proven history of deployments with contactable references
- Functional focus agnosticism – does your overarching objective for collaborative automation include a mix of functionalities that transcend any single functional area? Often the materials creation process for example, incorporates not only elements of data management but also finance, logistics, quality management and others.
- Scalability – how many differentiated processes would you be looking at and is this something you could deploy in an evolving way? When you make a commitment to a given technology are you required to build a fortress or a stockade? Sometimes a stockade will do.
- Workflow – What are your workflow requirements are they fully bound to SAP or is Workflow in SAP simply a nice to have but in reality you simply need some kind of auditable workflow?