Оргсистема предприятия и управление знаниями: заказчик, организатор, методолог, онтолог, программист

[ailev]

Предприятие (enterprise) -- это люди и оборудование/помещения с известным распределением полномочий и ответственностей

Comments

[ailev]

Методолог -- это технолог, он сосредоточен на собственно методе "в жизни". По сути, это "эксперт предметной области", который "знает как" (владеет know-how). Тут словом "методолог" я хочу подчеркнуть, что он высокорефлексивен -- то есть у него есть понимание того, что такое метод, и поэтому он может уделить равное внимание и продуктному его аспекту, и процессному, и используемым моделям с их языками и нотациями, и людям с их инструментами. Он "знает как" делать, он про глаголы.

Онтолог у меня тут -- модельер данных. Он знает, как записать знания в компьютерной форме, связав их с другими, ранее записанными знаниями, причем так, чтобы не нарушить целостность общей картины мира, отраженной в компьютере. По сути, это онтологический инженер, который отвечает за презентацию знаний (а за их репрезентацию отвечает программист).

В этом плане методолог работает с ситуациями и связанными с ними смыслами, онтолог -- со значениями, а программист -- с символами/данными.

от концептуального проектирования организации к сист

[sys_eng]

Не вижу причин, почему в системе документационного обеспечения предприятия (ГОСТ не-помню-какой-номер) не могут присутствовать такие документы, как

Re: от концептуального проектирования организации к си

[ailev]

Не любые описания сводятся к документарным. Так, "перечень целей предприятия" не эквивалентен стратегии (ибо в стратегии перечисляются не только цели, но и средства), а стратегия сейчас более распространена. Есть стандарты описания стратегий (типа OMG BMM, ITU URN, S&TT и т.д.). Процессы совершенно необязательно в BPMN, могут быть и другие группы описаний (типа описаний жизненного цикла, или диаграмм DEMO).

Я довольно много постингов писал, что не всё так просто, и организация не сводится к суперпозиции процессов и органиграммы. Разделение на "основные процессы" и "вспомогательные" я не понимаю (мне больше нравится нахождение ограничений, для этого процессы нужно представлять как материальные/денежные потоки).

Так что я бы воздержался от именно такого курса.

[ext_1010322]

А как view - это может поддерживаться? В вашем разделении акторов на классы по шкале "вовлеченности" всё равно будут "голубые воротнички", которые будут читать "инструкцию", глядеть "ППР", и выполнять технологическую карту. Для них генерировать (рендерить) эти "текстовые документы" из МОДЕЛИ - святое дело.

Тут я, конечно, поменял тезис. Согласен, что простой текст не является инструментом системной инженерии. Ну так и инструментом обычной "организационной работы" он тоже уже давно не является; позади любого "регламента" живет "картина мира этой фирмы" и "логика процесса", в голове у писАтеля.

[ailev]

Сейчас появился Архимейт версии второй, тамошние расширения прямо касаются темы данной дискуссии -- там и цели-средства, и собственно "организовывание" (проекты воплощения архитектуры) против деятельности (процессы самой работы целевого предприятия) добавлены -- http://ailev.livejournal.com/978200.html