Where in the cloud are you with SAP?
Cloud conversation to SAP is coming—for all SAP customers the solution is eventually S/4HANA. For early adopters the right answer was to move quickly. Yet for some companies HANA is not a priority, for budget reasons or even on the 3-year roadmap.
It’s common to hear SAP customers say, “We’re not planning on HANA right now—we’re focused on other non-SAP projects.” True, most IT department have lengthy project lists and yearly budgets need prioritization. So as companies plan for 2018, it’s worth discussing best practices and how technical teams can add value to the SAP investment, even if your S/4HANA migration won’t happen this year.
10 Projects to consider if you’re not migrating to S/4HANA—now.
1. Apply Enhancement Packs (and other patches)—EHP’s fix bugs and contain functional SAP enhancements. If you haven’t applied them lately, doing so will be a welcome move by the functional teams that rely on the software daily. Today, EHP8 is a prerequisite to move to S/4HANA. You’ll get the fixes and functionality and will be ready to migrate smoothly.
Did you know you can be working in the cloud in minutes? We have the tools to get enterprise workloads running in the cloud, delivering cloud migration with virtually no downtime, wait time, or risk.
2. Archive Data—Many companies delay archiving, but there are two good reasons to tackle it. First—data retention policies. Most people think of data retention as keeping data for a certain amount of time. However, retaining data that is no longer useful or required could be problematic (seek legal counsel for retention requirements). Second—performance. Eliminating unnecessary data can speed up reports, backup and recovery, and disaster recovery failover times. Archiving can reduce the size of your database, speeding refreshes times, and helping avoid or defer the next SAN purchase. Remember, when sizing for HANA, reduced memory size requirements impact the cost of the new HANA hardware.
3. Test and enhance your Disaster Recovery plan—For many, DR is rarely tested. It’s merely a concept of what to do in an emergency. So, seriously consider dedicating time to your SAP disaster recovery plan. The lack of a tested plan can be devastating during a significant outage.
4. Work on performance—Serious performance problems generally get the attention they deserve. But what about month-end processing; the report that runs for 6 hours; the single transaction that always takes 10 seconds to execute (but is run 1000 times daily). Improving performance makes user communities happier and more efficient.
5. Develop a true monitoring/alerting infrastructure—Most SAP users don’t have an enterprise monitoring platform for their SAP environment. “Enterprise” means it can monitor critical thresholds across technologies, including the network, operating systems, databases and SAP. Some have third-party products while many rely solely on Solution Manager that is configured to monitor only the most critical metrics. A robust solution monitors the entire SAP technical environment including alert analysis in order to pinpoint and prevent errors from impacting the systems and the business.
6. Review/revamp SAP security profiles—Over time SAP security profiles tend to get messy. The result? First, it’s an administrative nightmare. Second, security holes grant unauthorized access potentially to sensitive corporate data. It’s a project that can fall to the bottom of the list but getting it done right is well worth the time!
7. Review underlying security of operating system, database and network—Like SAP security profiles, elements of the underlying security infrastructure can get overlooked or changed without tracking. Security is not just for the network team—much can be done to harden servers and secure databases. The big question? If your company has policies for hardening servers when they are built, when were they last reviewed?
8. Move applications to the cloud—The cloud is a big topic, and moving your SAP systems can be complicated. Many IT managers say they’ll consider the cloud when they move to S/4HANA. But why not take advantage of the cloud now? Moving a stable application environment to the cloud is less complex than moving to the cloud and migrating to HANA simultaneously. Move now, upgrade later. Reduce capital outlay, significantly reduce deployment time, increase flexibility, improve performance and tap into a vast array of tools and applications. Just a few reasons to move to the cloud—sooner.
9. Update your OPS documentation—Hundreds of operational tasks are needed to keep an SAP environment running smoothly. When was the last time documentation was updated? How many tasks are still not documented at all?
10. Build an S/4HANA roadmap—As an SAP customer S/4HANA must be part of your strategic direction. The decision to move to S/4HANA will be driven by business needs, but specific technical requirements to physically migrate the system need consideration; understanding tasks and efforts will help drive the conversation. EHP upgrade requirements are among many that need a thorough review: The hardware platform must change (but current purchases can be strategic), Fiori must be deployed, 3rd party interfaces must be supported by S/4HANA (including other SAP products), “clean-up” must be done in advance (e.g., archiving, security, ABAP, etc). Of course, every business will have unique issues that should be addressed and included in the overall roadmap.
There’s our quick top 10. When these are neglected they will ultimately be exposed at the worst possible time. Others will certainly be added to the list, but start here. While these aren’t flashy or high-profile projects, get them right and you have a foundation for successful migration to S/4HANA.
