Justin:
* For enterprise-wide data modeling, be as business centric as you can. ERD's are very business centric - plus they focus on interrelationships. A big problem with the UML is that all the models - data, fucntion, state - try to slant things towards implementation considerations. They are meant for BA's who are programmer wanta be's. If you try to, at the same time, think implementation AND design on an enterprise wide effort, you will fall into a confusing mess.
* Sounds like you have the very common situation of a bunch of lower level flow charts that do not tie together - and you can bet you bottom dollar are very disjointed. You need to take an integration approach, and to do this you need approach analysis from a higher level of abstraction (i.e., take a bigger picture approach). You can not approach larger scale process/fuinction analysis from the bottom up; you will drown in an ocean of detail if you try.
One of the toughest things about working at a higher level of abstraction, is that you have deal with the fact that at this level, systems are non-sequenctial. Therefore, you can not use a sequence based modeling techinque to model process/fucntion. (All the process/function UML techniques, except Use Cases, rely upon sequence - and Use Cases are useless as they do not model the essential interrelationships.) Only data flow diagrams will do.
* Requirements tracability is an exercise in proper system decomposition: To trace requirements from the higher level of abstraction to the detail level. Only data flow diagrams lead to a logical decomposition.
Tony