Advanced use cases include IoT based integrated SAP Retail Application, cross-applications built on CAF or an x-APP, or an end to end business process complete business process irrespective of the number of SAP components involved (R3/mySAP, with XI BPM))

1. Know…Now!
SAP-SETU Approach and Advantages

2. Current Scenario
Ent Apps
Bus
• Multiple vendors, both
traditional (one pipe per
device) and emerging
(unified data pipe) exist,
addressing a part of the
physical process
• Disparity in Physical
Business Process and
System Business Process
is not yet bridged

3. Current Scenario
•Partial, piece-meal
approaches (eg., AII) only
lengthen the process
without addressing the
core need
• SETU presents an easy,
elegant, quick-to-market
approach addressing the
same

4. SAP-SETU Approach
XI
SAP Web AS
R3/mySAP Biz Suite/x-Apps/3rd Party
Apps
Uniform, correlated, singular data pipe
to all AIDC devices / Sensors through
SETU
Other Components
Business Contexted, App specific data
to PHYSICAL ENABLE the Apps
Impact of WAS hosted SETU
SAP Web AS
Disparate, non-uniform 3rd party
patches to AIDC devices /Sensors
Other Components
Other
mySAP
NC-R3 3rd
Party
my SAP
SCM
R3
XI
Physical Biz Process in sync with
System Process. Maps with XI BPM, EP
WF and WAS Biz WF
Without SETU

5. SETU - Introduction
• SETU consolidates various AIDC devices (including industrial
automation – PLC etc.,)
– Not just serialized data but also multivariate
• (serialized data of BC, RFID, non-serialized like UBW, Wi-Fi, Triangulated, multi-
coordinate data like RTLS, GPS, multi-variable data like GPS or sensors)
– In-Memory data processing
• SETU adds business context in terms of PHYSICAL BUSINESS
PROCESS
– Process definition as per global standards – Van der Aalst patterns and
BPEL4WS
• SETU handles EPC-centric AND non-EPC centric data as EPC is
restrictive on non-retail domains
– RP AND Non-RP
– ALE AND Non-ALE
– Thus SETU works with non-EPC feasible devices also (e.g, a unique EPC Code
for triangulated location within my warehouse? For data from a microcontroller? Or a globally unique
seat number for a flight?)

6. PHYSICAL vs SYSTEM BP
• SETU BPM is customized for PHYSICAL business processes
– SYS Proc Def:
• Receive PO – Pick and Pack – Ship
– Instance
• One SPECIFIC PO received, 10 SPECIFIC items picked and ONE parcel shipped
– PHY Proc Def:
• Receive PO – Pick and Pack – Ship
– Instance
• One SPECIFIC PO received
• 10 SPECIFIC items picked
– Each action of picking ONE item creates ONE INSTANCE in the BP. So 10
INSTANCES of ITEM MOVEMENT
• ONE parcel shipped
• The life cycle of PHYSICAL Items, as per physical process is different
from that of SYSTEM process
• Only a focused approach in PHYSICAL Process will track the Physical
objects throughout the process effectively, thus also enabling many
physical-level controls – Eg., ISO Process enforcement, KANBAN
enforcement, FIFO etc.,

7. How SETU maps to SAP
• SYSTEM Business Process defined in SAP (XI-BPM, EP WF or WAS
Biz WF)
• PHYSICAL Business Process defined in SETU
• Map the relevant Data Points in SETU BP to any SAP BP
• Instantly PHYSICAL ENABLE the SYSTEM Business Process in SAP
• E.g., a specific process in mySCM, SAP Retail application, any xAPP,
any CAF built app
• Physical enabling is a time and resource consuming exercise – as it
needs custom building of the above system processes using AIDC
devices (even in the presence of AII in case of RFID) – e.g., Adaptive
mySCM took @ 2 years)

8. SAP-SETU Bridge
• SETU BPM is customized for PHYSICAL business processes
• SETU’s deployment on SAP WAS allows for easy integration and
smooth transitions between PHY and SYS processes
• The process mappings in SETU and SAP are synchronized through XI
• All front-end activities are synchronized through EP
• SETU exposes granular functionalities as web services that can be
tapped at various levels (raw-data, physical contexted data, business-
contexted data, Events, Alerts, EPC RP filtered data, EPC ALE/IS
filtered data etc.,)
• Based on correlation between PHY and SYS process definitions, SETU
services can be tapped to trigger events in the SYS process (i.e, any
SAP BPs)
• Physical (SETU) process definition follows industry standards – so can
be exported to 3P engines and vice-versa

9. SAP-SETU – Phase 2
SAP Web App Server
S
E
T
U
mySAP SCM
mySAP CRM
mySAP SRM
mySAP PLM
R/3
X-Apps
SAP Retail
etc.,

