Blog

Basics of IT Consulting in the Connected World

Introduction to IT Consulting

IT Consulting is a technique of providing expert advice/guidance pertaining to business process, information technology and operational excellence of an organisation in pursuit of its short term or long term objectives and goals. These advisory services help organization to transform their business processes and IT operations with strategies aligned to the specific needs of their industry and organisation.

Types of IT Consulting

  •  Technology Consulting

Consulting related to technology will fall into this category. For instance, a Hospital is planning to build a new central data repository to store their administrative, financial and clinical data. In this scenario, Technology Consulting comes into picture to provide guidance on the selection of data-warehouse tool considering factors such as costs, data volume & variety, integration with upstream and downstream systems.

  • Business Process Consulting

Consulting related to impact of a regulation/new requirement on the organization’s business processes, re-engineering of the organization’s existing business processes or defining of new business processes falls into this category. For instance, a Health Insurance Organisation is planning to implement X-12 5010 changes. In this scenario, Business Process Consulting comes into picture to provide input on the magnitude of impact on the organization’s business processes & IT systems, changes to be done, order in which the change needs to be implemented, to help the organisation to carry out business as usual.

  • Strategy Consulting

Consulting related to the organization’s performance excellence falls into this category. For instance, a Software Product Company is planning to release a new Core Banking Software to the market. In this scenario, Strategy Consulting comes into picture to provide guidance on competitive analysis, timing for release of the product, product pricing, target market geography.

Consultant role in Consulting

Consultant plays a pivotal role in a consulting engagement. Important skills that a consultant need to have are:

  • Ability to
    • Collaborate with stakeholders
    • Identify issues or key areas for improvement
  • Art of questioning (Close ended, Open ended, Conditional, Factual, Follow-up questions)
  • Breakthrough Thinking
    • Set the right stage
    • View change as dynamic and challenges as opportunities
    • Identify connections and patterns that are not obvious
    • Derive different scenarios and explain with real life examples
    • 360-degree analysis
    • Shed assumptions
  • Good communication

Steps involved in a Consulting Engagement

 Let us understand the steps involved in a consulting engagement:

picture1
Consulting Process

Icons Source: Google Images; Source: IBM Blue Consulting

Definition – Understand the Scope

  • Understand the objective(s) and goal(s) of the client and the engagement
  • Identify major barriers for implementation/roll out of client solution (ex: release of similar solution by competition during the same time frame)

Structure – Create Starter Set

  • Identify key areas of engagement (ex: pros and cons of competitor solution, magnitude of market competition, business and technology changes required)
  • Conduct stakeholder assessment
  • Derive hypothesis for each of the key areas
  • Prepare an exhaustive questionnaire focused on addressing the scope, key areas and the barriers.

Data Gathering – Gather appropriate Data

  • Create a data matrix template
  • Gather data from stakeholders using various data gathering methods (interviews, focus groups, questionnaire, observation, available data) and sources (internal, external)

Synthesis – Prepare Recommendation Report

  • Look for patterns, similarities and differences in the data
  • Develop findings based on the data captured
  • Convert hypothesis into conclusions on the basis of findings
  • Include findings and facts as part of conclusion
  • Develop diagrams to strengthen recommendations
  • Prepare recommendation report

Note: Use natural language and active voice, avoid unnecessary jargons. Ensure that acronyms are explained. The most critical area should be addressed first in the report followed by the less critical ones.

Client Buy-In – Final presentation to the Stakeholders

  • Present executive summary of the recommendation report to stakeholders and submit the detailed report for review
  • Update recommendation report with the feedback
  • Follow up with the client

Note: At the time of presentation, maintain focus on key client message, headlines of each slide should indicate conclusion and not recommendation.

Conclusion

The primary focus of IT consulting is to provide advice to organizations seeking external expertise on the best use of information technology. Consultants are called in the by organizations to gain access to specialized expertise in release of a new product to the market, to revamp their entire IT processes, migration to a new technology platform, re-engineer their business processes, build vs buy decision, selection of COTS system to carry out their day to day transactions, implementation of a new regulation and the list continues. Hence it is important that a consultant has good qualities as discussed in this article like good communication, advisory and breakthrough thinking skills.

