In general, it depends upon the definitions of your organization. However, there are some fairly "sticky" definitions out there that might just help your organization agree on something and then understand the importance of definitions.
So, what you asked without any additional context AND given that definitions vary - they could be the same and then again they NOT could be! [img]images/icons/smile.gif[/img]
I tend to embrace Glenford J. Meyers's definitions as updated by Boris Beizer's definitions.
To me the term "Integration" is too broad. At that broadness, it could mean unit/component/module-level, or sub-system, or system, or multi-system.
Let us say the many people you refer to, meant to say that "System" & "System-Integration" testing are the same. (not to be confused with SystemS Integration)
Using my own inherited base definitions, I would vote that "System Testing" and "System-Integration" testing are different according to the focus of the type testing. In the latter, one is validating successful integration at the system level. Contrast that with "System" testing according to my borrowed definitions & the testing focus becomes broader in terms of all the "...abilities" one should validate.
System Testing in many cases would naturally include or by default, validate "System-Integration" since the intent of System Testing is to prove that the System is equal to the "as-intended", "as-designed", "as-built", "as-delivered", "as-adjusted-by-changes-and-accepted"! Therefore, one will be default prove or disprove correct integration.
(Both Meyers and Beizer refer extensively to ... abilities).
The bottom line...
Have an agreeable set of definitions! It sure makes it easier to set expectations. [img]images/icons/smile.gif[/img]