Your first need is a detailed business assessment. If you do not have a solid understanding of the overall business (or individual business units) needs or desires, you cannot design a solution to meet them.
The best way to handle this is through a set of informal workshops, which include a high-level introduction to the technology, what it does, how the departments and end users benefit, and possibly a short demonstration of the product.
The three main reasons you hold these workshops are:
To inform departments of what you are doing
Get their buy-in
Get their feedback in the form of requirements
The meetings should sufficiently inform department members so they begin to give you feedback about how they will leverage the system. Remember that you are only gathering data at this point; do not make any commitments.
The following list presents some ideas on what you need to define. Think of these as the bare minimum; use your imagination and tailor them to your organization's unique landscape along with any industry methodology that you might be following, such as ITIL.
Who are they and what business function do they have?
What do they need support for? For example, software
What types of request will they make? For example, X is broken, how do I achieve Y, I need Z
What response are they expecting? For example, if X is broken, then it must be fixed within Y hours
After you have your first set of meetings with the greater business, do the same with the IT department.
Who are the support staff?
What can they support?
What types of request can they deal with?
What response can they deliver?
There will be differences between what the business expects and what IT is capable of delivering. You will need to meet with the various parts of the business again, or even several times, to discuss these and obtain alignment. Only then should you move forward with implementation.
This is not a static exercise. You need to review and adjust over time as requirements change.