Advertisements

Software Product Management

Software Product

A software designed to satisfy specific set of requirements is called a Software Product. It is an intangible asset with no physical form. For example, ‘Hospital Information System’ is called a Software Product to meet the administrative and clinical requirements of a Hospital.

Three essential components that need to be considered while designing any product are:

Picture1.png
Product Components
  • Domain: Domain that the product will address. Example: Healthcare, Automobile, Transportation, Banking and so on.
  • Technology: Technology on which the product will be built. Example: Web based product built using Java, SQL Server as the backend and on Windows platform.
  • Market: Market that the product is intended for. Example: ‘Hospital Information System’ product targeted for medium sized hospitals in Asia Pacific market.

Characteristics of a good Software Product

Quality is an important aspect of any software product for sustainability and growth in this competitive world. Let us understand what are the quality characteristics that needs to be present in the product:

Picture1.png
Product Characteristics

Icons source: Google images

Software Product Management & Lifecycle

Software Product Management is the process of building and managing the product from its inception to growth. It is paramount to keep a hawk’s eye on the market variations, identify appropriate opportunities, develop the product and continue this cycle for profitable growth of the product. Let us understand this lifecycle of the product:

Picture1.png
Software Product Lifecycle

Role of Product Manager and Product Owner in Product Management

Product Manager and Product Owner play key roles in product management where one owns the product (Product Manager) and the other (Product Owner) manages the product. Product Manager works with the stakeholders to create a blue print of the product whereas Product Owner works with the development team to build the product based on the blue print. Even though these two are distinct roles, some of their responsibilities overlap. Let us understand the responsibilities of these two roles in the Product Management Lifecycle:

Picture1.png
Product Manager & Product Owner Responsibilities

Note: The roles mentioned in this section are based on Agile Software Development.

Conclusion

To summarize, the three essential components that needs to be considered while conceptualizing and designing a product are domain, market and technology. In addition to this, incorporating the 10 essential characteristics in the product will enable the organization to deliver quality product and in turn increase their customer base. Also, the product management process is a critical business function essential to forecast, define, develop, sell and sustain the product growth in the market against competition.

Important aspects in design of User Interface of a Software Product

Usability

Picture1.png
Dilbert!!!

Source: Google images

Hundreds of good features included in a product will go unused or unnoticed if the user interface designed is complex or confusing to use. Hence, usability plays a vital role in Software Product Development. Usability is defined as the ease with which an application can be used by a user to achieve the specified set of goals in a particular environment (context of use).

Let us understand the Usability Metrics that can be used to measure the usability of a Software Product.

Usability Metrics

International Standards Organisation (ISO) recommends that a software product usability can be measured using the following metrics:

Picture1.png
Usability Metrics

Let us understand the Usability Requirements of a software product to satisfy these metrics.

 Usability Requirements

According to International Standards Organisation, software product usability requirements should include the following:

Picture1.png
Usability Requirements

Icons source: Google images

After understanding the usability requirements, the next important step is the design of the User Interface.

User Interface Design (UID)

User Interface Design or UI Design is the design of screens using which the user will interact with the software to achieve specified set of goals. According to Human Factors International (HFI), there are four important dimensions which needs to be applied to any screen design and are:

Picture1.png
User Interface Focal Points

User interface design should be centered around the user of the product and this is called as User Centered Design discussed in the next section.

User Centered Design (UCD) & User Experience Design (UXD)

User Centered Design (UCD) is an approach where the UI is designed from the perspective of the user who will be using the product. HFI defines three important profiles to be considered for UCD:

Picture1.png
User Centered Design

Icons source: Google images

User stories, task flows, surveys, interviews, focus groups are the different methods which helps in collection of data for these profiles.

