There are so many things that can affect performance that it's hard to know where to begin, and since you're dealing with a canned vendor package there are very definite limitations as to what you can do without jeopardizing your support from them.
The obvious things to check are to make sure statistics are current, indexes and tables aren't badly fragmented, and that there's no corruption. I run DBCCs every night, the size of the database(s) and maintenance window dictates whether that's possible. Since there is already an FK relationship, you know the data types match, so you shouldn't be getting any flack from the query optimizer for problems involving joins with those tables.
Have you restored a backup to another database to make sure they are restorable? That's ALWAYS a good thing to confirm if there's any risk of corruption. A DBCC problem can be indicative of a disk problem, which could cause performance issues. So there's lots of things that you can dig in to.
If you can identify a specific process/query that's performing poorly, if the database is small enough that you can restore it elsewhere, running said process/query against the new copy and seeing if the performance is similar could be informative.
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]