In part one, we examined the possibilities of digital transformation as well as the very real challenges. To help solve for the challenges, we suggested CIOs first conduct an assessment. In part two, we look at using the output to build a proof of concept.
Once an assessment is run and options are understood, the next step is to build a proof of concept (POC). Many organizations skip this step to save money and rush to the 'finish line' but without a POC the risk goes up. Understanding proof of concept cost at this stage helps plan budgets without surprises.
Too frequently we hear about (or have experienced) horror stories of failed SAP implementations. The POC reduces that risk and reduces cost. We need to build a prototype based on one or more use cases of existing and/or future business processes.
Catch problems early
Without actually building a real model of a business process you are just guessing that you are on the right path. Many problems can be caught in a POC that you don't want to find later in production, thus avoiding the 'kicking the can down the road' to the transformation stage. That's often deadly to a project.
Working out the details and technical kinks within a business process that includes specific end-to-end data flows and interfaces to upstream and downstream legacy systems is invaluable. Engaging the user community early and involving this community in the user acceptance test (UAT) phase of the POC, which tests how the system will support the process, is useful for two reasons:
- To uncover and correct anything that is not working and
- To build user confidence in the IT organization.
The steps required to migrate to production can be executed in the POC, allowing the team to move forward to the transformation stage with confidence, user community buy-in, and real-world experience.
Move on with confidence
Real data from the client's production or QA systems is essential for a successful POC. That data needs to be tracked as it goes through end-to-end testing from SAP ERP Central Component (SAP ECC) extraction, through data cleansing, data loading into the SAP HANA POC instance and reconciliation back to the ECC source data. With that covered and production data successfully reconciled, the user community can sign off with confidence that the IT team is ready to move to the next phase. The user community signing off on a POC is typically a minimum requirement and an 'entrance gate' to transformation.
If you are tempted to bypass the POC step to economize, please remember the old adage 'it's only cheaper if you do it one time.' The total proof of concept cost for a successful POC starts at around $200k, but for smaller organizations there are ways to reduce that cost.
Although not required, it is significantly less expensive to fund a POC if it's done in the cloud. Upfront licensing and hardware costs of potentially hundreds of thousands of dollars mostly disappear with a cloud POC. A monthly fee of a few thousand dollars is all that is required to get a POC system up and running. And remember: We don't need to over-complicate.
A POC can be a single use case, i.e. an A/P use case to demonstrate vendor invoicing, or something larger, such as a migration of all of SAP ECC FI/CO to SAP HANA Finance, depending on client requirements.
With a successful POC and user signoff, the road to migration to production opens.
Q&A
Question: Why is a proof of concept (POC) critical before full digital transformation?
Answer: A POC reduces risk and cost by catching problems early and validating assumptions with a real prototype. Instead of “guessing” that a design will work, teams test end-to-end business processes, data flows, and integrations with upstream and downstream legacy systems. This helps avoid the common pitfalls seen in failed SAP implementations and prevents issues from being pushed into the far more expensive transformation and production stages.
Question: What should a successful POC include?
Answer: It should prototype one or more real business use cases using actual client data, exercise complete process flows, and validate integrations. That means tracking data end-to-end—from SAP ECC extraction, through data cleansing, into the SAP HANA POC instance, and back via reconciliation to ECC—to prove accuracy. It should also include user acceptance testing (UAT) with the business, and execution of the steps required for migration to production so the team gains real-world experience and confidence.
Question: How and why should we involve users in the POC?
Answer: Engage the user community early and include them in UAT. This serves two purposes: (1) uncovering and correcting what isn’t working before transformation, and (2) building user confidence in IT and the solution. Their sign-off on the POC is typically the minimum requirement—an “entrance gate”—to move forward with transformation.
Question: What does a POC typically cost, and how can we economize?
Answer: A successful POC generally starts around $200k, though smaller organizations can reduce that cost. Running the POC in the cloud often lowers spend significantly by eliminating large upfront licensing and hardware purchases; a monthly fee of a few thousand dollars can get a POC system running. Keep the scope focused—don’t over-complicate—so you only pay to prove what matters.
Question: How do we choose the right POC scope?
Answer: Match scope to your goals and risk areas. It can be as small as a single A/P use case (e.g., vendor invoicing) or as broad as migrating SAP ECC FI/CO to SAP HANA Finance. The key is selecting use case(s) that exercise critical end-to-end processes and data, so that with successful testing and user sign-off, the path to migration to production is clear.