User Experience Design (UXD) is an approach for creating UCD. UXD is the process of conducting research with the intended users of the product through surveys, interviews, focus groups and activities which will allow users to express their emotions and motivations about their task(s).  This in turn will help to create user centered design in a way that users will experience the use of the product as acceptable and satisfying.

Apart from usability, it is also important that the product meets the internationalisation requirements to reach global audience. Next section defines Internationalisation, Localisation, Globalisation requirements.

Internationalisation, Localisation, Globalisation

Understanding of the differences with respect to business practices, acceptable vs offensive and formats, are important considerations for building a product to address international audience. To satisfy this, it is imminent that the product meets the internationalisation requirements as shown in the figure below:

picture1
I18N, L10N, G11N

Note: Incase of support for Asian languages, the product also needs to support multi-byte character set for Chinese, Korean, Japanese languages. 

Examples of Internalisation:

  • United States follows ‘mm/dd/yyyy’ format whereas Germany follows ‘dd.mm.yyyy’ format
  • ‘Program’ in US English and ‘Programme’ in UK English,
  • Arabic language is written/read from right to left and English from left to right.
  • Color ‘red’ denotes danger in US and in China it denotes happiness.
  • Italian, French and German are the languages used in Switzerland. In this case, the software has to support all these three languages. There can also be scenario where German is the spoken language but writing is done in English.
  • Another example,

Picture1.png

Source: Human Factors International

Good Principles of User Interface Design for any Software Product

  1. Keep UI elements consistent, one primary action per screen and shortcut keys for user actions.

Picture1.png

2. Avoid information overflow on the interfacePicture1.png

3. Build intelligence to the product

Picture1.png

4. Include worklist and workflows for scheduled tasks that need user’s attention/approval

Picture1.png

Icon source: Google images

5. Group similar tasks and display the goal of the User InterfacePicture1.png

6. Finally, ensure that UI elements fits well when viewed on a tab or smartphone

Picture1.png

Conclusion

Incorporating usability requirements along with the four important focal points of user interface design makes the product more intuitive and less complicated to use. It is paramount that the software is designed keeping the user in mind i.e. his/her task profiles, environment profiles and location profiles. Product also needs to accommodate internationalisation requirements if it is intended for the global audience. A good design of the software product is critical for the growth of the business. Hence, it is essential that the organization invests time and effort in creating a good design of their software product.

 

 

 

Picture1.png

Commercially-off-the-shelf(COTS) Product Assessment

Definition

Commercially-Off-theShelf (COTS) is a Product:

  • Readily available in the market
  • Can be used as-is
  • Sold under a perpetual or subscription based licensing model
  • Sold by the vendor for profit
  • Supported and maintained by the vendor

Example of COTS Product: SAP/Oracle for Supply Chain Management, Finacle for Core Banking, Cerner for Clinical Information System.

COTS Assessment Process

There are multiple COTS products available in the market to address the same set of requirements. For example, there are number of COTS products available in the market like Finacle, Temenos, Misys and so on to address Core Banking requirements. Hence, it is important to have an assessment process in place to shortlist the final product(s) from the list. Below diagram depicts COTS Assessment Process:

Picture1.png
COTS Assessment Process

COTS assessment process can result in selection of one or multiple products. For example, while assessing COTS product for Hospital Information System, Hospital ABC can decide to go with Cerner for Computerized Physician Order Entry and Epic for Patient Administration System.

It is strongly recommended to include Build vs Buy as part of the evaluation process if not already done by the organization.

Build Vs Buy

Buy is buying COTS available readily in the market and Build is building the same system in-house (also called as custom development). From the organisation’s business goal, budget and timeline perspective, it is paramount that the pros and cons of build vs buy is evaluated either before or during COTS assessment process. Typically:

  • Buy (COTS) is recommended when there is:
    • Lack of skilled resources
    • Time to market pressure
    • A system that is readily available which satisfies all or most of the requirements
  • Build (Custom/in-house) is recommended when:
    • Requirements are unique
    • Budget is limited
    • Organization is looking to build or use in-house talent

