Yes, FP can be used in enterprise applications. Clojure is one example of an FP language with success in enterprise: http://cognitect.com/clojure#successstories
Representing state can be a challenge in FP and changing paradigms to fit FP can be a bit of a mind warp. Some FP languages completely disallow side affects and mutable state. Clojure allows both but discourages or isolates those paradigms.
In short, state representation may be very similar to OO. It's state modification that is very different. So for instance, in FP state may be represented by lists and maps. A list of employees may look like:
[[name: "James Brown" address: "Barnwell, SC"]
[name: "Elvis Presley" address: "Tupelo, MS"]]
There are two ways I know of to handle state modification in FP. One is something like functional reactive programming. In this paradigm all state is handled at the highest level only... for instance, an HTML view of your application has state in the view (like the person's name, address, etc.). Now when you click "update name" a function is called that handles every thing about a name update except actually changing the name. This may sound weird... but bear with me. The changed name would then be returned by the function and the view (or persistent data store, etc.) will show the new name. Or, alternatively, an entire new structure with the updated name will be returned. So what does the function do? It validates the name and returns the new name if it is valid, an error if it is not, and possibly a new view or navigation link to follow. For something more complex than a name change it may do a lot more.
So for FRP the object returned by the function is the new state and can be given directly to the view or whatever is at the high level. In some cases FRP takes the whole state passes it to the function and gets the whole state back.
With this paradigm, the container or framework needs to handle the update of the display, database, or whatever else needs updating from the new state. So you can imagine a framework that draws the application on screen. When a user clicks something functions are invoked and the new state is returned. The framework then updates the screen by either redrawing everything or intelligently redrawing parts of the display. See http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/
Clojure uses the second paradigm that I've come across and that is to isolate state changes but not necessarily restrict them to the highest level. With Clojure all mutable state must be "held" (unless you're using Java objects for state) by an atom, agent, or reference. The way this works is the object held or pointed to or referenced (however you want to call it) by the atom/agent/ref is immutable, but the atom/agent/ref can change to point to a new object. In this case you use special methods on the atom/agent/ref that say "update the object here by doing such and such and reassigning the atom/agent/ref to a new object".
Why is this beneficial you may ask? Because the immutable object referenced by these Clojure constructs may be passed to a function that does something and while that function is running its reference to the object is guaranteed not to change. That is, the atom/agent/ref isn't passed to the function but the immutable object pointed to by them is passed. Atoms, agents, and refs have special properties that handle updates and concurrency in ways that are safe and part of the language. See http://clojure.org/state
I hope this helps. I suggest reading more about Clojure state and FRP to get a better understanding for how employees and persons can be represented in FP. Though, the actual representation would be similar to object oriented programming... it's the mutability that is really different.