Why this blog?
There's a big trend now days to set KPI's on SAP Implementations on WRICEF's or similar numbers. If you're a CxO and have bought SAP for your business - one of the business cases is the fact that SAP gives you out of the box best practices with only minor configuration and obviously you want that benefit to reduce errors and overall support costs.
I'm not here to debate how much configuration is actually required; or suggest you get a reporting/integration/mobile/etc strategy in place to minimise the number of reports/interfaces/frameworks/etc required. I'm here to cover off the preconception I see in the market regularly that all custom development is bad.
Definition of Custom Development
For purposes of this blog - when I refer to custom development, I'm not referring to enhancement points, se38 style reports, interfaces or forms. Sure this is a type of custom development, but it's what I really think "configuring" SAP really means in many cases. Yes - some developers "configure" a little too quickly without looking at existing functionality but that's a different topic altogether from where I'm coming from.
What I'm referring to is large scale development on projects. Effectively developing new modules or significant functionality. Or from my perspective, when you're developing the fun stuff that can really differentiate and make a difference to a standard implementation.
So is Custom Development bad?
Well with my EA hat on - generally Yes! - "buy over build" is a pretty typical principle to stick with and in most cases pays off as a good weighted principle in software decision making. But there are a few use-cases (aka business scenarios) where I say - bring in your Agile team, do some design-thinking, and let's make this SAP system ROCK for our end-users.
So what are some of these use-cases?
Occasional User Centric Interfaces
SAP ERP UI's aren't for everyone and you can see SAP addressing that through iPad UI's, non-WebDynpro browser based applications and even new products like SAP SUP and Gateway. This is especially true for those users who only occasionally need to do something in SAP (who typically also don't want to touch SAP).
If you really want to get engagement from these types of end-users it may in fact be worth investing in a UI that works for end users. This could be as simple as what Mentor Graham Robinson spoke about at Mastering Technologies in Sydney where he provided a simple email system using email replys for approval of workflows rather than a dedicated UI (i.e. Some design thinking here).
Alternatively, if a more guiding UI is required, maybe you could be providing an offline HTML5 mobile app that can be deployed to end users that interacts with SAP through Gateway, SUP or directly via the ICF* (* Give us a shout if you want the source code from Al Templeton and my TechEd session where we created a prototype jQueryMobile web offline app based on ICF)?
One point around these interfaces...Look for a fast ROI or a stable business process as if you're not careful, you could be opening up a very expensive maintenance project with specialised resources. Also, a caveat that you should get ahead of the game with is to make sure you have an enterprise mobility strategy in place that supports this appropriately. i.e. Get security (both network and authentication/authorisation) sorted first and know your target mobile market as you don't want to support "everything" at this point of time.
Whoops - I know I said this wasn't about strategies, but fundamentals are still required in new areas like mobility, and you should also relate this to non-standard UI's as there are a lot of potential cross-overs (Gateway and HTML5 may potentially be a common solution).
A Related Gap in Functionality that SAP will never Fulfill
Obviously SAP does a lot but it never will do everything. So what do you do when you have a piece of required critical business functionality that needs integration with SAP and SAP don't have anything for you.
- Sometimes there is an Commercial Off The Shelf (COTS) product with just a little tweaking and development to fit your requirements - perfect.
- Though alternatively, sometimes the best COTS product will require significant development and potentially complex integration with SAP.
In this latter scenario, you should consider custom development.
So when you have this custom development option; do you go and build this in .NET or JAVA/CE/Neo and integrate with SAP; do you implement this directly within your ERP system in ABAP; do you build a BPM solution with a CE front end, etc?
Well hold your horses first. Let's make sure SAP don't have any plans first - I believe there's a free service you can get from the SAP's custom development organisation to give you a quote and inform you the intentions of SAP in this space. That couldn't hurt to do first.
Okay, now if you've got to develop a solution to fulfill your business needs still; it then depends on your organisation support structure, available skills, the level of integration required with your ERP/CRM/SRM/etc system, plus many other dimensions. How you exactly build this solution needs careful consideration of your specific circumstances. Strongly consider developing closest to the system with the most aligned data, and in the samedeveloment tools if you can - provided you're not seen as innovating the core 🙂
Cross-System Mash-ups
Another quick one to highlight as an example is cross-system mash-ups. Bringing information together can be very powerful; and bringing this information together in a mash-up that provides the users the information they need to make decisions plus act on these decisions is obviously one of the things that the Business Objects targets with dashboards. Dashboards are pretty much custom development; and it's probably worth saying that dashboards are always wanted but rarely get delivered and I believe this is related to my main point below.
So What's with the bad wrap for Customer Solutions?
Custom development is an art - UI, Design, Getting the real requirements and not the perceived requirements, etc. Again, I am not talking about development that takes place in usual implementations of SAP or on small scale .NET database applications. I feel that typically custom development, and especially custom development within SAP doesn't benefit enough from best practices from the Software Development industry. This is not to say it's always like that but it is something to consider.
I've seen both implementations and massive module custom development within SAP and they are world's apart in terms of the approach. For example, I often harp on modelling techniques like taking use-cases through high-level sequence modelling before starting a single line of code; and mocking up UI's for the stakeholder understanding of the solution as part of the blueprint. I'd love to see this type of activity on implementations, but that's not the style of most implementations as flexibility is less preferred when compared to custom development..
On that, another thing not to forget is to be prepared for change as custom development does promote a more flexible approach with the stakeholders than implementations. Expecting a fixed price custom build solution for anything more than 3 months of work, will dangerously give you whatever is written in the requirements and will have a higher risk of failure since the flexibility to alter scope is not there.
Also, agile techniques work great with custom development; but require a different approach to managing requirements than implementation teams are used to. I always throw out the concepts introduced by RUP which looks at stability, priority and architectural significance of requirements which allow you to tailor your iterations to align both with customer expectations, and the needs of building a stable foundation. I've had numerous successes with this approach, and it's not quite as extreme when you look at this way as SCRUM might be in your organisation (though this is not a SCRUM versus RUP versus Waterfall discussion).
Finally, it's easy to build a solution that no one can support except the custom development team; so building a solution based on the underlying support organisation is critical. Even if it means not leveraging all the latest technologies that could be used 😞
So in essence, custom development has it's place, but custom development is a different set-up that can be established, but should not be assumed to be within your organisation unless you've made sure it exists.
Happy Coding!
