Although SAP HANA has only been on the market for several months, companies should no longer consider proof-of-concept (POC) projects merely to test faster reporting on large quantities of data, according to one consultant.
“You’re not going to prove anything new there. It is at a point where people should be doing projects, not POCs, at least in a data mart scenario,” said Vijay Vijayasankar, a consultant who specializes in SAP business analytics at IBM Global Business Services in Phoenix. There are roughly 30 to 50 companies in various stages with those kinds of projects, some of which have gone live and can act as references, he said.
“They should pilot it rather than POC it,” he said.
Next month, however, SAP is planning on releasing service packs that will enable SAP Business Warehouse (BW) to run on SAP HANA, which will allow companies to use the tools within BW to create more complex applications that let them slice and dice the data around various what-if scenarios, Vijayasankar said.
Customers interested in those kinds of applications are the ones that should begin with POCs, he said.
“For BW-based HANA, it’s different. It’s brand new. Nobody has tried it out; there are no public references. It makes total sense to do it as a POC,” Vijayasankar said.
Jon Reed, an independent SAP consultant agreed: Companies should indeed rely on reference customers, but only if the use scenario is the same. Learning from others can help save time and money.
POCs, he said, “can get expensive.”
Who belongs on the proof-of-concept team?
There are a number of best practices that companies doing POCs should follow, Vijayasankar said, including making sure the right people are on the team.
The team should include a data provisioning expert who can get the data into HANA, a data modeler who understands how to model the data within HANA and a front-end developer who understands SAP BW and how to report the data out correctly. The team should also include a HANA administrator who can oversee patches and upgrades to the appliance. This person typically has a background in Basis/DBA, given the similarities to HANA administration. The team also needs a part-time or full-time architect, depending on how ambitious the project is. That architect can also double as a project manager, he said.
The biggest piece of advice Vijayasankar has is making sure the person doing the data modeling has exhaustive SQL skills.
“Hire the best SQL person that you can. That is the most important thing to make your project a success,” he said. “You need to write pretty complex SQL statements to make things work. It’s not a fully 100% GUI-driven exercise. There is no [data] abstraction in HANA. There is no data dictionary per se in HANA.”
Because HANA deals with in-memory technology, there are also subtle differences in the type of SQL it uses compared with the more widely recognized ANSI SQL, he said.
HANA bugs and patches
Because the technology is still new, companies should be prepared for revisions that come every two to three weeks during the POC, at least at this stage, according to Harald Reiter, a Tucson, Ariz.-based Deloitte consultant who specializes in in-memory technology. POCs typically last two to three months.
“They introduce new libraries, new functions. They do introduce new functions of the engine itself," he said. "So that when you run your SQL script, it [can be] completely different from the revision before. You’ve got to watch out for that.”
Although the frequency of revisions will soon slow down, Vijayasankar says, companies shouldn’t be overly concerned with implementing the latest changes once the POC project is stable.
“If the revisions are coming every two weeks, SAP probably only had enough time to do one round of testing. You might be only signing up for more testing," Vijayasankar said.
“You can just stabilize on one version and finish your POC. Then by the time you’re ready to go live, you could patch your system to the latest levels. It’s a very case-by-case decision. “