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.
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:
1) To uncover and correct anything that is not working and
2) 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 ERP Central Component (ECC) extraction, through data cleansing, data loading into the 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 cost of 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 ECC FI/CO to HANA Finance, depending on client requirements.
With a successful POC and user signoff, the road to migration to production opens.
Next time the discussion will continue when we delve into the remaining component of the Genesis10 solution: Transform.
Related:
The CIO’s Dilemma: Navigating Digital Transformation without Disrupting Your Organization—Part One
