Gimmal Blog

Read the latest thought leadership and industry news from the experts at Gimmal!

All Posts

Document Management on the Road to HANA

The Hana Highway on the Hawaiian island of Maui stretches from the town of Kahului to the remote town of Hana, but the portion from Pa’ia to Hana is infamous for how winding and narrow it is. It takes over two hours to make the drive, even though the towns are only about 50 miles apart.

As a tourist on this road several years ago, I rode the brakes of our rental car so hard that we had to stop to let them cool off. Meanwhile, the locals who knew the road sped by us with ease and speed because they knew exactly where they were going: where the difficult turns where and the best approach to taking them.

The road to S4/HANA

SAP has set a deadline of 2025 for its ERP customers to transition to S4/HANA, which is an ERP running on SAP’s proprietary in-memory database called SAP HANA. Much like the Hana Highway, there are many twists and turns you’ll have to navigate when transitioning to this new database paradigm. That’s why we refer to this transition as the “road to HANA.” Much like the actual road, you can travel it as an unprepared tourist or navigate it like a local who knows exactly what to expect.

SAP HANA itself is a platform for business data that provides a relational database optimized for transactional (OLTP) and analytical (OLAP) processing. It resides “in-memory,” which means that it primarily relies on main memory to store data rather than disk storage.

Such in-memory access provides for much faster access to and processing of data. In addition, the knock-on effects of slower disk-based access, such as race conditions and deadlocks, are greatly reduced in such a system. This leads to the main benefits of running enterprise resource planning (ERP) software on such an in-memory system: transactional speed, data integrity, and real-time analytics.

With the benefits of running ERP software on an in-memory database it makes sense for SAP to push customers towards this technology and transition its flagship software to use it. However, there are considerations to make with transitioning from a disk-based database to an in-memory one, the chief of which is total cost of operation. The cost of main memory is, byte for byte, considerably greater than that of disk storage.

A bend in the road

This premium price tag means that storing data that is not directly necessary for transactions or analytics in an in-memory database is not cost-efficient. This is particularly an issue for SAP ERP users that are accustomed to a traditional disk-based database and have stored unstructured content (supporting documentation for transactions, reports, etc.) there for convenience. Storing these items in the SAP database is not cost-effective when running on SAP HANA.

This is the first twist in the Road to HANA that an organization must deal with: they’ll have to identify the unstructured content currently stored in the SAP Database and transfer it to a content server. This should be done in such a way as to preserve its utility to the end user.

Content should continue to be accessible from the SAP user interface, and any solution should provide a process for adding new content in the same intuitive way. SAP provides for this requirement with their “HTTP Content Server” protocol.

There is an additional opportunity in moving unstructured data out of the ERP database and into a true enterprise content management (ECM) system. In addition to reducing the footprint of the application database, it becomes possible to provide this content and associated metadata to users and processes outside of the ERP system. This has implications across approval workflows, e-discovery and legal holds, managing retention schedules, and dozens of other use cases.

Go easy on your brakes

Hopefully that provides a taste for what I mean by “the road to HANA,” and provides a good example of the challenges that await those organizations who will travel it. In a series of blog posts to follow I plan to dig deeper into this challenge, discuss some approaches to addressing it, and consider the opportunities that addressing it provides.

Moving your unstructured content out of the SAP database and in to ECM is essential for transitioning to a HANA-based SAP deployment. Knowing this and addressing it early will make you feel like a local traveling the road to HANA, and avoid you needing to use the brakes too often along the way.

WATCH NOW

Nathan Hampson
Nathan Hampson
Nathan Hampson is a Principal in Gimmal's Client Success department with a unique, front-line view into concerns facing SAP users.

Related Posts

3 Tips to Ensure KORA Compliance

There has been a spotlight on the Kansas Open Records Act (KORA) in the media lately, largely due to recent violations. Under KORA, any individual can request public records from government bodies. If all requested records are not provided within in a specific timeframe, these organizations are subject to significant repercussions. This is merely one example of a ‘sunshine law’. The purpose of sunshine laws is to provide transparency into government agencies by giving the public access to local government proceedings.

Creating a Retention Schedule that Works

Creating a usable, automated, and simple file plan is an important part of ensuring records are managed in a consistent manner and that you are protected from legal risks, such as failure to disclose information during a discovery proceeding or the unauthorized leakage of information. The first step in the process is creating a retention schedule, which outlines how long records are kept in accordance with the organization’s obligations and the law.

How to Manage Your Sprawling Content

Sprawling content, the spread of content across multiple repositories, has been a thorn in the side of records managers since the dawn of document management. Consolidation of repositories, which began in the early 2000s, at first looked to be the solution. However, it ended up highlighting the problems of content sprawl due to the high costs of consolidation as well as need for records managers to manage multiple file plans. Federated records management offers a solution to these problems but doesn’t offer the same locked-down approach with regards to regulation that consolidation can. Consolidation of repositories and federated records management both have pros and cons and, depending on your organization’s content management processes and repositories, one can be more beneficial than the other in the long term.