What I mean by sequential is to just don't do the same task simultaneously. So if you are calling a stored procedure, just make sure your package only calls that stored procedure once and waits for it to complete.
Dumping the file/record into a temp table and having that happen multiple times at in your SSIS package (pulling all files from disk and pushing them to the same database table all at once) you will have blocking again. This time, the blocking will be on the temp table though which will be less impact to end users, but still the same snags.
Without seeing your SSIS package and knowing how it is set up, it is tricky to help with this, so I am just trying to describe the concepts for sequential processing instead of stream processing.
But my approach would be if the file names are static, I would build it up as step 1 pulls file 1 into the database and does all work that needs to be done. Once step 1 completes, move onto step 2 and repeat until all files are processed. That is if all files need to do inserts/updates on the same table. If I can break them out into isolated tables (such as file1 pushes data into the table file1 and file2 pushes data into the table file2 and so on), then I would run all of those at once. If I needed to combine this data later, I would build up a VIEW for it. This way I have multiple independent tables that are smaller and easier to work with and a view (likely an indexed view) for the larger data set. This way I can do updates on all of the file tables at the same time without impacting the other file tables. Probably turn off the index on the view prior to starting the data import and turn the index back on afterwards, but depends on how much data is changing. If it is 10% of the data or less that is changing, I probably wouldn't bother with the index disable, but that is just a guess. Best way to tell is to test it. Using the multiple files to multiple tables approach should result in less blocking. May still get blocking (ie will) if someone tries to SELECT from the view or tables during the update, but that should be short lived.
Alternately, rather than rewriting your SSIS package, having some better indexes on the main table may make your updates faster in which case blocking would be shorter. Or possibly you have too many indexes or duplicate indexes. Having the data ordered in a way that makes your WHERE clause faster to search for will result in faster queries. Having duplicate indexes or too many indexes will slow down the insert/update performance as each index will need to be modified with each insert/update. As to which indexes to keep or how many to keep, it depends on your use cases and queries. it might be that you can't remove any indexes and there are no good ones to add. But if you have any duplicate indexes, those should be safe to remove and should help performance. If you have unused indexes those MAY be safe to remove, or they may be used just very infrequently. Be careful with index maintenance if you go that route. You will need to review any indexes before removing them. An index on column A and B may look like a duplicate to an index on column B and A, but they may (ie very likely) be ordered differently and thus may both be required.