Is a unified, enterprise-wide information system a feasible or worthy goal?

Question

Considering the vast amount of digitized information sitting in each department of a large organization, is it a worthy goal to refocus information systems development away from linking individual systems and start considering a single infrastructure that aspires to be flexible and extensible enough to meet all the current and future requirements of each department?

For example, sales has a CRM package but would like to integrate with a custom-built system that the legal department uses. Both refer to the product database that is managed by the engineering and business development departments. Business rules across departments abound.

This web of dependencies is messy- so I am wondering if there is any best practice in dealing with this. Is a single "system to rule them all" a practical approach?

Does this type of goal amount to a net positive for the business, or have you experienced net negative effects?

It would obviously be an iterative development process but should some pieces get rolled out without a full spec + implementation, or would it be better to run a parallel system and cut over at a certain time?

I still haven't mentioned the business requirements of the finance department... :)

Answer 1

As soon as you can construct a development organization that everyone who has profit-and-loss responsibility can agree will fairly balance everyone's priorities and understand their needs at least as well as the people under their direct control do, and will allocate resources as efficiently and responsively as they can acquire them from elsewhere, then it would make sense. But I'm not holding my breath.

Answer 2

I've worked on a number of these... at early stages of just trying to get all the players in the same room to actually building out something that was "agreed" upon. No matter what happens, who does it, how it comes about, etc, etc, it's painful.

The problem within an existing organization is that each group - sometimes department, sometimes product team - has developed their own tools and methods for getting the job done. No matter how inefficient or out of date it might be, it's theirs. If you can get these people willing to check out the system, that's a starting point.

The next problem you'll run into is that each team does things a bit differently, has different jargon for the same things, and wants to store/interact with the information a bit differently. While this doesn't seem like a huge thing, it is.

The complexity compounds with each and every group you add to the mix. And if you think "well, I'll start with this group and add more and more groups as I go!", it doesn't quite work that way. Once you launch it with one group (sales?), the other groups will see it as the "sales system" and be adverse to doing it.

Trust me... there are reasons why ERP-type system runs into the 10's of M's... it's not all technical, lots has to deal with the willingness to put up with this crap.

Answer 3

When you have one monolithic big-@$$ mainframe/etc, that becomes more do-able. However, in my experience, I fond that each department has its own priorities, wants and needs. Quite often, they are not compatible with each other. If you try and make these things fit together, you can never get total agreement on the end product, and probably never server your departments to the level they require.

This also leads to a secondary problem where the departments build their own ad hoc systems in secret (probably in MS Access or Excel); that you discover years down the line when the maintainer quits/retires/is_fired, and the department discovers it needs some kind of maintenance.

There's also a timing issue. You now end up with multiple departments waiting on the upgrades for another department before their can get their own. Sorry, F&A - you can't have your tax update until engineering gets their fizz-bang enhancement in, an they are 2 months behind schedule already.

I think it is saner to have multiple systems dedicated to the task at hand. If data needs to flow from one department to another; that's where glue code and interfaces come into play. Or in the worst case situation, you just add it to a humans task list. "Clerk Jane, on Monday, you are going to print report X and send it over to Dept. Y through inter office mail."

Answer 4

In short:

• an organisation in a growing market has better things to spend it's money on than this kind of global optimisation of costs
• in a stable or contracting market, it's unlikely to be financially viable unless it leads to real savings: i.e. job losses
• the people who would lose their job if it succeeds almost certainly have an effective veto over it's success.