I have seen business applications owned by both the business and by IT, and currently work in a mixed environment. There are arguments on both sides. Business owned IT is typically more agile but less stable, and too often critically dependent on key individuals. IT-owned applications are typically less agile but more stable and more likely to be designed & operated for the long haul.
The segregation of duties issues should be considered carefully for any business-owned IT. Especially for systems concerned with revenue & its recognition, there is a potential conflict of interest if the business owner also has operational technical control over the systems and especially their data. Any good IT auditor will flag this.
-Charlie
-----Original Message-----
From: erp4it@yahoogroups.com [mailto:erp4it@yahoogroups.com] On Behalf Of Cary King
Sent: Tuesday, May 27, 2008 5:48 PM
To: erp4it@yahoogroups.com
Subject: [erp4it] RE: ERP Systems by Ross McConnell
To your points:1. & 2. Your math is correct.3. Non Causa Pro Causa. Your assumption seems to be that IT is the problem. I submit it is not. The business units, or in your case, governmental units, have an option to cooperate to build the different systems (unless prohibited by law). It is not IT that prevents this, it is the business units that choose to not cooperate with each other. IT is, and needs to be, a separate business unit from others precisely because of the specialized skill sets - just as are Finance, Accounting, HR, etc. IT must, in fact, own these systems because IT is the organization with the specialized skills to implement, operate and support them. IT does not, however, own the people, policies, or processes - the business does. If you feel the business units need to share to gain commonality by sharing, how would having the business units each own this help?4. & 5. & 6. Also non causa pro causa. Again, the implementation of governance, portfolio and project management is a policy and process issue, most assuredly not a tool issue. The business can, and should, insist on a service (not a project) portfolio. PPM is not a panacea by any means. It's not even a good start. Projects only cover about 20% of the IT budget and only cover the new changes. The real costs are of the services - the other 80%. A budget made up of demand for services that the business units will "buy" each year, not projects, would be useful.Actually, I'm too bored to go on with this...The individual business, or governmental, units have the responsibility to manage their policies, processes and budget. IT cannot be responsible for the outcomes of the business, only the delivery of services. For IT to deliver excellent IT service products it must learn to manage those service products as products - run IT like a business within a business. IT must get out of the idea that budgets can be effectively managed by column - travel, etc. - and must realize that to deliver a product there is a set of functions that work together.Realized benefits are primarily an outcome of good management and not necessarily the best technology.IT should never get into the position of having to document operational benefits, such as revenue gains, market share improvements, inventory reductions, product quality gains, or enhancement of customer satisfaction. Leave all such explanations to line management who are directly responsible for them.