Smartphones will soon replace laptops as the primary tool for service technicians.
Companies are realizing that laptops are expensive to maintain in the field, and no longer present a clear-cut alternative to a smartphone. In addition, many service personnel already have a smartphone with them at all times for communication needs.
Advances in core technologies have made smartphones quite capable for the diagnostic tests and troubleshooting of field service personnel. And new smartphones will still support legacy systems via USB adapters just as laptops do.
The main thing lacking is apps that integrate information for service technicians, which is no easy feat. The apps must be smart and collect data from various sources, including diagnostic test information, part procurement, customer and warranty information, and incident and problem reports to name a few. It is this total integration in a simple package that will be a game changer.
Please share with me your experience with moving your service personnel to a mobile platform.
-Gary
When it comes to technological solutions, you want a firm that has a proven track record of excellence. As one of the first software and hardware consulting firms in the Northeastern United States, Advanced Decisions is a leader in the industry. Our strength is not only in the experience that we bring, but also in our approach to developing solutions.
Showing posts with label Smartphone. Show all posts
Showing posts with label Smartphone. Show all posts
Wednesday, November 7, 2012
Thursday, June 28, 2012
My New Favorite Product
Pebble Technology in California has developed a watch using the new Kickstarter funding platform to raise over $10 Million by 68,929 backers. KickStarter is a direct offshoot of the JOBS Act, which enables entrepreneurs access to money from non-accredited sources.
I find the Pebble watch fascinating because it is one of the first products to act as a portable display device enabling hands-free monitoring of information on your smartphone. It is an intelligent e-paper wristwatch that communicates via Bluetooth with Android and iPhone devices.
And beside the fact that it’s just a cool product, what’s also interesting is that the company is planning an SDK to further customize the product to meet user needs.
Just thought I'd share my latest gadget-lust. Let me know what yours is.
-Gary
I find the Pebble watch fascinating because it is one of the first products to act as a portable display device enabling hands-free monitoring of information on your smartphone. It is an intelligent e-paper wristwatch that communicates via Bluetooth with Android and iPhone devices.
And beside the fact that it’s just a cool product, what’s also interesting is that the company is planning an SDK to further customize the product to meet user needs.
Just thought I'd share my latest gadget-lust. Let me know what yours is.
-Gary
Friday, March 11, 2011
A sad yet preventable story of software failure
I read an article today reporting that Nokia had announced that it was abandoning its development of its own Smartphone platforms and APIs. By itself, that’s not so sad. It’s smart to know when to cut your losses, right? The reason this story makes me sad, is that it was entirely preventable.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.
Subscribe to:
Posts (Atom)