Our fictional CEO wants an estimate before we've even defined any clear goals. That's a sure sign of buzzword compliance.
Have any of our readers embarked on M2M projects for real?
Discussion on:
View:
Show:
that's done via Internet protocols instead of dedicated cable. The real first questions are:
What do you want monitored?
How much do you want monitored?
In the past I've had a little to do with setting up remote manufacturing machinery monitoring, but that was with direct cables and we had to know which of the instruments were worth such detailed monitoring. Experience has shown you do NOT need to monitor everything on everything all the time. Some are best with snapshots taken at different times, otherwise you get buried under way too much detail and fail to see the forest as a whole for the trees and the brush.
Another good point is how you want the information to be displayed, in some cases raw data as digits is good, while others are best shown as a line graph.
In short, you need to point out there's many hours of work needed to establish the relevant goals before you can even estimate how much it's going to cost to do, let alone any benefits.
One case I worked on years ago we had the per unit cost from another operation, so we could work out the cost of setting up remote monitoring for the two main productions lines was the equivalent of employing a person to do the relevant manual monitoring for ten years, heavy costs in safe installation of cabling as wireless gear was no good due to electromagnetic interference in the building. The current system had one person doing the manual monitoring of those two lines and three auxiliary lines that would still require the person to do, or more than double the costs to do the lot. Decision was made to leave it as manual.
This sort of analysis is where the consultants will be good, but they need clear goals before they can do any real estimates.
What do you want monitored?
How much do you want monitored?
In the past I've had a little to do with setting up remote manufacturing machinery monitoring, but that was with direct cables and we had to know which of the instruments were worth such detailed monitoring. Experience has shown you do NOT need to monitor everything on everything all the time. Some are best with snapshots taken at different times, otherwise you get buried under way too much detail and fail to see the forest as a whole for the trees and the brush.
Another good point is how you want the information to be displayed, in some cases raw data as digits is good, while others are best shown as a line graph.
In short, you need to point out there's many hours of work needed to establish the relevant goals before you can even estimate how much it's going to cost to do, let alone any benefits.
One case I worked on years ago we had the per unit cost from another operation, so we could work out the cost of setting up remote monitoring for the two main productions lines was the equivalent of employing a person to do the relevant manual monitoring for ten years, heavy costs in safe installation of cabling as wireless gear was no good due to electromagnetic interference in the building. The current system had one person doing the manual monitoring of those two lines and three auxiliary lines that would still require the person to do, or more than double the costs to do the lot. Decision was made to leave it as manual.
This sort of analysis is where the consultants will be good, but they need clear goals before they can do any real estimates.
M2M will only ever be applied to simple context decisions where the cause and effect of management problems is constant and well defined. I.e like a fridge ordering milk. But even then, the technology will probably not be that great. Why? Because your 10 year girl (who doesn't know) or your 18 year old boy (who does care), will not put the Milk back in the exact right fridge hole. The fridge will think your out of milk and you'll end up with new orders of milk when you already have three in the fridge.
So this is my response to such a CEO: have you a decision in your business that you will always know the source circumstances of the problem and exactly what the solution will be? (Plenty of these do exist by the way) If so, then sure, I reckon we can build a M2M device to help you out. If not, then you probably stuck with people as managers. What a bugger!
So this is my response to such a CEO: have you a decision in your business that you will always know the source circumstances of the problem and exactly what the solution will be? (Plenty of these do exist by the way) If so, then sure, I reckon we can build a M2M device to help you out. If not, then you probably stuck with people as managers. What a bugger!
There's always been "M2M" interaction - it used to be lumped under a label called "interfaces". As computing power has increased, size decreased, etc., etc. the opportunity to do more capable M2M has increased as well. To me this extends virtually everywhere. For example: the Jan 2013 issue of Wired has "robots" as its feature, which (other than the autonomous variety) are quintessential M2M applications.
Another cutting edge discussion, I have a client interested in and a co-consultant has another. After lengthy, relatively lame phone calls with Dell, where the representatives seem trained to qualify every statement with a perhaps and maybe, it does not offer many benefits to a standard platform. IF you have a project and have to hire, FAST, a whole slew of temps to start pounding away, THEN it makes some sense but otherwise it is a dead dog issue for the standard office.
There are a number of technologies that when used together could eliminate the problem of unneeded milk being ordered. In this case, a 'smart' fridge would team up with dumb, but enabled packaging (RFID comes to mind) so it knows what is on each shelf and, with a shelf weight sensor, how much product exists. As items are removed and returned to the fridge an exact measurement (where only 1 item is removed) or an approximation (in the case of multiple items) can be used to deplete the inventory quantity of the used item. It really is simple math once the base data is known if you've got the proper senors in place.
The same would be true but on a grander scale (computationally speaking) to link traffic lights with each other and vehicles. Here queuing and cost algorithms are at play for the decision of when to change the light from red to green, but the basic inputs are relatively few.
The same would be true but on a grander scale (computationally speaking) to link traffic lights with each other and vehicles. Here queuing and cost algorithms are at play for the decision of when to change the light from red to green, but the basic inputs are relatively few.
In order to achieve this in practice, you would have to impliment a standardised packaging system across all food products. That will never happen! We ca not even standardise country of origin labelling in food. Food systems only ever become less standardised over time (because of economic drivers like product differentiation and competitive advantage). Plus such a system will inevitably require a high level of managment by user (beeping foods in, telling the fridge what are stock items, verus birthday presents, etc), which history says, people don't care for (people don't like technologies that make their life more difficult). Also because of the advanced technology required, such a fridge will always be more expensive as compared to other non-techo alternatives. And comparative cost is always a major factor in technology adoption.
So I return to my original point. Because the user context around food and fridges is so complex, automated systems like this example will always come up short for the majority of the market (users/potential adoptors). I agree, such a system is technically possible within a computer lab and will get lots of attention at the latest CES Conference. In the real world of consumer habits, food economy and product commercialisation, I expect any attempts to commercialise such a fridge technology will prove to be a great way for tech companies to burn a whole heap of cash for nothing.
Tech developers must appreciate the real-world applications where computer techs are useful and where they are not. Company's simply can not afford to continue take hit-and-miss guesses anymore. Its simply too expensive to do so.
So I return to my original point. Because the user context around food and fridges is so complex, automated systems like this example will always come up short for the majority of the market (users/potential adoptors). I agree, such a system is technically possible within a computer lab and will get lots of attention at the latest CES Conference. In the real world of consumer habits, food economy and product commercialisation, I expect any attempts to commercialise such a fridge technology will prove to be a great way for tech companies to burn a whole heap of cash for nothing.
Tech developers must appreciate the real-world applications where computer techs are useful and where they are not. Company's simply can not afford to continue take hit-and-miss guesses anymore. Its simply too expensive to do so.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