10. SAP – SETU Possibilities
“Physical Enable – Productize the access to business
contexted data on the entire life-cycle of moving, non-moving
physical objects”
• Since SETU will be part of the WAS, users can Physical Enable
ANY process of ANY component just as they build any composite
app do using CAF
• Each Process built so can be productized for more promising
areas - eg., Physical Enable SAP Retail or mySAP SCM and
various other possibilities

11. SAP-SETU Scenario 1
Physical Enable vertical application like SAP Retail
Internal
Warehouse
Distribute Shelf-Life Sale Post-Sales
Subscribe to
Services
Subscribe to /Pull
from SAP
Internal
Warehouse
Distribute Shelf-Life Sale Post-Sales
Forecast/Replenish
Physical Process
– life cycle of Pallets,
Cases, Items,
Trucks, Forklifts,
Employee Shift
Cycle etc.,
System Process
– Activities of
Business Process
Web Services exposing
data at various levels - Raw
data from devices, Physical
Contexted data, Business
Contexted data, Physical
Events and Actions, Device
Triggers etc.,
Process Def,
Scenarios, Process
Constraints, Master
Data, Process
Mapping from XI BPM,
EP WF and WAS Biz
WF etc.,
Step 1: Define Physical BP that covers the scenarios in System Process. Step 2: Define Data Points needed for
each activity/step in System Process Step 3: Define level of depth and context for such data points (can also
include other components like NW BI) Step 4: Map System Process to select Setu Data Services. Step 5: Auto
subscribe to relevant Setu Services. PRODUCTIZE IF FEASIBLE.

12. SAP-SETU Scenario 2
Physical Enable a complex application built on CAF or an x-APP
Subscribe to
Services
Subscribe to /Pull
from SAP
Physical
Process
Web Services exposing
data at various levels - Raw
data from devices, Physical
Contexted data, Business
Contexted data, Physical
Events and Actions, Device
Triggers etc.,

13. SAP-SETU Scenario 3
Physical Enable a complete business process (as in XI BPM)
irrespective of the number of SAP components involved (R3/mySAP)
Subscribe to
Services
Subscribe to /Pull
from SAP
Physical Process
Web Services exposing
data at various levels - Raw
data from devices, Physical
Contexted data, Business
Contexted data, Physical
Events and Actions, Device
Triggers etc.,

14. SAP-SETU Scenario 4
Float any of the above as Service on a Cloud (e.,g Amazon CC)
• Once such applications as above are productized, a number of easy-to-use
services can be floated. Examples (many such services can target SME/Business
One users):
• Anti-Counterfeit
• All connect points in a pharma supply chain can simply scan barcode/tag and
automatically send the same to an Authentication Service hosted on a cloud, with
immediate reply
•This can be as simple as sending an SMS. Can be used by anyone (subscribed)
• Warranty
• A service center (e.g., mobile/electronics) can simply send an SMS to the service hosted
by SAP but paid for by the OEM and service centers
• A user can scan/photograph a barcode or number thru his mobile to check authenticity of
any product.
• Supply Chain
• A customer / sales man in the field can check exact delivery status by SMS’ing PO
Number - truck status by GPS and package status by UWB/RFID

15. How is this different from current solutions?
• Current approach (AII) is Process Extensions based – eg., Inbound,
Outbound, RTI etc.,
• Each Process set/ extensions has to be custom built and only then a
process can be Physical Enabled, that too only for RFID/some AIDC
and ONLY from EPC perspective
• e.g., release of mySAP SCM RFID. This way, slowly all of the
apps will be PE’d but it will take very long time and that too for
frozen process steps only. What if a new x-APP or CAF calls for
PE? Or what if the customer has a process different from the std?
• Unlike this approach, SETU allows to build any Physical Process on
the fly and map it to the System process of any of SAP components –
so making all SAP apps more flexible, adaptable and extensible

16. Advantages
• Allows the users to define ANY business process as per their
requirement
– Unlike the process extensions of R3 in AII
• The process definitions can extend to any of the components of
mySAP Business Suite and SAP Netweaver
• The presence of Physical data with business context and
access to the powerful components of mySAP Business Suite
opens up many opportunities for building COMPOSITE
APPLCIATIONS
• This approach goes beyond RFID focused, EPC oriented
solutions which needs large-scale customizations
• An SAP Web AS hosted SETU can be become the default
PHYSICAL ENABLING PLATFORM for any SAP component

17. Advantages…
• SETU adds to AII:- The out-of-the-box AII process extensions
apply only to standard SAP business processes (that too only in
R3 and lately mySCM). For example, customized shipping
solutions in SAP will prevent the enterprise from utilizing the out-
of-the-box shipping solution built in AII
• SETU approach increases the usage and thus ROI of Netweaver
XI and other components, at a fraction of the cost of custom
development for Physical enabling applications

18. How SETU Complements AII
• Based on the outcome of the conf call on 12.3.09,
this could be the summary on how SETU
complements AII
– SETU acts as
• Device Driver and Controller
• Physical Business Process Modeler
– And Integrates through AII to SAP environment