Organisation can also decide to go with combination of build and buy. For example, Hospital ABC might decide to go with Cerner for Patient Administration System and in-house/custom development for Billing.

COTS Assessment Parameters

Consider an example where Hospital XYZ has decided to go with COTS product for their clinical workflows and has shortlisted 3 vendors (COTS product) i.e. Cerner, Allscripts, Epic.  In order to finalize on the COTS product, it is imperative to have data collected and compared against the standard set of parameters for graphical visualisation of how the product(s) is/are functioning in the market. Below diagram depicts standard set of COTS assessment parameters:

picture2

Conclusion

Defining the right set of parameters for COTS product(s) assessment coupled with assessment of pros and cons of build vs buy will enable organisations to take better decision on the final solution which in turn will help them to have a good start.

IT Due Diligence Process

Definition

Due Diligence is an investigation process to find the impact of any new requirement on the organization’s business processes and IT Systems. New requirement can be:

  • New Requirement: 
    • For example, support for multiple currency in a Supply Chain Management system
  • Mandate: 
    • For example, implementation of ICD-10 changes on Healthcare IT systems.
  • Technology Migration:
    • For example, migration of legacy Cash Billing application (built on Mainframes) to web based application.

Due Diligence Process

Let us understand the various steps involved in Due Diligence for implementation of ICD-10 changes on Hospital business processes and related IT systems:

picture1
Due Diligence Process

Due Diligence Report Format (Sample)

picture1
Due Diligence Report Format

Note: There can be situation where some of the changes can impact only the IT System but not the business process.

Conclusion

Due Diligence is an essential and the first step that every organization need to perform for implementing a new requirement to understand the magnitude of the changes. Based on this, organization can build their roadmap for implementation of new mandate, or decide on Go/No Go with the new requirement or technology migration.

 

 

 

 

Software Development using Scrum Methodology

What is Software Development ?

Software Development is the process of developing a Software Product or execution of a Software Project.

A software designed to satisfy a specific segment of the market requirement is called a Software Product. For example, ‘Hospital Information System’ is a software product to meet the administrative and clinical requirements of a Hospital.

A project where service(s) is offered to meet specific requirements of a customer is called Software Project. For example, Implementation of ICD-10 changes on the customer IT systems.

Software Development Life Cycle (SDLC)

Two most widely used SDLC process which majority of the Product Development Organizations follow are Waterfall and Agile methodologies. Waterfall model follows a sequential approach and is process oriented whereas Agile model follows an incremental approach and is people oriented. It is difficult to say which model is better. Selection of Agile or Waterfall Model depends on three important factors i.e. project contract (Fixed Price/Time & Material), requirements (unambiguous/ambiguous) and the customer delivery needs.

Scrum Methodology

There are number of specific methods under Agile Model. Scrum is one of the widely used Product Development Methodologies which uses Agile Framework. It is an iterative SDLC process to manage projects and product development.

Let us understand Scrum Methodology with an example:

Project Requirement: There is a requirement to create ‘Outpatient Registration’ application which should support the following features:

  • New Outpatient Registration
  • Collect Registration Amount
  • Print Registration Card
  • Print Registration Amount Receipt
  • Modify Outpatient Registration Data
  • Record Patient Revisit to the Hospital
  • View Outpatient Registration Data
  • Cancel Outpatient Registration

Scrum Roles

Team consisting of the following members is formed to start the project.

picture1
Scrum Roles

Scrum Phases and Process

Scrum is a time boxed development process which has fixed length iterations called Sprint which typically lasts typically for 2 to 4 weeks. Each Sprint has distinct phases as shown in the figure below:

picture1
Scrum Phases & Process

Note: Scrum Team comprises of 5 to 7 members and all the members have equal skill sets.

Product Backlog

Product Owner creates Product Backlog Items (PBI) with inputs from customer/market requirements and product roadmap. Each item in the product backlog is explained in the form of User Stories. High priority requirements are considered first followed by low priority items. PBIs are prioritized based on Business Value, Dependency and Risk Factor.

