Это ответ на комментарий к поему посту [Чем мне поможет построение онтологии моего предприятия]]. Ответ получился длинным, тянет на отдельный пост)
Очень интересная тема.
Мне кажется, практика на реальных проектах, это максимально быстрое обучение из-за обратной связи.
Вопрос, как это не превратить в описание без ориентации на результат.
Почему Вы выбрали начать описание со своего отдела?
Потому что это понятнее или есть проблема, которую нужно срочно решать?
Даже если ограничиться отделом, какая самая важная проблема в отделе? Как с помощью онтологии подойти к решению этой проблемы?
А что будет результатом по итогу месяца, недели, сегодняшнего дня.
Отличные вопросы вы задаете! Спасибо!
Согласен, на реальных проектах все гораздо быстрее. У меня только затык тут, чтобы сделать первый шаг. Кажется зачем мне прописывать онтологию и так все понятно. Хочется выбрать что-то маленькое для тренировки, но в суете будней не получается этот выбор сделать - все горит, все срочно, куча дел. Уже пришел к пониманию, что не все дела надо делать. Далеко не все из них горят, и если дело записать и просто сказать, что скоро или когда-нибудь оно будет сделано - то большинство удовлетворяются этим.
Я выбрал начать со своего отдела, потому что это то, что у меня под носом. То, что я лучше знаю. У меня тут работают рельсы от чтения курса системного мышления — пытаясь определить целевую систему начинаешь с того, что делаешь сам, пытаешься разобраться где ее надсистема, потом оказывается, что надсистема она вообще где-то далеко у какого-то там клиента, а то что делаю я - это система в обеспечении какой-то другой системы в обеспечении и так может быть несколько уровней вложенности.
Такие же мысли у меня и тут были, что, начав, описывать свой отдел - я так или иначе перейду на соседний отдел и доберусь до всего предприятия в целом.
Но пока не начал, разбираюсь с мощностями)
Какая самая важная проблема в отделе? Хороший вопрос. Наверное, это скорость работы. Точнее, скорость конвейера в целом. Отдел - это конвейер по выполнению каких-то задач которые в него попадают. Попадают задачи из определенных областей деятельности только, не все подряд. Эти области деятельности определенны, задачи по ним можно сортировать.
И моя задача - сделать скорость выполнения всех задач ровной и предсказуемой. То есть сделать так, чтобы мощностей конвейера хватало для обработки поступающих задач (учет мощности), сделать так, чтобы затык в конвейере быстро можно было обнаружить и устранить; и во время заметить нехватку мощностей конвейера и увеличить его ширину (нанять еще сотрудника) или разобраться в причинах увеличение входящего потока и что-то автоматизировать (заменить человека на машину).
Не уверен как тут онтология поможет, но на собранность - большие надежды 
Результатом по итогу должен стать пустой конвейер в конце рабочего дня - ни одной задачи в очереди.
А те задачи, которые не решаются за день - в соответствующем статусе: или бэклог с понятной датой выполнения, или блок с понятной причиной блокировки.
Задачи связаны с годовыми и квартальными целями, статус этих целей можно в любой момент времени проследить по статусам задач с ними связанных.
Простой результат простой менеджерской работы, как мне кажется)