We've said it before and we'll say it again--the current economic climate is presenting many IBM i shops with the perfect opportunity to prove their worth and make sure the IBM i (and they) are around for the future. A lot of the more ambitious (and often futile) major software changes are on hold. In other cases (and we learned of another such example today) the financial climate is making companies take a long hard look at the true economic realities of the "miracle" software that they have been struggling to implement. The result of such reality checks is invariably a realization that the new system has racked up at least twice the originally projected cost, uses far more hardware and manpower than promised, and often under performs. Pity that it took an economic disaster to make people realize what many of us could have told them before they started!
One successful tactic that an increasing number of shops are trying involves having your IT department act as a vendor. If you know that software/hardware package XYZ is under consideration, ask to be considered a vendor. Put together a bid and ask for it to be considered as an alternative. Even if you factor in the costs of a major rewrite of your existing applications, add the cost of learning new skills, and add in a few experienced contractors to help mentor the team and bring them up to speed on the "new stuff" we'll lay you odds that you will still come up with a budget that is less than 50 percent of package XYZ. You'll also find that you can set a project time-line that is significantly shorter than that for XYZ, and will offer greater customization for the users. You can do it. It works. After all, who knows your business better than you?
In other shops, we're seeing smaller projects emerge where IBM i developers seize the opportunity to show off "what i can do" that impresses their user communities. You may be surprised how much impact you can have by trying your hand at small modernization projects, such as producing browser interfaces to what were spooled file reports (many ways to do this, most requiring minimal modifications to existing RPG report programs) or providing an easy Web service via XMLSERVICE.
On the subject of modernization, Jon did a lunchtime seminar for the Atlanta User Group (amcu.org) today titled "Modernizing Your Applications--For Free" where he focussed on many of the free tools that we have mentioned here and in our columns for IBM i EXTRA. It was a good crowd--bigger than they've had in a while apparently--and the subject fit in well with their theme for this year's education series, which is modernization.
Jon challenged his audience at AMCU today to "just say yes" when requests come in for "out of the ordinary" application functions. Say yes and worry about how implementation. If you say no or even if you say, "Let me get back to you on that after studying the options," before you know it, someone in the Windows group will have jumped on the project or the users will have found a packaged "solution". As a result, you may well end up spending more time in the long run wrestling with integrating what they did than it would have taken to implement the project on i to begin with.
AMCU is also planning to cooperate with other user groups that are working to update their members' skills. One such group, SEMIUG (the Southeast Michigan iSeries User Group), is currently working on a collaborative project aimed at teaching members new skills while helping to demonstrate the viability on the IBM i as a modern platform. In fact SEMIUG's meeting tonight is dedicated to a progress report and anyone can join the webcast and see what they are up to. See here for details.
We applaud efforts like this and intend to work with these groups whenever possible.






We are proof that becoming your own vendor is more cost effective. When we had a costly and fragile vendor solution to create our customer bills, we took it on in house and saved thousands of dollars a month. When our change management software licensing doubled and tripled, we wrote our own PHP solution. When we needed to encrypt our credit card data, we wrote it in house. Besides the incredible cost savings, we get two very important side effects: 1) when we need/want a change, we can do it quickly and 2) we only write what we need. Most packages give you more than you need in some areas and miss key features that you want. It's important to note that training and research played a key role in developing these skills sets. Thanks Jon and Susan for dipping our toes into PHP! So yes, be your own vendor!
Posted by: Jeb Bouchard | January 19, 2012 at 06:35 AM
@Jeb Great comment Jeb - thanks for sharing that - and delighted that we have been part of that transition.
Posted by: Jon Paris | January 19, 2012 at 09:07 AM