Rapid implementation solutions in 2012. Limited value at best?

Rapid implementation solutions in 2012. Limited value at best?

Summary: Rapid implementation solutions are being developed as a way of adding value to large deployments. Are they all they are cracked up to be?


Closing out a year on a bit of controversy is always fun and 2011 does not disappoint. Mike Krigsman's rapid implementation solutions predictions post caused a bit of a stir among colleagues yesterday.

Vijay Vijayasankar threw the whole argument under the bus relegating it to minor importance in 2012. (Disclosure: Vijay is a regular JD-OD.com panelist and a senior IBM'er. We have no commercial relationship but we're good buddies.)

During the slightly tongue in cheek conversation we had yesterday (see video above), Vijay points to the basic problem that most if not all ERP projects are going to be judged a 'failure' because it is almost impossible to define the whole project scope at the outset. I chose not to challenge that as it is a diversion from the topic but understand why he would make that assessment.  Others will vehemently disagree with this position saying it self serves the SI position as implementers who gain significant economic advantage.

The real question is whether rapid implementation is the right solution to that problem and whether there are alternatives. Vijay makes two crucial points:

  1. What happens after implementation as that is only a fraction of the problem? What about post implementation topics like integration, deployment etc?
  2. If vendors are taking more responsibility for implementation, as seems to be the case through this approach, then why not go the whole way and build out for cloud/SaaS deployments?

I am on the fence about this one for the moment. I've not seen enough evidence to persuade me in any particular direction although I would favor cloud approaches if they exist. However I take note of the fact that Krigsman's piece did not include a single customer reference. My view here is that predictions without any practical evidence are at best precarious. On the other hand, Jarret Pazahanick, an SAP HCM consultant is convinced this concept is a dud:

One size fits all approach to often doesnt fit anyone except very small customers. Market for isnt as large as believed.

->What makes the expert in knowing how to run successful rapid implementations () for customers.

Pazahanick's position is equally understandable although Vijay notes that Pazahanick claims to have run the numbers for a like-for-like HCM solution using traditional techniques and says he can undercut SAP pricing. I'll await the evidence before commenting further.

I noted that John Appleby, another JD-OD panelist and business development director at Bluefin Solutions (Disclosure: I am developing a small piece of content for Bluefin) had not jumped into the discussion. I am aware his company is something of a fan of this type of solution. Appleby must be the sensible one, enjoying a well deserved vacation. Instead, Mark Chalfen, SAP finance Capability Lead at Bluefin added nuance:

will create a good platform for most clients and they can enhance from the core solution.

with over 100 in 2012 some will be better adopted than others and have different restrictions. Add on market will be big.

This is a discussion that will not go away anytime soon but it is worth bearing in mind that:

  1. Supporters among the vendor community view this as a way of delivering early value - essentially giving them an implementation get out of jail free card for past mis-steps.
  2. At least one and likely more large SIs believe the 2012-2015 timeframe will bring much more important projects stemming from planned M&A plus the impact of macro economic conditions.
  3. Tier 2 SI customers may see benefit from this approach.

Who will be proved right? We cannot know and I for one am not going to make any predictions.

Note - The video quality isn't that great, the audio is better. We recorded the conversation over Skype across some 5,000 miles distance.

UPDATE: Dave Hull of Disney (@sapdba) added his personal view:

@dahowlett speaking from experience, large SIs will overly complicate implementations, to the detriment of smaller customers @vijayasankarv

@dahowlett And as SAP have yet hardly tapped SME market, and that market may be >= large cust market, #RDS is worthwhile @vijayasankarv

@dahowlett I agree w @vijayasankarv when it comes to large complex impl, but #RDS is necessary for smaller cust/less experienced SIs

Topic: Social Enterprise

Dennis Howlett

About Dennis Howlett

Dennis Howlett is a 40 year veteran in enterprise IT, working with companies large and small across many industries. He endeavors to inform buyers in a no-nonsense manner and spares no vendor that comes under his microscope.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The idea that the scope isn't known is preposterous.

    No matter what type of development process is used, someone surely has to define the requirements. Then that piece of work needs to be completed without moving the goal-posts. I can quite accept that other business-areas can later be bolted on, but the same principle should apply. Scope not defined means misunderstandings all round and project disaster.
  • What are the options?

    If you buy packaged software maybe the best way to proceed is to change your business practices to fit how the package works. This way the principle obstacle to rapid implementation is changing the business practices. <br><br>However once you have learned how the package works this is probably less work and less expense than attempting to customize the package to suit your requirements. <br><br>The other way is to define you business processes very carefully before you even think about software. After all, there may be many business practices that simply cannot be automated and require human action, responsibility and judgement.<br><br>If you have defined the business processes carefully then you have a good a blueprint for how the software should fit into them. You then have something to compare the package against to see if it is a good fit, though one should be aware that software salesmen will say everything is possible (though how realistic this is can only be discovered after you have signed on the dotted line).<br><br>The second option probably isn't very rapid, but it may be more likely to benefit your business long term - you might even decide you don't need any new, expensive software.
  • RDS - can be add-ons

    As mentioned by the end of 2012 there will be over 100 RDS solutions.

    Most of these will be add-ons to the core and so in theory some RDS's that will take say 6 weeks will replace an project that could take 16 weeks.

    Having standard config delivered on day 1 is a real accelerator as will all of the testing and training documents.

    Lastly, the solution provided in the RDS is basic. However that does not mean that it will only fit a SME. A large client could use the solution as a template and roll it out across various entities. The solution could be enhanced overtime - but using a simplistic solution will enable clients to start to realise benefits earlier which is one of the complaints of tradional implementations.
    Mark Chalfen