picture1
Prioritized Requirements

Note:

  • Scrum doesn’t define any structured method to define Product Backlog Item. Some of the techniques from eXtreme Programming (one of the Agile Methodologies) like User Story, Epic, Theme are used to define Product Backlog Items.
  • PBI list can contain features, bug fixes and enhancements.
  • User Story is requirement told as a story by the customer. User Story typically should say who the user is, what is the task that the user wants to perform, value that can be derived out from the task.
  • Theme is a collection of user stories; Epic is a big user story which needs to be split into smaller user stories. Theme can have multiple epics; each Epic can have multiple small user stories; each User Story can have multiple tasks.

Product Owner completes writing user stories for the high priority requirements: 

picture1
User Stories 1001, 1002
picture1
User Stories 1003, 1004
picture1
User Story 1005

Note: Product Owner has completed User Stories for 3 high priority requirements. Status will be updated accordingly to In Progress (Started), Done (if the completed solution meets the acceptance criteria) during the course of the project.

Product Owner also prepares the Release Plan in consultation with the Stakeholders:

Table 1: Release Plan

Feature Release 1 Release 2
Outpatient Registration 1.     New Outpatient Registration

2.     Print Registration Card

3.     Collect Registration Amount

4.     Print Registration Receipt

1.     View Outpatient Registration data

2.     Record Patient Revisit

3.     Modify Registration Data

4.     Cancel Registration

Sprint Planning Meeting

Product Owner explains the high priority items in the product backlog to the scrum team to the extent that they can break the user stories into detailed tasks.

Note: It is not required for the Product Owner to explain all the user stories during sprint planning meeting. User Stories sufficient for minimum of two sprints should be explained.

Sprint Backlog

Based on the sprint planning meeting, scrum team selects four user stories 1001, 1002, 1003, 1004 to be executed in the first sprint and moves it to sprint backlog for defining tasks. Sprint duration is planned for 2 weeks. Sprint goal is also defined.

Note: It is final decision of the development team to decide the number of top priority PBI to be included in a Sprint and Product Owner does not have any say in this. Also, the low priority PBI will be considered on completion of top priority items.

Sprint Goal: Develop New Outpatient Registration with features to register new patient and print registration card.

Scrum Team prepares Sprint Backlog and updates it at the end of each day:

Table 2: Sprint Backlog

picture1

Note: User Story defines ‘what is the requirement’ and Task defines ‘how the requirement will be achieved’. Task is the smallest level of work break down structure.

Sprint Process

Daily Scrum Meeting

Scrum Master facilitates daily scrum meeting for 15 minutes to understand the project progress and issues (if any) from the scrum team.  During this meeting, one of the members’ X informed that he is finding it difficult to implement task 6. Team member Y informed that she can take up task 6. Hence, task 7 is assigned to X and task 6 to Y. In this way, rotation of work happens incase someone is finding it difficult to handle a task.

During another daily scrum meeting, the team informs the scrum master that user story 2 is taking lot of time and the estimates are going more than the original (from 24 hrs to 36 hrs). Product Owner is brought in for a discussion by the scrum master.

Product Owner removes user story 2 and modifies user story 3 (as User Story 3 is dependent on User Story 2). Estimate of user story 3 remained same as original i.e. 24 hrs. After this modification, project continued smoothly. 

picture1
Modified User Story 1003

Scrum Master prepares Sprint Burndown Chart based on the number of hours of work remaining at the end of each day:

picture1
Sprint Breakdown Chart

Sprint Review Meeting

Scrum Team presents the work i.e. User Stories 1001, 1003, 1004 in the form of a demo to the Product Owner, Stakeholders (Management, Customers). Solution is accepted by everyone. However, per the release plan prepared by the product owner, release 1 should have user stories 1001, 1003, 1004, 1005. In addition to this, release 1 should also include Print Registration Amount Receipt which is not completed. Hence, the release will not be done to the Customer.

