The RPM Effect (Rapid Project Maker)
ericmedley
Posts: 4,177
I am fully aware that in this venue any discussion of this topic can quickly devolve into a long series of rants. let me state clearly I am hoping that it doesn't and we just have a civil discussion on the merits or lack thereof of RPM and how it effects what we do.
Now that RPM has been out in the wild for some time now I've collected a few anecdotal notes as to how its presence has effected my independent programming (AMX VIP) business. At first blush my emotional reaction was that it was basically a programmer replacement tool; allowing non-programmers to create working Netlinx projects. My concerns were usually met with explanations from AMXers along the lines that it was not meant to replace us programmers but was meant to be a fast and easy tool to create simple projects that were in some ways "beneath us" or "too simple of a system to waste our brain power on"
I actually gave it a few tries myself, but being a programmer, I found it to be cumbersome and frankly annoying as it drags you kicking and screaming through a series of steps that may or may not be needed to finish the project. Enough, however, of my opinions on it which none of your really care about anyway.
To my topic: Now that I've had enough time to live in a world with RPM I can see some interesting trends as to its use by integration firms. (my stock and trade) I can say it does tend to have an effect on my business; particularly in projects where there are multiple spaces like conference centers, large commercial/industrial. The kinds of projects that seem to come into play are projects where there might be several conference rooms/teaching spaces/board rooms in one facility. At first I was finding that it was kind of an all-or-nothing game that I either got hired to do the whole thing or they would try to do the whole thing with RPM. And since RPM has a definite project scope limit, the integrator would, in an effort to keep the whole project within RPM, would scale down the parts of the project that went beyond it's capabilities. I'd get feedback from clients that they were under the impression that the reason for scaling back on certain desired features was that "AMX couldn't go there" or that "The customization required to go there was cost prohibitive."
In an effort to try and play nice I've tried to adapt by figuring out ways to do a more 'ala carte' approach and just sell my services only where needed. So, I've been involved in several projects where I'm doing the bigger, more complicated, more custom rooms and the integrator is using RPM to do the simple spaces. The main effect this has had on me is I spend quite a bit of time sussing out RPM problems that I'm not billing for as well as shrugging and saying they'll need to contact AMX for what end up being true issues with RPM.
I'm not a very good liar or actor. So, it's hard for me to hide my feelings on the matter. My overall feeling is that RPM has not really done much to make the end user feel good about AMX in general. The honest truth (IMHO) is that it does nothing much different than any of it's lower-end competitors like Control4 or Savant and has only taken the whole brand down market. It may well be the goal for all I know. All I do know is over the past year or so, I've had several discussions with Integrators and end-users who are surprised that AMX can actually do 'X"; that they thought that was only the province of Craptron; that AMX was just an expensive Control4 or whatnot. Bear in mind, my clientele are all commercial. This is not a bunch of know-nothings.
Numbers are a bit difficult to put together. Anecdotally I can safely assume there has been some effect. When I look through my last year I can see a pretty consistent presence of RPM in projects I didn't get (In other words: the client told me they opted to scale back the project scope/complexity and do the gig with RPM instead of using their programmers and/or me) As well, the number of projects where I'd be doing several spaces within the whole project - my scope footprint was reduced to just the more complicated spaces. I am not even considering the "Ones that got away" and I don't know why. I'm only dealing with the ones where I have good feedback. Every year I've done this I've seen fairly consistent growth from year to year. This year is going to be close; I'll either have slight growth or be nearly even. Fortunately, this kind of project is not the only egg in my basket. I also do Military/Govt/Commerical stuff that RPM is nowhere near ready to tackle.
I fully realize that my situation is not the 'norm' and that many of you may use RPM to your benefit. But, I would be curious to hear other stories with regard to how RPM has helped/hurt/neutral them.
Now that RPM has been out in the wild for some time now I've collected a few anecdotal notes as to how its presence has effected my independent programming (AMX VIP) business. At first blush my emotional reaction was that it was basically a programmer replacement tool; allowing non-programmers to create working Netlinx projects. My concerns were usually met with explanations from AMXers along the lines that it was not meant to replace us programmers but was meant to be a fast and easy tool to create simple projects that were in some ways "beneath us" or "too simple of a system to waste our brain power on"
I actually gave it a few tries myself, but being a programmer, I found it to be cumbersome and frankly annoying as it drags you kicking and screaming through a series of steps that may or may not be needed to finish the project. Enough, however, of my opinions on it which none of your really care about anyway.
To my topic: Now that I've had enough time to live in a world with RPM I can see some interesting trends as to its use by integration firms. (my stock and trade) I can say it does tend to have an effect on my business; particularly in projects where there are multiple spaces like conference centers, large commercial/industrial. The kinds of projects that seem to come into play are projects where there might be several conference rooms/teaching spaces/board rooms in one facility. At first I was finding that it was kind of an all-or-nothing game that I either got hired to do the whole thing or they would try to do the whole thing with RPM. And since RPM has a definite project scope limit, the integrator would, in an effort to keep the whole project within RPM, would scale down the parts of the project that went beyond it's capabilities. I'd get feedback from clients that they were under the impression that the reason for scaling back on certain desired features was that "AMX couldn't go there" or that "The customization required to go there was cost prohibitive."
In an effort to try and play nice I've tried to adapt by figuring out ways to do a more 'ala carte' approach and just sell my services only where needed. So, I've been involved in several projects where I'm doing the bigger, more complicated, more custom rooms and the integrator is using RPM to do the simple spaces. The main effect this has had on me is I spend quite a bit of time sussing out RPM problems that I'm not billing for as well as shrugging and saying they'll need to contact AMX for what end up being true issues with RPM.
I'm not a very good liar or actor. So, it's hard for me to hide my feelings on the matter. My overall feeling is that RPM has not really done much to make the end user feel good about AMX in general. The honest truth (IMHO) is that it does nothing much different than any of it's lower-end competitors like Control4 or Savant and has only taken the whole brand down market. It may well be the goal for all I know. All I do know is over the past year or so, I've had several discussions with Integrators and end-users who are surprised that AMX can actually do 'X"; that they thought that was only the province of Craptron; that AMX was just an expensive Control4 or whatnot. Bear in mind, my clientele are all commercial. This is not a bunch of know-nothings.
Numbers are a bit difficult to put together. Anecdotally I can safely assume there has been some effect. When I look through my last year I can see a pretty consistent presence of RPM in projects I didn't get (In other words: the client told me they opted to scale back the project scope/complexity and do the gig with RPM instead of using their programmers and/or me) As well, the number of projects where I'd be doing several spaces within the whole project - my scope footprint was reduced to just the more complicated spaces. I am not even considering the "Ones that got away" and I don't know why. I'm only dealing with the ones where I have good feedback. Every year I've done this I've seen fairly consistent growth from year to year. This year is going to be close; I'll either have slight growth or be nearly even. Fortunately, this kind of project is not the only egg in my basket. I also do Military/Govt/Commerical stuff that RPM is nowhere near ready to tackle.
I fully realize that my situation is not the 'norm' and that many of you may use RPM to your benefit. But, I would be curious to hear other stories with regard to how RPM has helped/hurt/neutral them.
0
Comments
Often times, I don't get to make the decision on what control system I'm programming. Either the customer has a preference or a consultant or similar has spec'd before hand. So I make what I have work.
I feel the same way about RPM(and RMS, and Duet modules, etc). I would never be an advocate for any of them. I can do it better and more reliably with good ol' Netlinx. But if that's not what they want to buy, so be it. Someone still has to configure it, and I'll still pick up the phone, and I'll still bill for it.
What we need to be good at is managing expectations and communicating clearly what the customer is buying, and if appropriate, what an alternative would mean and how those differences would affect them. Those could be internal customers or end clients you're communicating to. If you've got the programming chops(or something in the code bucket) that can benefit them, why would they not want to entertain at least hearing the difference, as long as you know how to present it.
But... RPM sure falls so flat on it's face once you get outside of it's established sandbox. You've got to understand where to draw that line when choosing how to approach systems. There are also hella annoying little functionality quirks in the RPM modules, but they are still "good enough" for general production.
I expect a lot of my custom systems will eventually be overtaken by RPM-programmed systems, but that's gonna take awhile. The refusal to support non-amx equipment in modules means it will be a few years before we replace existing equipment with RPM-supported equipment. In the meantime, I guess I still sorta have a job.
That's just sad and doesn't say much for AMX's mindset.
Ugh that made my stomach hurt.