CxM in the IoT: the case for service verticals integration
•Download as PPTX, PDF•
2 likes•2,517 views
A provocative view in the the domain of Internet of Things. An attempt to address the fragmentation as a key element endangering the diffusion of an IoT ecosystem and disrupting the Customer Experience. A stimulus for the discussion to link technology elements currently not in the mainstream ( not covered in the presentation but: shall ontologies be the key element for context definition ) ?
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to CxM in the IoT: the case for service verticals integration
Similar to CxM in the IoT: the case for service verticals integration (20)
Recently uploaded
Recently uploaded (16)
CxM in the IoT: the case for service verticals integration
- 1. CxM in the IoT Industry The case for Service Verticals Integration Alfeo Pareschi - VP Customer Solutions Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 -- New Yorrk -- Sao Paullo -- Siingaporre
- 2. CxM Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 3. CxM Customer eXperience Management… AND … ConteXt Management Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 4. An example Home … … Baby … … Maritime … … Industrial. Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 5. Context Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 6. Context Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 7. Customer Experience Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 8. Who is the Customer ? The one purchasing food / drinks The operator of the vending service Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore The technology vendor of the machine The advertisement company
- 9. Customer Experience ? Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 10. Quick summary Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 11. Context transfer: how it looks like Smart Home Context Remote Monitoring Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore Remote Monitoring Service Provider ATM Context Financial Transaction Smart Home NOC User House is Ok Power failure in one room House has some Problems
- 12. Context Management Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 13. Customer as a multi-sided entity Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore Service Provider ATM Context Financial Transaction NOC End User Bank Law Enforcement Security Company
- 14. Where Customer is: Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 15. Context + Customer(s) = State Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore • subscription state • history • session • profile • other users users devic es netwo rk • applications / UIs • configurations • connections on / off premise • up / down utilisation • health • policies • services
- 16. Context + Customer(s) = State CONSISTENT users Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore users devic es netwo rk STATE API
- 17. Context+Customer(s) => API Engine Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 18. What are the key needs ? Context(s) Customer(s) API Engine Communication Network Aware Management I/F Neutral Multi-Layer Multi-Tenancy Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore User Profiles / Use Case Agnostic Web Services I/F Extendable
- 19. Technology Challenges Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore
- 20. Axiros answers Authentication ACS SIEBEL DHCP Order Decomposition Network Our Lyse / Altibox implementation is a good starting point RGW SERVICE Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore HUB Network Provisioning Application & Service Provisioning STB Media Control & QoS VoIP Device ALARM PANEL Voice Profile & QoS Service Provisioning & Alarming Fire Sensor Intrusion Sensor scalability data models interfaces END USER Self Care MDMS Metering Data web services
- 21. Conclusion Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore CxM is about a single holistic experience
- 22. Headquarter: © 2014 All Rights reserved by Axiros Axiros Gmbh Altlaufstr. 34 D-85636 Munich Hoehenkirchen Germany Phone: +49.8102 8065 500 Fax: +49.8102 8065 501 Mail: info@axiros.com Web: www.axiros.com Copyright 2014 Axiros - Aarau . Lisbon - Kazan - Milano - Munich 2013 - New York - Sao Paulo - Singapore International Locations: Emea ￭Aarau Switzerland ￭Lisbon, Portugal ￭Kazan, Russia ￭Milan, Italy Americas ￭Boston, USA ￭San Paolo, Brazil APAC ￭Singapore, Singapore
Editor's Notes
- First of all let me introduce myself: my name is Alfeo Pareschi and I am responsible for the Customer Solutions in Axiros. Which means that I overlook the Demand phase of our engagements with Axiros customers WW. As such, I want to mention a specific aspect which we believe is getting the right attention in terms of ability to monetize the technology.
- Let’s start from the title: we are all familiar with CEM. So what’s CxM and why one more acronym ?
- In the business domain of the Internet of Things we need to couple two important aspects: the Customer Experience - where the tricky part is the definition of who is the Customer and I am going to explain it in the next few slides - and the Context - which is part of the experience itself, when we think that the “Thing” connected lives in a specific environment - which is finally what we want to control.
- ( click to start the transition ) They are all IP cameras, they will all carry live or still frame video but the context defines which application and management function we want to activate. The context defines the additional equipment these “Things” need to connect to, the SLA, the connectivity requirements and finally the complete control plane that needs to be activated on these devices
- ( click to start the transition ) Make examples: - Communication domain: Mobile, Wireless BB over Fiber, Mesh Radio, etc. - A functional domain: Metering, Sensing, Alarming, Access&Authorization - Business need: AMI/AMR, Traffic/Load Shaping, Demand/Response, etc. - Segment in the value chain: packaging, warehouse, transport and logistic, delivery, installation, etc.
- ( click to start the animation )
- ( animations start at click - two phases ) emphasize the concept of the second phase where the context arise from the combination of behavior of two - or more - devices
- ( click to start the transition ) just remind the key concepts
- Here the concept we need to highlight is that a Customer is a pretty different concept than the usual one in the Telco industry. It might be a set of APIs that connect to external applications , plus the direct billed user of a service , plus some other notification APIs that transfer the information about the usage of a service. At the end all of these Customer concepts - including the End User - consume APIs. A user browser is today with modern web technologies accessing APIs in the same way it accesses content on the web thus making the user accessing an application really identical to an application to application interface.
- ( click to start the transition ) going through the concepts to explain the different type of Customers. Some of them are not even real users, but applications to which we need to connect. Make the recent example of the use of WebHook technologies to link to workflows that use other web services - like Google Docs - to create compelling events for the application that subscribes to it.
- The key concepts have been exposed So how do we related them This grphical representation is how we see it Users = Customers Network elements + Devices = Context
- All of them accessible through a consistent set of APIs
- ( click to start for every single item ) This time the key concept we have to transfer is the ability to extend from pure Data Collection to the Management of Device States to the Management of Contexts ( typically aggregation of states across different devices ) to the APIs that expose management functionality over the Contexts. And - since the use of those APIs can be very different - the API layer needs to be extensible.
- So - after consolidating the two key concepts of: Being able to build Context(s) out of the device data, potentially combining them Being able to axpose a polymorphic set of APIs for the same service, depending from the type/profile of users willing to connect to it The next big this is to qualify some specific needs: Communication Network Aware: because - especially in Industrial IoT , but not only - service can happen of every kind of communication network, fixed or mobile. The traditional concept of having a low bandwidth mobile network only for control - which was valid in M2M , does not hold any longer Management I/F Neutral, because when it comes to the ability to build a Context, you might need to interface devices that do not have homogeneous management interface Multi-Layer / Multi-Tenancy: because the need to manage different User Profiles / Use Cases brings with it the ability to create dynamic ( eventually hierarchical ) Device groups. Web Services extendable: because our Context(s) and Customer(s) are by nature dynamic concepts and require the ability to manage consistently changes to the API layer. Not just being able to create new APIs but also the ability to expose different API behavior based on the type of User authenticating to the API Engine User Profile / Use Case agnostic: Here the concept is that no internal behavior of the API engine is designed around any specific type of user. It is not only for a management user, for a service user or for an end user. It’s for all of them
- ( every topic animates with a click ) This is a very broad topic. Play the topics one by one: scalability: in terms of devices, but also transactions and distribution of server infrastructure data models: to be neutral ranging from tr style, to snap style to CLI style to netflow same as above but with even more focus on the ability to integrate new transports this is the wizard style, not only to create new interfaces to the external world, but also to connect them to the internal data models and the business logic
- ( click for every element ) And finally a walk through the four key elements and map them back on how we solve the challenges