At different stages in an initiative, project or product you will see a variety of offerings that fall into one or more of these categories.
This blog post will explore some of the nuances associated with these different concepts and how to understand and position them according to your audience or project stage.
During the lifecycle of your implementation or project you will likely leverage a sandbox or IDES system to test out scenarios that you believe will be appropriate to your environment or for a given set of industry related problems. At Winshuttle we constantly use a variety of IDES systems to demonstrate product capability in relation to the thousands of SAP GUI transactions and remote enabled function modules and BAPIs in SAP systems.
IDES systems don’t cover all the scenarios that you want to ultimately leverage a given product for, but they give you a sense of the steps for implementation and whether the objective is even remotely feasible. In the context of a product, or an SAP sales cycle it is therefore nothing more than a demonstration or a demo of capability. You might use a similar system or approach to deal with an RFP.
Canned scenarios that are data dependent
In the sales cycle of SAP Ecohub solutions this is quite normal, the data is artificial, the scenario is somewhat contrived and the level of error handling, variation and nuance is limited. The rationale is quite obvious, you have a limited window of time, you have a restricted attention span and you have an audience that is interested but not yet vested or committed to your proposal or solution. You also need to be able to rinse and repeat as many times as necessary in a soliud and unvarying way that can be handled by technical and no technical people.
The key here is typically around generating a wow factor, what I like to think of as ease of use, form, features and functions. For the most part we pound away at relatively predictable and solid performing SAP transaction types, the material master, sales orders, financial transaction postings and HR transactions like employee creation or infotype change.
These usually work well, unless someone has done something horrible to the SAP data in the IDES system in which case you need to quickly spin up some alternatives. Some of our sales engineers and support consultants use their own material masters or employees but generally I would say that we get by with a handful of common items and the worst scenarios are locked records.
What functionality are you looking to address?
Particularly in larger deals, there is an almost inevitable demand for Proof of Concept but the waters are a little muddy around who should actually pay for a POC and what the real difference is between a POC and a Prototype. Seth Gottlieb provides some great thoughts on POC, Prototype, or Pilot? When and Why but I thought it is useful to expand a little on this idea here but leave out the pilot part because pilots ultimately mean you have a degree of adoption already in place.
As Gottlieb says, a Proof of Concept (POC) is an example to test a discrete design idea or assumption about functionality. Developers do POCs instinctively when they experiment with technology. An example of a recent Winshuttle POC was testing interoperability with Winshuttle Transaction and Google docs spreadsheets. The best POC should clearly state what it is to be proven and to what degree, our ability to update a spreadsheet for example, demonstrated our ability to talk to the Google cloud from the desktop and thereby created a bridge between SAP and the cloud based document.
Similarly, if your desire is to see field level validation of SAP data from Excel before committing the data to SAP then the specifics of the transaction may or may not be relevant depending on how you defined the needs of the POC. Recipe field level validation may be more challenging for example, than say a regular bill of materials. Usually I would expect to see a POC only being built around a slightly more complex scenario that will have been identified by the customer or prospect as opposed to a rehash of existing demo content. Since POCs may inevitably lead to prototypes or pilots they don’t necessarily need to be built on customer systems and data but sometimes this is inevitable.
A solution that requires an industry solution for example like IS-Media or IS-Utilities or even IS-AFS may not be easily proven out on a standard IDES system. The degree of acceptability of a POC should ideally be agreed up front, something like, so if I show you that we can update this field in this screen, is that sufficient? You don’t want to get into a scenario of building a prototype when your objective is defined as POC. POCs again, also don’t necessarily need customer commitment beyond providing the requirement and the expectations, but of course depending on the cycle of adoption, investment and implementation this might be appropriate. Essentially, don’t expect an all-singing all dancing result from your POC.
Solution fits the problem, but what is the flexibility?
Prototypes speak to specific functionality or specific scenarios that are close to exactly what you want to achieve they try to simulate the full solution. My experience is that these tend to be built on customer or prospective customer databases and using customer defined scenarios and data.
A well implemented prototype likely is paid for by the customer and has participation in its engineering by representatives of both the vendor and the customer. This is usually a professional services engagement or a time boxed evaluation period for the full product solution, not some hobbled version that only executes a limited amount of functionality or for a limited set of data. You need to be explicit in defining what you hope to gain through building the prototype as opposed to just going head-on into solution construction and understand the minimal level of completeness that it would take to get the information you need to decide on investment, abandonment or pilot. Have you seen enough to be confident this solution is a good fit for your requirement?
The best prototyping environment needs customer involvement because if they are ultimately agreed and adopted, they will need to be re-tweaked and administered by the customer and if this is a turnkey only approach then sometimes the end result is suboptimal because the intellect required to do any changes were left to the vendor or consultant who built the prototype. Prototyping also needs that employee resource to be appropriately trained, this is another cost. The kind of exclusivity associated with someone simply dropping a prototype into a customer is great for perpetuating a consulting revenue stream but is not such a great end result for the customer who needs to constantly pony up additional money to make changes and yet have plenty of internal resources that could do the work if they knew how.
In my opinion it is incredibly difficult to create a working prototype that can be quickly adopted without using customer configuration and data to perform prototype testing because often there are enough variations between SAP instances that you can have unexpected results with something created in a completely different environment. Again, this is the blessing, and in some respects the curse of a highly configurable SAP environment.
Material masters for example vary in their views of the data, depending on the material type, the user exits you may have configured and the rules you might have configured.