Я тут скажу с тех позиций, которые разбираются в моей книжке "Системноинженерное мышление" -- http://techinvestlab.ru/systems_engineering_thinking
У ПГЩ прямо говорится, что "разделение труда" -- это про труд, который в деятельности (methodology realm из ситуационной инженерии методов), а вот работы -- они в предпринятиях (endeavor realm). Я ровно так это себе и понимаю.
На схеме/онтологии инженерного проекта в http://ailev.livejournal.com/1159110.html работы -- это works. В проектном управлении они обычно "разбиваются" (work breakdown structure), организовываются (распределяются по ресурсам и ответственностям), но никак не "разделяются". А вот труд не разбивается, ибо он сидит в технологиях (way of working).
В оригинале в Way of working практики, но я называю это "технологии" для подчёркивания завязанности на средства производства и материалы, капитал ведь именно тут.
Практики = дисциплина+технологии, дисциплину я отношу к команде, через компетенции -- невзирая на то, что навыки и компетенции по технологиям у команды тоже должны быть). Работы -- это выполняющийся труд (практики, которые проходят enactment). Труд делится по головам и связан с компетенциями, а работы разбиваются по ресурсам и связаны с логистикой. Когда у станков-роботов появится место, куда грузить дисциплину, в этот момент можно будет и говорить о разделении труда между станками. А пока можно говорить только о разделении между ними работ, а не труда.
Я бы это всё рассматривал больше понятийно, а не лингвистически. Лингвистика и попытки вытащить что-то "из живого языка" (очень разных лет и очень разных естественных языков) дают только ориентир, контрпримеры подбираются очень легко. Тут ещё нужно учесть разницу и в терминологии СМД-методологов с терминологией инженерных стандартов. То, что я называю "дисциплина" (из "практика=дисциплина+технологии") в СМД-методологии это "логика", а моя "технология" у экономистов будет очень близка к капиталу, а у СМД-методологов это специализация "логики" со средствами её овеществления в окружающем мире (подробней http://www.fondgp.ru/gp/biblio/rus/82/GP77d.doc, и учитываем многоуровневость в дисциплинарности). Слово же "практика" у методологов тоже означает совсем другое.
В любом случае я согласен, что "разделение труда" может онтологически противопоставляться "эксплуатации труда" и всяким другим ролевым рассмотрениям, а разделение (разбиение) работ -- нет, ибо про работы это не деятельностное-ролевое, а логистическое-ресурсное рассмотрение. Труд вполне может разделяться (по людям с их компетенциями) и организовываться (полномочия по разделению труда).
В принципе, аналогичное разделение пытались сделать в ArchiMate. Вначале там был класс Activity с подклассами Process как последовательность работ-шагов (логистика) и Function как работы, сгруппированные по иному признаку: A business function is defined as a behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences). Потом решили, что надкласс Activity будет лишним, и оставили только Process и Function -- для меня это про последовательности работ и разделение труда (http://pubs.opengroup.org/architecture/archimate2-doc/chap03.html#_Toc371945165).
Я не сторонник кибернетической парадигмы в системном подходе (в которой есть два основных концепта: концепт выделения в системе управляющего элемента и концепт обратной связи). СМД-методологи на базе этой кибернетической парадигмы вводят "управление" и "вертикальное разделение труда" (где управляющий элемент разделяет труды). Я же вижу, куда всё клонится: к каталлактикам, агентским сообществам, где разделение труда может быть не столько "управляемым", сколько "складывающимся" -- ибо на каждого "управляющего" есть свой "не хотящий управляться, а хотящий только координироваться".
Опять же, я не хотел бы влезать в невнятные и мутные разборки, кто там кем управляет в системах из людей и компьютеров. Ну, и "обратный манёвр Конвея" (http://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver) приводит к тому, что управлять организацией разработки начинает архитектура системы -- я хотел бы это как-то описывать без слова "управление" с одной стороны, а с другой стороны понимаю, что речь идёт и в этом случае как о разбиении работ (между ресурсами разработчиков), так и о разделении труда (между программистами и электронщиками, например).
Про работы нужно читать книжки про lean, kanban, TOC и т.д.. А вот про разделение труда и его неминуемость даже в знаниевых (беловоротничковых) профессиях для меня классикой является очень неожиданная книжка: The Checklist Manifesto -- http://ailev.livejournal.com/1029295.html.
В принципе, я в 2013 году писал довольно много про разделение труда, но тогда и сейчас меня волнует не столько его разделение (оно проходит "само собой", каталлактически -- хотя я легко могу представить людей, пытающихся разделить труд "планово"), сколько объединение. Попробуйте собрать труд из его осколков, разделённых по разным людям и компьютерам, чтобы получить потом скоординированные целостные работы по созданию какой-то успешной системы!
Поднял я эту тему в http://ailev.livejournal.com/1068772.html, потом обсуждал связь менеджмента, инженерии, науки, образования в http://ailev.livejournal.com/1069847.html, разводил объединение труда и объединение работ http://ailev.livejournal.com/1071172.html, эта тема была одной из важных на апрельской четвертой встрече Русского отделения INCOSE в Бекасово (http://ailev.livejournal.com/1072420.html), июльские мысли по терминологии разделения работ/разделения труда http://ailev.livejournal.com/1080678.html, миниатюра Райкина "Кто сшил костюм" (про низкоклассную команду из высококлассных специалистов) http://ailev.livejournal.com/1089503.html.