Note: If all the requirements under release 1 was included & completed in this sprint, then the team could have released the code to the customer for user acceptance. On passing user acceptance, the code is deployed on the customer production environment.

Sprint Retrospective Meeting

Scrum Team, Scrum Master and the Product Owner meet to discuss the following points on the past sprint:

  • Things that went wrong
  • Things that went right
  • Things that need improvements/changes

Product Backlog Refinement

To ensure that the product backlog is ready for the next sprint and based on the feedback from sprint review and sprint retrospective meetings, product owner:

  • Splits big user stories into smaller ones (Ex: User story related to ‘Collect Registration Amount’ broken down into ‘Collect Registration Amount with single payment mode’ and ‘Collect Registration Amount with multiple payment modes’)
  • Removes user stories that are not relevant (Ex: User Story related to ‘Record Patient Revisit to the Hospital’ removed)
  • Re-assesses the priority of user stories (Ex: Priority of the user story related to ‘Modify Outpatient Data’ changed to medium from low)
  • Includes enhancements as new user stories (Ex – Option to clear the data on the ‘New Patient Registration’ page)

Note:

  • For the above, the assumption is the product owner has completed writing user stories for the remaining requirements.
  • Bugs if any reported can also be included as user stories in the product backlog as part of product backlog refinement. (Ex: ‘Date of Visit’ not defaulting to the current date)
  • Release Plan also need to be modified accordingly based on the feedback of product backlog refinement meeting.

Conclusion

Scrum follows 3Ds i.e. Divide, Develop and Deliver policy for development of software product. Use Scrum when:

  • Final product is not clear
  • Changes to the requirements are anticipated
  • Need for rapid deployment of the product
  • Less inter-dependencies of the features
  • Custom Software Development

Use Waterfall Model when:

  • Requirements are clear and fixed
  • Project is fixed price contract
  • Experience in working on similar projects
  • Project is simple
  • Speed is not the key to success
  • Multiple software components need to be designed in parallel for integration with external systems (Because the design is completed early in the development lifecycle).

Whether it is Waterfall, Agile, Lean, Rational Unified Process or any other SDLC process, each process has its pros and cons. Depending on the project needs, Service Provider Organisation has to select the SDLC process that meets their, and the customer objectives and goals.

Internet of Things – Explained in Simple Words

Picture1

Source: Google Images

As you can see in the above pictures, the devices are either talking to people or to each other. The technology that is enabling this communication to happen is Internet of Things (IoT). IoT is transforming the way every industry works. Any physical device called a ‘Thing’ which can be assigned with an IP address (Internet), can collect meaningful data (through sensor) and send data over a network (Wired or Wireless) is termed as IoT. In 1999, Kevin Ashton a British Entrepreneur called this technology as ‘Internet of Things’. Industrial Internet (by GE) and Internet of Everything (by CISCO) are synonyms to Internet of Things.

Transfer of meaningful data can be between two devices, device and a living thing, device and an external system.

IoT application includes almost every industry – Banking, Healthcare, Infrastructure, Energy, Transportation, Consumer electronics, Manufacturing, Construction, Building, Automobile, Agriculture and Environment.

Let us take an example to understand IoT in detail

As the saying goes ‘Health is Wealth’, it is imperative to stay fit to maintain good health condition. Good health means fewer or no visits to the Doctor.

Consider a Wearable Device intended for patients with Cardiac Arrhythmias. This device can help patient to track his/her biometrics (meaningful data) i.e. movement, heartbeat and pulse rate. This meaningful data can then be sent to the Physician Application (on a smart phone/tab) for remote monitoring. Also, patient can monitor these values on his/her smart phone/tab.

How does IoT device work?

Every IOT device will be embedded with Sensor (for capture of meaningful data). It can also come with an RFID embedded sensor.

