DinamochatmDinamo,
я еще в 2004 году пытался получить какую нибудь пользу от UML в применении к 1С . Суть заключалась в выгрузке объектов конфигурации и модулей в виде классов, с наследованием (подчиненные справочники), указанием сложных типов в реквизитах и т.д. Получилось красиво, но не пригодно в практическом применении, так как выяснилось, что методологии разработки кардинально различные.
В основном методика разрабатывалась для "обратного проектирования".
В чем я вижу необходимость рисования диаграмм по "конфигурации".
Во первых диаграммы понятна аналитикам не знакомым 1С, но знакомым с UML. Что актуально при условии когда 1С лишь одна из систем используемых в компании (у нас их например не меньше 5, все на разных технологиях и разные команды разработки ими занимаются).
Во вторых во многих средствах существует возможность разработки других диаграмм ООАП (ERD, DFD и т.д.), диаграмм требований, бизнес процессов и т.д. Описав объекты на этих диаграммах, можно на диаграммах отражающих классы конфигурации отразить взаимосвязь, что дает понимание какие понятие предметной области какими классами в разных системах представлены. В этом случае репозиторий моделей и диаграмм в комплексе может описывать все аспекты предметной области и аспекты реализации в системах. То есть чтобы понять какая функциональность есть в системе достаточно подключится к хранилищу диаграмм, а не искать в документации по разным системам где-какие функции реализованы (все прекрасно знаний по системе передаются из уст в уста, а это определенные риски). Теоретически наличие моделей снижает риски ухода команды и затраты на переход на новые системы.
В третьих ну надо же мне было какую-то тему не особо хлопотную выбрать ;).

По поводу п.1 могу Вам только посочувствовать - если более 5 ERP систем одновременно - это редкий зоопарк.
По п.2 - здесь, как мне кажется, есть опасность наступить на те же грабли, что и я. 1С (что 7.Х, что 8.Х) не реляционная модель, как минимум. Аналитики, не знакомые с 1С, могут не учесть этот факт. То есть функционал 1С зарыт в коде (кодах модулей) и лично я затрудняюсь представить сколько нибудь наглядную схему хотя бы проведения документа "Реализация товаров и услуг" в UML с учетом массированного использования общих модулей.
п.3 - с учетом вышесказанного мне не кажется эта тема не особо хлопотной