SAP recently announced that it would entertain involvement in its PartnerEdge program from partners who previously had never been involved in the SAP space. This apparent ‘new’ offering through their website differs from other partner programs in the past in that it is promoting very specific capabilities namely “help create and monetize innovative, specific applications in the mobile, cloud, database or high-performance in-memory areas” It is clear from this statement that the targets are Mobile, Cloud and HANA.
While historically a on-premise software technology provider, SAP itself has produced a number of mobile applications for free and for a variety of uses from Business Objects to Order Status Inquiries from ERP. Downloading the applications themselves is probably fairly straightforward but getting them to talk to your back end systems is another matter; you have to navigate the complex world of SAP security authorization, externally facing ERP systems etc.
Against the backdrop of more recent announcements regarding SAP system vulnerabilities it is likely then that newcomers and business adoption levels will likely be low.
The SAP application landscape, like those of many enterprise back office behemoth systems suffer from a kind of innovation stalemate. When the business commits resources to enabling certain functionality then the likelihood of success is higher than if individuals try to create a groundswell of interest in functionality by leveraging peripheral or micro apps like many of these mobile applications to address certain edge case business scenarios.
It will be interesting to see whether opening the proverbial floodgates to innovation partners with little or no prior experience with working with SAP and SAP systems will in fact make a difference. The landscape is complex, the technology quirky and old fashioned in some respects and yet the business dependence on all of these, immense.
The opportunities for those innovators who manage to crack the nut of addressing a real business need cost effectively and at the same time keeping IT and the Auditors at bay will be tremendous.
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?
There’s a lot of talk about the fact that HANA adoption may be on the up-and-up and SAP’s Q1 numbers were largely buoyed by a transformation in the mindset of IT. The “radical transformation of the industry” statement was made by SAP co-CEO Jim Hagemann Snabe in an interview on CNBC and reported by Forbes.
There should be some concern about this perception of IT’s role in servicing the business though. Conceptually, renting someone else’s infrastructure to run IT operations, the way cloud technology is positioned, isn’t really something terribly new, is it?. Data processing bureaux have been around almost since the first commercially viable computer systems became possible. The nature of the big businesses though, is that they like control and pushing their technology off to a third party provider will not be palatable to many of them. It may be palatable to IT perhaps, but ultimately not very appealing or of much interest to the business. How would IT convince the business to commit to a HANA investment, cloud based or otherwise? The answer has to be simply; higher performance, scalability and lower cost of ownership (TCO). The cloud has the potential for the first two but does it really mean a lower TCO?
SAP’s current incarnation of in-memory technology is something that all the major technology players have fiddled with to some extent. Most significantly though, the recent proposal that businesses move their On Line Transaction Processing (OLTP) systems to full in memory technology seems extraordinarily expensive. Systems that are memory laden are something that Oracle have been pushing for some time with their own appliance offerings and undoubtedly there is some sentiment that the whole HANA initiative is a direct attempt to undermine the existing Oracle database stronghold as the RDBMS supporting SAP ERP but it is much more, it is a genuine acknowledgement that there’s a lot of data in those systems and the current analytics approaches are not performing well enough to address business needs.
I won’t go into the benefits of memory based OLTP versus a hybrid approach of volatile memory, disk caching and disc storage but it is important to understand that there is inevitability to this technology and now is as good a time as any to get on board. Any aspirations that IT might have that they can consolidate all their peripheral systems to a single HANA instance is likely overly ambitious. Consider too, that the way this technology is being positioned is that it presupposes that it can be the best solution for everything i.e. OLTP and On-line Analytical Processing (OLAP). See Martin Klopp’s article on consolidation and some unaudited HANA performance numbers, of particular interest may be the statement that “HANA inserts rows at 1.5M records/sec/core or 120M records/sec per node” – those sound like screaming numbers particularly if you are planning on using a product Winshuttle Transaction with SAP ERP to push batched or pre-staged data into your OLTP system.
The ‘solves all performance issues’ suggestion that IT may be thinking may be a little surprising since many of the use cases hailed as incredibly beneficial have been squarely in the OLAP and analytics space and more particularly, when there is no synchronization or latency issues between the OLTP data being replicated or made accessible to the OLAP technology. For OLTP consumers to reap the benefits of the in-memory technology the expectations are pretty clear. Faster data retrieval, faster decision making and faster storage. In the Farber et al “The SAP HANA Database – An Architecture Overview” paper HANA is succinctly described but it also points out that some of the inherently advantageous characteristics of HANA are in fact the compression schemes which mean less memory consumption and memory bandwidth utilization. Perhaps surprising is the suggestion that real-world OLTP actually doesn’t match the TPC-C profile. This has resulted in SAP’s Benchmark Council taking a different view on transaction processing throughput and how it should be measured.
In their paper, Farber at al suggest that real OLTP workload has larger portions of read operations than standard the TPC-C suggests and this is perhaps particularly true when one considers that changing and updating existing records in a given ERP system is very commonplace.
Those unfamiliar with the TPC-C benchmark may be interested to know something about the TPC. In 1988, the database and application vendors formed a consortium called the Transaction Processing Performance Council’s (TPC). The TPC’s goal was to reduce the bench-marketing hype and smoke being created by hardware, database and application vendors by defining a level playing field on which all vendors could compete and be measured. In 1989 the TPC-A benchmark was born. TPC-A defined metrics for performance in transactions per second (tps)as well as price / performance ($/tps). The TPC-C benchmark soon followed and continues to be a popular yardstick for comparing OLTP performance on various hardware and software configurations.
Wholesale porting of SAP ERP to HANA may not necessarily bring immediate performance benefits without modifications to the underlying application code and this is borne out by a raft of training being made available specifically for developing on HANA platforms that suggests that some of the data retrieval logic may need to be reworked. A question then will be what should one do in terms of a migration strategy if one is considering a HANA based system as the next target for your ERP migration? Should you consider a migration of your existing system as is, and can you in fact do that without coding changes? Or should you rather meticulously plan rework of some of your existing code in preparation for a migration.
SAP’s key event, Sapphire, is coming up in Orlando next week and when you’re having a HANA conversation this is certainly something you will be wanting to ask.
I am notoriously bad at crystal ball gazing on matters in general but in the world of IT I think I have been around for long enough to have the ability to tell the difference between a rat and a cat and in this instance I call rat!
The rat in question is the whole question of Microsoft’s Office365 being successful and achieving the pervasive use and ‘buy in’ that major corporate customers would consider viable for their long term IT sustainment needs.
There are plenty of partners and vendors out there promoting cloud based technologies and Microsoft is a little later to the game than the likes of Google but in the grand scheme of things will the biggest of corporations make the leap.
From my perspective a lot of the view of Office365 is that it is nothing much more than a file sharing environment for word documents, powerpoint presentations and excel spreadsheets. Many organizations attempt to point to wide adoption through sensational headlines like “Fast Growing Wholesale Sales Agency Turns To Office 365” for their expansion plans but when you dig a little deeper and look at the characteristics of the case study customer, you determine that the customer is a small or medium business. convergencealimentaire.info published an infographic back in 2012 and identified that ten brands principally own the world of consumer goods ie they are manufacturers, buyers, distributors and sellers of much of the world’s stuff that it consumes.
Can one reasonably expect these companies to move their corporate information in bulk to a hosted provider like Microsoft or Google. I think not. Many of these companies run the leading ERP’s, sometimes many versions of them. In the idealistic world of cloud software solution providers all of these solutions are envisioned as being run across the interwebs.
Office365 itself has seen a very chequered history from the early days of Hotmail, through passport, Live etc etc The latest incarnation, building on the successes seemingly, of XBOX and the apparent success of Google on the cloud has undoubtedly seen significant investment, certainly in the days when I worked with Microsoft, the investment in datacenters alone was considerable and in the interceding years no doubt more revenue has flowed to shoring up this infrastructure. Is this ultimately all enough?
For cloud solutions, or any solution for that matter to be significantly of interest four fundamental factors need to be in play:
- Easy to use
Cheap is relative of course, my Google storage just came up for renewal for 2013 and didn’t auto renew because my credit card attached to my Google Wallet was out of date, I am debating whether I need to renew at all, I subscribed almost on a whim but do I really need this thing, I don’t have a chrome book and I don’t use an android phone, I spend my life in MS Outlook, Word, Excel and Powerpoint, on reflection I am not even sure why I signed up for Google Cloud. I am sure I am not alone. For my employer or customer to invest in Google Cloud would cost considerably more and the decision would not be taken lightly. MS Office Home Premium subscriptions strike me as expensive at $99.99 a year. I would pay $20 a year for MS Office but PCMAG http://www.pcmag.com/article2/0,2817,2414803,00.asp for example predicts it will fail and I am inclined to agree. The last time I bought a full suite of MS Office was 5 years ago and I consider it an investment well made it lasted me until December when Windows8 decided to delete it from my machine as part of the upgrade from Windows7 – major #fail there Microsoft. If Microsoft can’t get the consumer pricing right what is the likelihood of getting it right for corporations.
Appropriate is of course all about relevance. While the look and feel of Office365 professional looks not much different from any of the other new Metro themed applications, does it address the functional needs that my business requires. Unlike products from companies like Adobe. Apple and Microsoft products don’t transform over time, they tend to stagnate until the next major version and as a result lag behind in features and functionality that seem more contemporary. Adobe releases frequent incremental changes to the whole functionality and experience – for some this spells instability, for others this speaks to relevance and appropriateness. Cloud solutions are able to be released with new functionality centrally but the question that has to be asked, is that functionality enough to address the needs of the average corporate user. I try to send folks URLs to n networked documents internally rather than attaching them to emails but sometimes sending a document is a more effective way to get stuff where it needs to go – again, I may not be perfectly representative of the average user but in conversations, I have learned, that shared and sending documents is the norm rather than the exception. How easy even with cloud applications, is it to share documents in such a way without compromising on access controls and overall document integrity and security.
Reliability seems to be potentially the biggest bugaboo that will make or break cloud solutions as being appropriate to the corporate customer in particular. Anyone who has worked the support gristmill will tell you that quality of service is a challenge even with internal solutions, move them out into a world managed by a third party and all of a sudden your business users no longer have the proverbial employee throat to choke. SO many factors can influence quality of service that it seems highly unlikely that businesses will adopt cloud technologies like office365 wholesale unless they can afford a compromise in system availability and performance.
Ease of Use, this is probably the one area where software producers like Microsoft have tremendous opportunities to understand better, their existing and future products. What features and options do users really use. It is possible to instrument existing desktop applications but anxiety around performance, privacy and other factors all influence whether this actually happens. This is extended further by the question of who scrutinizes these statistics and when a decision is made to change or axe a feature what levels of consensus are required from existing customers before this will actually happen.
Ease of use may be the one thing that Office365 will be wonderfully successful at, but it is likely to fail on the reliability and appropriateness front. For mainstream corporate users all four factors will come into play. My prediction is that Office365 will languish for several years and eventually move to commodity status like email but for ordinary consumers not those with rich coffers and deep pockets.
I have just spent the week at the SAPInsider Financials2013 conference held in Las Vegas and organized by WISPubs. SAPInsider is the premier SAP focused conference track for all things SAP and the Financials show is one of the highlights of the SAP Finance related calendar. Attending the Financials conference is always an opportunity to have a number of different conversations with different stakeholders in the SAP world and in particular this year there was a strong focus on controls, audit, compliance and generally keeping your SAP systems safe.
I was particularly interested in conversations with customers and prospects alike who have challenges with being prevented from performing mass actions in their SAP environment. Access to mass transactions tends to be restricted because there is some illusion that entering data manually through the transaction numerous times is safer than running a mass action that could potentially break dozen, hundreds or thousands of records, or worse, create garbage records in your system that are almost impossible to get rid of or correct. The fear of mass transactions is understood but withholding access is not well understood given that IT and the auditors don’t own the business data and the business is ultimately responsible for making sure that the SAP data is correct, present and all accounted for. Worse, delays in changing data can lead to profoundly negative outcomes for the business, far worse than the risk of some of the minor errors that may arise from the incorrect use of a mass tool.
SAP is many things to many business users, but one thing it definitely cannot be described as, is an application platform that is easy and forgiving to use. A certain modicum of proficiency in navigating transaction screens, application logic and the UI as a whole is accepted to be a requirement for effective use however there are a great many inefficiencies in the way the application is presented to the ordinary user. Recent developments in UI optimization have attempted to remediate the situation but on the whole the experience is still sub par and the gap continues to widen as business users come to expect more and more with a richer and more sophisticated experience.
The enhancements to the user experience still do not address the mass actions that business users may need to perform and as a consequence business users are often left with a very limited list of options for performing mass actions against SAP systems.
One approach is the deployment of custom code that allows the mass actions to be performed based on a data input file. The latter is often a text file and the automation code is often of a very fixed and rigid nature. This fixed characteristic may achieve the objectives of the day but in the long term as the requirements evolve and in fact further requirements arise, the custom application may prove to be more of a problem to maintain than initially thought.
A second option that the business may want to consider is the use of 3rd party tool for mass loading of SAP data. This 3rd party tool can use the existing security authorizations and existing transaction processing logic that a user might use when posting the records manually into SAP however it can be enhanced further applying workflow wrappers to the end to end process so that there is visibility into the data activities that the business intends to apply to the system of record. Of perhaps distinctive interest is the fact that the workflow wrappers need not be exclusively exposed to business users but can also be provisioned in such a way that folks from SAP Security, SAP IT and any internal controls or audit group, can weigh in and add their voice to any given planned action.
SAP doesn’t natively support the use of workflow with mass transactions without special configuration but with the use of 3rd party applications, particularly those that ruin atop SharePoint, it is possible to still achieve business efficiency and yet still maintain governance, control risk and ensure compliance.