I had the chance of working with SAP customer Whistler-Blackcomb on a project to build a Fiori app to support warehouse transfers.
We decided to use SAP Build as a way to help refine the scope. As the work was done remotely and knowing how perception of requirements can differ between business and developers in cases like this, I decided to build a mockup of the app to be built and sent to the customer for feedback. In the past, some projects have run longer or were more costly than expected. The customer really didn't want it to happen again.
What is nice about the Build solution is that it helps you prototype while engaging in feedback cycles. After a conference call, I mapped out the requirements and designed the prototype. After first round of feedback, I realized I was 85% right, great, but 15% off and that was actually a problem. These 15% would easily translate into 30-50% cost overrun if not identified early. These are normal types of misses. Happens all the time. Usually comes up after development or in testing and means a lot of rework (and a less desirable situation with the customer, to say the least). But we wanted to deliver on-time and on-budget.
In this first screenshot you can see that BUILD allows the creation of multiple projects. In our case it was the one on the right.
In the project, you define the screen sequence of the app. We have used the Master/Detail template. It was very close to what we needed and greatly accelerated the design process
In preview mode, we are able to simulate an execution in a PDA where screen size is reduced. This is the list of existing STOs created. The button "Create STO" starts the creation process of a new one. This is the main use case of the app.
Once you click on an existing STO, you can browse its details. (Master/Detail paradigm)
Once you click on Create STO, the screen to add items appears. It has been designed so that it leverages the built in Barcode of the device. The reading is brought up to where cursor is.
After scanning an article (in this example a Jacket), the items summarize on the bottom part of the screen. This is important because we don't want to see one line per scan, but one line per article, with quantities summarized.
Two scans of the same article. See quantity of 2
Another different article added.
Once all scanning is complete, we click on SAVE and a popup asks for SENDING WAREHOUSE (yes, multiple are possible and cannot be defaulted) and RECEIVING STORE. In the backend a STO is posted.
So, after a few back and forth of precisions by email, we got the final scope defined.
It is hard to emphasize how much a working prototype helps estimating the development effort. You see it. There are no surprises. The developer was very comfortable with what needed to be built.
Did we deliver on-time and on-budget? YES! We had to use a little bit of our contingency budget as we ended up missing a couple of points (hey, that is completely normal considering how much time we had to work on this – see below) but we were fine.
BUILD by numbers:
- BUILD exercise, prototyping, feedback, conference calls to confirm requirements, estimation etc. = 4 hrs
- BUILD PHASE (coding) including Unit testing = 2 weeks
- Complete time to value(from initial call to go live) = 3 weeks
- 2 transports/releases and to date (of 2 weeks ago) zero bugs/change requests.
Takeaways:
- I believe BUILD should be used in ANY frontend initiative.
- It greatly helps define scope and as consequence, speeds up the process and reduces cost;
- In many ways, it replaces heavy MS-WORD driven Functional specs while delivering more value.
Call to action
In IT, doesn’t it all comes down to “How much value can I deliver for my IT dollars”?
Well, BUILD can really help you with this equation.
Get to use BUILD. Discover it for free.
A lot of information is available.
https://www.build.me/splashapp
https://www.build.me/splashapp/learning
https://www.build.me/splashapp/community
- SAP Managed Tags:
