お客様の業務を理解して、システム全体をデザインして導入し、保守していく能力です。システムに関すること全部じゃないかとおっしゃるかもしれませんがその通りです。
ここでは、技術を分割している関係上、お客様の要件を理解してシステムの実装に落とすことに着目します。要件定義能力といってもいいかもしれません。

お客様とお話ができるというのは重要なことです。「どういうこと？」と思うかもしれませんが、業務をシステム化する以上、業務を知らなければできません。たとえば医療業界では医学の専門用語が飛び交い、業界の常識が当たり前のように理解されていなければ使えない物が出来上がることになります。場合によっては、生物学の常識を知らないと、たとえばデータベースのキーに患者の名前、生年月日、血液型等を入れてしまうかもしれません。病院では血液型は変わる可能性がありますからそのような場合でもキーにはできないのです。(白血病などで骨髄移植をすると血液型が変わる可能性がありますし、病気の種類によっては検査上違う血液型と判定されることもあります。)
流通業界ではリテイルの常識を知らないとシステムの拡張性に関する作りを間違えるかもしれません。部門が増えたり商品カテゴリーも商品特性ではなくメーカーによって違う扱いにしてあったり、同じメーカでも複数の部門にまたがることもあります。（塩コショウ、焼き肉のたれは、一般食品(グロッサリー)扱いのものと精肉部門扱いのもの(生たれで冷蔵が必要なもの、ハムメーカの塩コショウ等)があります。）これらは会社の方針によりますが、このことを知って柔軟に拡張できるシステムにしていないと、新たな取扱商品が処理できないことになりかねません。同一商品他部門扱い価格違いチェック等の問題も発生します。
研究系などでは研究論文を読まないと駄目である場合があったりします。この場合は大学等でその分野の研究に携わっていないと理解できないことも多いです。実務では論文の内容をシステムで実装してくれという乱暴な依頼も経験しています。
官公庁のシステムでは法律を執行するためのシステムですから、当該法律(たとえば社会保障関連の法律群)を理解していないと、システムが作れなかったり、仕様書に法律と行政解釈(電話帳の２倍くらい厚い)がついてきたりします。

これらの業務知識は一朝一夕では身につきませんが、身についてしまえばそれは資産というべきノウハウになります。こういうノウハウがあるためにISerはこのような各分野における業務知識を独占しようとします。
極端な業務知識でなかったとしても、その業界の人と話ができるということは重要です。これ自身SIに携わる人にとっては技術・能力となることを理解する必要があります。