For too long Remote Services (and its crazy uncle in the attic, M2M) have been stuck in the device-centric, command and control mindset. Back at the turn of the century, in the early 2000’s, when most of the currently used Remote Services application suites were developed, giving a service organization a remote connection to a device was the equivalent of giving a BIC™ lighter to a caveman. The remote device and its occasionally connected characteristics became the center of attention in any application. In hindsight, while that seemed like a good idea at the time, that focus gave short shrift to user needs and business goals. Unfortunately, that is still going on today. Slap some APIs on those device centric applications and call it a platform, and what you get it the ability to create your own version of those same device centric applications. It’s time to fundamentally rethink Remote Services.

Any modern business application needs to help an organization (a) achieve its goals, and (b) identify and break down the tasks and activities required to do so. Activity-centric thinking helps the user plan their day and the business plan their year. Activities are tasks that help deconstruct a larger problem or goal set into manageable, measurable chunks. However quite often what they aren’t is planned. While we would like to have all of our tasks planned, in this interrupt driven world we all live in we must be flexible, dynamically adjusting our activity stream based on new, higher priority tasks that might arise. Try as we might, no can predict when a lightning strike takes out that key piece of equipment that our most important customer is depending on. More importantly, the task isn’t to identify the problem, the task is to solve the problem. That requires much more than just connecting to a device. In fact it requires more information than that which the device alone can deliver and quite often, more brainpower and knowledge than a single user can provide.

This is a fundamental failing of the current set of device-centric Remote Services applications. Having a device automatically create a trouble ticket or giving a user the ability to see the device’s current status and run remote diagnostics, while useful and helpful, does not solve the problem. Solving the problem is the task, a task that requires not just interacting with that device and visibility into its history, but also having pre-filtered, focused information at your fingertips. It requires the ability to collaborate with others. It requires a dedicated workspace where people can share ideas, track the situation, and give management visibility into the progress of the task. Activities and tasks also have a finite lifetime. Activity-centric applications must be able to manage this lifecycle. For example, dynamically create a collaborative workspace and invite the appropriate users when an event happens while also closing out the task and harvesting any new knowledge and learning that have been acquired during this closeout so that it is available the next time a similar event occurs.

Of course, not all tasks are purely reactive. They may be time based – a service technician needs to fill out a time sheet once a week, or planned – a machine is coming up on 10,000 cycles and needs preventive maintenance.

Finally, because we live in a world that includes devices and business processes in addition to people we also must not limit our concept of activities to humans alone. For example, devices themselves may have activities that are either time based – every 15 minutes collect this set of properties and push it to a server for further analysis, or exception driven – if the temperature exceed its threshold notify the server with this error code. These activities are every bit as important to achieving certain goals (e.g. increased equipment uptime) as are the activities that are undertaken by collaborative group of people.
Bringing this activity-centric model to Remote Services requires a new way of thinking and a new toolset. While your current Remote Services infrastructure may suffice for pure device connectivity, it doesn’t give you everything you need to define and track the activities and tasks that help you achieve your goals. Most importantly it doesn’t give you the ability to manage your team or track your progress and it doesn’t let you harvest the tacit knowledge gained during these activities. I believe that activity-centric thinking and applications can completely change the game in Remote Services while erasing some key barriers that most Remote Services efforts encounter, such as both management and user buy-in. More importantly it will help M2M in general, and Remote Services in particular finally deliver on its tremendous promise.