1) The document proposes using the formal specification language Z to specify SAP functional work, with Supply Chain used as a case study. Z is recommended because it bridges natural language requirements and technical solutions using formal logic and math. 2) A Supply Chain Optimization Framework (SCOF) is presented, which is a library of Z schemas that can specify domains within Supply Chain to support SAP application lifecycle management. 3) An example Planning schema is shown, and it is argued that using formal logic and Z schemas to systematically specify problems can lead to better SAP solution options, especially as business landscapes increase in complexity.

1. A Mathematical Approach to
SAP Functional Work – Deck 1
Making a case for the use of Specification Language Z for
SAP Functional Work
1

2. Intent
• To posit Specification Language Z as a useful
tool for SAP Functional Work
• Apply the concept to a good degree of detail for
SAP Supply Chain as a case study
• Lay the ground for further extensions into other
functional areas (as well as technical), leading
up to coverage for SAP ALM as a whole
2

3. Case for Formal Specifications in
Business IT Systems
Within the scope of specification, formal methods utilize the concept of
mathematical proofs to ensure the correctness of a system or a solution.
•Formal Methods help traceability to the requirements
•Formal methods help eliminate ambiguity
In our specific context - SAP functional work is a bridge between the requirements
arising from business process flows, and system configuration and technical
development.
Lines of Business typically define their requirements, and Business Analysts
perform the initial fit/gap analysis (based on questionnaires, simulations, mockups
etc.) to map the Enterprise processes and requirements to solutions offered by a
chosen System/Platform.
Given the nature of SAP functional work (which has a good degree of overlap with
the above defined scope of the Specification phase in the SDLC), using a formal
specification language is a natural fit
In the Software Development Life Cycle, Specification comes into play between the
Requirements Analysis and the Design phases – as below:
Feasibility/Requirements Analysis -> Specification -> Design -> Build -> Test ->
Deploy -> Maintain

4. Case for Z
Z is recommended for use in specifying SAP Solutions because:
• As a specification language it bridges between natural language (e.g.
English) based business requirements, and machine language (e.g. SAP
config + RICEFW) based technology solutions
•This makes it a perfect fit for doing functional work
•Applications Management work involves many activities, all of which are
based on common sense and logic
•Whether it is primarily applications work (such as SAP functional/ABAP), or more
infrastructure facing work (such as SAP BASIS), or ITIL based governance type work, all
such activities can be expressed logically
Z specifications can help with the decision points during the blueprint phase (wide-landscape
decisions such as whether to use APO or SmartOps for Inventory Optimization, as well as
core ERP decisions such as whether to use version control for outline agreements).
Starting from this upstream phase, Z specifications can evolve all the way along the
implementation such as whether a RICEFW element is needed to meet a given requirement.
And if for example the solution to meet a requirement involves looking up factory calendars to
calculate lead time, then Z as a language can go as far forward as to provide the necessary
pseudo-code, in case the decision is to build an Extension.
And furthermore, in contexts of sustainment, any given SAP implementation would have a
certain element of “hardening”, that is to say, some design decisions would have led to a
system that is has significantly deviated from the original expectations. In such contexts as
well, Z specifications will be able to help work out alternate routes.

5. More on Z
• Uses Typed Set Theory and First Order Logic
• Typed Set Theory uses the framework of logical atoms, sets, types, relations, functions
and all the associated mathematical structure that has evolved over millennia, potentially
extending over to more advanced disciplines such as metric topology, measure
theory, functional analysis and calculus
• This structure is so incredibly rich that you can specify basically anything, to any
desired level of detail
• All programming languages are built on the foundation of Mathematical Logic, and
therefore expressing business requirements in the same format makes it easier to
translate from one to another, and also for purposes of RTM (requirements traceability
matrix)
• Uses Schema Calculus
• Variable declarations and predicate expressions are represented as schemata. This is a
compact notation that helps capture requirements specifications in an encapsulated form
• Z is ISO standardized
• (ISO/IEC 13568:2002, Intern. Standard.)
• Details can be found at http://en.wikipedia.org/wiki/Z_notation

6. Z Schema
In specification language Z:
The container for Z expressions is a schema. Related schemata are
structured together to form a narrative, which specifies the full solution.

7. SCOF
Supply Chain Optimization Framework - SCOF is a library of Z schemata -
for each major domain within Supply Chain as per the composition structure of
SAP. Each Schema is intended to support the ALM (Application Lifecycle
Management) functions for that domain, to complement the functionalities of the
SAP ecosystem entities in that domain.
The market norm for an SAP methodology is usually an add-on to SAP’s own
ASAP methodology, by providing additional roadmaps to Solution Manager.
SCOF on the other hand, approaches the need for a methodology by offering an
independent and complementing value-add to the existing SAP ALM solutions
such as ARIS and Solution Manager.
SCOF does so by using mathematics, based on Specification Language Z.
This provides a means of independent verification and validation for the
guidance offered by the aforementioned ALM techniques.
It complements current techniques and methodologies in a given SAP
landscape

8. SCOF – A Schematic

9. Example - Planning Schema
9

10. What do we expect to get out of
this?
• For any given problem situation, chipping away
at it using systematic logic will provide scope for
finding better solution options
• Looking forward into the future, as business
landscapes get more complex, ERP work will
correspondingly increase in complexity.
Adopting the use of systematic logic will help
navigate those waters 10