It would be better to store the TAGs as a Child Table, one tag-record per row. Easy to say .. might not be easy to do of course!
last_mo_source_tag like '%sep%'
Will match any tag-value that CONTAINS "sep" - which might not be what you want, so you might need
' ' + last_mo_source_tag + ' ' like '% sep %'
if they are space-separated (can do similar for a different delimiter, like "," for example). That will run even slower
This sort of ambiguity comes about whenever the database structure is bypassed and columns are overloaded with multiple values. The typical one is Users who tell me they want a reference "XXX123YYY" were "XXX" is the company/geographic-area/etc., 123 is the actual, unique, reference, and "YYY" is the person handling that business - or some other data-attribute. What they should really be using is "123", but when they write the Reference on a paper-file / email it carries with it all the other useful information. Trouble is, it changes - and the historic emails never do, nor does, usually, the physical file wrapper ...
Store it how the database would prefer to have it, and performance will improve (along with data integrity!)
You could still have the [last_mo_source_tag] column in "human readable form", just add a Trigger to the table which "splits" the [last_mo_source_tag] value on its delimiter, and stores the values in a child-table. You can then use that for query purposes, and the user-form / other code won't need to change.