Interesting point this, Business versus IT, might be worth a separate posting.

I'm strongly against business systems being owned by IT but recognize the practical problems. The situation is slowly improving but in my experience the business has difficulty in (1) accepting the responsibility of ownership and if they do (2) actually performing the tasks involved. 

Which tasks? The Business Information Services Library (BiSL) provides a useful framework that addresses:

• day-to-day support and control from a usage perspective: helping users to use the system as intended
• specification of changes to the functionality, acceptance testing, implementation in the user organization
• managing services and service levels from a demand management perspective
• translating business strategy into information (not IT) strategy and managing the information lifecycle portfolio

What are the practical problems that business organizations encounter? It usualy boils down to two things: competencies and power. As far as competencies are concerned, it's often the the case that these tasks are allocated to key-users who are well-motivated but but lack both analytical skills and knowledge of information management principles. The other problem area is power. Even if the employees are well-equipped to perform these tasks, if they operate from within a weak staff department they're going to be overruled by line managers with P&L responsibility.

So, when confronted with such an immature (information management wise, that is) business organization, it's very tempting for IT to claim ownership. But it ain't right. Enlighten, yes. Educate, yes. Support, yes. Disqualify and ignore, no. I like the metaphor of power assisted steering versus steering. It's up to IT to offer power assistance and to resist the temptation of actually steering.

And the same applies to the business: leave the T in IT to the professionals and just focus on the I: that's where the value-side of the equation is.

--- In erp4it@yahoogroups.com, "Charles Betz" <charb@...> wrote:
>
> 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.
>