В конце концов, желание компаний можно понять: они хотят научить методам работы, которые у них приняты. Для этого нужно уметь описать этот метод. Метод (согласно стандарту Essence) -- это практики (главным образом дела с продуктами работы), которые ведут к изменению контролируемых в проекте абстрактных сущностей -- альф.
Это означает, что образовательные продукты по (ситуационному, конкретному используемому в компании) методу должны бы быть как-то связаны с описанием метода. Описали метод для данной технологии, сдизайнили курс, пошли обучать методу.
Фишка в том, что есть ещё и абстрактные сущности, которые существуют независимо от конкретных дел и их моделей -- все эти "требования", "стейкхолдеры", и даже та самая "технология". Ну, и деятельности типа "исследовать возможности" (explore possibilities). Этот набор абстрактных сущностей тоже описывает некий "абстрактный" (не привязанный к конкретной технологии, т.е. конкретным используемым инструментам и продуктам работы и выполняемым с этими инструментами делам по изменению продуктов работы) метод, "неситуативный метод", "обобщённый метод". Вот понимание этих абстрактных сущностей и есть образование. Образование сохраняется при смене инструментов и рабочих продуктов -- это те акценты внимания, которые у вас будут при любых используемых инструментах и рабочих продуктах. Если вы усвоили важность работы с "требованиями", то хоть формальные модели требований на SysML, хоть use cases, хоть user stories, хоть использование GRN -- вы не забудете про нужность работы с требованиями, а уж конкретным премудростям вас обучат на месте. Если не понимаете про абстрактную сущность "требования" -- то вам, необразованному, никакое повышение квалификации в конкретном методе работы с требованиями не поможет.
Итого:
-- софт для образования каким-то образом должен в себе описание набора сущностей (kernel какой-то дисциплины с расширениями для поддисциплин) метода, а для обучения ещё и описание практик (дел и продуктов работы, связанных с используемой технологией).
-- я думаю, что люди из мира учебного софта (образовательного, который "для университетов" и который покупают ректораты и деканаты, и обучающего, который покупают HR-службы предприятий) вообще о ситуационной инженерии методов не слышали. Они сегодня все думают в терминах scorm-пакетов (думайте в этом месте об использовании интерактивного-PowerPoint-на-стероидах, в котором никаких знаний о самом учебном предмете нет, а есть только знание об учебной форме).
-- про архитектуру предприятия (которая должна быть озабочена, чтобы все эти методы работы стыковались с бизнес-архитектурой, то бишь содействовали бизнесу, а также с архитектурой IT-решения, то бишь поддерживались софтом и инструментами) я тут вообще молчу.
Так что какая-нибудь "утренняя продувка" будет вышита крестиком минимум четырежды:
-- в архитектуре предприятия, чтобы понимать, какие софты её поддерживают (и это будет счастье, если кусок "бизнес-процессов" и регламентов работы не оторвут от этой архитектуры в какую нибудь "службу качества"),
-- в описании метода работы (ибо в какой-то момент менеджеры среднего звена вдруг начинают понимать, что им нужны для людей совсем не те описания, которые им предлагают делать на всяких изводах BPMN или даже ArchiMate люди из архитекторов, а документы "службы качества" хороши только для отчётности о взятых у работников интервью сотрудниками этой службы).
-- этих самых scorm-пакетах образовательных продуктов, которые будут жить где-то в районе HR-службы. Ибо людей-то учить нужно!
-- а теперь, когда всё описано, развёрнуто и обучено, мы со всем этим раздраем попытаемся метод исполнить: опишем его для этого, например, в трекере/планировщике системы adaptive case management (ну, или в виде шаблона проектного управления, или процесса в BPMS -- это уж кому как понравится).
Управление конфигурацией (то есть вопрос о том, будет ли совпадать "утренняя продувка", описанная в этих разных системах -- то есть нормативно описанная процедура, поддержанная софтом процедура, процедура, которой учат и процедура, которую реально исполняют) остаётся открытым.
Это и есть современное состояние корпоративных информационных технологий, сегодняшние "лучшие практики".
Мне не верится, что все эти софтины вдруг в ближайшие годы начнут обмениватья друг с другом знаниями о тех методах работы, которым одна софтина сотрудников учит, а другая тех же сотрудников на следующий день жучит за несоблюдение выученного в ходе трудовых будней. Это, конечно, не значит, что не нужно пытаться такое делать.
Возможные сценарии развития событий:
-- описание деятельности (текущая конфигурация деятельности) содержится где-то в одном месте, остальные софты его пользуют из этого одного места. Хорошего ничего не будет, ибо всем этим софтам нужно про деятельность знать совершенно разное.
-- софт business intelligence научится заглядывать в знания (то бишь повторно где-то используемую информацию) одной системы и другой системы, и предъявлять нестыковки в виде списка issue. Что-то типа сегодняшней системной инженерии, в которой модели склеиваются друг с другом исключительно для целей раннего (в компьютере, а не в жизни) обнаружения ошибок.
-- описание деятельности будет переползать из системы в систему, попутно обогащаясь содержанием и меняя формы: generative organization engineering, оно же model-based organization engineering. То есть одни модели деятельности, менее детальные, будут порождать (с использованием справочных данных и данных конфигурации) более детальные модели деятельности.
Не ждите, что напишу "жаль только - жить в эту пору прекрасную уж не придется - ни мне, ни тебе". Скорости изменений в айти пейзаже корпораций сейчас сильно недооцениваются. Технологический спурт в айти сейчас идёт, по всем моим ощущениям, не хуже, чем был в середине семидесятых.
Так что ждём-с появления управления конфигурацией не только оборудования, не только проектируемых и эксплуатируемых систем, но и управления конфигурацией методов работы. Мастер метод менеджмент, инженерия справочных методов и так далее, по всему списку.