Tuesday, March 02, 2010
When do programmers contribute to "the bottom line"?
Patrick Gray has an intriguing Tech Republic blog article, “Is IT a profit center or a cost center? Who cares?”, with link here.
The article discusses creative accounting or allocations that try to justify or quantify what an internal IT department produces for an organization. The idea comports with the idea of “internal customers”, and a customer service culture even internally in a company, particularly companies that set up centralized customer service calling centers.
Of course, over time (spanning decades) a higher percentage of IT professionals have become employed by “staffing companies” for which the consultants actually bring in revenue in the form of billable hours. The development of purchased systems (like Vantage for life insurance) has contributed to this trend.
Career consultants talk a lot these days about quantifying results on resumes, and showing how one as an individual contributed to the "bottom line". Sometimes the quantification is indirect: by automation, positions can be eliminated and costs reduced (and it sounds brutal, doesn't it?)
In one consulting company for which I worked around 1989, “computer costs” in terms of disk space and excp’s were accurately tracked between divisions to show “profitability” of particular operations.
Sometimes within a company individual departments want more control of their own “end user computing”. Back in the mid 1990s, “client-server” end-user applications, standalone, sometimes coded in Microfocus COBOL, were seen as a way around mainframe cost allocations. One problem could be that security, when applications were decentralized, would become much weaker. In time, however, external Wall Street pressures caused companies to consolidate, using mainframe legacy replication with Unix or Linux mid-tiers, direct-connect, or sometimes consolidating applications altogether after mergers, ultimately eliminating internal programming jobs (particularly after Y2K).