Posted by: Todd Morrison
when relevant content is
added and updated.
The article I recently wrote on SAP Rapid Deployment Solutions drew some interesting comments about the potential impact and benefits of RDS applications as well as the potential pitfalls related to scope creep.
In the article, Dominick Beck, an IT manager with Papyrus, a midsize vendor of wholesale commercial paper and cleaning products based in Göteborg, Sweden, spoke about his company’s experience deploying the RDS version of SAP Extended Warehouse Management. According to Beck, the RDS templates had provided about 60% or so of what they needed, and Papyrus did the rest.
“When we started with this RDS, [it gave us] a system where one warehouse number was fully set up,” Beck told me. “Then we copied from this warehouse number all the settings to our own warehouse number, and [went through the] customizing process where our processes were different compared with the original template,”
Scott Priest at SAP Experts writes that this could be the way of on-premises apps in the future — or not:
That might be where on-premise software is heading. Think of it like the way personal computers used to be: You’d get a giant package from Gateway or IBM or whomever with scores of discs to run, that took a bunch of time and left the possibility that you’d make a mistake. Nowadays you buy a computer and it’s ready to go from the start. The battery’s usually fully charged, too.
So maybe what will happen with enterprise solutions is a shift to RDS-like packages that are easier to implement, with experienced shops having an advantage on customization due to their own resources.
Or maybe RDS will prove a failure. It’s certainly possible. Due to the ever-changing nature of many of these applications, it’s difficult to be comfortable that your in-house resources will know the software inside and out, where a consultant might be able to provide more value.
At the same time, other folks weighed in with some thoughts of their own on independent SAP analyst Jon Reed’s Google Plus page. Reed, who noted that SAP created the RDS line in part to compete against SaaS-based applications, writes about scope creep, the tendency of some IT projects to grow out of control:
The catch is that RDS approaches are intended to be out-of-the-box. SAP has also said in conversations about this topic that change requests after RDS installs can be the biggest threat to success. In other words, the danger is scope creep. If a customer misunderstands what the RDS can and can’t do, or if an overzealous salesperson pushes it too hard, you have a bad fit, ergo change requests. I want to talk to more RDS customers, my views on this are still in flux.
Reed said afterward that scope creep is a danger to any project, but it could be especially toxic to RDS projects given that the whole point is to get something up and running in a matter of weeks.
“A lot times, say with an ERP upgrade, [you will] allow nine months for a project. If you go over a month because of scope issues, [it's likely not a huge problem given] you probably allocated a year because you knew it was going to be a big deal,” Reed said. “With RDS, if you go over a month, and it was only supposed to take six weeks to begin with, you’re not very happy.”
Jarret Pazahanick, an SAP HCM consultant with EIC Experts, a Houston-based IT consulting firm, echoed Reed’s concern, stating that many systems integrators love RDS is because it helps them get their foot in the door, after which they can sell pricey add-ons for the RDS software.
Pazahanick also wondered if some of the “best practices” that SAP claims are baked into RDS applications are really just basic functionality.
Those are good questions. And I’m not sure of all the answers, either. Like Reed, I look forward to talking to more customers about their experiences with RDS. RDS was designed to be as simple as possible. But as many IT professionals can attest, enterprise software rarely turns out to be as straightforward as it might seem.