Standard SSAM or custom MDK development

SAP Service and Asset Manager is itself built on the Mobile Development Kit. Choosing the standard doesn't close the door to extending it, and choosing MDK doesn't mean starting from nothing. The real question isn't which product, but how much of your process you want to carry yourself for the next five years.

If your operation looks like classic corrective and preventive maintenance, the standard covers more than people expect — and every SAP release improves it without you paying for that development.

• Reasonably conventional PM, CS or inventory processes
• You want to absorb SAP's functional updates every year
• The internal team can't maintain an app of its own
• You're in a hurry: a pilot in production within months

When the process is the product. In some operations the way field work happens is part of the competitive advantage, and forcing it into the standard costs more than building it.

• Processes that don't fit the work-order model
• Roles that need three screens, not forty
• Heavy integration with non-SAP systems
• Hard hardware requirements: scanners, sensors, specific cameras

The price of an extension isn't building it — it's keeping it alive. Every customisation gets retested at every upgrade, and a custom app depends on somebody still understanding it three years from now.

• Functional regression at every SSAM update
• iOS and Android releases that force a rebuild
• Dependency on whoever wrote the MDK metadata
• Documentation and handover, never in the budget

Start standard and extend only where it genuinely hurts. Go live with the standard process and one real crew, let the operation point out the three or four things that don't fit, and put MDK exactly there. It's faster, cheaper, and leaves an app somebody can maintain once the project ends.