Skip to Content
Author's profile photo Former Member

The power of the PoC

“Proof of concepts (PoC’s) are now a more powerful tool to educate and influence a customer to implement a solution or process”.  


Is this a statement that you believe in or have experience in? I am going to use this blog to share my views on the power of PoC’s and provide a high level insight how to use the engagement to your benefit as a customer and as an implementer.


Set the scene – what is a PoC?


A proof of concept in terms of a SAP implementation is a quick installation of either a system or process to show the business the potential of the solution. There is not a set rule that defines how long it should take to implement your proof of concept. For some solutions the PoC could be designed and implemented in a couple of weeks, some solutions may require more effort both in terms of time and resource. Whilst the duration may be unpredictable the key is that the solution should provide a high level overview of the functionality and that part of the PoC will be re-useable in a full blown implementation. Further to this the effort required to deliver the PoC should be a fraction on doing the implementation without the PoC. It is advisable to request some business input into the PoC, so when the solution is played back to the business audience the PoC can be seen to fit the high level requirements of the business.


Benefits of a PoC


1 – Customer benefits


The main benefits for this approach are with the customer. The customer can get early visualisation of the solution that they are interested in implementing. If this is wrong or needs to be re-scoped then this can be done in a more costly fashion – i.e not waiting until some form of UAT. The customer can also influence the final design by reviewing the potential functionality and change the scope so it aligns to the true business requirements. Further to this, the customer has a ½ built system (not tested, not end user trained) but you have an asset that can be built to validate the cost of using a PoC.

Lastly it could provide a customer the missing information to create a business case for a fuller implementation. Without a detailed knowledge of the product and the businesses requirements it is very hard to write an accurate business case for the functionality. The PoC methodology aligns to an AGILE methodology of drip feeding functionality in small chunks of effort, providing business benefits much quicker than a traditional Waterfall implementation.



2 – Implementer benefits


The PoC implementation provides benefits to the implementer as well.  It could be argued that it is an easier sale to a customer, as the outlay is not as high in terms of cost and the effort is not as great. Aligned to this the implementer starts to build a positive relationship with the customer demonstrating knowledge of the customer’s business and related processes. This then leads to the implementer being  seen as a reliable partner to sound ideas off and to help scope the solution.





Whilst this blog is very high level, and you may be using a PoC for some new edge technical solution or a full CRM implementation the benefits are there for both customer and implementer. There are many cases where the use of a PoC is not required. I am not saying that a PoC is for everyone or every project. The PoC implementation needs to be seen as a partnership between the customer and the implementer.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Mark,

      Solutions can be scary for customers, especially when they've had bad experiences previously with other consultants.  Building confidence in the product, the consulting groups skills plus proving to yourself you can do what the customer wants is critical in my mind.
      The only caveat I'd add is that in almost all cases PoC's should be thrown away after the concept is proven (or kept for PoC's for other customers).

      An alternate example for you...Once I had a consulting company trying to push a design for a custom solution that was not recognising the obvious patterns within the requirements.  The solution required was quite abstract, hence I spent a night putting together a PoC.  Next day, demo'ed the solution, and everyone was on board with the simplified, fit for purpose design.


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Matt,

      Thanks for your comments.

      I like your views on PoC's as being throw away.
      I suppose this is the case where the functionality is not required. I also know this is the case for say an upgrade PoC.

      However the customer should be able to "re-use" in some form the benefits of the PoC.

      Do you have any examples where you have thrown away PoC's?

      Author's profile photo Former Member
      Former Member
      Hi mark,

      Typically I take a fairly agile approach to development, with prototyping being a key part of the early phases.  So if you consider the pre-sales as the earliest part of the methodology, you usually have to prove a few things early on.

      One example I could state was that I was a fairly early adopter of the AJAX Framework Page (a.k.a. AFP or Portal Signature Design) for an external facing portal.  As this customer needed an extremely sexy portal (which we know is not typical of the SAP Portal); I spent a few days working off a visual design to come up with something that would support two separate brandings concurrently (via different URL's), lookg great, and require minimal modification/development of the Portal.  By prototyping the AFP, this was achieved quite easily.  If I had to use the light framework; it would have been a complete custom development.

      Spending a few frantic days on this produce the result, but I was doing some many variants to get it working the way I wanted it to; I couldn't keep track of all the changes I made.  If I used the PoC, I may have ended up introducing broken code into production.

      Similarly, I once leveraged the Calendar functionality within SAP for a complex diary booking system.  It's actually quite powerful, albeit, poorly documented. In order to not write everything from scratch, I prototyped building and configuring the booking system using this inbuilt functionality to make sure it worked.  Once proven (and I understood all the functionality); I could write the first draft design.

      This are both obviously quite technical in nature; but time and time again, I've ensured this happens.  For reference, in the Rational Unified Process, it actually states the same thing which when you think about it, makes a lot of sense.