In our example, Wearable Device (IoT device) will monitor patient’s biometrics using the sensor embedded in the device and this data is securely transferred (Device Connectivity) to Physician Application for remote monitoring (Data Visualization). Patient will be able to view his/her biometrics on the Smart Phone and also compare it with the previous results to take better control of his/her health (Device Connectivity & Data Visualization). Rules can be configured to automatically send alarm to the Physician when the biometrics crosses the danger mark (Rules Engine). In this way, the physician can be in constant touch with his/her patients, outside of the clinical setting. Also, with an RFID embedded sensor, physician will be able to track patient location incase of medical emergency.

Data generated by similar devices can be collected in a common data pool (Database) and analytics (Analytics & Tools) can be run on this data to gain deeper insight to the problems which in turn will help in providing more effective care plan to patients.

Also, data churned out by the above device can be sent to patient’s Electronic Medical Record for detailed investigation and future reference (External Interface). This data combined with patient’s clinical information can be used to provide personalized care plan to the patient.

It is also important to handle software upgrades to devices and applications (Device Management).

A platform is necessary to develop and support services like common data pool, analytics, rules engine, secure device connectivity, device management, end user application features and external interface. This platform is called as IoT platform and is usually hosted on a cloud. There are umpteen number of companies venturing into IoT platform development on cloud. Few of the big players are: IBM, Amazon, Google, Microsoft, Intel, Cisco.

A good IoT Application Platform should enable the following functions:

  • Deployment of software applications that manage connected devices
  • Data collections from connected devices and standardization of data
  • Secure connection between connected devices
  • Integration with third party systems
  • Interoperability

IoT Analytics.com recommends that IoT application platform should comprise of the following software components: Device Connectivity, Device Management, Database, Rules Engine, Analytics, Data Visualization, External Interface and Tools for reporting, access management, prototyping.

An IoT Ecosystem usually comprises of the following components as shown below:

Picture1

Note: Icons used in the above diagram are taken from Google Images.

IoT and RFID Technology

IoT is a technology that has emerged from RFID. In IoT, data sharing is done using the Internet Protocol. In RFID, data sharing is done using components like tags, antenna and readers in isolation. These tags can read/write data like condition, context, location of the object and so on. Sharing this data dynamically with stakeholders across enterprises using Internet Protocol will definitely result in an increased return on investment. This can be achieved using an RFID embedded sensor in the IoT device. Value proposition that can be derived from this will drive the relationship between IoT and RFID in each of the industrial sectors.

Opportunities                                                                                                                                                                                  

IoT has definitely opened door to ample opportunities across industries. It is revolutionizing industries and empowering them to take better control of their business.

Applying analytics on the data provided by IoT devices can help organizations in understanding their Strength, Weakness, Opportunities and Threats. This in turn will help them in identification of new business streams and revenue generation avenues.

As per Gartner survey, by 2020 there will be over 26 billion connected devices, CISCO estimates this number to be 50 billion and some even estimate this number to cross 100 billion. Forbes estimates Investment in IoT to reach $117 billion by 2020. Based on survey done by IBM, IoT is driving 71% of COOs to re-evaluate their operating models, 91 % of business leaders in Electronics Industry say that IoT will reshape their organization’s brand equity.

Challenges

Industries need to diligently contemplate on deciphering information from the plethora of data generated by the IOT devices. With too many vendors entering into the IoT market, privacy and security of data transferred across devices is a big challenge that IoT world is encountering today. Normalization of data collected by billions of devices is another challenge which the industry needs to seriously think. Industries also need to give a deep thought to the regulations surrounding the IoT ecosystem. There are no clear interoperability standards for exchange of information between IoT applications leading to integration complexity and confusion.

Ending Note

With continuous surge in the number of IoT devices, opportunities and challenges will co-exist.

It is the fundamental responsibility of every industry to look into effective ways of analyzing and connecting data generated from billions of IoT devices to gain potential value from IoT.

Examples of IoT device

There are plenty of IoT devices available in the market which are beyond our imagination. To name a few: Prescription bottles fitted with microchips for medication tracking, Industrial Assets embedded with sensor and RFID for tracking. For more examples across industries visit:  http://postscapes.com/internet-of-things-examples/.

 

Please leave your comment!